Duo integration options for Cisco AnyConnect VPN with ASA and FTD

[zalkurdi]

• Introduction
• Pre-requisites
• Components used
• Duo background information
• Duo Authentication Proxy
• Duo Access Gateway
• Duo Cloud
• Integration Scenarios
• 1) ISE RADIUS Proxy and Duo Authentication Proxy
• 2) Duo Authentication Proxy and ISE Primary Authentication Source
• 3) Primary and Secondary Authentication servers
• 4) Duo Authentication Proxy and LDAP
• 5) Primary and Secondary Authentication with LDAPs
• 6) Duo Access Gateway and SAML Authentication
• Summary
• Resources

Introduction

According to recent studies, such as the Verizon's Data Breach Investigations Report, Credential theft is one of the most common ways a network is breached by external adversaries. The use of username and passwords alone to connect to a network is no longer considered a secure approach. Many companies are employing Multi-Factor Authentication (MFA) solutions with VPN technologies to secure external access to network resources.

Cisco’s Duo is a leading MFA solution and is an essential pillar of Cisco’s Zero-Trust Strategy. Duo easily integrates with Cisco VPN solutions to provide extra layers of security as well as great visibility into network access.

There are a variety of ways Duo can integrate with ASA and Firepower VPN to provide Two Factor authentication. This document will show the different ways to integrate with Duo, the Pros and Cons of each approach and the user experience expected from each setup. This document is mainly focused on theoretical concepts and does not contain configuration or feature specific details. Some additional resources can be found at the end of the document for further education. 

Pre-requisites

• Basic Cisco Firewall and AnyConnect VPN knowledge
• Basic knowledge of ISE Authentication and Authorization flows
• Basic AAA protocols knowledge (RADIUS, LDAP, SAML) 

 

Components used

The information in this document is based on the following software and hardware versions:

• Cisco ASAv running version 9.12.3.12
• Cisco Identity Services Engine (ISE) running version 2.6 patch 3.
• Duo Authentication Proxy running version 3.2.4
• Duo Access Gateway running version 1.5.10
• Cisco AnyConnect 4.8.03052 

 

Duo background information

Before discussing the different integration options, an overview of the Duo components involved would help understand the flows that will be described later in this document.

Duo Authentication Proxy

The Duo Authentication Proxy is an on-premises software service that can be installed either on a Windows Server or a Linux machine. It receives authentication requests from a local network device or application via RADIUS or LDAP, optionally performs primary authentication against an existing LDAP directory or RADIUS authentication server, and then contacts Duo to perform secondary authentication. Once the user goes through second factor authentication (received as a push notification from Duo Mobile, or as a phone call, etc.), the Duo proxy returns access approval to the requesting device or application.

Duo Access Gateway

The Duo Access Gateway or DAG secures cloud and web applications using the SAML 2.0 Authentication standard. SAML delegates authentication from a Service Provider (SP) to an Identity Provider (IdP) and is used for single sign-on (SSO) solutions.

Protected applications or SPs redirect users to the Duo Access Gateway server in the network. Duo Access Gateway acts as a SAML IdP, authenticating the users using an existing primary authentication source for credential verification, and then prompting for two-factor authentication before permitting access to the SAML application.

Duo Access Gateway supports local Active Directory (AD) and OpenLDAP directories as identity sources, as well as on-premises or cloud SAML IdPs. It can be installed on a Windows Server (2012 or later) as an IIS virtual Site or as a Docker container in most modern Linux distributions.

Note: Duo recently released the “Duo-Hosted SSO” Beta feature. This feature allows the Application to connect to the Cloud directly for Primary and Secondary Authentication without the need to install a DAG in the network. This feature is in BETA phase at the time of writing.

Duo Cloud

Duo is a SaaS offering and the Duo cloud is where most of the functionality is located. All policy configuration, reporting, endpoint visibility and management is done on the web interface hosted in the cloud. Some basic configuration is done on the Proxy and DAG to connect them to the Primary authentication source and the cloud.

The cloud also holds details about user and endpoint that connect to the network or to protected applications. Details such as username, email address, phone number, type of device and many more can be found in the web console.

