Our Digital Workspace consulting practice engages with customers each day who are moving their applications and desktops to public cloud services. Many of these customers no longer want to keep buying, managing and then replacing hardware every few years with all the associated costs of time and money. We’re seeing a particular trend for moving existing virtual desktop and application environments with their significant hardware footprint into cloud based services such as Amazon WorkSpaces, Amazon Appstream and Citrix Cloud. We often help our customer to choose the the Cloud service that fits the current and future needs of their business. But one common thread is security – no customer wants to compromise security as they exit their own datacentre and move applications onto public cloud. Multi-factor authentication is a long held standard by most companies for staff accessing virtual applications and desktops from remote locations. This article shares our experience when setting up multi-factor authentication with Amazon WorkSpaces and RCDev’s OpenOTP radius token service.
Summary of Steps
- Firstly we assume that you have set up Amazon WorkSpaces with Single Factor authentication. For help connecting your Active Directory to Amazon Workspaces, take a look at our blog article Connecting your AD to AWS in 5 Minutes
- Launch a new RCDev OpenOTP instance from the AWS Marketplace Community AMI’s
- Configure your Active Directory to work with the OpenOTP service
- Configure the OpenOTP instance with your Active Directory details without extending the AD schema
- Test the OTP service
- Configure the Radius Bridge on the OpenOTP instance
- Configure your AWS Directory Service for Multi-Factor authentication using the OpenOTP instance for Radius
- Test Amazon WorkSpaces with Two Factor Authentication
1. Set up Amazon Workspaces with Single factor Authentication
AWS generally create very good documentation for their services, and Amazon WorkSpaces documentation is no exception. Follow the steps at these links to establish your Amazon WorkSpaces environment.
- Get Started with Amazon WorkSpaces Quick Setup
- For help connecting your AD to AWS, check our blog Connecting your AD to AWS in 5 Minutes for a step by step guide
2. Launch a new RCDev OpenOTP instance from the AWS Marketplace Community AMI’s
Aside from a good number of very handy security features on a single virtual appliance, the great thing about RCDev’s OpenOTP server is that the first 40 licences are free. Therefore it’s the perfect place to get enterprise sized Amazon WorkSpaces deployments started and tested with minimal cost, and also great for smaller businesses who have less than 40 users of Amazon WorkSpaces. If you need to extend beyond 40, you can always contact RCDev for paid licences.
- Within the AWS EC2 console, launch a new instance from the Marketplace. Search for OpenOTP and you should find the WebADM OpenOTP Virtual Appliance, as below. Note these instructions are based on the appliance version 1.5.13.
- We use a Nano instance type.
- Select Networking and VPC settings appropriate for your AWS environment. Note that the OpenOTP appliance does not need to be on an external network, but it does need to be on a network that is routable from the Elastic Network Interfaces (ENI’s) of the Amazon AD Connector’s for your environment. You can check the IP details of the ENI’s from the “Details” page of your directory in the AWS Directory Service Console.
3. Configure your Active Directory to work with the OpenOTP service
- Create a new service account within your AD with normal domain user read-only access
- Create a new Organisational Unit under the root of your domain called WebADM
- Assign admin privileges to the service account for the new OU. Use the Advanced Settings to ensure these privileges are applied to “This object and all descendant objects” for the OU.
- Within Active Directory Users and Computers, find the top level search OU that will be used for OpenOTP searches for AD Users. Right click and choose delegate. Select the user service account, and then select “Create a custom task to delegate”. Now select “bootabledevice objects” and after selecting Next, choose:
- Read bootParameter
- Write bootParameter
- Click next and apply these settings.
- Repeat the previous step for delegating control for the service account, again select “Create Custom Task to Delegate”. Scroll to the bottom of the next list and select “User Objects” and click Next. Then select “General” and select all available permissions. Finish and save the delegation changes.
4. Configure the OpenOTP instance with your Active Directory details
- Connect to the OpenOTP service using Putty and the credentials you saved when creating the instance. If you are new to this it’s best to get some help from an AWS Consulting Partner . If you are just “playing around”, read this guide from the Amazon website.
- Change the permissions on the key files so that the OpenOTP server can be configured by executing these commands with root privilages:
sudo chmod 777 /opt/webadm/conf sudo chmod 777 /opt/webadm/conf/webadm.conf sudo chmod 777 /opt/webadm/conf/objects.xml sudo chmod 777 /opt/webadm/conf/servers.xml
- Replace the webadm.conf and objects.xml files with versions that do not require extension of the Active Directory schema by running these copy and past commands within Putty:
cp /opt/webadm/doc/ActiveDirectory/Schema_Not_Extended/webadm.conf /opt/webadm/conf/ cp /opt/webadm/doc/ActiveDirectory/Schema_Not_Extended/objects.xml /opt/webadm/conf/
- Now we need to edit these files. To keep things simple for newbies, connect to the OpenOTP instance using WinSCP in order to browse the file system, and edit the files using the inbuilt WinSCP editor. Firstly, within WinSCP navigate to /opt/webadm/conf and simply double click on the file webadm.conf to edit the file. Look for the proxy_user section and change the details to reflect the details of your service account (but using the correct password), like the below example. Its very important to make sure that you have the Distinguished Name (DN) of your account correct by checking the Properties of the account within the Windows ADSI Edit tool. Don’t guess this as it can be a real time waster.
proxy_user "CN=openotp_svc,OU=Users,DC=peninsula-it,DC=net,DC=au" proxy_password "**********"
- Still within webadm.conf file, look for the super_admins sections. Change the default details with the correct locations for your admin account and also the location of your domain users group. Again, use ADSI Edit to ensure you have the correct DN’s.
- Now we specify the location of the WebADM OU that we created earlier. Again, within the webadm.conf file, do a find and replace as follows using the correct details for your WebADM OU and domain – again, use ADSI Edit to ensure the DN’s are correct. Remember to change the details below in the “Replace” section to match your own OU structure:
- Within the WinSCP editor save the changes to the webadm.conf file. You may get an error about saving file attributes, but don’t worry about this as the file contents will be saved (you can double check this to be sure).
- Again within WinSCP navigate to /opt/webadm/conf and double click on the file servers.xml to edit the file. Scroll down and edit the location of the LDAP server (s) using the details of your own domain controller (s), like the below example.
<LdapServer name="LDAP Server" host="192.168.1.130" port="389" encryption="NONE" ca_file="" />
- Save the servers.xml file (again ignoring errors about saving attributes) and then restart the webadm service via the Putty commandline:
sudo /opt/webadm/bin/webadm restart
Make sure you check for errors as the service is restarted.
If there are LDAP errors as shown above, you should go back and check that you have assigned the various Distinguished Names correctly in the configuration and that the account and password details are correct. Make changes and then restart the service again to see if you have cleared the errors. To debug errors check the log file location at /opt/webadm/logs/webadm.log on the OpenOTP server.
- Using a web browser, navigate to the WebADM console using the IP address of the OpenOTP instance. Login using the Distinguished Name for the super_admin as specified in the webadm.conf file earlier
- After login, you will be prompted to finish the install. Scroll to the bottom and click Create Default Objects and Containers. This will create all the AD Objects in the WebADM you created earlier.
- Check the results of the above operation. If there are errors, they need to be cleared. Check items such as:
- The DN given for the dedicated WebADM container in the webadm.conf file may be incorrect. Make sure you use ADSI edit to confirm that the DN is correct (for example, make sure it uses the syntax OU instead of CN where needed).
- The Proxy user account does not have sufficient permissions on that OU.
- Assuming the errors are now cleared, logoff and log back on using the normal samid username of the service account, (not the DN). Click on Admin in the top left of the screen and then select Local Domains.
- Select the domain you just created and click on rename, and then change the name of the domain to the netbios domain name of your domain. Then click configure, and:
- Update the default domain alias by entering both the FQDN and NetBios domain name, separated by commas.
- Update the LDAP query search location in the “User Search Base” field to improve the speed of LDAP searches during logon. Make sure you don’t specify a query location that is too narrow and hence does not capture all needed user accounts, including administrators. Be sure to use ADSI Edit to make sure that you have the correct Distinguished Name. When done, click Apply at the bottom of the page and then click OK to close the Default Domain admin screen.
5. Test the OTP service
- To activate a user for testing, use the tree view in the left side of the WebADM web page to select the user you are seeking to activate. Once selected, click “Activate Now” on the right side.
- Specify a description, click Proceed and then click Extend Object to enable the user account AD object to be updated with the WebDAV objectclass. The user should now show as activated, ready for multi-factor configuration.
- Open the Applications tab and select Register. The status will quickly change to enabled.
- Now click on Configure and ensure that the default domain is selected and that the domain you configured earlier is showing like the example below. Scroll to the bottom and click apply.
- On the left side of the screen, select the user account that was activated earlier and then select “MFA Authentication Server” on the right side.
- Select Register / Unregister OTP tokens
- Select “I use a QRCode-based Authenticator (Time-based)” and a QR Code will appear. Use a supported token app such as the Google Authenticator phone app to read the QR code. Once the code has been added to the Authenticator Phone app, click Register on the admin portal. A message will appear confirming that the token is now registered.
- Navigate back to the user account on the left side of the admin portal, and for that user again select Configure. Click on OpenOTP on the left side, and then select Login Mode and OTP Type on the right side. Set the configurations to require OTP password only and also ensure that the OTP type is still listed as TOKEN.
- For testing the test-users token, go back to the test user’s configuration page, and select MFA Authentication Server
- Scroll to the bottom and select Test User Login. Enter the username, password and current token from the Authenticator app like the example below.
- If the details were entered correctly, a success message should appear.
6. Configure Radius Bridge on the OpenOTP instance
- We need to specify the Radius password. In your Putty session connected to the OpenOTP instance, execute these commands to enable editing of the configuration file:
sudo chmod 777 /opt/radiusd/conf/ sudo chmod 777 /opt/radiusd/conf/clients.conf
- Using WinSCP, edit the file /opt/radiusd/conf/clients.conf.
Scroll to the bottom of the file, and change the secret password from the default shown below (make it ideally 16 random characters in order to secure the radius protocol).
- Make sure you use AWS security groups to secure the Radius server appropriately. For testing we will allow connections from any client as shown above and not change the ipaddr setting apart from the password.
- Save the file and then restart the Radius Bridge service with this command:
sudo service radiusd restart
- Ensure that you record the password from this step as it will be needed when configuring Amazon Workspaces.
7. Configure AWS Directory Service for Multi-Factor authentication using the OpenOTP instance for Radius
- Update the Security Group configuration for the OpenOTP server to allow inbound connections from the AWS Directory services ENI’s (elastic network interfaces) security group. First you need to find the name of the AWS Directory services security group opening the Amazon WorkSpaces web console, as below.
- Edit the Security Group inbound rules for the OpenOTP servers and add a rule to allow inbound UDP traffic on port 1812 with a source as the Directory Services security group from the previous step.
- Now open the AWS Directory Service console, and select your Directory. Select the Muti-Factor authentication tab at the bottom.
- Check the box to enable Multi-Factor authentication as shown below. Specify the password used when configuring the radius bridge in the earlier step and also PAP as the authentication protocol. Change the timeout to 20 seconds and then click “Update Directory” on the right.
- The previous step is the moment of truth. If Radius is working correctly, you will receive a COMPLETED message. If there’s something wrong with your setup, it will time out after 5-10 minutes with an error stating FAILED.
8. Test Amazon Workspaces with Two Factor Authentication
Now that Radius is configured and tested we need to test that Amazon Workspaces now prompts for a token code.
- Download the Amazon WorkSpaces client from https://clients.amazonworkspaces.com/
- Once installed, launch the client and enter the username, password and the Token code from Google authenticator.
- If authentication is successful, the WorkSpace should launch quickly in the same manner as it did before implementing MFA authentication.
RCDEV’s online documentation and howtos: Active Directory with WebADM