EAP-TLS - Match external certificate to AD user
04-14-2020 01:04 AM
I have a situation at a customer which I would like to verify if this is even possible.
Customer has a ClearPass and internal AD and mobile iron MDM and uses 802.1X with EAP-TLS for authentication on Wi-Fi with mobile phones.
The MDM supplier is installing user certificates on the mobile phones.
Now comes the strange part:
The CA that installs the certificates is not integrated within the customers Active Directory. It is a standalone CA that uses the domain @customer.tld for each certificate.
I can check the certificate details like the user, issuer and OCSP, but I cannot get it to match it to an AD user with the same UPN (also the same format; email@example.com
I think it is not possible because the CA is not linked to the AD, I am correct?
The 2nd problem is more an issue, because the customer also uses radius proxy (eduroam/govroam). When the request are being proxied in, all certificate details are stripped out of the radius request and only the e-mail address is sent back to ClearPass, I am also having trouble to validate that to my AD, and I cannot check the OCSP
- - - - Aruba ACCX #748, ACDX #758, ACMP, ACEAP | HPE Master ASE - - - -
- - - - - - - Feel free to give kudos or accept as a solution! - - - - - - - - -
Re: EAP-TLS - Match external certificate to AD user
04-15-2020 12:40 AM
For the UPN as username, that should be possible with a different LDAP Query as described here.
For the proxied request, if you just get the e-mail/UPN, it looks like the remote equipment terminates the EAP session and does the actual authentication and proxies only the identity. What you would like to do is to have the EAP requests proxied so the client can validate the server certificate and only your ClearPass needs to trust your client certificates. Normally the RADIUS server (like ClearPass) would check on the realm (part after the @-sign, or any other identifier/username pattern) to determine if the request should be proxied, or processed and authenticated locally.
If the request is proxied, the EAP session will be terminated at the proxy destination. Critical here is that the client will see the 'home' RADIUS certificate and only the home server authenticates/needs the client CA; so there is no need to distribute any certificates/policies between the proxy partners. If you receive the full EAP authentication, you can do all checks and balances as you would do if the user was local as for ClearPass the authentication is the same.
If you see a non-EAP authentication coming in, the client was already authenticated remotely which means RADIUS proxy was not set up correctly at the source as described above.
If you have urgent issues, please contact your Aruba partner or Aruba TAC (click for contact details).