ISE 3.2 p3 - Cert based Machine auth does not work

[mtar]

Hello!

We have implemented Windows 10 native client TEAP authentication, which works perfectly if the User and the Machine is authenticated via MSCHAPv2.  So the EAP-Chaning is working in the environment.

But If we want use EAP-TLS to authenticate the machine via Certificate the following error appears:

	22070	Identity name is taken from certificate attribute
	22047	User name attribute is missing in client certificate - Subject - Common Name
	22002	Authentication complete
	22057	The advanced option that is configured for a failed authentication request is used
	22061	The 'Reject' advanced option is configured in case of a failed authentication request
	12529	Inner EAP-TLS authentication failed

The certificate is on the machine, the common name is name of the machine and it exist in the AD.

TEAP config is okay, the certificate is selected which to use during the dot1x authentication.

But still the Machine cannot auth itself

What could be the problem?

[Aref Alsouqi]

Which option you switched to EAP-TLS in TEAP properties on the supplicant settings? please note that the primary EAP authentication method is referring to the machine authentication, and the secondary is referring to the user authentication.

[mtar]

Hello Aref!

I know it as the exact opposite. Like the primary is the user and Secondary is the machine.

The above reffered logs are part of the Machine authentication logs, so I think I am right.

BR,

Mate

[Aref Alsouqi]

Hello Mate, you're right, my bad, I flipped them around. Do you also have a SAN value on the cert with the machine name? if so, could you please change the CAP on ISE and set the DNS SAN instead of the CN attribute?

[mtar]

Hello!

Unfortunately there is no SAN field in the certificate, although we have tried to modify the CAP according to it, but we get an authentication error during the dot1x process . Which is expected since there is no SAN field.

Thx,

Mate

[mtar · Accepted solution]

Hello!

It turned out a well known bug caused this issue:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwf80292

BR

[Aref Alsouqi]

Thanks for sharing this. Did the suggested workaround fixed the issue?