Category: Aruba Clearpass

When configuring ClearPass, you must authenticate your administrative user. In this guide, I’ll explain a simple method to utilize Active Directory for ClearPass admin login. I use Active Directory since it’s widely used, allowing us to seamlessly integrate without establishing new systems or relying on the admin database in ClearPass.

ClearPass Operator Login – Duplicate the Current Service

ClearPass utilizes its own authentication process. When you click the login button on the ClearPass login page, ClearPass generates a TACACS request and authenticates the user using a service. The default service for this purpose is “[Policy Manager Admin Network Login Service]”:

Copy this service and place at the top of all services. You can rename the service and modify the Authentication Sources to include Active Directory and change the “Strip Username Rules” section to reflect it to look like the below screenshot:

Create and Apply Role Mapping and Enforcement

Create a role mapping policy to map Active Directory group membership to the appropriate role for administrative access.

I am using the default Enforcement policy that was on the default cloned service:

This saves me time. However, feel free to establish your own rules and policies. Keep in mind to include the conditions mentioned above in your policy for a backup plan. This ensures you can rely on the local admin account in case of a disaster. So, modify the default admin account password to a secure and complex one and store it safely

Log out from ClearPass and log in again using an AD account. For added security, use a different browser to test the login without logging out first.

If you successfully log in, we’ve done it right. You can then deactivate the old service by clicking the green light at the end of the row; it will turn red.

Additionally, check the login with the built-in account to ensure the fallback plan is functioning correctly.

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.

1. 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.

This article from Juniper does a fantastic job of explaining Clearpass and Juniper Switch integration so I won’t recreate the wheel here, but I wanted to share one caveat that I experienced with this:

https://www.juniper.net/documentation/en_US/release-independent/nce/information-products/pathway-pages/nce/nce-157-aruba-dot1x-mac-configuring.pdf

Here is an example of the Juniper switch filters or Access Control Lists. Notice that the “IT-Admin” name is just the role that Clearpass sends over to the switch once Clearpass completes the role mapping process for a user authentication.

set firewall family ethernet-switching filter IT-Admin term Block_Internal_Server from destination-address 198.18.255.75/32

set firewall family ethernet-switching filter IT-Admin term Block_Internal_Server then discard

set firewall family ethernet-switching filter IT-Admin term Allow_All then accept

set firewall family ethernet-switching filter SonyLaptop term Block_Internal_Server from destination-address 8.8.4.4/32

set firewall family ethernet-switching filter SonyLaptop term Block_Internal_Server then discard

set firewall family ethernet-switching filter SonyLaptop term Allow_All then accept

The only issue I saw was when testing this was when I had created my service, role mappings, etc in Clearpass with a new role, but had not yet created this matching filter/ACL on the Juniper switch side. So, what would happen is Clearpass would show the user authentication and the correct role mapped, but the user wouldn’t have access. I wrongly assumed that the Juniper would assign a default role so that essentially no filter/ACL would match and the user would simply be allowed full access, but that was not the case. Without a specific filter/ACL for that role sent from Clearpass, the user will not have access.