ISE - AD account search

[Matt_S]

Hi,

I have a customer that is wanting to use user authentication with user certificates (wired and wireless). ISE is joined to their domain and providing the RADIUS authentication. When ISE receives a user cert it learns the name from the CN or SAN fields, and searches for a valid AD account with matching account name. The way their AD accounts are setup is that the ‘User logon name’ does not match the ‘User logon name (pre-Windows 2000)’ field. Searching for an account by the ‘User logon name’ will fail, but searching for an account by the ‘User logon name (pre-Windows 2000)’ will succeed. The problem we have is that the certificate generated for an account will take the User Principle Name which is the ‘User logon name’ , and not ‘User logon name (pre-Windows 2000)’. ISE will only ever learn the ‘User logon name’ from the cert, and will search for an AD account by that name – which fails. It is a particularly difficult task for the customer to change domain account structures and/or certs. So, the question is, is it possible for ISE to search for domain accounts based on anything other than account name? or, is there any other suggestion about how to make to get this working without changes to the customer domain?

thanks,

Matt

[Arne Bier]

There is an official document that describes how this works.  It's a bit tricky for us non-AD experts to understand and perhaps it makes more sense to you than it did to me.  I had a related issue to understand how ISE handles ambiguity (i.e. you have the same username in 3 domains - which one will ISE choose?)

Have a look here

I will say that in my case we also match on the user's email address attribute - is that attribute populated in your customer's case?  In our case the user's email attribute is completely different to the UPN.

I find the Test User tool in ISE (External Identity Sources) is invaluable to trying to understand what's happening under the covers.

[paul]

Unless the client has totally jacked up their AD ISE should be able to look up users by just the username or username@domain.com.  If the customer lookup is not working for username@domain.com you can use identity rewrite rules under advanced tab in AD definition in ISE.

[user]@domain.com  rewrites to [user]

[Matt_S]

thanks for the reply Paul and Arne. The issue here is that the customer AD accounts look like that attachment. You'll see in this example that 'martin.ferguson@lab.local' is the user logon name, but the pre-Windows 2000 name is actually 'fergusma' - this is what is SAM /account name. So if you search AD for an account name called martin.ferguson it will fail. It will only succeed if you search for fergusma.

When a certificate is generated for this account, it populates the CN and SAN fields with the UPN. The UPN is taken from the logon name - 'martin.ferguson@lab.local' - not the pre-Windows 2000 SAM. So, when using EAP-TLS, ISE will only ever learn martin.ferguson' from the cert info. It will try to search for and account name called 'martin.feruson' and that will fail.

Its a long shot, but I was wondering if there is any way that ISE can search for a UPN rather than SAM, or if anyone had seen this before and had a resolution - other than changing all the AD accounts :)

hope that description makes more sense.

thanks,

Matt

[paul · Accepted solution]

Check to see if you have some rewrites happening because if the cert has martin.ferguson@lab.local in the field you are pulling for identity (I would just specify the SAN field and not do an AD check in your cert profile) then that should be what ISE looks up unless you have a rewrite happening. Remove the AD check from the cert profile and do the check in the authorization phase. I have included a screen shot of the cert profile I use on all my installs. If not working checking the details to see if rewrites are happening.

[cid:image001.png@01D43030.48927BF0]

[Matt_S]

hi Paul, I couldn't see the attachment with your post, but looks like we have a fix. Your suggestion about the identity source on the cert profile was spot on. Changing this from the default CN to 'Any Subject or Alternative Names Attributes' option sorted it and now ISE appears to be searching by UPN.

FYI, the 'Test User' tool is a little misleading in this situation. If I search by 'martin.ferguson' in the test tool it is a failed result, even though this is the name and format ISE is now finding the account with. It seems the 'Test User' tool only searches on sAMAccountName field, as searching by 'fergusma' in the tool is the only way to get a successful result

[paul · Accepted solution]

Here is the screen shot.   

The problem with using "Any Subject or Alternative Name" is you are forcing ISE to do an AD lookup in the authentication phase of an EAP-TLS connection to verify the identity obtained from the cert is contained in AD.  This means the cert profile can only be used for certs that contain ID information.  What if you want to allow the customer to issue certs to other devices via NDES/SCEP?  Then you would have to build a cert profile that doesn't tie to AD and do some extra work in your authentication section to parse out those use cases.

If you use the setup I linked above you can process most uses cases and gather identity information from the SAN field.  Most modern cert templates if done correctly should have identity information in the SAN field.  Then you do all your AD checks and other things in your authorization rules.

If you look at my ISE setups I never use more than a the default authentication rule.  The authentication source is a sequence that ties together AD and this generic SAN field cert profile.  So in the authentication phase is just answering two questions:

1. Are valid AD credentials being presented regardless of authentication protocol?
2. Is a valid cert being presented issued from a CA I am told to trust for client authentication?

Then in authorization I can get very specific on what I am looking for:

1. PEAP + Member of Domain Computers
2. EAP-TLS + Member of Domain Computers
3. EAP-TLS + Member of Domain Users
4. EAP-TLS (to handle the other cert uses cases)

[Matt_S]

we're using eap chaining with both user and machine certs. Because the customer does not have the required information in the same fields consistently for both certs, selecting any single option fails, or fails user / passes machine, fails machine / passes user. I tried each individual option just to be sure. "Any Subject or Alternative Name" is the only one that succeeds for user and machine.