05-10-2019 02:02 PM
Our environment consists of two Mobility Controllers (7205) which up until recently had both been running AOS 220.127.116.11 (FIPS) in conjunction with ClearPass 6.8.x.
Recently we split the controllers and upgraded one of them to 18.104.22.168 (FIPS) and associated it with a Mobility Master VM. We then upgraded all of our APs and associated/terminated them with the upgraded (22.214.171.124) controller.
Our Windows clients authenticate via 802.1x to ClearPass and have a wireless (802.11) profile which is pushed to them via Group Policy. In this policy we are using WPA2 / PEAP with an authentication mode of "User or Computer". This allows for a machine to boot to the login screen, use computer/machine authentication, pass "host/machinename.domain" as a username and authenticate to the network into a particular VLAN and subnet (ex. 10.20.1.x). When the user logs in with their domain credentials they are then re-authenticated after login via ClearPass and placed in a different VLAN and subnet based on ClearPass enforcement policy (ex. 10.30.1.x).
When connected to an AP terminated on the 6.5 controller users are able to login and this whole process including login scripts (drive mappings, printer mappings, etc.) run without issue. If we take that same machine
and connect to an AP terminated on the 8.4.x controller users can still login, the process works, however it seems to take longer as our login scripts (drive mappings, printer mappings, etc.) sometimes fail or hang at various points (at the same time these hangs / errors occur we can see the user authentication entries in Access Tracker). Aside from this we haven't encountered any other issues in operations utilizing devices connected to the APs terminated on the upgraded (126.96.36.199) controller.
I've set the "Authentication Mode" in the wireless profile Group Policy to "User authentication" and in the "Advanced" options enabled "Single Sign On" for "Perform Immediately before User Logon", the user connects to WiFi immediately upon login and there are no issues with logon scripts, however the machine does not authenticate at the login screen any longer. If I set the "Authentication Mode" to "Computer authentication" the machine authenticates at/prior to the login screen, but the VLAN/subnet no longer changes when the user logs in with their AD credentials. If I set the "Authentication Mode" to "User or Computer" and do not enable Single Sign On in the "Advanced" settings I run into the issue described where the machine authenticates at login screen, user logs in, logon scripts run, but around this same time the user re-authenticates via ClearPass, the connection is dropped momentarily and the connection drop causes logon scripts, etc. to fail.
As an attempt to work around this I've set the "Authentication Mode" as "User or Computer" and enabled "Single Sign On" in the wireless profile pushed by Group Policy and set it to "Perform Immediately before User Logon". The computer authenticates at the login screen with no issue, but when I log in as a user Windows says "Connecting to SSID" then "Unable to connect to SSID. Logging in...". Once it fails the machine continues to login and I see in Access Tracker that the machine passes credentials of "host/machinename.domain" and reconnects, logon scripts begin to run, then the user's credentials are passed to ClearPass and the user successfully authenticates and is put into the proper VLAN/subnet (however, this sometimes causes issues with logon scripts as I had mentioned).
In the Event Viewer of the client workstation I can see in the WLAN-AutoConfig logs that the machine is successfully connecting with machine credentials (host/machinename.domain), it then does attempt to retry 802.1x authentication when user credentials are entered but fails
with "Reason: The authenticator is no longer present" followed by "WLAN AutoConfig service failed to connect to a wireless network" with "Failure Reason: Failed for an unknown reason." The issue(s) occur whether I have the "This network uses different VLAN for authentication with machine and user credentials" checked or unchecked in the Single Sign On settings of the Group Policy.
It appears that 802.1x re-authentication as the user is trying to occur but it is failing. If I turn airplane mode on/off at the login screen (after the machine has authenticated/connected) and then login with the user credentials, the (pre-logon) user authentication works without an issue. At the same time I see these messages/errors in Event Viewer I am not seeing anything in Access Tracker.
I've put in a case with TAC and spent a number of hours working with them regarding the login issue (delay) that began after the upgrade, the case was escalated and I have not heard back yet. Based on what I've read in the forums here it seems like VLAN/subnet switching at login is not recommended, although it did work for us without issue in the past (using the 6.5.x firmware[s]). My thought is that enabling Single Sign On would be a more proper way to implement what we are looking for (or had been doing). I've been unable to find much information regarding those aforementioned error messages in the WLAN AutoConfig logs. I was wondering if anyone is aware of any adjustments I need to make either on my Controller, ClearPass, and/or Group Policy settings
to allow this to work as desired?
Thanks for reading,
Solved! Go to Solution.