ISE 2.3p4 EAP-TLS to AD identity lookup problems. NO_SUCH_USER

[Eric Hansen]

So my scenario is this, I am setting up wired ISE using 802.1x with certificates.  My certs are issues from the internal company CA(windows) and were specifically issued for this purpose.  Subject format is Common Name, including email, and SAN includes email, UPN, and SPN.  My certificate authentication profile is set to use the Subject - Common Name because well..... its human readable being LASTNAME, FIRSTNAME.  Then testing with my laptop and looking at the user cert that was issued under subject CN = MYLASTNAME, MYFIRSTNAME.  Good to go.

Auth fails with NO_SUCH_USER in the steps.  Then I jump over to the AD settings and test user, if I plug in my CN (MYLASTNAME, MYFIRSTNAME) is fails.  Ok... so I plug in my sAMAccountName and run a lookup and it works....BUT... it returns the auth results and says that [sAMAccountName]@[Authentication domain] is my UPN, which it is most definitely is not.  And I can verify this under the attribute list that has a very different value for User Principal Name.  

But it gets stranger,the Auth Results also show the "User Distinguished Name" incorrectly, and like the UPC I can verify this in the attribute list.  The DN in Active Directory specifically has a "\" after the 'CN=LASTNAME' as an escape character for the space that comes after the LASTNAME, to treat the comma as literal.   

So then if I test with the DN *with* the backslash escape character it works, but if I test user lookup with the DN that was previously returned with a sAMAccountName the lookup fails.  So its looking like in the Auth Results that the UPN is in fact not the UPN, and the DN is in fact not the DN.


So I started looking into advanced tuning, and found out that ISE by default uses sAMAccountName, but you can change it using a registry key to use Common Name or what they call "CNSAM" which is both Common Name and sAMAccountName.  When I change the registry value to use CN, then my EAP-TLS certificate auth for the user, using the CAP of 'Subject - Common Name' works.  But when I change it to CNSAM it seems to only use sAMAccountName and the auth fails and the test use lookup using LASTNAME, FIRSTNAME fails.

So.... how is one supposed to get the Common Name to auth?  And if Cisco is going to call it UPN and DN, shouldn't literally match those values in Active Directory since AD owns the information?

I'd upload pictures if they weren't loaded with identifying information, "look at these blurry things that don't match", sigh

e-


Oh I almost forgot, I toyed with the idea of leaving the advanced tuning set to CN, but when I test it, while it worked for wireless and wired auth, it totally broke my ASA/Anyconnect authentications which seems to be stuck in a sAMAccountName world.

[Angel_Inglese]

Hello,

I suppose you are using EAP/TLS, right? 

What are your Allowed Protocols? is the Authorization Policy defined with it? What Server Sequence are you using? 

I suggest you review your Server Sequence and your Certificate Authentication Profile configuration,

regards,

[Angel_Inglese]

Hi,

you could look into External IDentity Sources > Certificate Authentication Profile > (the profile related to validate user certificates)

This should be your option,

[paul]

100% agree with using the SAN field for identity.  Keep the cert profile simple, no AD checking.  Grab the identity from the SAN field and use it in the authorization rules.

[Eric Hansen]

Sorry all, found the problem.

So the UPN is indeed the [sAMAccountName]@[Authentication Domain], I don't know why Cisco chooses to call this UPN, but it is in fact not the UPN.

So this means that the default behavior of a PSN is to query Active Directory with sAMAccountName.  In order to change this you have to go into the Advanced Tuning section and add the following registry key:

REGISTRY.Services\lsass\Parameters\Providers\ActiveDirectory\IdentityLookupField

The problem is the official Cisco documentation....

https://www.cisco.com/c/en/us/td/docs/security/ise/2-3/admin_guide/b_ise_admin_guide_23/b_ise_admin_guide_23_chapter_01110.html?bookSearch=true#reference_D81D04FDE46C4FF1A396641074E8836C

.... says that you can use the values of SAM, CN, or ***CNSAM***.   The last one is wrong.  This is a documentation error on Cisco's part, the syntax is backwards and you have to use SAMCN.  If you add the registry key to all your PSN's and restart the ad connector you can then use the CN = LASTNAME, FIRSTNAME, while still authenticating connections that need to use sAMAccountName.  It doesn't work the other way around.


e-

[Eric Hansen · Accepted solution]

Sorry all, found the problem.

So the UPN is indeed the [sAMAccountName]@[Authentication Domain], I don't know why Cisco chooses to call this UPN, but it is in fact not the UPN.

So this means that the default behavior of a PSN is to query Active Directory with sAMAccountName.  In order to change this you have to go into the Advanced Tuning section and add the following registry key:

REGISTRY.Services\lsass\Parameters\Providers\ActiveDirectory\IdentityLookupField

The problem is the official Cisco documentation....

https://www.cisco.com/c/en/us/td/docs/security/ise/2-3/admin_guide/b_ise_admin_guide_23/b_ise_admin_guide_23_chapter_01110.html?bookSearch=true#reference_D81D04FDE46C4FF1A396641074E8836C

.... says that you can use the values of SAM, CN, or ***CNSAM***.   The last one is wrong.  This is a documentation error on Cisco's part, the syntax is backwards and you have to use SAMCN.  If you add the registry key to all your PSN's and restart the ad connector you can then use the CN = LASTNAME, FIRSTNAME, while still authenticating connections that need to use sAMAccountName.  It doesn't work the other way around.


e-

[RicardoDiaz]

This issue occurs in ISE 2.3 patch 6.

The same workaround applies and corrects the issue.