Duo is not a new player to the multi-factor authentication world. Founded in 2010, Duo has built a powerful offering of on-premise application deployment, native cloud integration, and REST API capable security features encompassed into a single platform. It supports the full gamut of modern MFA methods, including app-based pushes, one-time use codes, SMS verification, phone validation, and hardware tokens. It’s not surprising then why Duo is now Cisco’s most recent acquisition.
With this acquisition, one of the first questions people may be asking is, how does Duo integrate with the existing Cisco portfolio?
Identity Services Engine (ISE) has become a staple of Cisco’s security portfolio. At its core ISE offers authentication, authorization, and accounting services using RADIUS and TACACS, but goes even deeper by providing a wide range of advanced features. Profiling, posturing, pxGrid, TrustSec, guest access, and more have been integrated into ISE over the years, making it a cornerstone of access control for many IT organizations.
But at the heart of it, ISE is a RADIUS server with Active Directory integration. And so is Duo. So how do they integrate, and would you even want to try?
Upon deeper inspection, we find that while ISE and Duo fundamentally perform the same function (responding to RADIUS requests for access control), they offer vastly different capabilities. Sure, ISE isn’t a MFA platform, so that’s an obvious advantage for Duo. But Duo has other advantages as well. Duo’s cloud-based GUI allows policy creation and enforcement for many criteria that ISE cannot implement as simply, such as:
· Access request country of origin
· Previously connected devices
· Insecure browser plugins
· Tampered/jailbroken mobile devices
· User biometric verification
· Personal or corporate device detection
ISE isn’t defenseless in this arena however, and offers powerful access control features that Duo does not have an answer to, including:
· pxGrid integration
· Downloadable ACLs
· Authorized VLAN to use
· Voice domain permission
· Security Group Tag
· Web redirection
This is where we begin to see that while ISE and Duo perform similar functions, they each have unique and complimentary feature sets. So is it possible to have your cake and eat it too, getting the best of both worlds?
Duo has existing documentation for integration with external RADIUS servers, such as ISE. In this architecture, an Authentication Proxy is deployed, which is a Duo component that is hosted on the company’s corporate network. This Authentication Proxy is used to provide RADIUS connectivity to on-premise applications, and in Duo’s documentation is recommended to be the RADIUS server that is configured for the application. The Authentication Proxy can then be configured to connect to Active Directory for authentication, or to ISE.
The issue that arises here is one of feature availability. This architecture works well for Duo, and maximizes the capabilities that Duo provides to the deployment. However, this comes at a cost to ISE functionality. For instance, the ability for ISE to identify the connecting machine operating system, the AnyConnect agent version, or the IP address of the connecting device are lost. Additionally, by default this configuration completely eliminates the ability to implement advanced ISE functionality such as dACLs or VLAN restrictions. This can be modified with additional configuration on the Authentication Proxy, but adds more steps to troubleshoot. And even then, Change of Authorization is unable to be implemented from ISE at all in this architecture, regardless of what options are configured on the Authentication Proxy.
This architecture does present benefits however, particularly with the native ISE integration with Active Directory. Specifically, this permits ISE to easily return different authorization parameters according to user groups within Active Directory. You’re just limited as to what those authorization parameters can be.
Now, this isn’t the only way that ISE and Duo can be deployed together. Another option is to reverse the order of this authentication process, configuring the application to authenticate to ISE, then have ISE authenticate to Duo.
This architecture enables full ISE functionality to the RADIUS authenticator, including the ability to implement Security Group Tags, CoA, dACLs, and any other option that would otherwise be supported between ISE and the application in question.
A few issues arise when we look deeper though. On the Duo side, we no longer have the ability to determine the public IP address the user is connecting from, and thereby cannot implement country of origin restrictions for users accessing Duo-protected resources. Additionally, in this design Duo would integrate with Active Directory, rather than ISE. This limits the ability for ISE to implement different levels of access control according to groups within Active Directory. This can be worked around by implementing multiple applications within Duo, applying the various levels of access control to each, and testing them in order from ISE to determine where the user lands, but the solution gets messy fast.
Regardless of which architecture you choose, both support the full range of MFA options provided by Duo. Using AnyConnect VPN terminated to a Firepower appliance, both architectures provide the ability to authenticate via push, access code, SMS, phone, and hardware token methods.
Looking to the future, I expect Cisco will begin to integrate Duo more fully with the current security portfolio. SAML functionality within Firepower is still missing, and would provide additional integration capabilities with Firepower VPN using AnyConnect. Additionally, today to integrate ISE to authenticate to Duo requires the administrator to configure Duo as a generic RADIUS token. I anticipate that Cisco will look to improve this integration to not only resolve these integration limitations between Duo and ISE, but also to build out even greater functionality and security capabilities.