It is important to mention that the Duo Cloud does not store or see user passwords and does not perform any primary authentication. Primary authentication is always handled by the external identity store connected to the Proxy or DAG, whether it is an AD, LDAP server or a SAML IdP.

Integration Scenarios

This section shows the different ways Duo can be integrated with Cisco AnyConnect VPN solutions.

1) ISE RADIUS Proxy and Duo Authentication Proxy

The first setup involves a Cisco Firewall, ISE and Duo Authentication Proxy. The same concept applies if a Cisco FTD or ASA was used. With this setup, RADIUS will be chained between the ISE and Authentication proxy to perform Two Factor Authentication. RADIUS requests from the Firewall will reach ISE first which are then sent to the Duo Authentication proxy. The diagram below illustrates the flow of this setup:

1. A VPN connection is initiated to the Firewall. The primary credentials and second factor of choice is provided by the user.
2. The ASA sends a RADIUS authentication/authorization request to ISE.
3. Based on the configuration, ISE relays the RADIUS request to the Authentication proxy.
4. Authentication Proxy performs primary authentication with Active Directory or an external RADIUS server using the credentials provided by the user.
5. After successful primary authentication, the Authentication Proxy establishes a connection to Duo Cloud over TCP port 443. Only the Username and Authentication method of choice is sent to the cloud. The user’s password is never shared with the Duo Cloud.
6. Secondary authentication initiated and push notification is accepted.
7. The authentication proxy receives the confirmation from the cloud and replies with a RADIUS Access-Accept to ISE. At this point, ISE has successfully finished authentication and can continue with authorization.
8. Cisco ASA VPN access is granted based on the Authorization profile provided by ISE.

Adding the Duo Proxy behind the ISE deployment works well in already existing VPN environments that need an additional layer of security using MFA. There is no need to change any VPN configuration on the Firewalls. ISE will act as a single source of truth for all authentication requests coming from network devices. ISE only needs to be configured to send certain requests to the Duo Proxy while allowing other RADIUS requests to pass through the normal authentication and authorization flows.

User Experience:

With this setup, the user experience will vary depending on how the Duo Authentication proxy is configured.

1) RADIUS Auto Append Mode

Using the RADIUS Auto Append mode, the user will see the standard AnyConnect authentication prompt upon connection. In the Password Field, the user will be required to enter their Primary password, followed by a separating character and then their Secondary authentication method of choice appended to their password. The Second Factor can be written as:

• <Password>,Push. This sends a push notification to the Duo Mobile App. 
• <Password>,Phone. This initiates a phone call to the user’s number which needs to be answered
• <Password>,SMS. This sends an SMS with a One Time Passcode (OTP) which needs to be entered using a second Authentication attempt.
• <Password>,<OTP>. One Time Passcode (OTP) generated from the Duo mobile App which is a 6-digit code.. 

If a second factor is not chosen, a push will automatically be sent. If the user does not have the Duo mobile app, a phone call back will be used. The figure below shows an example:

Note: The separating character can be configured in the Authentication Proxy configuration file. By default, it is a “ , ”. The Proxy does not differentiate if this character is already part of the user’s primary password. Take caution when choosing the separator and make sure it is not a character that is allowed in the user’s password.

 The same user experience applies for WebVPN access through the browser:

2) RADIUS Challenge Mode

Using the RADIUS Challenge Mode, the user will see the standard AnyConnect authentication prompt upon connection. Once they submit their username and password, without appending anything, they will be presented with a Challenge Prompt to choose the second factor of choice. They can use Push Notification, SMS codes or the OTP code generated on the Duo Mobile App as seen below:

The same applies for WebVPN access through the browser:

User Enrollment:

If a user authenticates with their primary credentials but their account is not registered with Duo, they will see the following prompt after successful Primary authentication which requests them to enroll:

Going to the specified link will start the enrollment process as shown below:

The same user experience applies for WebVPN access through the browser:

Note: This is one way to perform enrollment. The link below shows other possible enrollment options for Duo: https://duo.com/docs/enrolling-users

The following table lists the Pros and Cons for this approach:

