Duo: Here-a-Push, There-a-Push, Everywhere a Push-Push

Duo innovated with their 2FA (“Two-factor Authentication”) using mobile Push notification.

Although Duo’s primary focus is corporate, they have a great “freemium” version that is useful for SMBs as well as individual users.

This article takes Duo out for a test drive as well as a technical dive into Duo ssh configuration.

This is the last article in a series concerning 2FA with mobile Push notification. Previous articles looked at Google’s Mobile Push AuthN, and LastPass Password Manager.

Introduction

What and Why?

Duo is a cloud-based SAAS provider specializing in 2FA for a wide range of technologies. They innovated with the use of mobile Push notification for 2FA ease of use.

Duo is essentially oriented towards corporate AuthN. As a result their product integrates with a wide range of technologies: Vpn, Microsoft and Linux OS, as well as major web applications such as Splunk / Drupal / LastPass.

Duo’s OS integration

In particular Duo offers tight integration with native OS authentication:

• MS credential provider (cf MS Dev: Winlogon and Credential Providers )
• ADFS adapter provider (e.g. MS MSDN: Build a Custom AuthN Method for AD FS in Win Srv 2012 R2 )
• Linux PAM module (eg http://stackoverflow.com/questions/4841203/how-to-create-a-pam-module )

The tight integration with the native OS API allows Duo to support both remote and local access for MS and Linux.

Microsoft Windows

At time of writing, Duo outdoes Microsoft! Duo offers better, cleaner support than MS Azure Premium 2FA for MS’ own products!

As an example, look at MS Azure: Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS).

On MS Windows, Duo integrates with:

• ADFS
• OWA
• RD GW / RD Web / RDP, RRAS
• TMG / UAG.
• 3rd-party PC remote access products such as TeamViewer are also supported (as long as access occurs from the initial logon screen).

All of this is a direct result of Duo’s direct integration with Microsoft’s architected native APIs.

Linux

For Linux, Duo provides a PAM module. This means that Duo can integrate with anything that uses PAM. 

Applications supported include sudo, su, and ssh / scp.

Test setup

For Linux testing, the following systems were tested:

• Ubuntu 16.04 xenial
• CentOS 7.1-1511.

Windows 7 and 10 systems were tested.

Duo’s Mobile Authenticator was installed on an Android test phone.

Documentation

End-user guide:                 https://guide.duo.com/ 

Reference manual:        https://duo.com/docs 

What the testing showed

This section describes findings from the (limited) “hands-on” testing.

Federated AuthN

It rapidly becomes obvious that Duo is targeting large enterprises.

For instance Duo’s AuthN support for major Internet SAAS websites (e.g. Dropbox, AWS) leverages SAML federation along with a drop-in probe called the Duo Access Gateway. See for instance Duo Protection for Amazon Web Services (AWS).

If Duo is not available

Being an online service, Duo offers several layers of “backup” access.

This is essential. For instance “Murphy” can strike with a mission-critical server outage which also happens to take down access to Duo’s servers. The server sysadmins will still need “backdoor” access to their server even if normal Duo 2FA function is broken.

Duo provides several ways to obtain access in an emergency:

• Access can be configured to “fail open” if the onboard Duo component cannot “phone home” to the “mother ship”.
• 
  
• When an end user registers to Duo, there are multiple potential choices for the 2FA prompt. If one channel is broken, another can possibly still be up and working:

• phone call
• Duo mobile 6 digit codes
• SMS passcode
• U2F token such as Yubikey
• Duo Push

• 
  
• When a user logs into Windows or Linux, he can choose how he wants to be authenticated. For instance on Windows, the user types one of the following into the Duo prompt:

• A passcode (e.g. from Duo Mobile, SMS, hardware token)
• push
• phone
• sms (to get a batch of sms passcodes).

Push does not always work

Duo’s documentation mentions that “Push” might not always work – especially if the mobile phone is connected to cellular data and WiFi simultaneously.

During testing I noticed that running a VPN on the phone also seemed to confuse Duo’s Push notification.

Integration with Linux relies on PAM

Duo provides two methods for integration with Linux: an older login_duo, and pam_duo. PAM of course is the best approach for Linux because the same integration can address anything in Linux that is dependent on PAM: sudo, su, and ssh.

