cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
355
Views
1
Helpful
4
Replies

Endpoint failed to authenticate after user switch.

Sergey Polski
Level 1
Level 1

Hello everyone. I have a customer with ISE 3.2 Patch 6, Cisco Catalyst 9300 switches and Windows 10 as an endpoints.

Customer uses certificates for user and machine authentication (EAP-TLS). Certificates generated by MS CA, which is part of Active Directory infrastructure. Windows built-in supplicant is used, Everything works fine until user that was not logged in the machine tries to login, either after reboot or by performing logoff to current user.

This is the test I did:

 

1. Created new user in AD.

2. Rebooted the PC. Once PC is up and before user loggs in, I can see that PC performs authentication with computer certificate.

3. At that point I'm continuously pinging the PC. Once I login with new user that was not logged in on this machine, on the switch I can see that authentication User-Name is ISE-TEST-01@test.lab (value of Principal Name is SAN filed in the certificate), same username that was when I performed user logoff.

4. By doing packet capture on the swith I can see that after about 20 seconds machine sends EAPOL packet. Switch asks for Identity, with no reponce.

5. Switch keep asking for identity 3 times every 30 seconds, and afther that send Failure (EAP code 4).

 

From what I understand NIC on the machine tries to perform authentication while certificate was not downloaded yet. Even when user certificate downloaded (I've checked via MMC and I can see the certificate), machine doesn't send it to the switch, as when it does when user's certificate was already on the machine before login.

I tried to do the same test (user switch) when I manually deleted user certificate. In this case login is much faster (since user profile already exist in OS), certificate is downloaded, but still NIC is not sending it.

 

I've tried to play with timers and single-sign-on option in Authentication tab on the NIC, but it doesn't affect anything.

 

Any suggestions on what can be done in such case? Maybe something can be done on OS part, like restart of Wired AutoConfig process once certificate is downloaded (if such thing is possible at all).

Another solution I was thinking about using username/password for authentication instead of TLS on machines where users frequently switched.

 

Thank you

1 Accepted Solution

Accepted Solutions

Greg Gibbs
Cisco Employee
Cisco Employee

This is a common issue due to the order of operations MS has for when the User 802.1x process kicks in vs. when the User GPO kicks in (which is responsible for enrolling the User cert.

See this discussion for an optional workaround using TEAP(EAP-TLS):
https://community.cisco.com/t5/network-access-control/eap-teap-first-time-user-login-chicken-amp-egg-scenario/td-p/4475351

 

View solution in original post

4 Replies 4

Ben Walters
Level 3
Level 3

Hi Sergey, 

So once the user cert is downloaded to the machine the user authentication works after a reboot or a logoff/logon?

How long is the delay after the user logs on for the cert to be downloaded? Do you see failures in the ISE logs from that machine after the user logs on?

You could try a logon script that forces the download of the cert, checks that it's installed and restarts network services but that might be a bit too complicated here. 

Hi Ben,

Yes, after user cert is downloaded authentication works either after logoff/logon, nic shut/no shut or after reboot.

It depends. Usualy if this is a first login with this user, I'm unable to check for first 2-3 minutes since OS is creating user profile. In case I manually delete the cert and login (user profile already exist in the OS), it takes around 20 seconds for me to open MMC and look for the cert, so I assume it takes 10 or so seconds for cert to be downloaded.

 

Yes, this is what I was thinking about, to restart either network services or Wired AutoConfig service.

Unless I don't find another solution (like Greg suggested in post above), I'll try to implement this one.

 

Cheers.

Greg Gibbs
Cisco Employee
Cisco Employee

This is a common issue due to the order of operations MS has for when the User 802.1x process kicks in vs. when the User GPO kicks in (which is responsible for enrolling the User cert.

See this discussion for an optional workaround using TEAP(EAP-TLS):
https://community.cisco.com/t5/network-access-control/eap-teap-first-time-user-login-chicken-amp-egg-scenario/td-p/4475351

 

Thanks Greg. I'll try the workaround with TEAP.