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

ISE Certificate Authentication Profile: Using LDAP Only to resolve identity ambiguity

Scott Gillies
Level 1
Level 1

Hi

 

For ISE BYOD the certificates are issued and stored internally on ISE.

 

On ISE the BYOD certificate template only allows the Common Name for the certificate to be the UserName.

My users credentials are hosted on an LDAP server so when the user is on-boarding to the BYOD service they are initially authenticated against the employee LDAP server.

 

As part of my security process, when performing EAP cert authentication I wish to confirm that the UserName (the certificate Common Name - CN) is still active/valid on the LDAP server.

 

The Certificate Authentication Profile only allows "Always perform binary comparison" for LDAP servers i.e. assumes that the certificate is stored on the LDAP server which causes the authentication to fail. It does not allow the "Only to resolve identity ambiguity" option.

 

How can I check the UserName is valid on the LDAP server as part of the EAP authentication?

1 Accepted Solution

Accepted Solutions

Greg Gibbs
Cisco Employee
Cisco Employee

From past experience, when using a direct LDAP Identity Store, ISE will not extract the name from the certificate’s subject to send it via LDAP for verification. It will only check the certificate validity via binary comparison, therefore the binary comparison option cannot be disabled.

If you cannot store the certificate in LDAP, the options to work around this include using Active Directory integration instead (if AD is your LDAP store) or use a CAP with the Identity Store set to 'not applicable' and use the Authorization Policy to check for a valid user via group membership.

 

Cheers,

Greg

View solution in original post

6 Replies 6

Try to create an authorization rule that matchs byod endpoints, looks at cn
in the certificate and validate its group membership in AD. If you disable
your users in ad or move them to inactive group then authorization will
fail.

**** please remember to rate useful posts

Greg Gibbs
Cisco Employee
Cisco Employee

From past experience, when using a direct LDAP Identity Store, ISE will not extract the name from the certificate’s subject to send it via LDAP for verification. It will only check the certificate validity via binary comparison, therefore the binary comparison option cannot be disabled.

If you cannot store the certificate in LDAP, the options to work around this include using Active Directory integration instead (if AD is your LDAP store) or use a CAP with the Identity Store set to 'not applicable' and use the Authorization Policy to check for a valid user via group membership.

 

Cheers,

Greg

Hi
Thanks for your recommendations.
I will need to test the Certificate Common Name against its LDAP group membership/s.
I have being trying to configure this without success.
I assume this is not testable at the Authentication stage, only the Authorisation?
I have configured the LDAP connection to include the Attributes memberOf and sAMAccountName.
I have configured the condition:
CERTIFICATE:Subject – Common Name CONTAINS Test_LDAP.memberOf

 

I am obviously missing something in my condition. Could you be kind enough to point me in the direction of the correct configuration to test the Cert CN against the LDAP group membership?

 

Thanks in advance.

You don't need to specify in the AuthZ Policy where ISE should look for the identity in the certificate. The attribute you specify in the CAP (Common Name, Subject Alt Name, etc) will be used by ISE for the identity.

In your AuthZ Policy, you would specify the External Group of which the user (or computer) is a member.

Example:

<LDAP_ID_Source>:ExternalGroups EQUALS <LDAP_Group>

 

Cheers,

Greg

I had a similar issue and this post helped me toward my eventual solution, so thanks for another helpful reply @Greg Gibbs . I’m going to explain my issue and solution in case anyone else is hitting the same wall.

In my situation, I was implementing PKI Authentication to ISE admin with LDAPS connection to AD. I was able to get PKI admin login to ISE with a normal AD connector, and I was able to get username and password login to ISE working with the LDAPS connector, but was not able to get PKI login over LDAPS. This issue would exist for PKI authentication for users/endpoints to LDAPS as well.

I used the following guides for configuration:
PKI login to ISE: https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/215308-configure-certificate-or-smartcard-based.html

External Identity Source LDAPS connector: https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/216190-configure-and-troubleshoot-ise-with-exte.html

After banging my head against the wall, I eventually did a methodical process of packet captures on the LDAP (AD) server (this only works for a non-secure connection, but it gave me the info I needed which can then be applied to a secure connection). 

What I found is that ISE sends an LDAP search request with the identity of the user as defined in the CAP (Certificate Authentication Profile) certificate attribute. In my case this is the userPrincipalName from the SAN (Subject Alternative Name - Other). That value has to be defined in the LDAP user account so the LDAP server knows how to find it. No big surprise there.

Additionally, ISE includes in the LDAP request all the attributes configured in the External Identity Source LDAP connector under the Attributes tab. The document I referenced doesn’t include anything about the attributes tab, but if you’re like me, you may have added the attributes you thought were necessary. So in the LDAP request, ISE is asking the LDAP server to lookup the account defined in the CAP, and return the values from the attributes defined in the LDAP connector attributes tab.

Attributes.jpg

However, because ISE requires binary comparison for LDAP connectors, it also appends the “userCertificate:binary” attribute to the end of the list of attributes in the request. The LDAP server recognizes the first “userCertificate” attribute in the list and returns the encrypted certificate value to ISE rather than the binary value. ISE can’t perform binary comparison which causes authentication failure. Here is a screenshot of the packet capture from the failed request. The red box contains the attributes configured in the LDAP connector Attributes tab. The green box is from the CAP.

Fail.jpg

The solution: simply remove the “userCertificate” attribute from the LDAP connector attributes tab (or don’t populate the tab at all per the document) and voila, PKI authentication successful over LDAP (and LDAPS).

Success.jpg

Obviously I created my own issue, but understanding how ISE is sending the info in relation to the connector config is really helpful info for me.

Hello, If the communication between ISE and LDAP server is using LDAPS (port 636), does the LDAP server return the binary of certificate to ISE ? Is the “userCertificate” attribute only for domain user certificate ?