Security

Hello,

Our environment consists of two Mobility Controllers (7205) which up until recently had both been running AOS 6.5.4.7 (FIPS) in conjunction with ClearPass 6.8.x. 

Recently we split the controllers and upgraded one of them to 8.4.0.2 (FIPS) and associated it with a Mobility Master VM. We then upgraded all of our APs and associated/terminated them with the upgraded (8.4.0.2) 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 (8.4.0.2) 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,

- Steve

Honestly, you should be able to use the basic "user or computer" authentication options.  Boot to the ctrl-alt-delete prompt and make sure that your device is being machine authenticated first.  If that is not happening, check for failures.  That is all that you honestly should need.

With that being said, it is not a good idea to switch VLANs when the user logs into the computer, because you break communications with the domain during the login.  Make sure the VLAN is uniform for both authentications and just try the "user and computer" option.

Thanks for reading through the lengthy post and for the reply cjoseph!  Device is being machine authenticated at the Ctrl-Alt-Del screen, both machine and user authentication do in fact work if I use just the basic options for "User Or Computer Authentication" in my Group Policy, both with 6.5 and 8.4 controller firmwares.

Even if the user doesn't switch VLANs (machine and authenticated user utilize the same VLAN) it seems like the connection is still dropped during login as the machine performs the 802.1x re-authentication and ClearPass authenticates the user and assigns the role.  The drop is what seems to cause errors / issues with the login scripts, as it is breaking communication with the Domain Controller(s) as you said. 

We're using the same Group Policies and same ClearPass logic with 8.4 as we were with 6.5.  It just seems like there is a slightly longer delay in changing from machine to user authentication now that we've gone to 8.4 and it is causing the logon script issues.

I've checked to ensure that our Mobility Master VM and both ClearPass VMs meet the recommended system requirements (C1000V).  Is there anything you're aware of in Mobility Master, 8.x or ClearPass that should be adjusted or optimized to transition between authentication types more quickly?  We've been holding out upgrading our second controller to 8.x until we can get this sorted out.

Thanks,

Steve

I am not aware of anything that has changed.

Are you restricting any traffic in either the user or machine role on the Aruba Controller?  Try them with noting blocked, and not switching VLANs to make the bar as low as possible.  That should absolutely work, because there is no disconnect when the user finally authenticates, unless the VLAN changes or the ACL on the user role becomes more restrictive.

You could be running into a timing issue due to the restrictions.  Try to lower the bar until you can get it to work.

I did come across that the 802.1x authentication profile associated with the AAA profile being used had the default machine and user roles for Machine Authentcation set to "guest" on the 8.x side where on the 6.x side it had been set to "authenticated" (which is less restrictive).  Changing this didn't seem to make a difference in the issue.  

Another test that was run was setting the default VLAN on the VAP we were connecting to, to be the same as the user VLAN.  Login scripts seemed to still have a little delay but we didn't encounter any errors.  However, this still didn't address scenarios where the machine/user VLAN was switched.

Not the most ideal solution but for now we've setup our login script to pause for 20 seconds if the user is on WiFi.  This allows client, ClearPass, controller etc. to process and complete VLAN switch and all logic in the script to then run without error over WiFi.

The quick responses and ideas are much appreciated!  We still have a case open with TAC on this, if any new developments or resolutions come up I'll post back and share!

Continued to work with TAC on this but couldn't find any further potential causes of our issue.  We rolled the controller and Mobility Master firmware back from the 8.4.0.x release to the most recent Conservative Release (8.2.2.5) and we no longer experience any issues with our login scripts during a VLAN change (switch from Machine Auth to User Auth).

Hopefully, this helps anyone else who may have encountered this or similar.  Thanks to all who responded!

Hi Stevepo,

I am also facing this similar issue. I am using AOS 8.5.0.2. Since we deployed AP-515 on campus that AP's driver only compatible with AOS 8.5.0.X, so downgrading to conservative version isn't an option.

Our end customer computer only switch from machine user role to staff user role with the same IP address not changing neither VLAN nor subnet.

The machine user role now configured to allow all except icmp ping for testing.

After Ctrl+Alt+Del prompt to Window log on screen, we unable to ping this computer by testing policy. Then after log on to window desktop, there is some delay before we ping to this computer successful. But  then we lost about 3 ping the window wifi icon show disconnected. The computer then switch it back online that's when logon script was failed sometime.