Pros	Cons
Pointing RADIUS requests directly to ISE allows it to filter RADIUS requests going to the Duo Proxy. The filtration can be done based on conditions such as Network Device Groups, VPN Tunnel Group name, Network devices IP, Username and many more.	Duo Authentication Proxy does not support using MS-CHAP protocol with RADIUS requests when using an AD as the Primary Authentication source. This will prevent the use of Password-Management on the Firewall which allows users to reset AD passwords when they expire through AnyConnect.
Works well with features such as Profiling and Posture as the RADIUS Change of Authorization (CoA) flow is unaffected.	Extra considerations need to be taken into account when it comes to High Availability and Failover between ISE and the Proxy.
RADIUS attributes such as Downloadable Access-list (DACL) and Security Group Tags (SGTs) can be used.	Chaining RADIUS across multiple devices may add additional latency to the authentication request.
Easy and fast to setup in an existing VPN environment.
Un-enrolled users will be prompted to enroll using an HTTPs link as explained below.

2) Duo Authentication Proxy and ISE Primary Authentication Source

The second setup involves a Cisco Firewall, ISE and Duo Authentication Proxy. The same concept applies if a Cisco FTD or ASA was used.

This setup is similar to the one mentioned before with one difference. The ISE and Duo Proxy positions are swapped. The VPN connection will terminate on the Firewall which will then send a RADIUS request to the Authentication proxy directly. The proxy will send the request to ISE to perform Primary Authentication and authorization.

The diagram below illustrates the flow of this setup:

1. A VPN connection is initiated to the Firewall. The credentials and second factor of choice is provided by the user.
2. The firewall sends a RADIUS authentication/authorization request to the Authentication Proxy.
3. The Proxy relays the RADIUS request to ISE.
4. ISE performs primary authentication locally or with and external store and continues to authorization. Based on the configured rules, ISE replies to the proxy with Access-Accept containing the attributes needed to allow or restrict the level of access.
5. After successful primary authentication, the Authentication Proxy establishes a connection to Duo Cloud over TCP port 443. Only the username and Authentication method of choice is sent to the cloud. The user’s password is never shared with the Duo Cloud.
6. Secondary authentication is initiated.
7. The authentication proxy replies with RADIUS Access-Accept to the Firewall. The same authorization attributes provided by ISE are pushed to the Firewall.
8. AnyConnect VPN access granted

Adding the Duo Proxy in front of the ISE deployment works well in an environment where password management is needed for VPN users. It is also suitable to organizations that don’t have direct control over their ISE setup and would rather avoid any major changes there.

User Experience:

With this setup, the same user experience mentioned in the previous setup, using the “RADIUS Auto Append Mode”, the “RADIUS Challenge” mode or User Enrollment, still applies.

Note: RADIUS Auto Append Mode is not supported when using MS-CHAP as the authenticating protocol. If MS-CHAP protocol is enabled on the firewall and used for VPN authentication, the user’s actual password is never sent throughout the communication. The Duo Authentication proxy will not see the factor of choice. With this setup, the user simply enters their Primary credentials when authenticating. If they have Duo enabled on their phone, they get a push notification. If not, they will get a phone call back. If the user does not have a Duo Account, an enrollment link will be sent.

The following table lists the Pros and Cons for this approach:

Pros	Cons
Pointing RADIUS requests directly to the Proxy allows the use of MS-CHAP protocol. As mentioned above, the Duo Proxy supports MS-CHAP only when its primary authentication source is a RADIUS server. Users will be able to change their passwords via AnyConnect if it expires.	All RADIUS requests generated from the firewalls will go through the proxy. This will add additional load on the proxy as the filtration mechanisms are not as granular as ISE.
RADIUS attributes such as DHCP attributes, Security Group Tags (SGTs), group-policy names…etc can be used.	Firewall configuration needs to change and point to the Proxy as the RADIUS AAA server for VPN authentication
No major changes on the ISE side as it is not aware there is a second authentication flow. Only the IP and shared secret of the proxy needs to be added.	Features such as Profiling and Posture will not work as expected since the Duo Proxy does not support the RADIUS Change of Authorization (CoA) packet generated from ISE and will be dropped.
Un-enrolled users will be prompted to enroll using an HTTPs link.	The use of Downloadable Access-lists (dACLs) is not possible with this setup. When ISE pushes a dACL name the ASA attempts to download the contents through another RADIUS request which is not recognized by the Proxy.
	Chaining RADIUS across multiple devices may add additional latency to the authentication request.
	Extra considerations need to be taken into account when it comes to High Availability and Failover

 3) Primary and Secondary Authentication servers

