cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Register for SecureX webinars to learn about our newest integrations and features.


1000
Views
20
Helpful
5
Replies
Highlighted
Beginner

Adhoc problems with ISE authentication

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.

Event5400 Authentication failed
Failure Reason12520 EAP-TLS failed SSL/TLS handshake because the client rejected the ISE local-certificate
ResolutionCheck 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.

 

20132020-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
110062020-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

 

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

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.

View solution in original post

5 REPLIES 5
Highlighted
Collaborator

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.

Highlighted

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!

Highlighted

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.

View solution in original post

Highlighted

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.

Highlighted

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.

Content for Community-Ad
Additional Cisco Threat Response Resources


August's Community Spotlight Awards
This widget could not be displayed.