Overview
itopia CAS deployments are created as standards-compliant Remote Desktop Services (RDS) infrastructure; this allows significant flexibility and extensibility when configuring your environment. Many organizations now choose to enforce multi-factor authentication (MFA) for their administrators, end-users, or both.
CAS provides support for both of these scenarios through different mechanisms. This article will describe MFA support in itopia CAS and Cloud Desktop Deployments.
Using MFA with the CAS Admin Console
When administrators log in to the CAS admin portal (cas.itopia.com), they have the option to use external identity providers such as Google and Microsoft to perform single sign-on. These providers are enabled by default, so long as the identity in CAS (i.e. the administrator's username) matches the identity from the external provider (typically the email address, which is also the same as the username). If CAS receives a valid identity token from one of these providers, the administrator will be granted access to the CAS admin console.
Each of these platforms provides their own MFA support using both native and third-party providers. Therefore, if MFA is enabled on the external provider, that MFA challenge will be required to access the CAS admin console.
Administrators with the Organization Owner role in CAS can selectively enable or disable local CAS authentication or the SSO providers. If local authentication is disabled and the SSO provider is configured to use MFA, then administrators must complete the MFA challenge before accessing the CAS admin console.
To review your organization's authentication settings:
Log in to the CAS admin console as a user with the Organization Owner role.
In the top-right corner, click on your username and select Manage Organization from the drop-down menu.
On the General tab, scroll to the CAS Authentication section.
In the Authentication providers sub-section, review which providers are enabled. You can selectively enable or disable either provider; however, at least one provider must be enabled.
Enforcing MFA for End-Users
itopia CAS deployments implicitly support any third-party MFA solution designed for Microsoft RDS or Windows RDP. Typically, MFA solutions for RDS leverage some or all of the following mechanisms:
A custom authentication plugin can be installed on RD Gateway servers to trigger MFA challenges when users reach the RD Gateway. These challenges cannot be interactive --such as one-time passcodes (OTPs)-- and thus must be push-based notifications that return directly to the MFA provider
A custom Windows Credential Provider can be installed on Session Hosts that intercepts the user logon process and triggers an MFA challenge before user logon completes. Most organizations elect to use this mechanism as it supports both push-based and interactive challenges such as one-time passcodes.
Some providers include a plugin for the RD Web Access role in RDS deployments so that users accessing the RD Web portal via web browser must complete the MFA challenge before seeing their Remote Desktop and RemoteApp resources. This mechanism is rarely ever used on its own as it provides no MFA enforcement for the actual RDP connection, and it has any effectiveness if users only use the RD Web Access portal to access their remote desktops. This mechanism should only be considered a supplement to a custom WCP or an NPS plugin.
Using an RD Gateway Plugin
By default, the Microsoft RD Gateway role uses a built-in database to manage user authorization based on AD group membership. However, the RD Gateway role can also be configured to use Network Policy Server (NPS), a Windows role included in all versions of Windows Server. Some identity providers include an NPS plugin that can integrate with the RD Gateway role. NPS plugins are sometimes considered more secure because they prevent the user from even connecting to a Session Host before the MFA is completed, but they also don't support "interactive" MFA challenges such as one-time passcodes (OTPs); NPS plugins typically only support push-based MFAs such as notifications on mobile apps.
The diagram below illustrates the MFA process with an RD Gateway Plugin:
The user's connection is held by the RD Gateway server until authorization is achieved by the plugin.
The plugin sends an MFA request to the identity provider.
The user receives the MFA challenge on their registered device, such as a mobile phone.
The user completes the MFA challenge, and the identity provider tells the RD Gateway to permit the connection.
The plugin authorizes the users' session, and the RD Gateway server connects the user to their Session Host.
Using a Custom Credential Provider
A custom Windows Credential Provider (WCP) replaces the standard Windows login screen with a vendor-specific version from your identity provider. This option is usually the most effective method as it operates at the server level and provides users with a graphic representation of the logon process. To use this model, customers typically install the custom WCP on a custom OS image, and then use that image for their Collection Pools; as Session Hosts are created, they have the custom WCP built-in. Other options, such as installation via GPO or package-management solution, are also available.
The diagram below illustrates the MFA process with a custom Credential Provider:
The user is pre-authenticated by the RD Gateway server (using their Active Directory credentials and group membership) and connected to their Session Host VM.
At the Windows login screen, the Session Host activates the custom Credential Provider. The Credential Provider sends an MFA request to the identity provider.
The user receives the MFA challenge on their registered device, such as a mobile phone or, optionally, they receive a one-time passcode via SMS or phone call.
The user completes the MFA challenge, and the identity provider tells the Credential Provider to authorize the logon and the user is presented with their Windows desktop.
The vendor's WCP will "intercept" a user's login attempt, prompt them with an MFA challenge based on the rules you've configured, and then resume the login once the MFA has been validated.
Supported MFA Providers
The solutions below are commonly implemented by our customers in CAS deployments and have been verified by itopia; however, this is not an exhaustive list.
Azure Multi-Factor Authentication
Microsoft Azure MFA supports integration with the RD Gateway role using an NPS plugin. End-users can be verified using many methods supported by Azure MFA including push notifications and device compliance policies for Intune-managed devices.
More information is available from Microsoft: Integrate RDG with Azure MFA
Duo Security
Duo offers two different MFA models for RDS: the RD Gateway option supports a limited number of MFA challenges but offers slightly greater security, whereas the Windows Credential Provider option supports all MFA challenges provided by Duo but allows the user connection to reach the Session Host before the MFA challenge is validated.
More information is available from Duo: Duo Authentication for Microsoft Remote Desktop Services
Okta
Okta offers a Windows Credential Provider plugin that can perform an MFA challenge before the user is authenticated to their Cloud Desktop.
More information is available from Okta: Okta MFA for Windows Servers
Additional third-party solutions
RDS environments can support many other MFA products, most of which are offered as Windows Credential Provider plugins. The RD Gateway role can also integrate with many RADIUS-compatible systems for performing compliance scanning on client devices. For more information, refer to the documentation for your specific MFA provider.