The third setup involves a Cisco Firewall, ISE and Duo Authentication Proxy. The same concept applies if a Cisco FTD or ASA was used.

This setup is different than the ones mentioned above in that no RADIUS chaining is used. The Cisco Firewalls have the ability to perform Primary and Secondary authentication separately with two different servers.

The diagram below illustrates the flow of this setup:

1. VPN connection initiated to the Cisco Firewall. The credentials and second factor of choice is provided by the user.
2. The firewall sends a RADIUS authentication/authorization request to the ISE
3. ISE performs authentication and authorization either locally or with an external source.
4. ISE replies with a RADIUS Access-Accept and provides the appropriate authorization attributes to the Firewall
5. The Firewall sends a second RADIUS Authentication request to the Proxy. The password is never shared with the Proxy, only the username and factor of choice are sent.
6. Secondary Authentication is performed successfully.
7. The Proxy replies with RADIUS Access-Accept to the Firewall. The firewall applies the attributes received earlier from ISE and allows the VPN connection.

This setup works well for an existing VPN and ISE deployment. The only change needed is to add an additional authentication method on the Firewall without changing existing VPN configuration. In addition, two factor authentication is possible while achieving total separation of Primary and Secondary Authentication methods to satisfy Compliance requirements or possible security policies.

Note: The Primary Authentication server configured on the Firewall does not have to be a RADIUS server, it can also be an LDAP server.

User Experience:

With this setup, the user will be prompted to enter their username, their password and their factor of choice in three separate fields as seen below:

The options for the second factor are Push, Phone, SMS or OTP from the Duo mobile App.

The following table lists the Pros and Cons for this approach:

Pros	Cons
Using this approach, no changes on the ISE are needed. The firewall existing configuration will also remain unchanged, only a secondary authentication server needs to be added under the tunnel-group.	The use of Password management is not possible with this setup. Enabling Password-Management will enable MS-CHAP protocol for both Primary and Secondary Authentication methods. The Duo Proxy will not accept requests using MS-CHAP.
RADIUS attributes such as DHCP attributes, Security Group Tags (SGTs), group-policy names, DACLs…etc can be used.	Users not known to the Duo cloud can’t go through Inline enrollment with this setup. Other enrollment options need to be used. For more details, the following link can be used: https://duo.com/docs/enrolling-users
Features such as Profiling and Posture will work as expected since the RADIUS Change of Authorization (CoA) flow remains the same.	Extra considerations need to be taken into account when it comes to High Availability and Failover
No RADIUS chaining is used reducing the latency and allows greater flexibility.

4) Duo Authentication Proxy and LDAP

The fourth setup involves a Cisco Firewall, an LDAP server and Duo Authentication Proxy. The same concept applies if a Cisco FTD or ASA was used.

This setup relies completely on the LDAP protocol in order to perform authentication and authorization. It is a simple setup for the environments that don’t have a dedicated AAA server. Primary Authentication is performed against the LDAP server while the Duo cloud handles the second factor authentication. Once both authentications pass, the user is allowed basic access. Optionally, LDAP attribute maps can be used to provide different levels of access based on the received LDAP attributes from the server.

The figure below shows the flow in detail:

1. VPN connection initiated to the Cisco Firewall. The credentials and second factor of choice is provided by the user.
2. The firewall sends an LDAP authentication request to the Duo Proxy.
3. The proxy sends an LDAP request to the LDAP server which performs authentication and provides the appropriate LDAP attributes.
4. The Proxy sends a request to the Duo cloud for secondary authentication. The password is never shared with the Proxy, only the username and factor of choice are sent.
5. Secondary Authentication is performed successfully.
6. The Proxy replies with successful authentication and LDAP attributes to the Firewall.
7. The firewall applies the attributes received and allows the VPN connection.

 

