In EAP-TLS, a digital certificate replaces the user ID and passwords used by PEAP. If a user is disabled in AD and is using a certificate issued from ClearPass or an internal PKI infrastructure, access will be granted the next time the user authenticates. ClearPass, upon receiving the request, checks the PKI infrastructure using OCSP or CRL to verify if the certificate has been revoked, without checking AD for account disablement. If OCSP is configured correctly and the user certificate has been revoked, access will be denied. If revoking user certificates cannot be completed promptly, UserAccountControl should be employed to prevent disabled users from gaining access to the network.
- To accomplish this, first we must change the LDAP query at CPPM > Configuration > Configuration > Authentication> Sources > Click on proper source > Attributes > Click Authentication > Filter Query:
From the default:
(&(sAMAccountName=%{Authentication:Username})(objectClass=user))
To:
(|(&(objectClass=user)(sAMAccountName=%{Authentication:Username}))(&(objectClass=user)(userPrincipalName=%{Authentication:Username})))
While this step is optional, it allows users to be located using either sAMAccountName or userPrincipalName (UPN), which is the prevailing approach for generating user certificate Common Names (CNs). Modifying the Filter Query to incorporate both UPN and sAMAccountName eliminates the need for “Strip Username Rules.”
2. Next, we must include the LDAP Attribute named “userAccountControl” in the server settings for the Active Directory Authentication Source. This is done under CPPM > Configuration > Configuration > Authentication> Sources > Click on proper source > Click Authentication > Clic to add a new entry:
The following is a list of the common userAccountControl flags. With this scenario the only flag we care about is the 512 – Enabled Account. In the policy we are about to write, all authentication requests will query AD to retrieve the status of the userAccountControl. If the user account has a status of 512 access will be granted, if UserAccountControl returns anything other than 512 access will be denied.
512 – Enabled Account
514 – Disabled account
544 – Account Enabled – Require user to change password at first logon
4096 – Workstation/server
66048 – Enabled, password never expires
66050 – Disabled, password never expires
262656 – Smart Card Logon Required
532480 – Domain controller
3. Next, we need to create a Role Mapping using the userAccountControl attribute. We also check to make sure that the client cert is issued by the trusted Certificate Authority. Setting up both conditions is straightforward. First it checks to see if the certificate is issued from an internal CA, and user authorization with a userAccountControl of 512. If both checks pass, the user receives a role for internal network access.
4. Finally, once userAccountControl is activated in a service, Asset Tracker will present the account status for each authenticating user. The two RADIUS request below depict a user with account status 512 – Enabled.
