Clearpass w/ SSH & DUO MFA
If you have had any time in systems administration, you have probably heard of secure shell or SSH as it is commonly known. It is a much more secure remote access tool than the traditional Telnet protocol. However, SSH has its own set of weaknesses such as brute force attacks. Today we're going to explore how to make SSH more secure by layering on multiple factors of authentication.
Long winded explanation of concepts. . . #TLDR
In its 'traditional' form SSH would use a local account on the remote endpoint to authenticate the user. This is fine, especially when layered with public-key encryption using certificates. However, this introduces limited flexibility on managing user access. Imagine a scenario where you have thousands of machines, and an employee is removed from the company. You could be tasked with removing the user from all endpoints (server, network switch, router, etc.), removing public keys, or updating these credentials across all endpoints. This is terribly time consuming. So, what if we had a central location, or repository we could revoke the user's access from?
Enter identity providers; or IdPs as they are known. They are just a repository of users, credentials, and other properties. The most popular example of an IdP is Microsoft's Active Directory. Other IdPs include EntraID, OpenLDAP, Google Workspace, and Okta. Why am I mentioning OpenLDAP? yeeeeesh.
So, we have an IdP but how does that fit with access to a given piece of equipment? Enter Terminal Access Controller Access-Control System or TACACS(+) as it is most commonly known. (I'm surprised the developer, Cisco, couldn't think of a longer acronym. /s) The general idea of TACACS is take the idea of Authentication, Authorization, and Accounting that was traditionally used to grant users access to a network and apply those principles to allow access to endpoints. An endpoint can be pretty much anything such as: servers, switches, and routers. In this guide, we will focus on access to switches.
Now we have three pieces of the puzzle: An IdP (Active Directory), a method to authenticate (TACACS), and an endpoint (switch). While this configuration alone can add an additional layer of security to accessing your endpoint. . . If the user's credentials are compromised, how can we add another layer of security to the given device to prevent the user's credentials from being abused? We can use another factor of authentication or multi-factor authentication (MFA).
Most people are probably using MFA even if they are not aware of it. Have you ever been asked by your bank to provide a code to them that they just text you? Or, does your phone ever ask for a fingerprint to login to your work email? Then you are using MFA. In this guide we are going to be using DUO. DUO can be used to add MFA to a variety of different applications, and it is free for up to 10 users.
Now, before I am flamed. . . there is a real philosophical debate on MFA vs 2FA. 2FA is technically 2 different forms of identification such as something you know (password) and something you are (fingerprint). However, in a lot of literature out there 2FA is used interchangeably with MFA. MFA is technically just two forms of identification which could be something you know (password) and something you know (a security question). These are not different factors. . .I digress.
So, we are going to utilize what we just learned and combine SSH, an IdP, TACACS, and a second factor of authentication to login to a switch. But remember, these same steps could be used to login to your firewall, router, or other random device that supports TACACS/Active Directory authentication. On to the fun stuff!
Fun stuff!
Setup:
- Aruba Clearpass as our AAA server.
- This will handle initial request from the client to the switch.
- Aruba AOS-CX 6300 switch
- Ubuntu VM
- Free DUO account. DUO is free for 10 users.
Our Workflow: We will start at "Admin Machine"
Lets break down the diagram because it is a complete **** ****
1. Admin tries to authenticate (authN) to the switch.
2. Switch checks with Clearpass (CPPM) to validate the user.
3. CPPM checks with the AD Proxy to confirm the user's credentials.
NOTE: CPPM thinks the proxy is the actual Active Directory server.
4. The proxy forwards the request to AD to confirm the credentials.
a. If the request is successful the proxy determines if the user needs to perform MFA.
a.1 If MFA is approved by the user, a success message is sent back to CPPM to return to the switch.
b. If the request is unsuccessful a failure is sent back to CPPM to return to the switch.
Configuration
Assumptions:
- CPPM is setup and can support TACACS
- DUO free account is setup
- AOS-CX has network availability to CPPM
- There is a machine available to setup the DUO AD Proxy. (We're using Linux VM in this guide.)
- Active Directory server w/ a 'service' account.
a. This account is svc_cppm and is a member of "Domain Users".
Disclaimer: We're not using LDAPS for communication between the AD Proxy and AD, OR CPPM to AD Proxy. However, you unequivocally should. This is a lab to explain concepts and architecture.
Step 1:
Setup our DUO tenant.
- Login/Sign-Up and navigate to Users -> Add User.
- Set the username the same as your local AD's user.
NOTE: If you're logging into your switch with the AD user 'deputydog' that username needs to match here.
I'm not going to go into details on setting up the user for MFA, but the DUO interface is pretty straight forward. It will walk you through the process.
- Next navigate to Applications -> Protect an Application.
- Scroll down and find the "RADIUS" application. (Or use search)
- Note down the Integration key (iKey), Secret Key (sKey), and API hostname.
NOTE: With a free account you do not need to add or adjust any additional options. Again, we're just establishing concepts here. By default, the policy is: If you satisfy MFA/2FA your authentication is a success.
Step 2: Setup a CPPM Authentication Source
- Login to CPPM and navigate to Configuration -> Authentication -> Sources.
- Create a new source by clicking Add in the top right of the screen.
- Name the source appropriately. Net - DUO - AD.
a. Type is Active Directory
b. Untick the box "Enable to use this Authentication Source. . ." - Use the below screenshot and adjust for your environment.
NOTES:
- Bind DN: The user used here should be a regular AD user. Not a Domain Admin
In our example from above it would be the DN or UPN of svc_cppm
- Base DN: If your domain is example.com then the Base DN will be dc=example,dc=com. This is assuming you want to search the whole directory tree.
Step 3: Install & Configure DUO AD Proxy
The proxy is what makes all of the MFA magic happen.
Install
-
Install the AD Proxy. (Read every step below first!)
I am going to skip around a bit here because the instructions are laid out quite well in DUO's documentation (follow the Linux documentation to stay in step with this guide). I would recommend starting here -
Once you get to step 4 of their install guide stop and follow the "upgrade" guide that gives you the opportunity to install into your desired directory.
sudo ./duoauthproxy-build/install --install-dir /opt/duoauthproxy
Configure
The AD proxy has a plethora of configurations it is capable of. Here we are going to focus on authenticating against AD. I have sifted through the extras for you.
sudo nano /installDir/conf/authproxy.cfg
[main]
;debug=true
log_auth_events=true
[ad_client]
host=**FQDN/IP of Domain Controller**
service_account_username=**svc_account**
service_account_password=**password**
bind_dn=**CN=svc_account,CN=Users,DC=domain,DC=tld**
search_dn=**dc=domain,dc=tld**
; Who is allowed to use the Auth Proxy/login to the switch?
security_group_dn=**CN=Domain Admins,CN=Users,DC=domain,DC=tld**
; Network Devices
[ldap_server_auto]
Ikey=**iKey we noted earlier**
skey=**sKey we noted earlier**
Api_host=**API URL we noted earlier**
client=ad_client
exempt_primary_bind=false
allow_unlimited_binds=true
allow_searches_after_bind=true
exempt_ou_1=**Distinguished Name of the service account noted above.**
NOTE: exempt_ou_1 needs to be added so the service account doing the lookup doesn't trigger MFA with DUO. It should get a 'pass'. This is the DN of the service account from the ad_client section. In this case: It matches the bind_dn property.
Step 4: Configure CPPM TACACS service
Again, I'm not going to go into detail on how to configure a TACACS service with CPPM. The important part is creating/modifying a TACACS service, add the authentication source you created in Step 2, and move it to the top. Our enforcement policy is simple: If you are a member of the Domain Admin group, we will send back the highest privilege level available for AOS-CX switches.
Step 5: Configure AOS-CX Switch
Here, I'm going to highlight the important parts allowing TACACS to function on an Aruba AOS-CX switch.
tacacs-server host clearpass01.fqdn.tld key plaintext <TACACS Shared Key>
aaa authentication login ssh group tacacs
; The next line allows time for the user to fumble with their phone and approve the MFA push request.
tacacs-server timeout 15
Verification
Within the DUO application logs for the RADIUS application you configured you can filter on the username and determine success/failure, and MFA method.
Environment
- Duo Auth Proxy: Latest
- Aruba Clearpass: 6.12.2
- AOS-CX: 10.14.0001