User Experience:

With this setup, the user will be able to use the Append mode as explained earlier. The user will see the standard Anyconnect authentication prompt upon connection. In the Password Field, the user will be required to add their Primary password, followed by a separating character and then their Secondary authentication method of choice appended to their password. The Second Factor can be: Push, Phone callback, SMS or a One Time Password (OTP) generated from the Duo mobile App.

If a second factor is not chosen, a push will automatically be sent. If the user does not have the Duo mobile app, a phone call back will be used.

Note: The separating character can be configured in the Authentication Proxy configuration file. By default, it is a “,”. The Proxy does not differentiate if this character is already part of the user’s primary password. Take caution when choosing the separator and make sure it is not a character that is allowed in the user’s password.

The same applies for WebVPN access through the browser:

The following table lists the Pros and Cons for this approach:

Pros	Cons
No need for a dedicated AAA server for Authentication and Authorization. LDAP attribute maps on the Firewall can be used.	Limited authorization capabilities with LDAP attribute maps as opposed to a AAA server.
Password management is possible to allow users to change their passwords when it expires. This requires LDAPs to be enabled between the Firewall and the Duo Proxy.	Users not known to the Duo cloud can’t go through Inline enrollment with this setup. Other enrollment options need to be used.
	Extra considerations need to be taken into account when it comes to High Availability and Failover
	Existing firewall configuration needs to change. LDAP requests need to point to the Duo Proxy instead of directly to the LDAP server.

5) Primary and Secondary Authentication with LDAPs

The fifth setup does not involve the use of any on-prem Duo applications. In this setup, the Firewall will directly connect to a AAA or LDAP server for Primary authentication and authorization. Once successful, the Firewall will connect to the Duo Cloud using the LDAPs protocol for secondary authentication. There is no need to install the Duo Proxy or Access Gateway.

This setup is similar to the 3^rd one mentioned earlier, meaning two separate authentication destinations are used which are the AAA or LDAP servers and the Duo Cloud.

* Note: This setup is officially supported by Duo only on ASA and ASA with Firepower Services. Integration with FTD is technically possible but not officially supported. The FTD integration is limited to version 6.5+ and the FDM (Firepower Device Management) On-Box management service. FTDs that are managed by an FMC (Firepower Management Center) will not be able to use this setup.

The figure below illustrated the flow:VPN connection initiated to the Cisco Firewall. The credentials and second factor of choice is provided by the user.

1. The firewall sends a RADIUS or LDAP authentication request to the Primary Authentication source.
2. After successful Primary authentication, the Firewall sends a second authentication request to the Cloud using LDAPs (TCP port 636). Only the username and second factor of choice is sent. The password is never sent to the cloud.
3. Push notification is initiated and accepted
4. The Firewall accepts the successful response from the Duo cloud and allows VPN access to the user based on the attributes collected from the primary authentication source.

This setup works well for an existing VPN deployment that needs to enable MFA quickly and efficiently without installing additional on-prem applications. The only change needed is to add an additional authentication method on the Firewall without changing existing VPN configuration. In addition, two factor authentication is possible while achieving total separation of Primary and Secondary Authentication methods to satisfy Compliance requirements or possible security policies.

User Experience:

With this setup, the user will be prompted to enter their username, their password and their factor of choice in three separate fields as seen below:

The options for the second factor are Push, Phone, SMS or OTP from the Duo mobile App as explained earlier. A similar user experience is observed when using the Clientless WebVPN Portal.

Note, with this setup, it is possible to customize the user experience for the Clientless WebVPN Portal. Rather than showing a username, Password and Second Password field, the user will be asked to enter his Primary credentials first:

Once the Primary credentials are entered and confirmed to be correct, the user is presented with a prompt to choose their 2^nd method of authentication:

This customization applies only to the WebVPN portal and not to the AnyConnect Authentication Prompt. The link below explains how the Sign-in Page is customized: https://duo.com/docs/ciscoasa-ldap#modify-the-sign-in-page

The following table lists the Pros and Cons for this approach:

