Duo Multi-Factor Authentication

We recently rolled out Duo Multi-Factor Authentication to 400 staff who use our remote mail and application services, and I thought I’d share my experience of the whole process.

Background

In July of this year Dutch Haga Hospital was fined €460,000 under new GDPR legislation. While the media mostly focused on the fact that staff had unauthorised access to the medical records of a Dutch celebrity, a large factor in the ruling was the lack of MFA at Haga Hospital. The Dutch UWV (Employee Insurance Agency) also faced similar fines if they did not implement MFA before October 31 2019.

This, along with some recent targeted phishing attempts, spurred our execs into action; there’s nothing quite like the threat of a large fine to free the flow of ink onto a blank cheque! So we were tasked with implementing MFA on our external environment within 2 weeks.

Environment and Requirements

We needed to protect our two public facing login portals; OWA, providing external access for staff to our on-premises Exchange 2013 environment, and Pulse Secure, providing staff remote access to a number of applications usually only available on the intranet, as well as a limited number of Remote Desktop sessions.

Our key requirements were:

1. A single solution that would cover both OWA and Pulse Secure
2. Ideally hosted on-premises
3. Ease of use for the end user
4. Fast deployment

Looking for a single solution that covered both Exchange 2013 and Pulse Secure proved difficult, and it quickly became obvious that Duo was the way to go.

As a hospital with sensitive medical and patient data, we strive as much as possible to keep all solutions on premises, where we have full control over data retention. Duo, as a cloud service, initially raised GDPR concerns, but given the speed at which we wanted to deploy MFA and the limited solutions available, we conceded that a cloud MFA service would be acceptable.

Thankfully, Duo has proven to fulfil requirements 3 and 4 with ease.

Install and Deployment

I trialed the solution in my lab first; Duo is completely free for up to 10 users, and I still have it running in my lab domain, I highly recommend trying it out.

Set up is incredibly easy for OWA; it simply involves running an installation package on your CAS servers, entering a few provided values (Integration Key, PSK etc), and then configuring your policy from the admin interface at duo.com. Your policy gives you flexibility to configure Duo on a per-application basis, to enable/disable MFA, exempt public IPs from MFA, enable/disable particular authentication methods etc. These policies are key in making a smooth transition to MFA.

Pulse Secure was a bit more involved, particularly since I don’t have much experience with the product and we needed to split the login page between staff and vendor support, but there is excellent documentation on the Duo site, with clear step-by-step install instructions specifically for the service/platform you are looking to protect.

Below is a typical high-level data flow diagram, and very close to what we’re running in production for OWA:

It’s useful to note that it is the secondary authentication device that makes the request to Duo, the request is not initiated from the internal network/CAS server(s). Since Duo sees the public IP of this device, you can use this to your advantage to minimise the number of users you need to enroll (and therefore reduce the number licenses you need to purchase), by adding the public IP to a list of “white-listed” IPs that can bypass MFA. For example, we have a few small remote clinics that do not have a VPN to our central hospital. To use mail, they browse to the public OWA address. By white-listing the static public address of these clinics in the Duo admin console, they could bypass MFA from internal devices.

To enroll users, we used a mixture of pre-enrollment, self-enrollment, and manual enrollment:

1. Pre-enrollment involved identifying users who already make regular use of OWA/Pulse Secure and importing their usernames into Duo. A word of warning here; pre-enrollment still requires the account to contain a mobile phone number for the user, otherwise the user will not be prompted to enroll on first login.
2. Self-Enrollment was employed on Pulse Secure, allowing very easy MFA enrollment for users on first login. This was disabled after a few weeks, once the vast majority of regular users were enrolled.
3. Manual Enrollment was used on OWA as an extra security measure; users would initially receive an “unauthorized” message on login, and would have to call our helpdesk to request OWA access and provide a mobile number. This allowed us to audit users of OWA, manage licensing, and ensure each user was authorised by their line manager to access OWA.

In terms of the above enrollment methods, self-enrollment is obviously preferred. It is a really simple, user-friendly and slick process. Check out the below 35 second video for a quick demo, it really is as easy as this:

Manual enrollment was of course a little more painful, both for our helpdesk and end user, but due to a few security concerns it was deemed a requirement. It was very helpful at this stage to have a supportive CEO who emailed all staff asking for their patience and co-operation with the new security measures. Orders from the top!

Once installed, Duo MFA works as you’d expect: users log on, and are offered a number of second-factor authentication options. There are many to choose from, such as a push to app (our preferred choice, and by far the easiest and most reliable for the end user), SMS, phone call, Duo app code, hardware tokens etc. Once authenticated, they proceed as normal to the service.

