Cisco ISE 2.0 Native Supplicant Certificate Issue

[Maxim Bezzubov]

Hi

ISE 2.0. Corp PC joined to the AD, OS Win 8.1. I have created a GPO following this https://technet.microsoft.com/en-us/library/dd759154.aspx

So computer acc have auth, after that - users auth does. It works fine until I enable option: Validate server certificate. We have bought for the EAP a public certicate from  Thawte, Thawte root is distrubluted via GPO - users trusted it.

After Windows OS is booted I have seen this on switch:

sh authentication sessions interface gi1/0/19 details
Interface: GigabitEthernet1/0/19
MAC Address: xxxx
IPv6 Address: Unknown
IPv4 Address: 10.x.x.x
User-Name: host/notebook.domain.local
Status: Unauthorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Restart timeout: 10s (local), Remaining: 9s
Session Uptime: 170s
Common Session ID: 0A6401090000002303AF7A9D
Acct Session ID: 0x0000001F
Handle: 0x3900000F
Current Policy: POLICY_Gi1/0/19

Local Policies:
Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)

Method status list:
Method State

dot1x Stopped

So Machine auth is stucked. I noticed that if now I login in Windows and just logout, Machine auth is proceed correctly, so as user then.

I couldn't figured out where is bug or some miscofiguration: Windows, ISE or dot1x on switch.

Switch 2960S, IOS 15.2.2, thw newest, tried another one - no luck. Debug is showed:

%DOT1X-5-FAIL: Authentication failed for client (MAC) on Interface Gi1/0/19 AuditSessionID 0A6401090000001C03831815

%RADIUS-4-RADIUS_DEAD: RADIUS server 10.x,x,x:1812,1813 is not responding.

%RADIUS-4-RADIUS_ALIVE: RADIUS server 10.x,x,x::1812,1813 is being marked alive.

[howon]

Maxim, looks like the client is not trusting ISE server certificate. You need to make sure the whole chain is sent from ISE to the client during the authentication process. This requires you to find the chain of certificates all the way to the root CA, which includes root CA, sub-CA, more sub-CA, and issuing CA depending on the CA provider. Once these public certificates are in ISE's trusted certificate store, then ISE will send the whole chain to the endpoint where the endpoint can check the validity of the certificate comparing it to its local certificate store.

Another option is, if all this fails and you only have small number of ISE nodes, then you can simply import all of the ISE certificate directly into the PC's certificate trusted root store. When doing so make sure to import the certificate into machine store as well as user store if both authentication is used.

Hosuk

[Jason Kunst]

Also make sure if you have multiple psns that you deploy a certificate for eap communication that clients will easily trust when roaming between the PSNs

this especially holds true for iOS devices (otherwise they will be prompted to install the psn certificate very new psn they see in the network)

see this article on why you should use a wildcard in the SAN

Cisco Identity Services Engine - Design Guides - Cisco

What are WildCard Certificates, and how do I use them with Cisco's ISE? | Network World

[Maxim Bezzubov]

Hosuk, thanks for your answer. As I said the whole chain of certificates  root CA, which includes root CA, sub-CA is installed on the client PC. I have installed this whole chain on the ISE, both nodes. 

We are using this certs not only for EAP but for Guest portal - have no problem wwith trusting on Mobile and Windows Notebooks.

Thawte Root Primary, by the way, is installed by default on the Windows out of box.

[howon]

Maxim, check to see if the Windows machine certificate store is also configured the same way. Windows PC has two separate certificate store, one for machine and another for user. Just because web browser is trusting the certificate does not mean the supplicant is also going to trust the same certificate. For the supplicant you have to select the Thawte CA from the supplicant settings as a trusted root CA to make it work. Although the instructions in your MS link states that when none of the CAs are selected all CAs are trusted, I have had to check the specific CA to make it work.

Hosuk

[Maxim Bezzubov]

Thawte Root Primary, by the way, is installed by default on the Windows out of box on the both certificate store:for machine and for user as well.

Sub ca root - thawte dv ssl ca - g2 - have distributing via Machine Conf GPO.

[hslai]

Are such authentications passed successfully or failed in ISE at all?

It's strange that Cisco IOS marking ISE as not responding. If indeed taking time in ISE, we would need to debug on ISE runtime or at least see where it is taking time in the authentication detail reports.

Perhaps, the windows client OS is performing some type of CRL or OCSP checks on the ISE certificates. Then, it would be good to allow such traffic during machine authentications.

[Maxim Bezzubov]

Yes, as I said in first post: some auth passed successfully buth others stuck and failed.

%DOT1X-5-FAIL: Authentication failed for client (MAC) on Interface Gi1/0/19 AuditSessionID 0A6401090000001C03831815

%RADIUS-4-RADIUS_DEAD: RADIUS server 10.x,x,x:1812,1813 is not responding.

%RADIUS-4-RADIUS_ALIVE: RADIUS server 10.x,x,x::1812,1813 is being marked alive.

About crl checking... thats a good point. First of all - I've tried Native windows Supplicant, not AnyConnect maybe something wrong with it?

Secondly, users have an Internet access via our Proxy Server so they didn't have access to CRL or OCSP checks on the ISE certificates. I will try to permit full Internet access on the test PC and check if it help. So after that I could create a rule that allow CRL checking for all users,

[howon]

Server CRL checking with 802.1X is currently not possible as endpoint typically doesn't have network access. There was a RFC to perform Server CRL checking through the secure channel through the server, but not aware of actual implementation.

As I noted earlier, try manually selecting the Thwate CA in the supplicant settings under trusted CA list. Even though browser and supplicant share the same certificate store, for the supplicant you have to explicitly select the CA that you want to trust. So in the picture below, select 'Validate server certificate' along with 'Thwate Premium Server CA'. While at it, I also recommend selecting 'Connect to these servers:' check box and enter CN of ISE certificates to make sure endpoints only send credential for your servers.

Hosuk

[Maxim Bezzubov]

I was do it so.

Then I tried like this and this.

According Technet didnt selecting any of Root Certs - User Machine wll trust any of locally installed root ca in Trusted Root Store.

Any of above configurations will bring us to the same result, Same message in debug of dead and alive radius servers so as failed auth.

[howon]

I suggest validating that the ISE certificate chains up to one of the two Thawte CA listed in the Windows certificate store. Simple way is to download the ISE server certificate to the Windows PC on you are having issue with and rename it to xxx.cer and open it up and look at the certificate path and make sure it is chained up to the correct CA.

Additional step you can take is once you see the path on the Windows PC, export all the CA certificates in the path to a file one-by-one and import them into ISE trusted certificate store.

[Maxim Bezzubov]

I've checked on the ISE this... seems to be fine. As you can see that all cert chain is existed on the ISE, enabled for EAP and trusted.

Have no issues with trusting on the Mobile devices.

[howon]

Certainly looks like ISE has all the CA. Can you go to 'Administration > System > Certificates > System Certificates' and make sure 'EAP Authentication' is enabled for the Thawte signed certificate?

Hosuk

[Maxim Bezzubov]

We are using this certs not only for EAP but for Guest portal - have no problem wwith trusting on Mobile and Windows Notebooks with guest portal. Have no problem with Trust on Androids and other mobiles via EAP auth. Havings problem with Windows Native Suppl.

[howon · Accepted solution]

Looks like the issue is with the Windows supplicant. It could be the GPO or the setting it self. I suggest configuring few machines manually without GPO and make sure it works as expected and then move on to GPO pushed settings.