Distinguish Name Values on Machine PEAP vs. Machine EAP-TLS

[paul]

I am having some issues with OU matching when doing Machine PEAP vs. Machine EAP-TLS and I am hoping I am missing something obvious.  I am using the Windows supplicant.

When I configure the device to do PEAP Computer Only auth I get this information in the authentication details:

AD-Host-Resolved-Identities USBELLTP7RSSBS1$@kina.kerryad.com

AD-Host-Candidate-Identities USBELLTP7RSSBS1$@kina.kerryad.com

AD-Host-Join-Point ICT.KERRYAD.COM

AD-Host-Resolved-DNs CN=USBELLTP7RSSBS1,OU=Service Workstations,OU=Computers,OU=Beloit,OU=Locations,DC=kina,DC=kerryad,DC=com

AD-Host-DNS-Domain kina.kerryad.com

AD-Host-NetBios-Name KINA

IsMachineIdentity true

So you can see the DN is displayed correctly and my authorization match for DN contains ",OU=Computers," works perfectly.  I change the client to use computer certs.  I have ISE configured to pull information from the SAN field.  The SAN field contains the FQDN of the device USBELLTP7RSSBS1.kina.kerryad.com.  The AD information for this looks like:

AD-Host-Resolved-Identities USBELLTP7RSSBS1$@kina.kerryad.com

AD-Host-Join-Point ict.kerryad.com

So the resolved identities are the same, but no DN is displayed.  Is that because in the PEAP use case I am doing the AD lookup in the authentication phase and in the EAP-TLS case it is happening in the authorization phase?  The step data makes it looks like it is pulling the DN fields:

24315 Single matching account found in domain - kina.kerryad.com

24323 Identity resolution detected single matching account

24439 Machine Attributes retrieval from Active Directory succeeded - kerryad.com

24422 ISE has confirmed previous successful machine authentication for user in Active Directory

15036 Evaluating Authorization Policy

15048 Queried PIP - Network Access.EapAuthentication

15048 Queried PIP - kerryad.com.distinguishedName (2 times)

Am I missing something obvious?

Thanks.

[hslai]

Do you have a TAC case on this? We would need debug logs to check.

I am with you on this. Distinguish Name is an attribute in AD and, when used as an authorization policy condition, should have matched the same for the same subject, regardless the authentications.

[paul]

No I can open one tomorrow. I may do some other testing as well. Right now I have just a straight SAN certificate profile setup which is my usual setup. I could try changing it to an Active Directory certificate profile and have any check it any part of the cert for credential information. That really shouldn’t matter because the SAN field ISE pulled was looked up successfully in AD.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[Arne Bier]

In my ISE 2.3 lab it seems to work

for what it's worth, here are my configs

In my case, I didn't use a Windows supplicant (I used Freeradius eapol_test) - but the theory should be the same.

The client performs EAP-TLS and the SAN Other-Name is read in as  abier@MEGA.local - in my AD I exist as abier, which I then lookup successfully and it retrieves all the AD stuff.

[paul]

Take out your AD server from the cert profile and see if it works. Putting the AD in the cert profile does an AD check during auth.

I don’t have an AD specified in my cert profile.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[Arne Bier]

Ok when I remove the AD server then obviously it doesn't retrieve any AD details of the user.

Sorry, I must have misunderstood the question.

re you inspecting the cert Subject and looking for something specific, like a DN?

e.g. in my cert I have

       Issuer: CN=MEGA-MEGASERVER-CA

       Subject: DC=local, DC=MEGA, CN=Users, CN=abier/emailAddress=arne.bier@iptel.com.au

ISE Live Logs details show

Subject  E=arne.bier@iptel.com.au,CN=abier,CN=Users,DC=MEGA,DC=local

I have not tried to pick it apart in an AuthZ

[paul]

What happens in the authentication phase shouldn’t affect what happens in the authorization phase. The authorization phase is using a condition that requires AD data. ISE has extracted valid AD credentials from the cert. You can see in the step data that ISE successfully found the object in AD. So the question is why is the DN data not pulled correctly? That was my original question.

For this customer, I can add AD to my cert profile because all of their cert use cases have AD credentials in the cert. The issue with using AD in the cert profile is if the cert doesn’t have an AD account in it you will fail in authentication even if the cert is valid. Say the customer is using their Microsoft CA to issue certs to phones or printers that don’t have objects in AD. You can’t use a cert profile tied to AD to authenticate those. That is why I have stopped using AD in my cert profile. In most modern certs the SAN field contains identity information and will work in all cases.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[Arne Bier]

The part I don't understand is how you expect to get this AD data.   When you say "ISE has extracted valid AD credentials from the cert.  You can see in the step data that ISE successfully found the object in AD." .... so are you extracting a username from the cert and then looking it up in AD?  If so, how?  I thought you said that you don't add AD to the cert profile.  That's where I lost you ...

