PEAP authentication for domain & non-domain computers

Question

Hello Everyone,
Some of our users have laptops that are not in the domain and are unable to connect to the wireless network. Although their computers aren't in the domain, the users do have an AD account and are currently a part of the security group attached to the Wireless NPS policy. The only remedy I have for this problem is to manually add the SSID to their computer which defeats the purpose of this wireless network. The ultimate goal is to allow the user to connect to the wireless network by entering their domain credentials and moving on.
We have a WLC 2504 running 7.4.110.0 with 15 1602i APs. The SSID is configured to pass 802.1x EAP authentication to NPS running on windows 2008 R2. With mobile phones and tablets, the authentication is successful without a hitch so I don't understand why a non-domain computer is unable to connect without manually entering the SSID. In the WLC log, I will see entries such as:
"AAA Authentication Failure for UserName:host/LastNameFirstInitial-LT.mydomain.Local User Type: WLAN USER".
By examining this log entry, to me it says the domain profile on the computer is being sent to the NPS for authentication instead of the username and password. We have a  3rd party SSL certificate installed on the NPS server. 
Taking it one step further - We have a second SSID for guest users that is configured with the same setup except that the NPS is configured to accept authentication attempts from a single AD user called "mydomain\guest". We decided on this approach for the guest wireless network so that we can rotate the password automatically every week with a vbscript that manipulates the password via LDAP. Users with laptops in different domains are unable to connect to the guest wireless network and I'm starting to think the machine authentication is a problem. 
Any suggestions would be greatly appreciated.
Thanks,
Ali.

Answer 1

Hi Ali,
That’s all part of the wonderful world of wireless on Windows.
When a connection to a WLAN is made on a windows machine, by selecting it from available Wireless Networks list (Passive RF Scan), and Windows as parsed the 802.11 AP Beacon to contain the WPA2, 802.1X element, by default it will attempt to connect with known or active session credentials.
Typically it will be Machine account (they all have them whether on a Domain or not) and then /Or User. This order and preference may change depending on version of Windows (Vista to Windows 8) and service pack level.
Regardless the only thing you can count of for sure is that the first authentication attempt from a windows client will not involve the user entering information. Once the first attempt fails the Windows supplicant will prompt the user for login information via a notification in the system tray, which may or may be noticed by the user. May or may not stay for more than 5 seconds.
Windows XP and Vista were the worst for this. Windows 7 and Windows 8 this process and recovery and user prompt mechanism is greatly improved but not infallible.
The only way to avoid this would be to manually configure the WLAN profile on the windows machine as you are currently doing.
Mobile phones and tablets don’t have this issue as they don’t have issue because software coding in their supplicants. Besides the only “system” credentials on iOS or Android phone are typically your Play Store and App Store accounts, and both vendors know those won’t be accepted for network access by default anywhere.
There isn’t an easy way to support non-domain windows systems on a domain integrated one.
You might want to try adding another SSID.
You could have a corporate SSID, Guest Portal and a third that is PSK + Guest Portal. ON NPS you could filter for RADIUS attribute called-station-id (includes SSID) to allow all domain ID’s access instead of the just that WLAN.
Or you could look at swapping out NPS for a Cisco ISE VM/appliance with the new Plus licenses add lower cost for onboarding devices and Windows XP and up are supported for supplicant configuration via ISE.