Pros	Cons
Easy to integrate with an existing VPN setup. No need to install any On-Prem Duo services such as the Duo Authentication Proxy or Access Gateway.	The firewall needs to communicate with the Cloud directly on TCP port 636. Need to make sure that this port is allowed to the internet from the Firewall without going through Proxies.
If ISE is used as the Primary source of authentication, RADIUS attributes such as DHCP attributes, Security Group Tags (SGTs), group-policy names, DACLs as well as CoA can be used.	Users not known to the Duo cloud can’t go through Inline enrollment with AnyConnect. Other enrollment options need to be used*. For more details, the following link can be used: https://duo.com/docs/enrolling-users
Password Management is possible with MS-CHAPv2 with this setup allowing the users to change their passwords through AnyConnect if they expire.	Duo Certificates need to be imported and managed on the ASA to trust communication with the LDAPs service of the Duo Cloud.
Features such as Profiling and Posture will work as expected since the RADIUS Change of Authorization (CoA) flow remains the same.
No chaining is used reducing the latency and allows greater flexibility.
No failover or redundancy considerations are needed for the secondary authentication.

* It is possible to manage 2FA devices and perform Inline Enrollment with Duo through the Clientless WebVPN portal if the customization mentioned above is configured.

6) Duo Access Gateway and SAML Authentication

The final setup uses the Duo Access Gateway and the SAML standard for authentication. In this setup, the Firewall acts as a Service Provider and the Duo Gateway acts as an Identity Provider. It supports inline self-service enrollment and the Duo Prompt for AnyConnect and web-based SSL VPN logins. Primary and Secondary authentication occur at the identity provider, not at the Firewall itself.

Cisco ASA SSO requires ASA version of 9.7.1.24, 9.8.2.28, 9.9.2.1 or higher of these releases, or 9.10 and later, plus AnyConnect 4.6 or later. Prior versions of ASA firmware and AnyConnect do not support SAML login or use a different browser experience.

Note: SAML is not supported on Cisco FTD firewalls at the time of writing.

The figure shown below shows the flow in detail:

1. VPN connection initiated to the Cisco Firewall.
2. The firewall redirects the user to the Duo Access Gateway (DAG). The user presents a SAML request to the DAG and is asked to enter a username and password.
3. The DAG checks the credentials with the AD. A third party SAML IdP can also be used instead.
4. If authentication is successful, the user is asked to choose a second authentication method which is sent to the cloud
5. Secondary Authentication is performed successfully.
6. The DAG replies to the AnyConnect user with a SAML assertion response indicating successful authentication
7. The AnyConnect client forwards this Assertion response to the firewall. The Firewall verifies that the response is from a trusted source, in this case it is the DAG, and allows the authentication to pass.
8. Optionally, the Firewall can check with a AAA server to perform Authorization for differentiated levels of access (DACLs, SGTs, Filters…etc). ASA can not perform authorization based on SAML attributes alone.

Note: The SAML authentication flow can also be achieved using Duo Single Sign-On instead of an On-Prem Duo Access Gateway. Duo Single Sign-on is a cloud hosted Security Assertion Markup Language (SAML) 2.0 identity provider that secures access to VPN as well as cloud applications with users’ existing directory credentials (like Microsoft Active Directory or Google Apps accounts). 

This feature is a public beta phase and available for use. The same concepts discussed earlier apply to the Duo Single Sign-on approach. For more details, the following link can be used: https://duo.com/docs/sso#overview

User Experience:

With this setup, the user will be presented with the following authentication prompt window when the VPN session is initiated. This Window is from the AnyConnect embedded browser:

Once the Primary credentials are entered and confirmed to be correct, the user is presented with a prompt to choose their 2^nd method of authentication:

The user also has the option to add or manage their settings and devices:

Finally, if a user has valid domain credentials but is not yet enrolled with Duo, they will see the following prompt after they enter their username and password:

The same user experience applies for WebVPN access through the browser.

The following table lists the Pros and Cons for this approach:

