AuthLite Interactive Documentation
Quick Start: Install and protect Domain Admins AuthLite Features Supported Tokens Installation Configuration Administer tokens How to Log In Event Logging
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.


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.  


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.