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]

Are groups or other attributes matching ok? In general, we want to avoid using DNs in the conditions as it is not very efficient for lookups.

[paul]

I can test AD group matching tomorrow.

Why is DN matching not very efficient? The DN is one string and all you are asking with the Contains directive is the substring specified contained in the string. That should be a very simple operation shouldn’t it?

I would rather not map over 20+ Domain Users and 20+ Domain Computers groups and build big compound OR conditions. That seems like that would be way less efficient.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[hslai]

CSCut02359 is an existing enhancement since ISE 1.3 and our engineering team commented,

...It would mean we lose efficiency but also I am more concerned about the security aspects of having conditions like ‘group or OU ends with *XYZ’… that lack of explicitness means it’s a flexible and potentially insecure – someone could get elevated access just by renaming an OU or group in AD.

My guess is that DNs can not be really indexed and any searches without index in AD are prone to suffer performance.

[paul]

Okay follow-up on this. I had the customer change back to EAP-TLS computer only authentication and kept everything else the same and it worked perfectly. Go figure! The only difference in the Step data is this:

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

Yesterday that was saying:

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

So it seems like because we tested PEAP Computer first, ISE had a MAR cache entry for the device even though we aren’t using MAR cache in our rules. I do have MAR cache enabled. The fact that it had authenticated with PEAP computer first then we switched over to EAP-TLS Computer it seems to have affected the DN pull or something. That is my guess as that is the only thing I see different. I am going to add the AD into the cert profile because I know all the customer’s use cases have certs with AD creds in them.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[hslai]

... EAP-TLS computer only authentication...

Do you mean <authMode>machine</authMode> in the profile for Windows 802.1X native supplicant?

If possible, we should attempt to recreate it in the lab and compare/contrast the debug trace during the AD authentications and attributes lookup.

[paul]

I wouldn't worry about testing it in the lab.  I will see if it comes up again.  I think it was an odd sequence of events issue that may not be present in real world scenarios.