Potentially daunting technical challenge

However duo’s PAM integration is not for the faint of-heart:

• Sshd by itself can be complex to configure.
• The interactions between PAM and sshd can be quite subtle.
• Add SELinux to the mix (enabled on CentOS) and the technical challenges can be daunting.

The answer: Good documentation, thorough testiing

To help out, Duo documents detailed OS-specific recipes for different versions of the major Linux distros: CentOS, Ubuntu, RHEL, Debian, Amazon Linux, FreeBSD. See https://duo.com/docs/duounix for the details.

Duo also mentions the need to test thoroughly. This cannot be emphasized enough. There are many “moving parts” and things can break.

For this article, Duo integration with both CentOS and Ubuntu was (unit) tested (and eventually worked!).

• sudo and su more or less worked “out-of-the-box”.
• Sshd proved to be more of a technical challenge.

• logon with the Window manager also generally worked (some of the time - at least on Ubuntu).

See the “Gotchas” section below for more technical discussion and advice.

Duo in a production ssh environment

There are many things to consider before implementing Duo in a production ssh environment:

• Have the “boundary” error scenarios been identified and adequately tested?
• How will the “break-glass” fail-safe work? Is the approach truly robust under all potential conditions?
• Will all the servers be able to “contact the mother ship” with outbound https? From the DMZ and other isolated environments?
• What about production batch jobs that use ssh / scp? Duo will still try to authenticate these accesses unless specific action is taken.

Unusual user experience with Win10

The Windows integration showed signs that Duo’s developers took some shortcuts.

The logon has to occur using the “Other Users” version of the login screen. This results in an unusual user experience on Win10:

• At logoff the user is confronted with an apparently empty logon screen.
• The user has to find and click on the “Log on as another user” button at the very bottom / left of the screen.
• Next the user has to type in his username / password, then “Enter”.
• Finally the Duo 2FA prompt occurs.

“Gotchas”

Proxy support: “Sir, can you tell me which is the way to the exit?

This may seem painfully obvious but bears repeating.

The on-host Duo credential provider code has to interact with the main Duo servers out in the Internet.

This means that wherever the host is (isolated DMZ, protected internal zone), the host still needs “always-on” robust outbound https access to specific Internet addresses.

If there is a proxy in the path, then the host will need to interact cleanly with the proxy (including authentication if necessary) in order to communicate outbound.

1 logon ID == 1 license seat

With Duo, it is important to understand that 1 user logon ID requires 1 Duo licence.

If an administrator has different local account usernames scattered over the network, then each one will use a separate license.

Special treatment of MS domain accounts

Understand clearly the following basic concept:

The Duo “user” configured in Duo’s application must correspond exactly to what the Duo credential provider sees at the OS level.

Specifically only the local part of the user’s UPN is used (i.e. the part of the name before “@”). So Thomas.Johnson@myorg.com would have a Duo userid “thomas.johnson”.

For more information, see https://duo.com/docs/rdp-faq

If the wrong username is configured in Duo then the logon will probably not work. 

GPO setting “Interactive logon: Do not display last user name”

As mentioned above, Duo supports *only* the “Other Users” logon screen.

Duo’s Window FAQ says that the Windows host has to be configured using GPO (or locally with gpedit.msc) to enable the Security Policy setting “Interactive logon: Do not display last user name”.

Limited Windows protection

Duo does *not* protect the following accesses on Windows systems:

• Right-click “Run as administrator”
• Shift + right-click “Run as different user”
• PowerShell “Enter-PsSession” or “Invoke-Command” cmdlets
• Non-interactive logons (i.e. Log on as a Service, Log on as Batch, Scheduled Tasks, drive mappings, etc.)

“Fail-open”

If Duo is configured “Fail-open” (the default), then anything that interrupts the communication between the local OS and Duo’s cloud-based API will bypass Duo 2FA.

Examples:

• Configure “Airplane Mode” on a Win10 laptop’s logon screen
• Unplug the Ethernet cable from the PC or server.
• Use the VM hypervisor to temporarily shut down network access for a guest VM instance.

Given the above, it is clear that Duo is oriented more “enterprise” / “corporate server - application” rather than “personal” / “end-user PC or laptop”.