Keen to hear how this pans out - I thought I understood the question but I clearly missing something fundamental.

[paul]

The cert profile directs ISE where to get the identity information. So after the authentication phase ISE has extracted the identity from the cert. Now we move on to authorization. In the authorization rule, I have an AD DN check. So ISE should take the identity pulled from the cert and attempt to do an AD lookup on that identity and find the DN. You can see from the step data that happened:

24315 Single matching account found in domain - kina.kerryad.com

24323 Identity resolution detected single matching account

24439 Machine Attributes retrieval from Active Directory succeeded - kerryad.com

24422 ISE has confirmed previous successful machine authentication for user in Active Directory

15036 Evaluating Authorization Policy

15048 Queried PIP - Network Access.EapAuthentication

15048 Queried PIP - kerryad.com.distinguishedName (2 times)

The reason you see the DN query twice is because I have two rules checking for DN matching, one for your computers OU and one for users OU. Look at your step data in the details after you pulled AD from the cert profile. If you still have your DN authorization rule you should see it attempt an AD query.

Since your lab is setup for testing try this. Instead of doing a DN match change it to match Domain Users or Domain Computers AD group, whichever your cert object is a member of. That will work I am pretty sure because I do that all the time.

This is the first time I am trying the a DN match in authorization for EAP-TLS cert. The customer has 20+ domains I don’t want to make over all the Domain Computers/Domain Users groups when they have a well-defined OU structure in each domain. All user objects are under an OU=Users and all Computer objects are under OU=Computers.

Let me know if the AD group match works if you can test it easily enough.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[Arne Bier]

Right.  Now I understand - I had no idea that AD lookups could occur during authorization (I thought identity lookups happened only in Auth).   I learned something today.  Thanks

I created an AuthZ Policy to check if that user was in a particular AD Group (based on his cert Subject name) and it worked.

Other Attributes

IdentitySelectionMatchedRule  Corp Certs

AD-User-Resolved-Identities  abier@mega.local

AD-User-Join-Point  MEGA.LOCAL

AD-User-Resolved-DNs  CN=abier,CN=Users,DC=MEGA,DC=local

AD-User-DNS-Domain  mega.local

AD-Groups-Names  MEGA.local/PortalAdminAllGroups

AD-Groups-Names  MEGA.local/CorpWiFi

AD-Groups-Names  MEGA.local/TACACS-Superusers

AD-Groups-Names  MEGA.local/BYODsponsors

AD-Groups-Names  MEGA.local/ISEAdmins

AD-User-NetBios-Name  MEGA

TLSCipher  AES256-SHA

TLSVersion  TLSv1

DTLSSupport  Unknown

Subject  E=arne.bier@iptel.com.au,CN=abier,CN=Users,DC=MEGA,DC=local

Steps

22037  Authentication Passed

12506  EAP-TLS authentication succeeded

24423  ISE has not been able to confirm previous successful machine authentication

15036  Evaluating Authorization Policy

24432  Looking up user in Active Directory - Mega

24325  Resolving identity - abier@MEGA.local

24313  Search for matching accounts at join point - mega.local

24319  Single matching account found in forest - mega.local

24323  Identity resolution detected single matching account

24355  LDAP fetch succeeded - mega.local

24416  User's Groups retrieval from Active Directory succeeded - Mega

15048  Queried PIP - Mega.ExternalGroups

15016  Selected Authorization Profile - Allow_Corp

22081  Max sessions policy passed

22080  New accounting session created in Session cache

11503  Prepared EAP-Success

11002  Returned RADIUS Access-Accept

[paul]

Ohh and by the way the same process that I am saying is broken for computer certs works just fine when I configure the supplicant for User or Computer. The SAN field contains the email address of the user and ISE has no problem pulling the DN information in the authorization phase and matching my User OU rule.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[Arne Bier]

Would you mind sharing a screen capture of your Authorization Policy that is NOT working?  I would like to try that in my lab too.

[paul]

Here it is:

The computer session is hitting my Other rule which means it couldn’t match my OU conditions. So basically that is my catch all for successful Cert authentication but no AD matching worked.

The OU_Computers condition is:

The OU_Users condition is:

I know the conditions work because when I switch to PEAP my PEAP section works just fine:

We have PEAP User OU and Other disabled for now because they wanted to see PEAP Users being blocked.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[paul]

Just as a reference my cert profile is this:

My ISS is this. This is my stock setup to allow both PEAP and EAP-TLS use cases to work.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[paul]

I am betting when I make an Cert profile tied to AD it will work. When you tie in AD into the cert profile there is an AD check during the authentication phase.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250