Adhoc problems with ISE authentication

[donnie]

i all,

My users PCs connect to the network with user cert using EAPTLS authenticated by my cisco ise (v2.4).

Majority of my PCs are able to authenticate and connect to the network with no issues but there are 1x or 2x cases everyday of different PCs who have problem authenticating with my cisco ISE. They all have the same error on cisco ise logs as shown below.

Event	5400 Authentication failed
Failure Reason	12520 EAP-TLS failed SSL/TLS handshake because the client rejected the ISE local-certificate
Resolution	Check whether the proper server certificate is installed and configured for EAP in the Local Certificates page ( Administration > System > Certificates > Local Certificates ). Also ensure that the certificate authority that signed this server certificate is correctly installed in client's supplicant. Check the previous steps in the log for this EAP-TLS conversation for a message indicating why the handshake failed. Check the OpenSSLErrorMessage and OpenSSLErrorStack for more information.

The issues would be resolved after the affected user perform a reboot. 

Everyday this same issue would happen to different user using different machine.

The certificates used by my users and my cisco ISE are signed by the same internal CA.

Why am i facing this issue? Please advise.

Below is the wlan report from my affected users.

2013	2020-02-25T10:31:15	[‒]Wireless 802.1x authentication failed. Network Adapter: Marvell AVASTAR Wireless-AC Network Controller Interface GUID: {9b321aa8-0bfe-4b2c-a190-99b147b6f6c5} Local MAC Address: 28:16:A8:aa:bb:cc Network SSID: officewifi BSS Type: Infrastructure Peer MAC Address: 6C:8B:D3:aa:bb:cc Identity: User: Domain: Reason: Unable to identify a user for 802.1X authentication Error: 0x525 EAP Reason: 0x0 EAP Root cause String: EAP Error: 0x0
11006	2020-02-25T10:31:15	[‒]Wireless security failed. Network Adapter: Marvell AVASTAR Wireless-AC Network Controller Interface GUID: {9b321aa8-0bfe-4b2c-a190-99b147b6f6c5} Local MAC Address: 28:16:A8:aa:bb:cc Network SSID: Mercury BSS Type: Infrastructure Peer MAC Address: 6C:8B:D3:aa:bb:cc Reason: Unable to identify a user for 802.1X authentication Error: 0x525

[Colby LeMaire]

That specific error message usually means that the client side does not trust the ISE certificate.  Resolution would be to ensure that the Root and Intermediate CA certs of the CA that issued the ISE EAP certificates are loaded on the client machine in its trust certificate store.  Sounds like that should not be an issue since the clients have certificates issued by the same CA.

I have seen issues where GPO's are not getting fully applied and cause problems like this.  Ensure that your clients have access to AD domain controllers during their bootup and authentication processes.  Also make sure that you are not doing any sort of dynamic VLAN assignment.  When you switch VLAN's, that causes the machine to get a new IP address and breaks GPO's, login scripts, and drive mappings.

Other than that, the next time the issue happens, don't let the user reboot.  First, check the certificate store on the client to ensure that the Root/Intermediate CA certificates are there.  You may be pushing down with GPO and if the GPO doesn't apply fully, it causes this issue.

[donnie]

Hi Colby,

Apologies for late reply. Yes I am using dynamic vlan assignment as we leverage on ISE's authorization policy to direct different groups of users to different vlans base on specific parameters from their user certificate. Not possible for me to isolate the issue by doing away with dynamic vlan assignment. Could there be other possibilities that cause the problems i am facing since dynamic vlan assignment should be used very commonly for cisco ise deployment?

For root and intermediate certs, they are definitely in user's cert store as we would push them to the user's machine before we assign the machine to users. Thk you!

[Colby LeMaire · Accepted solution]

Dynamic VLAN assignment is not commonly used for Windows workstations because it breaks GPOs, login scripts, and drive mappings.  dACL's are recommended for Windows workstations instead of VLAN assignment.  VLAN assignment works just fine for other types of devices.  I used to work in Cisco Advanced Services for over 12 years and have specialized in ISE deployments from the first days of ISE.  We NEVER use dynamic VLAN assignment for Windows machines.

Even if the certificates are placed into the machine during initial provisioning/installation of the machine, GPO processing could still cause some issues.  Especially if you are changing IP addresses in the middle of that processing.  I would recommend setting your default access VLAN on switchports to the VLAN that Windows machines would be on so they don't have to change IP addresses.  Use dACL's for those machines if you need to separate/segment traffic for certain users.  Then for other types of devices (non-Windows), you can change them to the VLAN they need to be in.

[Sergey Bocharnikov]

The problem seems to be related to the client. If the certificate is not added to the list of trusted ones, then every time during authentication a window will pop up asking for confirmation. Probably the user cancels and this error occurs.

[Colby LeMaire]

That's what I was describing in my earlier reply.  I assumed that you had already configured GPO's to push the proper CA certificates to the clients.  Which is why I discussed the issue related to GPO's sometimes not being applied properly.  If you don't already, you can create a GPO to push down the CA certificates to clients so that they will trust ISE.