3rd-party Disk encryption not supported

Duo’s credential provider has to be the only 3rd-party credential provider installed on the Windows host.

3rd-party disk encryption software will usually input the Windows username / password before OS boot occurs. Then the disk encryption vendor’s credential provider will automate the actual login.

However since Duo’s provider disables all others, the disk encryption boot sequence will break.

Duo “Telephone Credits”

Duo caps the use of the freemium offering with their “Telephone Credits”. Essentially this is a (reasonably generous) upper limit on the number of SMS / phone call authentications that the account can do.

From https://duo.com/docs/telephony_credits:

If you ever exhaust your telephony credit balance, your users will not be able to receive authentication phone calls or text messages. They will still be able to authenticate using non-telephony methods: Duo Push, Duo Mobile passcodes, and hardware tokens.

Paid accounts are topped up every month. Free accounts have to buy more. Of course.

Admin access requires separate AuthN from normal Duo access

Duo Administrator Access has distinct Authentication from normal Duo access.

In a phone recovery situation, even though the normal Duo user “Push” AuthN might be working, the user’s access to the Admin Dashboard could still be locked out.

The 2 separate authNs can be seen by looking at the Duo mobile application. There will be two separate application entries. One will be marked “Admin”.

For the details see Duo Help: How does an admin re-enable Duo Push AuthN for their device? 

Understand and thoroughly test the Duo PAM Linux integration before deploying

As mentioned above, the Duo PAM-based Linux integration is somewhat complex. The main challenge is ensuring that ssh access is properly configured and working under all conditions.

Duo provides good documentation (referenced above).

Here are some comments to supplement what is mentioned in the official documentation:

• Consider compiling instead of using the Duo pre-compiled packages. This ensures that latest and greatest source is used and eliminates one possible area of problems.

• CentOS / RHEL come with SELinux enabled. Do not forget to update the SELinux policy to allow outbound https access to contact Duo’s servers for the 2FA challenge to complete. Note that this will require installation of the source code and associated development pkgs.

• When configuring PAM, it is probably a good idea to keep at least one root login shell open. PAM changes occur immediately once the file is saved.

• Once PAM is configured according to Duo’s directives, ssh password authentication is turned off in PAM. Only public key authentication will work (regardless of what is specified in the sshd_config file).

• To work properly with 64-bit Ubuntu, the fully qualified name of the pam_duo module had to be specified in the various configuration files. Eg. “/lib64/security/pam_duo.so”, not just “pam_duo.so”

• The key sshd directives are summarized here:

PubkeyAuthentication yes

PasswordAuthentication no

AuthenticationMethods publickey,keyboard-interactive

UseDNS no

ChallengeResponseAuthentication yes

UsePAM yes

Good general entry-level articles for ssh configuration with 2FA using PAM are:

https://sysconfig.org.uk/two-factor-authentication-with-ssh.html 

https://www.digitalocean.com/community/tutorials/how-to-use-pam-to-configure-authentication-on-an-ubuntu-12-04-vps 

Non-interactive ssh access

Non-interactive ssh access (e.g. scp in a batch script fired by a cron job) can have mission-critical importance.

A typical batch job cannot do an interactive 2FA logon. Duo’s default in this case is to first look in the environment to see if a 2FA method was specified in an environment variable. If not, then Duo uses the first available 2FA method for that user.

Probably what is really needed is to be able to turn off Duo 2FA selectively for batch job ssh / scp access.

This can be accomplished by adding selective “Match User” directives in the sshd configuration file.

Generally the configuration default would be:

AuthenticationMethods publickey,keyboard-interactive

To turn off PAM (and Duo) AuthN, the sshd directive for selected batch users would be:

AuthenticationMethods publickey

The Last Word

Duo, along with LastPass and Google Mobile Push AuthN provide powerful, “friendly” function to enable users to:

• Generate robust passwords and manage them effectively.
• Synchronize passwords across systems and share them between users.
• Authenticate cleanly and effectively to native Google applications using a simple Push.
• Do 2FA with mobile Push notification for Linux and Windows local and remote access.

Properly implemented and used, these technologies help mitigate abuse of logon credentials.