PEAP authentication for domain & non-domain computers
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 126.96.36.199 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.
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.
Thank you for your reply. We currently have two network policies that filter on the "called-station-id" as you've suggested and we're using two different AD security groups to control who can access to each wireless network but the issue is consistent across both SSIDs.
I did some preliminary reading on the ISE as you suggested and from what I gather it is basically a man-in-the-middle server that could forward RADIUS requests to a Domain Controller (aside from the additional features). So I think from the perspective of the user, their computer's involvement will reach as far as the ISE and then it has the responsibility of validating the radius attempts to the DC. How does the ISE behave when a domain/non-domain laptop attempts to connect to the wireless network that's configured with WPA2-Enterprise EAP 802.1x?
So ultimately I believe our Wireless infrastructure is going to change. We will have three SSIDs: 1 for the employees, 1 for the mobile devices (that could otherwise use 4G), and 1 for visitors.
SSID: Employee will use WPA2 802.1x PEAP against the ISE.
SSID: EmployeeMobile will use WPA2 802.1x PEAP against the ISE.
SSID Guest will use web-authentication against local authentication on the WLC.
One last question, ultimately I want to have an automatic method of changing the password for the guest wireless account as we currently do despite the fact the computers wireless supplicant is behaving weird. Your thoughts?
The challenge is with non-domain devices and configuring their supplicants to correctly authenticate to your RADIUS server. Issue is with the client device not RADIUS whether that is ISE, NPS FreeRADIUS.
ISE integrates directly into your AD environment and has additional capabilities over and beyond base RADIUS. You will still be able to auth to AD with client machine or user accounts. The one feature that might assist with your non-domain Windows clients would be Native Supplicant Provisioning. This is a mechanism where ISE can configure the Windows supplicant for wireless 802.1X connectivity.
You could have a policy on your Guest WLAN with central WebAuth to ISE, where if domain credentials are used (or credentials from certain domain groups) on the portal it kicks of the native supplicant provisioning process where the WLAN Profile for the non-domain employee device is configured correctly on the client laptop. The employee can then remove the guest WLAN from their device and will automatically connect to Employee WLAN provisioned by ISE.
With Central Web Authentication you can also keep your current domain based guest account for access to the guest portal or switch over to the sponsored guest access mechanism in ISE. The NSP process would also allow you to restrict how many devices are per user can be used on your network. Unfortunately it is a global setting that maxes out at 5.
This approach would eliminate the challenges around supplicant configuration, as nothing it is not required to connect to an open SSID and with the right credentials ISE will take care of the rest. If you are using public certificates on the ISE nodes there won’t be any security challenges from the portal either.
The only caveat would be that the users of the non-domain windows laptops should have admin rights on their laptop as the mechanism ISE uses to configure the supplicant is via Active X, so depending on the security settings in IE, they may need to adjust them. Usually they will be prompted by the browser.
Thank you for your time and effort. You've been a tremendous help and a solid resource for me as I could not find any solid information anywhere on the web. So with your explanation I understand the purpose of the ISE in that it will control the behavior of the Windows wireless supplicant when the user attempts to connect. So would the ISE become the "radius server" from the perspective of the SSID & WLC?
Am I on the correct path? I will configure the employee SSID with WPA-2 802.1x and reference the ISE as a radius server. Then I will reference the DC as a radius server within the ISE.
In regards to the mobile SSID, it'll behave the same way and as far as the guest web-authentication I'll reference the ISE's guest account or utilize local authentication on the controller.
What are you thoughts on the configuration of this?
No worries, you are on the right track. ISE is a RADIUS server. It will replace NPS for RADIUS AAA server functionality. ISE integrates directly to AD – It will join the AD domain and interface via service account (user object) and AD machine object.
For your WLAN profile configuration could be something like:
Employee SSID = WPA2 +802.1X / RADIUS ISE – ISE Policy = Domain User or Doman machine auth = permit access
MobileDevice SSID WPA2+8802.1X / RADIUS = ISE, ISE Policy = Domain User
Guest SSID OPEN +MAC Authentication (MAB) + NAC State =RADIUS / RADIUS =ISE ISE Guest Flow Policy 1 – If Domain Group (group that AD Guest account is a member of ) = permit access.
ISE Guest Flow Policy 2 – If other AD User (or non-domain grp user) = start NSP – (configure supplicant for access to Employee SSID).
We are moving! Please use WLCCA Forum for updates and discussions
[toc:faq] Wireless LAN Controller (WLC) Config Analyzer Download Click
here to Download To request access, send an e-mail to
firstname.lastname@example.org. Please include your Cisco.com userna...
[toc:faq] IntroductionHere is the step by step process that we have to
take care of while converting LWAPP to IOS and then vice versa..LWAPP to
IOSThe hardware used = 1141 AP (make sure we are using the right
[toc:faq] Introduction AnyConnect Secure Mobility Client 3.0: Network
Access Manager & Profile Editor on Windows Summary Use the Cisco
AnyConnect Network Access Manager Profile Editor to build custom
profiles for the AnyConnect Secure Mobility Client. App...