cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
538
Views
1
Helpful
6
Replies

ISE 3.2 p3 - Cert based Machine auth does not work

mtar
Level 1
Level 1

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?

1 Accepted Solution

Accepted Solutions

mtar
Level 1
Level 1

Hello!

It turned out a well known bug caused this issue:

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

BR

View solution in original post

6 Replies 6

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.

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

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?

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
Level 1
Level 1

Hello!

It turned out a well known bug caused this issue:

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

BR

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