Earlier today we started to tighten up one of our wireless networks, moving from PEAP to EAP-TLS authentication. In testing on 10.9.x & win7 clients, all worked well. But when deploying the same config profile that connected the 10.9.x clients to a 10.8.x Mac, the device failed to authenticate.
The 10.8.x clients console log didn’t show much information, so I took a look on the NPS servers logs (which are not a pretty sight) & after a time we came to a solution.
See below for the gory details.
Contents
Digging in
Our NPS server is a w2k8 server, as such the logs can most often be found in C:\Windows\System32\LogFiles (for more information configuring these logs, please click here).
For each connection request you’ll see two entries, (NOTE: We changed our log files properties format “DTS” as the xml format is the easiest for me to read). The top entry being the log of the “Connection Request Policies” the other, the “Network Policies.”
<Event><Timestamp data_type="4">05/19/2014 15:21:44.008</Timestamp><Computer-Name data_type="1">NPSServer</Computer-Name><Event-Source data_type="1">IAS</Event-Source><User-Name data_type="1">ComputerName.domain.com</User-Name><Calling-Station-Id data_type="1">f8-1e-df-e8-84-5a</Calling-Station-Id><Called-Station-Id data_type="1">00-3a-98-9c-aa-70:Internal Test network</Called-Station-Id><NAS-Port data_type="0">1</NAS-Port><NAS-IP-Address data_type="3">10.255.100.1</NAS-IP-Address><NAS-Identifier data_type="1">WLANCON</NAS-Identifier><Vendor-Specific data_type="2">0000376301060000000F</Vendor-Specific><Service-Type data_type="0">2</Service-Type><Framed-MTU data_type="0">1300</Framed-MTU><NAS-Port-Type data_type="0">19</NAS-Port-Type><Tunnel-Type data_type="0">13</Tunnel-Type><Tunnel-Medium-Type data_type="0">6</Tunnel-Medium-Type><Tunnel-Pvt-Group-ID data_type="1">110</Tunnel-Pvt-Group-ID><Client-IP-Address data_type="3">10.255.100.1</Client-IP-Address><Client-Vendor data_type="0">0</Client-Vendor><Client-Friendly-Name data_type="1">WLANCON</Client-Friendly-Name><Cisco-AV-Pair data_type="1">audit-session-id=0aff64010001f864537a1279</Cisco-AV-Pair><Proxy-Policy-Name data_type="1">Secure Wireless Connections</Proxy-Policy-Name><Provider-Type data_type="0">1</Provider-Type><SAM-Account-Name data_type="1">DOMAIN\ComputerName.domain.com</SAM-Account-Name><Fully-Qualifed-User-Name data_type="1">DOMAIN\ComputerName.domain.com</Fully-Qualifed-User-Name><Class data_type="1">311 1 10.1.2.42 05/16/2014 02:17:48 1307</Class><Authentication-Type data_type="0">5</Authentication-Type><Packet-Type data_type="0">1</Packet-Type><Reason-Code data_type="0">0</Reason-Code></Event> <Event><Timestamp data_type="4">05/19/2014 15:21:44.008</Timestamp><Computer-Name data_type="1">NPSServer</Computer-Name><Event-Source data_type="1">IAS</Event-Source><Class data_type="1">311 1 10.1.2.42 05/16/2014 02:17:48 1307</Class><Authentication-Type data_type="0">5</Authentication-Type><Fully-Qualifed-User-Name data_type="1">DOMAIN\ComputerName.domain.com</Fully-Qualifed-User-Name><SAM-Account-Name data_type="1">DOMAIN\ComputerName.domain.com</SAM-Account-Name><Provider-Type data_type="0">1</Provider-Type><Proxy-Policy-Name data_type="1">Secure Wireless Connections</Proxy-Policy-Name><Client-Friendly-Name data_type="1">WLANCON</Client-Friendly-Name><Client-Vendor data_type="0">0</Client-Vendor><Client-IP-Address data_type="3">10.255.100.1</Client-IP-Address><Packet-Type data_type="0">3</Packet-Type><Reason-Code data_type="0">8</Reason-Code></Event> <Event><Timestamp data_type="4">05/19/2014 15:36:50.977</Timestamp><Computer-Name data_type="1">NPSServer</Computer-Name><Event-Source data_type="1">IAS</Event-Source><User-Name data_type="1">ComputerName$</User-Name><Calling-Station-Id data_type="1">b8-e8-56-36-b6-58</Calling-Station-Id><Called-Station-Id data_type="1">00-3a-98-9c-aa-70:Internal Test network</Called-Station-Id><NAS-Port data_type="0">1</NAS-Port><NAS-IP-Address data_type="3">10.255.100.1</NAS-IP-Address><NAS-Identifier data_type="1">WLANCON</NAS-Identifier><Vendor-Specific data_type="2">0000376301060000000F</Vendor-Specific><Service-Type data_type="0">2</Service-Type><Framed-MTU data_type="0">1300</Framed-MTU><NAS-Port-Type data_type="0">19</NAS-Port-Type><Tunnel-Type data_type="0">13</Tunnel-Type><Tunnel-Medium-Type data_type="0">6</Tunnel-Medium-Type><Tunnel-Pvt-Group-ID data_type="1">110</Tunnel-Pvt-Group-ID><Client-IP-Address data_type="3">10.255.100.1</Client-IP-Address><Client-Vendor data_type="0">0</Client-Vendor><Client-Friendly-Name data_type="1">WLANCON</Client-Friendly-Name><Cisco-AV-Pair data_type="1">audit-session-id=0aff64010001f8e5537a1704</Cisco-AV-Pair><Proxy-Policy-Name data_type="1">Secure Wireless Connections</Proxy-Policy-Name><Provider-Type data_type="0">1</Provider-Type><SAM-Account-Name data_type="1">DOMAIN\ComputerName$</SAM-Account-Name><Fully-Qualifed-User-Name data_type="1">DOMAIN\ComputerName$</Fully-Qualifed-User-Name><Class data_type="1">311 1 10.1.2.42 05/16/2014 02:17:48 1389</Class><Authentication-Type data_type="0">5</Authentication-Type><NP-Policy-Name data_type="1">Secure Wireless Connections</NP-Policy-Name><Quarantine-Update-Non-Compliant data_type="0">1</Quarantine-Update-Non-Compliant><Packet-Type data_type="0">1</Packet-Type><Reason-Code data_type="0">0</Reason-Code></Event> <Event><Timestamp data_type="4">05/19/2014 15:36:50.977</Timestamp><Computer-Name data_type="1">NPSServer</Computer-Name><Event-Source data_type="1">IAS</Event-Source><Class data_type="1">311 1 10.1.2.42 05/16/2014 02:17:48 1389</Class><Session-Timeout data_type="0">30</Session-Timeout><Quarantine-Update-Non-Compliant data_type="0">1</Quarantine-Update-Non-Compliant><NP-Policy-Name data_type="1">Secure Wireless Connections</NP-Policy-Name><Authentication-Type data_type="0">5</Authentication-Type><Client-IP-Address data_type="3">10.255.100.1</Client-IP-Address><Client-Vendor data_type="0">0</Client-Vendor><Client-Friendly-Name data_type="1">WLANCON</Client-Friendly-Name><Proxy-Policy-Name data_type="1">Secure Wireless Connections</Proxy-Policy-Name><Provider-Type data_type="0">1</Provider-Type><SAM-Account-Name data_type="1">DOMAIN\ComputerName$</SAM-Account-Name><Fully-Qualifed-User-Name data_type="1">DOMAIN\ComputerName$</Fully-Qualifed-User-Name><Packet-Type data_type="0">11</Packet-Type><Reason-Code data_type="0">0</Reason-Code></Event>
Each event holds quite a lot of detail, (luckily Microsoft have a TechNet article on how to interpret the logs here).
So in deciphering the logs, we found that the 10.8.x clients were failing with:
<Reason-Code data_type="0">8</Reason-Code>
This yet again lead us to another TechNet article, which advised the following:
The user account that is specified in the User-Name attribute of the RADIUS message does not exist.
The 10.8.x Mac was bound to the domain & have a valid cert using the Machine template, so the message struck us as being a bit odd. But as the reason code description mentioned “User-Name” attribute we searched the logs for this value.
In each of the logs we found the “User-Name” attribute, below are examples:
10.8.x client:
<User-Name data_type="1">ComputerName.domain.com</User-Name>
10.9.x & win7 clients:
<User-Name data_type="1">ComputerName$</User-Name>
So it appears that the 10.8.x clients are passing to “User-Name” their FQDN name, as this value. This “User-Name” corresponds with the AD Computer Objects RecordName attribute. If you have a look at this attribute (such as by using Directory Utility), you’ll see that it’s value is in the same format as the attributes passed to the “User-Name” attribute to NPS by 10.9.x & win7 clients.
This now makes sense of the earlier error description.
Workaround
But how to correct this behaviour?
I played around with separate profiles for the 10.8.x clients, but stumbled across something that the NPS can do itself. Enter “Connection request policies” & it’s option: “Attribute Manipulation.” (This can be found under the “Connection request policies” > Settings > Attributes).
This enables you to take the value of the “User-Name” attribute & manipulate the text string.
We entered the below, after which the resulting connections requests “User-Name” attribute from 10.8.x clients was correctly formatted.
This has been submitted to Apple under the ID: 16964003.
Excellent article, used it to fix a similar situation with NPS on 2012 R2 and MacOS
Awesome!