2FA with Remote Desktop Gateway / RemoteApp / RDWeb / RD Web Client
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 by making a Network Deny Policy exception.
Group Policy for Session Hosts / RemoteApp hosts
Block the AuthLite 1-Factor Session 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.
Also make Network Deny Policy exception 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.
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.