AuthLite Interactive Documentation
Home
Contents
CLOSE
AuthLite Interactive Documentation
Quick Start: Install and protect Domain Admins AuthLite Features Supported Tokens
How AuthLite uses YubiKeys
Installation
What platforms are supported? Prerequisites and Installation Linux systems MacOS machines
Configuration
Licensing AuthLite Set up User Groups
Configuring AuthLite to use your Group Pairs
Setting up the "Group for New Users"
ENFORCE 2-factor Logons
Use Group Policy to enforce 2-factor on Windows servers/workstations Secure Administrative Accounts with 2-factor Authentication Enforce 2-factor on File Shares using Access Control Lists (ACLs) Partial enforcement of a server (e.g. Exchange) with "Forced 2-factor Processes" Enforce non-Windows machines with "Forced 2-factor Computers" Enforce 2-factor logon to Office 365 with AuthLite
Windows Workstation (Endpoint) Protection
Offline Workstation logon with YubiKeys Offline Workstation logon with OATH tokens Zero-client two-factor workstation logons Workstation Safe mode operations
Remote Desktop
2FA over Remote Desktop Protocol 2FA with Remote Desktop Gateway / RemoteApp / RDWeb / RD Web Client
Replay Windows to support RDP and other re-authenticating protocols Replay Behavior setting VPN and RADIUS Configuration
Using IAS/NPS for RADIUS with AuthLite Microsoft VPN Client settings Wireless 802.1x Authentication DirectAccess and NetMotion Mobility XE Configure Watchguard SSL VPN with AuthLite
Active Directory Deployment Notes
Administer tokens
CONFIGURE Token Settings dialog SET UP New Tokens
Provisioning Tokens Administratively
YUBIKEYS: Provisioning Administratively (Soft) OATH Tokens: Set up Administratively (Hardware) OATH Token Provisioning
Self-Service Provisioning
SET UP the Self-Service Web Portal USING the Self-Service Web Portal
MANAGE Existing Tokens DELEGATE Rights to Manage Tokens RECOVERY Tokens Multiple OTP Tokens for the Same User Multiple users with the same OTP Token Password Operations
How to Log In Event Logging
CLOSE

2FA with Remote Desktop Gateway / RemoteApp / RDWeb / RD Web Client

Walkthrough video for 2FA on Remote Desktop Gateway / RDWeb / RemoteApp
Walkthrough video for 2FA on Remote Desktop Gateway / RDWeb / RemoteApp

This video reviews best-practices configuration for Remote Desktop Gateway assuming you have a 2012 R2 or later server hosting it.  This also applies for "Remote App" and load-balanced Remote Desktop hosting without a gateway; basically anything that uses the connection broker.  This strategy requires AuthLite version 2.3 or newer to work.

Background

Starting in 2012 R2, the Connection Broker is always in the loop.  And it makes our life difficult by eating the AuthLite one-time passcode and only forwarding the username and password on to the session hosts.  So we can't just set up a replay window like we used to be able to do.  The session hosts *will not* see the OTP if we enter it in the old RDWeb logon, or the newer "Remote Desktop Web Client". 

The easiest user experience we can do is avoid collecting an OTP at all during the initial gateway/rdweb logon, and then ask for it later at the session host.  Letting users connect here with just password isn't too big a deal as long as you're restricting what resources are published through the gateway and you make sure all those resources enforce 2-factor the way you want.

Group Policy for Gateway / Connection Broker

Start by making sure the RD Gateway system is not blocking network logons for AuthLite 1-factor users.  (Here I'm assuming that the gateway is NOT also being used as a session host.  If it is, you need to apply both sets of policies to it.  This one and the following ones).

Group Policy for Session Hosts / RemoteApp hosts

Block the AuthLite 1F Tag for the user right "logon to remote desktop services".  That way even users on the LAN bypassing the gateway will still use 2-factor.  And we want the kerberos ticket to be 2-factor on those hosts so you can seamlessly connect to other resources that might require 2-factor.

Avoid placing a Network Deny for the session host machines.  We need 1-factor to work here or else the initial Network Layer authentication from the connection broker to the session host will fail due to not having an OTP.

OK, now we need a way to actually collect the one-time passcode, since we're not doing it at the RDweb logon.   We can publish a registry policy in the AuthLite policy settings area.  HKLM root, key name:

Software\Policies\Collective Software\AuthLite

to turn on a setting called "CredprovSecondChance", a string whose value should be "true" (without the quotes). This makes the AuthLite logon tile fail gracefully when it sees a 1-factor logon, and offer the user a chance to enter their OTP.  Make sure to install AuthLite MSI on the session hosts if you didn't already!  This setting won't do anything otherwise.

Make sure policy's updated on the gateway and session host via gpupdate.  

Testing

Log in with an AuthLite user but just with their username and password.  It's not a big deal to let this be 1-factor as long as you're careful not to allow access to  any resources beyond this point unless they have 2-factor enforcement.

Open a resource next. Notice that it loads, and very briefly you might see a flicker of an error message that the user doesn't have permission.  But right after that, you should see a dialog that asks you to enter your one-time code.