A quick note on phone call authentication. We very quickly realised this wasn’t a sensible option to offer users. Firstly, this is the only authentication method we found technical issues with. Multiple users claimed they were not receiving the call/there was no voice instruction when answered/pressing key to authenticate wasn’t working. In addition to this, callback authentication is the most expensive (more on these costs later), so we disabled callback soon after deployment. In hindsight, it would have been nice to identify this issue beforehand, as we of course then had to re-enroll users who were using callback as their authentication method.

Pros and Cons

One nice benefit of MFA was rooting out users who were sharing login details, as they could no longer login without having a personal device linked to the account. We found a number of consultant secretaries were using their consultant’s login, or even sharing this login among multiple secretaries. Of course they were none too pleased when they were found out! But it was great from a security point of view to stamp this practice out.

There’s also a nice feature available that we don’t currently use, but may in the future, although it relies on the majority of your staff being licensed in Duo. As a Duo admin, you are able to push an authentication challenge to a user’s device. A classic helpdesk challenge is verifying users who call in to have their password reset. A nice feature with Duo is to be able to send this user a challenge, which they can then approve to verify their identity.

As discussed earlier, from a technical point of view Duo is incredibly easy to install and roll out, it has benefits beyond MFA, and it quickly fulfilled a very important security requirement for our business. So what are the bad points? There are a few of course:

1. Cost.
2. Administrative overhead.
3. User privacy
4. User kickback

In terms of cost, Duo is at least transparent with it’s price (which you can see at https://duo.com/pricing), but it is a costly solution. Bulk discount doesn’t start at the user level we were purchasing, so at $3/€2.72 per user per month for basic MFA, our annual Duo MFA bill comes to over €10,000, which will most likely need to increase as we receive additional requests for remote access from staff. I would imagine that when the time (finally) comes for us to move to cloud for our email, the time will also come to review MFA with Duo.

You want to be wary of hidden costs too. The initial enrollment SMS messages that you can optionally send to users, as well as the SMS/phone call authentication methods that users can authenticate with, all cost “credits” on your Duo account. You are given 10000 credits for every 100 users. With each SMS costing 10 credits and call costing 20 credits, this can rapidly deplete, and is something you have to keep an eye on.

Administrative overhead is not something unique to Duo, but it’s something you have to be ready for with any MFA deployment. Your helpdesk will be inundated with calls from users looking for setup help, despite Duo having an incredibly slick setup process. Communication is key, and you should do everything possible to forewarn all effected users of the pending additional security measures. But no matter how well communicated, or how detailed the user guides you send out, a certain percentage of users will be unable to enroll without somebody on the phone to talk them through every single last step. This is draining, and your helpdesk ticket stats are going to take a hit during MFA deployment, so be wary of when you choose to roll out.

We found privacy to be a concern with many users. Firstly, there was quite a bit of resistance to installing a work-related app on a personal phone, and this is difficult to argue against. Thankfully many of our remote access users would also have company mobile devices, and those that didn’t were mostly content to install the app once the reasoning for MFA was explained to them, or to receive a work mobile. Some users were also concerned with what user data was being sent to the Duo Cloud Service during authentication. I will write more about this shortly, as not only are we continuing our own investigation into this, but Duo have just updated their privacy policy as of the end of this month, to reflect the privacy policies of their new owners, Cisco.

Which brings us to the final, and most frustrating problem we encountered during our Duo deployment: user kickback. People hate change. People hate anything that delays their work. People hate anything that encroaches on their private devices. MFA manages to fulfill all the above in one fell swoop! And when combined with people who have a chip on their shoulder, or who feel they are in a position of power and exempt from security measures imposed on others, you get some very spicy phone calls and emails! Two months into this deployment, and we still have a couple of users holding out, refusing to use MFA. It’s difficult to deal with these users, but they will inevitably have to concede, as even just one user being exempt from MFA can begin a process of further user resistance.

Takeaways

So in conclusion, if you are looking to deploy Duo MFA, the following are the key points to be wary of:

• Ensure you have covered off any privacy/data protection concerns your company may have in regard to cloud authentication.
• Understand the Duo traffic flow of authenticating devices.
• Understand the annual costs, including “hidden” call and SMS expenses, and factor in growth/increased requirements for remote access.
• Device beforehand which authentication methods you want to offer end users.
• Trial as extensively as possible all methods users will use to authenticate, across a number of devices and locations.
• Understand in detail what way your Duo Application Policies will effect user login.
• Document in as much detail as possible the steps users will need to take to enroll at login. Distribute this document to all effected users with as much notice as possible.
• Ensure you have complete support from the very top of your organisation for MFA, and ideally have your CEO or other high-ranking executive communicate the need for MFA to every user.
• Be prepared for increased help-desk tickets in the week or two after deployment, and be particularly wary of ticket saturation on the day of deployment.