By now you should know that username and Password123 are not enough to protect access to your data. Even creating a complex password or a pass-phrase (which you should do) might not help you when your info gets dumped out on the internet from the latest data breach. Multi-factor Authentication (MFA) can help add another layer of verification to make sure you really are the person who is going to access a resource and not just someone who knows a username and password. In this entry, we will use Duo as our MFA solution with Cisco ISE configured for Device Management to verify who I am when I try to login to a network switch.
If you recall my last entry in the blog, I configured Device Management with ISE. This allowed me to utilize Cisco’s Identity Services Engine for authentication, authorization and accounting in my lab infrastructure. In the end, I was able to login to a switch that was configured for TACACS+ with valid credentials. However, all that was required was a username and password. If someone had my credentials and access to the lab infrastructure I logged into, they would be able to login without an issue. Nothing else was required of the user. We should always seek to add additional layers of security where possible and MFA is an easy win not only within infrastructure, but everywhere else you have data that needs protecting.
There are some requirements to keep in mind:
- Your Cisco Duo deployment is licensed with at least “Duo MFA”. Reach out to your Cisco account team for more info on this.
- Duo is configured to sync with your user directory (e.g. Active Directory) and users have been enrolled into Duo.
- You have deployed Duo Authentication Proxies in your environment. We will not cover that config in this entry, but Duo’s documentation is extremely thorough and covers that config.
- You have Cisco ISE and the Device Management license. My last entry dived in to that particular config. Keep in mind you can still use Duo in your environment without ISE, TACACS+, Device Management, but this particular entry uses that combination.
First we will jump into the configuration on the Duo side. I am assuming your Duo environment has been properly setup. My lab environment connects and syncs to my Active Directory where I have my users. Once logged in to the Duo admin dashboard, go to Applications in the menu on the left-hand side. This page shows you all of the applications you currently have configured and protected with Duo. Click on the Protect an Application button. Here you will find applications supported by Duo, including a few generic app entries that can be used in different use-cases. In ISE, we will be utilizing a “Radius Token”, so search for “Radius”. You will see any app that includes “Radius” in the name. Select the generic looking one that only says “Radius” by clicking the Protect button.
You will then be taken to that application’s configuration page. You will need the Details section (ikey, skey, and API hostname) information for your authentication proxy configuration.
The rest of the page allows you to rename your app, which is what users will see when they are prompted by the Duo Push. Mine is named “Infra Access”. Here you can also force users to enroll into Duo or simply not allow them in if they are not already enrolled. This is done via policy. Depending on your licensing, you can get a bit granular with the policies you create. For this example, I’ve kept all defaults.
Now we will need to configure the Duo Authentication Proxies in your environment. Notice how proxies is plural as you should have some redundancy built into your environment. Find your Duo Authentication Proxy config file and edit the file. You will be adding in a radius_server_auto section as shown below. This includes all pertinent information for the Duo app and ISE.
[radius_server_auto2] ikey=ABCDEFGABCDEFG12345 skey=ABCDEFGABCDEFG12345 api_host=ABCDEFG.duosecurity.com radius_ip_1=172.30.1.102 radius_secret_1=Password123 failmode=safe client=ad_client port=1812
You’ll notice my section is named “radius_server_auto2”. This is because I have other “radius_server_auto” sections. Each one’s number is incremented and unique. The application Details follow (ikey, skey, and API host). In the next section, we will be creating a Radius Token config within ISE. The IP of ISE and the secret use on the ISE side need to match here. Save the file after the changes are made. Once changes are made to the file, restart the “Duo Security Authentication Proxy Service”.
With the Duo side configured, lets head over to ISE. First we create the Radius Token, which is our Duo Proxy. Under Administration > Identity Management > External Identity Services > Radius Token click Add. Give your Radius Token configuration a name and a description. Under the Connection tab you will add in the IP addresses and Secrets for up to two Duo Proxies. In my lab, I am only using a single proxy.
Now we will create an Identity Source Sequence in ISE. This will then be referenced in our Device Management policy. Under Administration > Identity Management > Identity Source Sequences click Add. Give the Identity Source Sequence a name. Under the Authentication Search List section add in the Duo Proxy Token that was created at the top of the list. The second entry will be the directory where users’ accounts live. In my lab, it is Active Directory.
Once the above config is saved, we will use it in the policy I created last time. As a recap of the last entry, Device Management was configured which allowed me to create a policy that lets administrators login to a switch configured with TACACS+ in Cisco Modeling Labs. The policy controls which Active Directory group can run certain commands within the infrastructure. Under Work Centers > Device Administration > Device Admin Policy Sets I’ll revisit the policy I created last time. Under the Authentication Policy I swapped out my Active Directory entry for the new Duo_Identity_Seq sequence I created. Then I save the policy.
The Authorization Policy I created last time does not change, it still controls what access you obtain once you authenticate depending on the AD group you are in.
Now that ISE has been reconfigured, it is time to login. One piece of advice I’ll add in, specifically for your TACACS+ config, add the command timeout 60 to your TACACS server config. This will give the user enough time (60 seconds) to grab their phone once the Duo Push is sent to confirm their identity. The default timeout is too quick unless you are looking at the phone expecting the Duo Push. I login to the switch and receive the Duo Push on my phone asking me to confirm the login attempt.
If I check the Authentication Log within Duo, I will see the login attempts I’ve had throughout the day. The Duo Authentication Log will show you various pieces of information on the user who tried to login, including geolocation.
I can also see authentication and authorization info within ISE’s logs.
Success! We were able to reconfigure my lab environment to require another factor in the authentication process. Adding Duo in was relatively simple because of the clear documentation. Having MFA protecting your infrastructure and even your applications is a win for any organization. Give it a try today!