Pros	Cons
More pleasant user experience using the AnyConnect built-in browser.	No authorization capabilities using SAML and DAG. Must integrate with a AAA directly for Authorization. (DACLs, SGTs…etc)
Un-enrolled users will be prompted to enroll using Inline enrollment.	DAG installation and integration takes some time as opposed to Authentication proxy.
The user has the ability to add and manage 2FA devices from the Duo portal.	Extra considerations need to be taken into account when it comes to High Availability and Failover
If integrated with ISE for authorization, RADIUS attributes such as DHCP attributes, Security Group Tags (SGTs), group-policy names, DACLs…etc can be used.	The use of Password management is not possible with this setup. Users can not change their AD password through the AnyConnect authentication prompt.
If integrated with ISE for authorization, features such as Profiling and Posture will work as expected since the RADIUS Change of Authorization (CoA) flow remains the same.

Summary

Throughout this document, multiple methods to integrated Duo with the VPN infrastructure have been presented, each with its own advantages and disadvantages, components, flows and protocols. The table below summarizes the details discussed:

Integration Scenario	Protocols involved	Components used	RADIUS Chaining	Password Management	CoA Support	RADIUS attributes	Inline Enrollment	ASA Support	FTD Support
ISE RADIUS Proxy and Duo Authentication Proxy	RADIUS	ISE, Duo Authentication Proxy, Duo Cloud	Yes	No	Yes	Yes	Yes	Yes	Yes
Duo Authentication Proxy and ISE Primary Authentication Source	RADIUS	ISE, Duo Authentication Proxy, Duo Cloud	Yes	Yes	No	Yes	Yes	Yes	Yes
Primary and Secondary Authentication servers	RADIUS/LDAP	ISE/LDAP server, Duo Authentication Proxy, Duo Cloud	No	No	Yes	Yes	No	Yes	Yes
Duo Authentication Proxy and LDAP	LDAP	Duo Authentication Proxy, Duo Cloud	No	Yes	-	-	No	Yes	Yes
Primary and Secondary Authentication with LDAPs	RADIUS/LDAP and LDAPs	Duo Cloud	No	Yes	Yes*	Yes*	Limited**	Yes	Yes***
Duo Access Gateway and SAML Authentication	SAML	Duo Access Gateway, Duo Cloud	No	No	Yes*	Yes*	Yes	Yes	No

*     When integrated with a RADIUS server for authorization

**   Only through the Clientless WebVPN portal when Portal Customization is configured. Not possible with AnyConnect Authentication Prompt.

***  FTD Version 6.5 and only with FDM.

Resources

Duo for Cisco AnyConnect VPN with ASA or Firepower

Duo user enrollment

Duo Authentication Proxy reference guide

Duo Access Gateway

Multi-factor Authentication using Duo (LDAP) for RA VPN through REST API on FDM

Cisco ASA SSL VPN with LDAPs  

[Aref Alsouqi]

Top Work! Would be lovely to see a similar post with the configuration snippets of the ASA and Duo for each topology.

[zalkurdi]

Thank you Aref. I will keep it in mind for the next document. In the mean time, I have a reference section with links for the configurations if you are interested.

[Marvin Rhoads]

Excellent presentation of the options available. Thanks for sharing the work!

[zalkurdi]

Glad you liked it Marvin.

[_Warren]

This is amazing! Very well documented & comprehensive outline. @zalkurdi Thank you

[zalkurdi]

Thank you Warren.

[xjojackman]

Dear @zalkurdi

My customer needs to integrate DUO with Cisco ASA VPN and authentication ISE Posture.

I would like to know the configuration guide (ASA, DAP) scenarios number 3. 

Please send the configuration to me.

And I have any question Scenarios number 5 can support with ISE Posture? 

Thank you for sharing

[zalkurdi]

Hello,

I dont have the configuration available at the moment but the resources added at the bottom of the article should help you get started.

For the fifth scenario, I haven't tested posture specifically but theoretically it should work if you are using ISE as your primary authentication and authorization server.

Regards,

Zaid

[xjojackman]

Hello,  @zalkurdi 

Thanks for your reply to my question.
I see update the table Pros and Cons of scenario number 5. 
Have you tested it with ISE Posture?

[sabprabh]

Excellent article Zaid!! Very informative.

[taoli]

https://duo.com/docs/cisco   https://duo.com/docs/sso-ciscoasa