cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
14507
Views
16
Helpful
5
Comments
nspasov
Cisco Employee
Cisco Employee

Overview:

In this setup, ISE will forward the TACACS+ authentication requests to the Duo Authentication proxy. The proxy will then punt the requests back to ISE for local user authentication. This can be a little bit confusing but it is necessary for organizations that want to utilize the local user database on ISE and not relay on external identity sources such as Active Directory, LDAP, etc. If the authentication is successful, the end user/admin will be send a "DUO Push." If the local ISE authentication fails, then the process will stop and no "Duo Push" will occur.

Note: For integration with Duo, ISE and Active Directory, please visit the following link:

https://community.cisco.com/t5/security-documents/duo-mfa-integration-with-ise-for-tacacs-device-administration/ta-p/3881767

Detailed Steps:

  1. Admin user initiates a shell connection to a network device where he/she uses Active Directory based credentials
  2. Network device forwards the request to the TACACS+ server (ISE)
  3. ISE sends the authentication request to Duo's Authentication Proxy
  4. The proxy forwards the request back to ISE for the 1st factor authentication
  5. ISE informs the Authentication Proxy if the local authentication was successful
  6. Upon successful ISE authentication, the Authentication Proxy sends an authentication request to Duo cloud for 2nd factor authentication
  7. Duo cloud sends a "push" to the admin user
  8. Admin user "approves" the "push"
  9. Duo informs the Authentication Proxy of the successful push
  10. Authentication proxy informs ISE of a successful Authentication
  11. ISE Authorizes the admin user

Canvas 2.jpg

Assumptions:

  • You have good/solid understanding of AAA concepts and configurations
  • Your network access devices (Routers, Switches, Firewalls, etc) are already configured for AAA (TACACS+) with ISE
  • The ISE deployment is properly licensed

Components Used:

  • Cisco ISE running on version 2.6 - patch-1
  • Duo Authentication Proxy version 3.0.0 running on Windows 10 and Ubuntu 18

Step-1 - Duo System Configuration

  • Login to your Duo account and click on "Applications"
  • Search for "RADIUS" and click "Protect This Application"
  • In a notepad copy and paste your Integration KeySecret Key and API Hostname

Step-2 - Download, Install and Configure Duo's Authentication Proxy

  • Download the latest Duo Authentication Proxy from this URL:
  • https://duo.com/docs/authproxy-reference
  • Install the authentication proxy on your Windows or Linux machine (Installation Instructions are available in the link above). In this example, I have installed the primary Authentication Proxy on a Windows 10 machine while the secondary was installed on Ubuntu
  • Configure the proxy by editing the authproxy.cfg file:
[radius_client]
host=1.2.3.4 >>> IP Address of Primary ISE PSN
host_2=4.3.2.1 >>> IP Address of Secondary ISE PSN
secret=xxxxxxxxxxxxx >>> AAA Secret (Needed later in ISE)
!
[radius_server_auto]
ikey=xxxxxxxxxxxxxx >>> Your integration key (Step-1)
skey=xxxxxxxxxxxxxx >>> Same as above
api_host=xxxxxxxxxxxxxx >>> Same as above
radius_ip_1=10.1.1.1 >>> IP address of primary ISE PSN
radius_secret_1=xxxx >>> AAA secret
radius_ip_2=10.1.1.2 >>> IP address of secondary ISE PSN
radius_secret_2=xxxx >>> AAA secret
failmode=safe
client=radius_client >>> Instructs the proxy to use ISE for 1st factor authentication
port=1812 >>> RADIUS Port
  • Start the proxy server(s) and check the proxy logs for any configuration/connectivity errors:
  • Note: In Windows installations, make sure that the Windows Firewall is configured to allow connections for the authentication proxy:

Windows Firewall.jpg

Step-3-Configuring ISE:

Create Admin Group and Admin User in ISE

  • Create a local admin group by going to "Administration > Identity Management > Groups > User Identity Groups" and clicking the "Add" button. In my example, I have created a group called "NS-Network-Admins"
  • Create a local admin user by going to "Administration > Identity Management > Identities > Users" and clicking the "Add" button. Make sure that you assign the user to the local ISE group that you created in the previous step. In my example, I have created a group called "nspasov" and have associated the user to the group that I created in the previous step called "NS-Network-Admins"

Add Duo's Authentication Proxies as RADIUS Token Servers

  • Go to Administration > Identity Management > External Identity Sources > RADIUS Token > Click Add
    • Give it a name
    • Under the "Connection" tab, add the information from the Duo Primary and Secondary (If applicable) Authentication Proxies
    • Make sure that the "Shared Secret" matches what you defined in Step-2
    • Change the "Server Timeout" to a value of 30 seconds or greater in order to avoid RADIUS timeouts
    • Click "Save"

Create Identity Source Sequence

  • While on the same page, click on "Identity Source Sequences" and then click "Add"
    • Give it a name
    • Add the newly created RADIUS Token Server and your Internal Users to the "Selected" column in the "Authentication Search List"
    • Click "Save"

2019-06-29_20-19-46.png

Create Device Admin Policies

  • Navigate to "Work Centers > Device Administration > Device Admin Policy Sets"
  • In this example, I have created a Policy Set that matches on both protocols (RADIUS and TACACS+) with the "Allowed Protocols"set to "Default Device Admin"

