Many customers that we consult with are looking for solutions to handle Multi-Factor Authentication (MFA), Secure Access, and Adaptive Access Policies. These products, when implemented, will add an extra layer of security to Amazon Workspaces. We have settled on Duo Security by Cisco for our standard solution.
It works well with Amazon Workspaces, has a mobile interface that end-users like, and can layer on access, based on what is going on with the endpoint, such as current antivirus running, device patch status, and current browsers. The device insight about the make / model / version of the devices connecting to your environment is powerful as well.
We want to give an overview of how we deploy it in a normal environment and some of the challenges with deployment.
Reading the manual
There is an old adage in the IT community of “Read the Manual” especially when presented with complex multi layered authentication protocols such as IPsec, ADFS, or RADIUS. This is one of those cases where you should really go and read all the documentation from AWS and from DUO before proceeding.
Not only because it’s good for the experience points but also because in about two seconds I’m going to tell you to throw them into a supernova.
AWS has documentation on adding RADIUS MFA to your Directory Service and thus your Workspaces. DUO has documentation on both setting up MFA for AWS Directory Services and stand-alone RADIUS services. The DUO documentation for AWS Directory Service even comes with a CloudFormation script which I have yet to get to work right.
I suspect the errors have to do with the script’s over-reliance on built in AWS services such as the Systems Manager and Lambda and its high likelihood of not playing well with customized AWS VPCs. On the surface it appears to be an amazingly crafted script and I would love to see it work, however there just seems to be too much fragility for me to put it into production.
Building out the server
This leads us to building out our own RADIUS server, and we will follow the DUO instructions to a point. They are after all well crafted instructions.
Spool up an EC2 Instance of your choosing. I typically run a stock Windows Server 2019 AMI so I can domain join the instance and exert a bit more control over it, however if you want to do this using Linux then more power to you.
I run my standard AWS Windows Server Bootstrap protocol which runs Windows Updates, installs a preset list of applications, and runs the domain joining for me in the User Data field. Once the Instance is done cooking I connect over to it and start following the parts of the DUO documentation that I haven’t thrown into the supernova.
- Our first step is going to be logging into our DUO account and setting up the RADIUS application, per steps 2 and 3 in the DUO RADIUS setup Documentation.
- Next, we will need to download the DUO Authentication Proxy application to the server. For Windows this will be a .exe file available from the DUO support page, for Linux the RADIUS Setup Documentation has the appropriate and current yum, apt-get, and install commands.
- Finally, we get to where the paths diverge. Open up the C:\Program Files (x86)\Duo Security Authentication Proxy\conf\authproxy.cfg file in your preferred text editor. My bootstrap protocol pre-installs VSCode for me so I will go ahead and open it up with VSCode. Here we will have a pre-filled “sample” config file and an attempt to describe how it is supposed to be configured.
The DUO RADIUS Setup Documentation also makes an attempt at telling you how to configure this file in several different situations. There is even an entire page dedicated to the Authentication Proxy Config reference. Throw it all into the supernova.
Writing the file
So, honesty time. I’ve been a little dramatic because, well, it’s fun. These documents are perfectly valid, when utilized appropriately. However, since we are using this for workspaces, and are going to be using RADIUS to authenticate a proxy which authenticates to AD, which authenticates to DUO, I wouldn’t call a causality loop utilizing anything properly. But at the end of the day this is going to work, so go with it.
Now you are probably asking me, “Great, I threw my guides on how to write this file away, what now?” Not to worry, this is what the file is going to want to look like at the end of the day. First are some variables, what they mean, and then where they go in the language of the authproxy.cfg file.
- $APP-IKEY = The Integration Key Value in your DUO Application
- $APP-SKEY = The Secret Key Value in your DUO Application
- $APP-APIHost = The API Hostname Value in your DUO Application
- $Directory-IP1 = The first IP address listed AD Connector IP Addresses field in your AWS Directory Details.
- $Directory-IP2 = The Second IP address listed AD Connector IP Addresses field in your AWS Directory Details.
What we have here is a fairly simplified version of the authproxy.cfg file. The [main] Section is limited to just the debug status, there is no Client section, and the Server section is configured for DUO Only which will act as passthrough authentication to the DUO service. The last part is super easy. Just head over to the AWS Directory Service console, go to your Directory’s Networking and Security tab, and Enable the MFA section.
You will need the Internal VPC IP of your RADIUS Server, your Shared Secret ( I used correcthorsebatterystaple in my example ), and leave the rest as the defaults. Once enabled you will be utilizing DUO MFA with your workspaces in no time.
Implementing multi-factor identification
Implementing a Multi Factor Authentication (MFA) solution for Workspaces can have some initial implementation challenges, but once setup and functional will provide additional layers of security for your virtual desktop deployment. Having a zero-trust stance on endpoints connecting to your environment reduces risk.
We find that deploying Duo on Workspaces has become one of our best practices, you should give it a try in your environment.