Dot1x Cert AuthN and AD attribute for AuthZ

[jideji]

Hi Team,

I have a customer doing dot1x EAP-TLS  certification authentication, and he would like to use other attributes in AD in the authorization policy.  AD is currently join to ISE, and we  are  using  AD external group membership on the authorization AND condition. However, the issue we are running into is that, during the  AD group membership lookup, ISE is using the CN field on the Certificate as the username to lookup the group i.e “CN = Jacob Ideji”  but  that username doesn’t exist in AD, the actual  username in AD is “jacob1” hence, the group lookup fails with no such user “Jacob Ideji”

Our goal is to authenticate with a certificate and between the authentication and authorization phase, we need to take the Subject Alternative Name Other Name from the certificate and look up in AD the account which has an “altSecurityIdentities” attribute which matches the SAN Other Name and use the sAMAccountName returned as the identity which ISE uses to query active directory group membership.

My question is; can  we use  Identity re-write  feature to accomplish the above requirement, or if there is a better way to accomplish this Please any assistance will be greatly appreciated.

[gbekmezi-DD]

I know this isn’t the question, but this sounds unusual to me (and I don’t know if there’s a way to do what you are asking) so my question back to you is, is there a reason why they can’t place a username in the certificate field that can be used for authz lookups? Even something that can be re-written without depending on another lookup to derive the username would be good.

George

[gbekmezi-DD]

I know this isn’t the question, but this sounds unusual to me (and I don’t know if there’s a way to do what you are asking) so my question back to you is, is there a reason why they can’t place a username in the certificate field that can be used for authz lookups? Even something that can be re-written without depending on another lookup to derive the username would be good.

George

[jideji]

Thanks George. No, they can't replace the username in the Cert. This is  PIV authentication, they don't have control over the card.

[umahar]

I agree with George that this could be tricky and may not be supported.

ISE fetches the attributes to resolve the identity and can perform binary comparison against an AD for that identity.

Rewrite rules for identity are available in Advanced Settings under your joined AD however I have never used them in conjunction with binary comparison.

I think if you can come up with a general rule which is converting "Jacob Ideji" to “jacob1" it could work.

I will finally defer to the TMEs for their solution.

[Arne Bier]

I hope I understood the problem correctly - perhaps this will help

You can select a specific identity source during Authentication, and force ISE to use a SAN (and other attributes if needed) to authenticate the user.  Not sure if this is specific enough to meet your goal.

[jideji]

Arne, you up to something here. let me  try this. Thanks

[jideji]

Thanks again  Arne. Just want to let you know the results of my testing.

Using the certificate authentication profile  get me half way,  while the Identity is in a format  that is stored in active directory, we are still  unable to get  the active directory username  i.e “jacob1” . Remember before we change  to using the certificate authentication profile, ISE is using the CN “jacob ideji” as the identity which doesn’t exist in AD.  the username we will like to retrieve from AD is “jacob1”.

[Arne Bier]

Hi Jacob

I don't fully understand the problem now.

The recommendation in my previous post was successful ?  I mean, I assume you were able to extract the attribute from the cert and use that to authenticate in AD, right?

Is the missing thing now, that once you matched the cert to a user in AD, you want to resolve that user's alternate username (whatever that means) ?

Have you played around with Attributes under the AD External Identity Source?  Here you can selectively retrieve directory attributes that you are interested in.  I reckon if the user is found in AD, then AD will return additional attributes that you specify below and then you can use them in your policies.  I have never done this but it might be worth a go.

[hslai]

Scratching my answer after re-reading your post. The cert profile is to match a cert field as the username. As George said, you have an unusual need such that none of the certificate fields would be what used for identities directly, such as sAMAccountName, UPN, and email, but one field to match the AD attribute altSecurityIdentities. AFAIK AD does not use that to hunt identities so one potential is to use LDAP and tweak the schema to use altSecurityIdentities as the subject objectclass.