AD group auth rule - MSCHAP vs TLS

[YC2]

We are making the transition from TEAP (Cert machine auth, MSCHAPv2 User auth) to TEAP (Cert machine auth, cert user auth). ISE 3.1 Patch 5. Windows 10 22H2 clients.

Ran into a snag. If I logon to a machine configured for mschap for the second phase, with a user in the CustomerService group, I hit the first rule as expected in the below snapshot. If I use the same user, on a machine configured for cert user auth, I hit the second rule instead.

I believe the cert is ok (contains the userid in right field etc) because otherwise chaining would never have succeeded in the second rule. It seems when ISE fetches the userid from the cert, it doesn't do the AD lookup. Thoughts?

[Rob Ingram]

@YC2 have you create a Certificate Authentication Profile and configured it to perform a lookup against AD to determine group membership?

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/214975-configure-eap-tls-authentication-with-is.html

https://integratingit.wordpress.com/2022/04/17/ise-certificate-authentication/

[YC2]

I figured the profile is fine as it had to have fetched the computer name and user name to do machine and user auth. User name should be the only thing that ise needs to fetch the groups from AD. I'll double check it though.

[Rob Ingram]

@YC2 the identity of the machine/user would come from the certificate subject common name that is sent to ISE in the authentication request, no AD lookup/fetch needs to be performed for that. If you enable the binary comparison and select the AD identity store to lookup against, then it can lookup the user properties.

[YC2]

Agreed Rob. By AD lookup I meant having ISE take the common name sent through the cert and fetch the groups from AD

I just verified the profile - the identity store is set to ad, the use identity from is set to common name, and always perform binary comparison is checked. sh auth sess on the switch shows the username with fqdn. So it seems like the right info is being sent to ise.