2FA & SSO for RDG Apps
About this Document
In this document, we explain how AXS Guard system administrators can leverage the power of 2FA to enforce high-security for the protection of Remote Desktop business resources while also providing a single sign-on experience for end-users.
For end-users connecting to their desktops and applications, the experience is similar to what they already faced as they performed a second authentication in order to connect to a desired resource or application, except that the second authentication is no longer required.
Working Remote Desktop Web Access Deployment
It is strongly recommended that you have a working and tested Remote Desktop Web Access deployment before deploying AXS Guard 2FA & SSO.
In order to allow external connections through the AXS Guard RD Gateway, it must be configured with a certificate that is recognized by the devices of the end-users.
Administrators can use an SSL certificate issued by their internal CA (certificate authority), e.g. the AXS Guard built-in CA, or purchase a public trusted certificate from public CA. When using an internal SSL certificate, it will need to be imported on the RD Gateway as well as on all the devices of the end-users.
In this document, we assume that you are using a setup with certificates signed by a trusted public CA, which means you only need to import the certificate on the AXS Guard RD Gateway.
Gateway Access Token
The Gateway Access Token, based on Microsoft's pluggable authentication and authorization (PAA) framework, provides a single sign-on experience at the gateway level for Remote Desktop app users and enables system administrators to easily enforce strong authentication for Remote Desktop Services and applications.
When users log in with the AXS Guard RDP client, their RD back-end credentials are automatically stored or updated in their AXS Guard user profile via password auto-learning. This means users or administrators are no longer required to manually enter these credentials; they are automatically saved or updated on AXS Guard once they have been validated by the RD back-end.
The rollout of the AXS Guard RDP client is quite easy. Once the initial login of a user succeeds, various data provided by the user are saved in the Windows registry for reuse by the client, i.e. the FQDN of the RD gateway, domain, username and preferred RDP connector. Users can also update this data as required, which eases the administrative burden.
Server Side Configuration
- Log in to the AXS Guard appliance and import your RDG server certificate (PKI > Certificates).
- Ensure that RDG users are assigned an OATH or DIGIPASS token (User & Groups > Users > Username > Authenticators).
- Go to Reverse Proxy > RDG > Servers to configure the AXS Guard Remote Desktop Gateway.
Mind the period after the Certificate Common Name.
Select the desired authentication type, i.e. OATH or DIGIPASS and ensure that the
Password Auto-learning and
Use Gateway Access Token for SSO options are both enabled.
Client Side Configuration
- Log in to the AXS Guard appliance and navigate to Add-ons.
- Download the AXS Guard RDP client for Windows.
- Run the client and enter the requested information.
|RD Gateway||Enter the FQDN of the RD Gateway, e.g.
|Domain||Enter the NetBIOS domain name of the Remote Desktop back-end; this is the domain name without its domain suffix, e.g.
|Username||Enter the username. This name must be known by AXS Guard as well as the Remote Desktop back-end server (AD). The username will be saved in the Windows registry for future use, provided the initial authentication succeeds.|
|Password||The Windows password as known by the Remote Desktop back-end server. This password can be updated here as required by your organization's AD password policy.
Note that this requires the
|One-time Password||Enter the OTP generated by the user's OATH or DIGIPASS token.|
|RDP Connector||Select the preferred RDP connector, i.e. the built-in connector by Microsoft (default) or the FreeRDP connector.|