Windows 7 Slow Login / delayed user authentication issue connecting to wireless via ACS 5.8

[N3t W0rK3r]

Just setting up a new ACS 5.8 server farm (only 2 servers) here and having difficulties which I am hoping someone here can shed light on.

The new ACS server is set up to correctly authenticate network device administration and I am now working on setting up authentication profiles for our wireless users and corporate laptops.

Being new to this version of ACS (we're migrating manually from ACS 4) I followed a great example of this task outlined in a video on this site: http://www.labminutes.com/sec0044_ise_1_1_wireless_dot1x_machine_auth_peap

I have been successful in having a Windows XP sp3 client authenticate properly, first with machine authentication and then user authentication... and domain login process takes place in a short period of time < 1min and the user gets all their networked drives via the domain login script.

However, I am struggling to get our Windows 7 clients to authenticate properly.  It seems that machine authentication is working as expected (I can ping the test laptop from another machine on the network while the test machine is sitting at the login screen; and I see the host authentication recorded in the ACS Radius authentication logs).  But, when a domain user logs in with his/her credentials, the login process takes 4-5 minutes before a user authentication event is recorded on the ACS Radius authentication log, after which point the login process completes, except that the domain login script does not run and the user does not get their drive mappings.

Can anyone point me in the right direction here?  I'd appreciate any and all input on this.

Thanks in advance,

John

[chatataridge · Accepted solution]

I was having a similar issue with Wireless 802.1x Win 7 clients not able to login unless they had cached AD credentials.  The machine would authenticate but the user would take a long time if the Windows credentials were cached.

I was able to solve the issue by expanding the Airspace ACL used during the user Authentication to include all the DC's in the environment.  

[N3t W0rK3r]

Thank you very much... I will give that a try. There are other DCs in our Forest that I didn't include in the ACLs because I didn't think we'd be querying them for our particular domain... but who knows. :)

Question for you... do you have any idea how/where to view ACL hits or traffic being denied by these named ACLs?  Do I look on the WLC or on the ACS?  On a router, it's easy... in this environment, not so much.

John

[N3t W0rK3r]

Thanks again...

I had to create a new ACL rule to allow access to an entire subnet where I had been previously using only host-based rules, guessing at what servers needed to be accessed.

Cheers,

John

[chatataridge]

On the page where all the ACL's are listed, check the box " Enable Counters ".  Good to be of help..

[N3t W0rK3r]

I have one more question for you... hopefully you, or someone else can add insight.

Now that I have this login process working properly, I tried to add dynamic vlan mapping to the scenario, based on user name.  We have this running properly on our old ACS, however when I added those extra radius attributes to the authorization profile, the login process took longer again, and some drives didn't get mapped, BUT the vlan did get mapped properly.

In speaking with our domain admins, our domain includes additional services like DFS, and it was those IPs that were missing from my ACLs originally, I guess.  But now, I'm not sure whats happening.

What I do know, is when the machine boots and sits at the login prompt, machine authentication has taken place and the laptop gets an IP address on the default subnet.  After login, however, that's where the IP address changes (due to dynamic vlan mappping config on ACS) and I have a feeling that's where things get broken.  I wonder if some services needed to complete the login process were first contacted when then laptop had the default address, but then those connections are torn down when the IP address changes?

The other observation I wanted to mention is that this problem seems to only occur when the laptop is booted up from off (or restarted).  If I log off and then on again, the process works properly, which I don't understand at all... since when I log off, the laptop is put back on the default vlan.

Thanks in advance.

John

[chatataridge]

What are the log showing in ACS?  

When you look at the client session in the WLC what do you see?  

Has the CoA been pushed down and the client redirected to the " new "  interface on the WLC and the DHCP release and renew properly?  

Once logged into the device can you manually map the missing drives?

On the DC's in event viewer can you see the authentication session and profile being pushed to the client? I suspect you will see a time out as the DC is looking to the old address.

You could do a wireshark capture on the WLC interface to watch the conversation with ACS and the MS resources.

These are my best guess if i were troubleshooting the issue you are experiencing.  Hope this helps

[N3t W0rK3r]

Thanks for reply and questions.

I've really only looked at the AAA Radius authentication logs on the ACS, and they show successful machine and user authentication with the correct authorization profile being applied.  Is there something else I should look for here?

I have not looked at the WLC for the client session, but will try next time and see.

I believe the CoA has been pushed properly as the client does get an address on the new vlan and then gets an address on the default vlan when the user is logged out.  Is this what you mean?

I haven't tried to manually map the missing drives, but can easily try that.  I suspect I will be able to.  If I were to log off and then on again, everything would work fine.  Problem seems to only occur when the laptop is first booted up or restarted.

I have done a wireshark on the WLC interface back when I was troubleshooting my original problem, but then  was looking only at traffic from client computer, trying to figure out what else it was trying to talk to during login.  I'll run it again but this time hone in on ACS and DC communications.

I will also try to look at the DC event logs for clues as you suggest... just gotta figure out which of our many DCs to look at. :)

Thanks again very much. I really appreciate it.

John