2019-06-28_21-01-51.png

  • Inside my policy set, I have the following policies:
    • Authentication:
      • Default rule set to check the "Identity Source Sequence" that we defined in the steps above which contains the RADIUS Token Servers (Duo Authentication Proxies) and the local ISE user database:

2019-06-29_20-21-44.png

    • Authorization:
      • Here I have a rule that checks if the authenticated user belongs to the "NS-Network-Admins" group that we created earlier in ISE. If the user belongs to the group then I am returning back my pre-configured "Command Sets" and "Shell Profile."

2019-06-29_20-26-12.png

Add Duo's Authentication Proxies as Network Access Devices

  • This step is required since the Authentication Proxies will punt the authentication requests back to ISE
  • Go to "Work Centers > Device Administration > Network Resources > Network Devices" then click "Add
    • Give the device a name
    • Enter the IP Address of your Authentication Proxy
    • Give the device to a "Type". In my example, I created a "Type of Device" called "NS-DUO-Proxy"
    • Check the box for "RADIUS Authentication Settings"
    • Enter the shared secret that you configured in your proxy during Step-2
  • Repeat the above process if you are using more than one Authentication Proxy

2019-06-29_20-53-03.png

Create a RADIUS Policy Set

  • Again, this step is required since the Authentication Proxies are punting the authentication requests back to ISE. Thus, we will see RADIUS based authentications coming from Duo's Authentication Proxies and if we do not configure this, the requests will be dropped
  • Go to "Policy > Policy Sets" and add a new Policy Set
  • Here you want to make sure the conditions that you set are specific enough so this rule does not get hit/matched by other services/authentication methods
  • In my example, I created a Policy Set called "NS-DUO-Proxy-Auth" where I am looking to match on two things:
    • The Network Device Type must be "NS-DUO-Proxy" (I created this earlier when adding Duo's Authentication Proxies as Network Devices)
  • The Protocol used must be RADIUS
  • For "Allowed Protocols" I have used the "Default Network Access"

2019-06-29_21-02-32.png

  • In the Policy Set I have the following policies:
    • Authentication:
      • Default rule set to utilize the "Internal Users" identity store
  • 2019-06-29_21-06-06.png
    • Authorization:
      • Here I have a rule that would authorize users as long as they belong to the "NS-Network-Admins" group that I created in the steps above. If the user is part of the group then I am returning a simple "PerimitAccess" Authorization Profile (If you are using RADIUS based device administration, you can return different Authorization Profiles that match your requirements).

2019-06-29_21-09-26.png

Step-4-Add and onboard users in Duo

  • In the Duo console go to "Users > Add Users"
  • The username here must match the username that you configured in the ISE Identity Store in the previous steps. In my example here, I am working with the username of "nspasov"

2019-06-29_12-06-13.png

Step-5-Testing

  • Initiate connection (ssh or telnet) from a network device that is already added in ISE
  • Enter the username and password for the local admin user that you created in ISE. In my example, this is "nspasov"
  • Upon successful authentication, confirm that the user received a Duo Push
  • After approving the Duo Push, the admin user should be now authenticated and authorized
  • Your TACACS+ live logs in ISE should show Authentication requests against the Duo Authentication Proxies
  • Your RADIUS live logs in ISE should show Authentication requests against ISE's local user data store. These requests should be sourced from Duo's Authentication Proxies
  • You can check the "authproxy" log file in your Authentication Proxy for any errors/issues
Comments
Amo2019
Level 1
Level 1

Thank you for your great demonstration.

I apply above steps and configs and its working good. But i have one problem which is enable check box that says "change password on the next login" 

After enable this checkbox for a user, the user is failed to authenticate or change the password on the network devices CLI. 

By checking the RADIUS logs, it seems that the problem is related to change password attribute or something related to pap / Chap ??

Could you please help  


Thanks 

Joe Kiema
Cisco Employee
Cisco Employee

Quick observation:

Under Detailed Steps point #1

  1. Admin user initiates a shell connection to a network device where he/she uses Active Directory based credentials

This should refer to Local credentials (defined in ISE)  vs AD right?

eganclose
Level 1
Level 1

Thanks for a great document

I manage to successfully test vManage access via Tacacs and ISE/DUO

However when I was checking a failure scenario by rejecting duo push, but inspite of that I still was able to log on to vmanage

duo-proxy logs confirms reject response sent 

Any idea what could be the cause ?

I used this how-to to configure VPN users that are locally defined in ISE (non-AD users). The only difference that I have made was, that I didn't defined Device admin policy but I created two Policy sets: One for Duo proxy RADIUS and one for ASA TG. The problem that I have is that during first authorization (towards DUO proxy)  ISE is Looking up User in Internal Users IDStore which is OK. After successful DUO identification, when user should be properly authorized, ISE is looking up for user in "Looking up Endpoint in Internal Endpoints IDStore". So user is identified as workstation and therefore not properly identified and authorized.

ben.posner
Level 1
Level 1

@eganclosewe're having the same issue, one of my co-workers didn't get to the DUO push notification in time on their phone and they were granted access! seems like there should be some check in the radius side of the rules that checks for that but i haven't been able to resolve it yet either.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: