...ecommended configuration is to use RADIUS. @Fel did a post documenting the methodology and it's here: https://community.centrify.com/t5/TechBlog/Howto-Enforcing-Multi-Factor-A...
Note: With the Centrify-Idaptive spin-out, the Self-Service and MDM Enrollment capabilities will continue to be supported by Idaptive. For more info about the split see the FAQ here: https://www.centrify.com/centrify-idaptive-faq/ this article is left here for historic purposes.
This implementation example will be left in this blog for historical reasons. Turns out that back in 2017 when this lab was set up, we did not realize that there was loss of functionality related to some of the drivers loaded by the PCoIP Credential Provider (including copy/paste and printer redirection). This is obviously not acceptable. We are working with Amazon and once they have an SDK and an integration path, we'll do it like we've done with others (e.g. McAfee). In the meantime, the recommended configuration is to use RADIUS. @Fel did a post documenting the methodology and it's here: https://community.centrify.com/t5/TechBlog/Howto-Enforcing-Multi-Factor-Authentication-MFA-on-AWS/ba-p/31883
Identity Assurance for Cloud-based Desktops
The goal of this article is to establish a lab to test MFA capabilities using Centrify technologies.
As per the IAM model below, the first step is making sure that users accessing your AWS WorkSpaces are who they say they are, and with Centrify you can employ a variety of multi-factor or step-up methods.
With Centrify, organizations can secure Windows Systems by providing:
Access control using Centrify Zone technology
Strong Authentication with MFA at login, screen lockout or remote desktop
Privilege Elevation for application or administrative desktop
A complex requirement for some organizations is to run their own Active Directory Connector and RADIUS infrastructure (see details here) however, with the Centrify Agent for Windows™ and the Endpoint capabilities of Identity Service, we can provide MFA at login and screen lockout while still using Simple AD.
In this lab, we'll use the Plan-Do-Check-Adjust methodology
Planning
Planning Topics
Define the Authentication Factors required for AWS WorkSpaces MFA These could be true 2FA (Push MFA, OATH OTP, RADIUS, etc), step-up (E-mail, Phone Factor, SMS) or Multi-Secret (security question); this defines your authentication profiles.
Define the use cases that require MFA:
At login
At screen unlock - will there be a grace period? (e.g. do not require MFA if the screen is locked less than 10 minutes)
At privilege elevation (if the WorkSpace is being used as a management workstation)
Configure which users get challenged for MFA (e.g. will there be users excempt?)
Will offline passcodes codes be allowed (for requiring MFA if the WorkSpace can't connect to the Centrify service? What will be the behavior of the dialog box?
What is the Directory architecture? There are different approaches for AWS-hosted (Simple AD, Microsoft AD or even your own using EC2 instances) Expect this to be the most important planning topic
How many Centrify connectors and what services are required?
What's required?
Knowledge of AWS concepts: VPCs, EC2 instaces, Security Groups, Directories and AWS WorkSpaces
Basic Knowledge of Centrify Identity or Privilege Service MFA
Identity Service or Privilege Service (SaaS) configured for MFA:
A Role with the Computer Login and Privilege Elevation (e.g. MFA Computers)
An authentication profile configured for Computer Login and Privilege Elevation
The AWS Workspace system has to trust the IWA root certificate for the tenant
A Centrify connector reachable by the AWS WorkSpace(s) VPC
AWS WorkSpace configured and running
A WorkSpaces Directory (Simple AD) and administrative credentials Note: any Active Directory or similar technology including Simple AD or any AWS or customer-managed Microsoft AD) will technically work as long as the communication requirements are met.
Your end-users must be populated in the directory with information for any MFA or step-up methods (e.g. telephone, mobile, e-mail, etc)
At least one Windows Server 2012 R2 and up EC2 instance in a security group that allows communication with the AWS WorkSpace Directory servers (HTTPS and TCP 8443 from the WorkSpaces systems outbound to the connector)
The connectors security group should have outbound HTTPS and Service Bus connectivity to the Centrify Identity or Privilege service instance.
Software Requirements:
Centrify Group Policy Extensions (available from the Server Suite installation bits)
Centrify Agent for Windows (tm) - available from the Server Suite installation files or the downloads section of the Admin portal for Identity Service or Privilege Service. This post uses version 3.4.2.
In this lab, we'll run a Centrify Connector in a Windows Server joined to the AWS WorkSpaces directory, this EC2 instance is in a security group that allows IWA and AD communication with the directory service and members. Alternatively, you could run the Centrify connector in a dedicated WorkSpace.
Implementation
Applies to: Centrify Agent for Windows™ 2017.1 to 2017.3 and AWS Workspaces Client 2.4.3.588
Last verified: February 2018
Lab Overview
Verify pre-requisites
Launch an EC2 Windows Server instance, configure DNS and install Windows tools and features (RSAT-ADDS, GPMC)
Join the system to the AWS WorkSpace directory and sign-in with an administrative user
Create Structure in Active Directory (OUs, users)
Install a Centrify connector the EC2 Instance and download the IWA Root Certificate
Download and install the Centrify Windows Group Policy Extensions
Configure PKI Trust and Centrify Agent Settings via Group Policy
Launch an Amazon WorkSpace and download/install the WorkSpace client
Configure the WorkSpace in the directory and authorize it for MFA
Connect to the WorkSpace and Install the Centrify Agent for Windows
Test your configuration
Lab Diagram
Implementation
1. Verify Pre-Requisites
The most challenging part of this lab is to figure out the communication paths between the systems. In this lab we are over-simplifying the process, but in a real deployment always use the minimum set of ports needed for functionality.
Communications between the AWS WorkSpace directory and your EC2 instances Go to AWS Console > Workspaces > Directories and expand your Directory, note the Directory ID and the IP Addresses (these are the IP addresses of your DCs and DNS servers) Go to AWS Console > EC2 > Instances > Security Group and select the Security Group designated for your EC2 Windows instances that will run the Centrify connector service (e.g. Connector group). Make sure that: - The connector group and the directory domain controllers can talk AD communications (DNS, Kerberos, LDAP, etc) - The members of the domain (including AWS WorkSpaces systems) and the connector can talk over HTTPSgroup and TCP 8443. - The connector group has at least outbound HTTPS and Azure Service Bus connectivity with the Centrify Identity or Privilege Service tenant.
2. Launch an EC2 Windows Server instance, configure DNS and install Windows tools and features (RSAT-ADDS, GPMC)
Log in to your EC2 console console.aws.amazon.com/ec2 and launch a current Windows Server instance in the security group designated for the connectors; this instance should have at least dual core processors and 8GB of RAM. In addition it should have outbound internet connectivity (direct or via proxy).
With the information collected about the AWS WorkSpace directory (the IP addresses of the directory servers), open the Network control panel (ncpa.cpl) and modify the TCP/IP properties of the network card. In IPv4, add one of the IP addresses of the directory DCs as the primary and secondary DNS server entries for the EC2 Windows instance. To verify connectivity, ping the domain, you should receive a response. Note that this can be also accomplished with a VPC option set.
Open an administrative PowerShell, and add the AD remote admin tools as well as GPMC. Install-WindowsFeature RSAT-ADDS, GPMC
3. Join the system to the AWS WorkSpace directory and sign-in with an administrative user
Join Active Directory using the System Applet or PowerShell
When prompted, provide administrative credentials to the AWS WorkSpaces directory.
When prompted to reboot, select yes, and reconnect to your system
Sign-in with a directory privileged user (e.g. administrator)
Verify that you can open the domain administrative tools like Active Directory Users and Computers (dsa.msc) and GPMC.msc
4. Create Structure in Active Directory (OUs, Users)
Note: These steps will be described at a high-level.
Open ADUC (dsa.msc)
Create 2 OUs, one for the WorkSpaces computers, the other for the test Users (e.g. Staff)
In the Staff OU, create your test users. Make sure you populate the information required for your MFA challenges (e.g. email and mobile number. I created two users: Lisa and Diana.
Stay logged in as a domain administrator.
5. Install a Centrify connector the EC2 Instance and download the IWA Root Certificate Note: for detailed steps to install a Centrify connector. Check out this help article.
Go to Admin Portal > Settings > Network and click Add Centrify Connector
Click on 64 bit, this will start the Connector download.
When downloaded, double-click and follow the wizard for setup (you don't need mobile tools), when finished the configuration wizard starts.
Provide the Centrify tenant information and credentials, then follow the wizard (you don't need the activation or deleted items option).
Verify that the Centrify applet displays a succesful connection.
Go back to the Centrify Admin portal and under Settings > Network > Centrify Connector, press refresh on your browser. You should see the newly-installed connector on the list, double click it and go to IWA Service, then click on the "Download IWA root CA Certificate" link, this will download the tenant's Integrated Windows Authentication certificate. This is required for the client to communicate to the service.
6. Download and install the Centrify Agent and the Centrify Windows Group Policy Extensions
In the Centrify Identity or Privilege Service, go to the Admin Portal
Click the administrator's name on the upper right corner and select Downloads and click Centrify Agents
Download the Centrify Agent for Windows and the Centrify Windows Group Policy Extensions
Double-click the Centrify Windows Group Policy Extensions and follow the wizard until the installation is complete.
7. Configure PKI Trust and Centrify Agent Settings via Group Policy
In this section, we'll distribute the IWA trust root certificate from the tenant using GPOs; we will import the GPO templates for the Centrify Agent for Windows.
Open GPMC and expand your forest/domain
Right click the WorkSpaces OU and select "Create a GPO in this domain and link it here" and give it a name
Right-click the newly-created GPO and select Edit, this opens GP Editor.
Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities and right click the white space in the right pane, select Import
In the Wizard, press next and then press browse to the location of the IWA Trust certificate from the previous section. Once completed, you'll have the certificate for the tenant in this store.
Now, navigate to the Configuration > Policies > Centrify Settings
Right-click Centrify Settings and select Add Remove Templates, then press Add
Select centrify_windows_settings, press Open, then Press OK.
Expand Centrify Settings > Windows Settings , you should have 2 sections: Common and MFA Settings
Expand MFA Settings and on the right side, double-click "Specify credential providers to exclude from the logon screen" and enable the policy. In the box, add this string: {003D4E42-9B59-4818-9352-17B3F5D4ACAF}, to the beginning of the list (note the comma separator at the end). This will exclude the credential provider installed with AWS WorkSpaces. Note: this step alters the connectivity behavior of the AWS WorkSpaces under that OU. This means that the Windows Credential provider will be displayed after connecting to the WorkSpace.
Leave GP Editor open, we'll return to it to make some tweaks.
8. Launch an Amazon WorkSpace and Download/Install the AWS WorkSpaces client
Go to your AWS Console > WorkSpaces > WorkSpaces > Launch WorkSpaces
Select a Directory: pick the directory you are working with and press Next Step.
Identity Users > select search for users (e.g. Lisa or Diana), check the box and Press Next Step
Select your bundle > pick your product (e.g. Windows 10 Standard)
WorkSpaces configuration > pick the options as needed, press Next Step
Review and launch > review and press Launch. You may have to wait up to 20 minutes at this step.
Follow the instructions to install the WorkSpaces client in your platform.
When the WorkSpace is available, note the registration information and register with the AWS WorkSpaces client, before connecting, continue to the next section.
9. Configure the WorkSpace in the directory and authorize it for MFA
Monitor the WorkSpaces until the system is listed as available.
In your connector Windows system, open ADUC (dsa.msc)
Go to the computers container, you should have a new system aside from the connector (e.g. IP-C0A8F12F)
Move the computer object to the WorkSpaces OU. (Note, this can be automated) This will ensure that the GPO will apply to the WorkSpace.
Now, sign-in to Identity or Privilege Service > Admin Portal > Core Services > Roles > [select your role; e.g. MFA Computers] > Members > Add > Check computers and search for the system name, when you find it check it and press Add, then Save. Now the system is authorized to do MFA requests. The next step is to connect to our WorkSpace, and install the Centrify Agent for Windows.
10. Connect to the WorkSpace, Refresh GPOs, Restart and Install the Centrify Agent for Windows
Connect to your WorkSpace
Since the Credential Provider is disabled, you may have to re-auth after connecting.
Open a command window and type gpupdate /force, then reboot the system.
After reboot, reconnect to the system and log in as the test user.
Browse to the location of the installation bits for the Centrify Agent for Windows and shift+right click > Run as a different user > specify a privileged account (This is because the user assigned to the workspace will not be able to install correctly) Welcome page > press Next EULA page > check the box and press Next Destination Folder > press Next Ready to install > press Install Completed page > press finish. This will start the configuration wizard. Note: the configuration steps below can be set via Group Policy.
Press Add Service, at this point, depending on the information in AD, the services are visible
Select 'Centrify Identity Services Platform' and Press OK
Select your tenant instance
Multi-factor authentication on Windows login > Enable > Press Add > select your test users (e.g. diana, lisa), press Next
The platform will attempt to enroll the system. If the IWA Root Certificate for the Centrify tenant was installed succesfully via GPO refresh, this should be fine; if not, an error indicating this will be displayed. You can, alternatively import the IWA root certificate manually into the trusted root certification authorities for the system.
The installation will prompt to reboot. Reconnect to start testing.
Checking Functionality (Testing)
Here's a quick test matrix:
Verify MFA at login
Verify MFA at screen unlock
Verify no MFA challenge if screen unlock is under defined grace period
Verify MFA with offline code if connector(s) are not available
Adjusting (Improvements)
Here are the potential improvements for this setup:
Add additional Centrify Connectors for High-Availability
Use WorkSpaces Application Manager to deploy Centrify Agent for Windows (tm) automatically
Use Group Policy to define which users are required multifactor
Use Group Policy to define if MFA will be required during Windows unlock.