Higher Education

So we machine authentication working like a champ. The PC sits there on the dot1x (PEAP) secure wireless waiting from someone to login. If it's a student, then by virtue of the Almighty ClearPass (All hail) they get the Student Role on the Student VLAN and they rock -n- roll right along. If they are and Admin (i.e. staff/faculty) then once again by the power of ClearPass (All hail) they are granted an Admin Role, moved to an Admin VLAN and again, all is good in the Universe...

 

Mostly...

 

So when a device is machine authenticated, it sits on what we deem a student VLAN for security purposes. What we have been seeing is that sometimes (sometimes meaning often enough that its a problem but intermittent enough that its hard to try to get PCAPs because when you try you can't seem to reproduce the problem...) when an Admin logs in, the Role changes, VLAN changes as per the Role but they do not get the new IP address. It seems to hang on to the old one for some reason.

 

Now, my question is, have any of you seen this and if so could you pass along some details / possible solutions?

 

EDIT - for the record, DHCP is being supplied by an AD DC set up specifically to service the wireless and nothing else. This AD DC is the DHCP, DNS and is also the LDAP server for ClearPass.

Microsoft DHCP?

You are running into the almighty client issue. You will need to put a short dhcp lease on that initial vLan. It's a common issue where clients will hold onto the ip until the lease timer comes up.

Oh!? Could it truly be that simple of an issue!? What wouldst thou recommend for thine shortened lease time?

I believe microft has a min of 30 sec. What I have seen most customers use is either use a completely separate clan for all and have the shortest lease they can or you can set your initial role to put the devices in the proper clan off the bat with a firewall rule blocking all but esintials until the user auth. That way they don't have to get a new ip. It all comes down to if you can distinguish staff from students in the machine auth.

Omg. Auto correct loves vlan :)

 

Check the DHCP server logs to ensure that the device is not obtaining a DHCP lease from the *student* vlan during the switch to the eventual vlan.  If it is you need to tighten up your pre-auth/default policies because you are leaking traffic for a very short time window onto the student vlan after the reset.  For WIFi Microsoft has always errored on the side of always doing a DHCP transaction on any link state change (even OKC roams which is a bit dubious.)

 

If you have a similar problem on wired MAS switches, the same applies and also check out the new Aruba-Port-Bounce-Host attribute in MAS ArubaOS 7.4.0.3 to jiggle the handle on the DHCP client.

 

I finally seem to have this working properly and here is how it went down:

 

I ended up creating three VLANs for specific ClearPass roles (the numbers have been changed to protect the innocent)

 

- VLAN 100 for Admin/Staff users AKA Admin role

- VLAN 200 for machine authentication (i.e. school owned laptops and wireless desktops sit idle on this VLAN when no one is logged into the machine) AKA Machine Auth role

- VLAN 300 for student users AKA Student role

 

I dropped the DHCP lease time on VLAN 200 down to the AD minimum of 60 seconds based on some of the replies and other posts that I have read. Even at this point I was still having problems. Some students could login fine, others couldn't, some admin users could login fine and others couldn't. It was very strange. So I spent some time talking with our server team, the AD guys in particular and discovered that apparently some user accounts process faster than others. I am not an AD guy so I had no clue about this. This was the big revelation that sent me down the right path. I went back and took a look at our dot1x settings on the clients:

So after looking at this a little farther I had a hunch that since I had ClearPass authenticating first and THEN AD would authenticate the user on the box that it was a timing issue. So some accounts would take longer to process via ClearPass to get their role, so it would still be processing when the user box would try its AD authentication and since it was still in transition getting its role and VLAN and new IP, it couldn't find the AD server to authenticate the user to the box. You guys following me so far? I get fairly confused myself sometimes LOL.

 

That being said, I reversed the settings so it would allow the machines to authenticate via AD first then let ClearPass do its thing and set the roles. By default, there is a few seconds delay between authentication pieces so no more stepping on one another!:

This reversal step seems to have cleared up almost all of my login authentication issues. The few issues that remain tend to be ID 10 T errors...