In this section we'll install AuthLite and do the minimum configuration to strongly protect Domain Admin accounts. For a video walk-through of all these steps, see Figure 1.

Install and License

AuthLite must be installed on all DCs. To do this you need to be Domain, Enterprise, and Schema admin.
It is possible to log in with 2-factor even on member machines that do not have AuthLite installed, but you will have degraded experience. File shares and other remote tools may not reliably work (without using cumbersome workarounds). Therefore, you should consider installing the AuthLite MSI anywhere you intend to log in interactively and manage network assets.
After installation, request a license key.

Default Setup

From the start menu, run the AuthLite Admin Powershell
(If it is not UAC-elevated, run the "uac" command to restart the prompt under elevation)
Run the function Do-Default-Setup to initialize several important groups and settings to standard values that are correct for most customers.

Group Policy details

Do-Default-Setup will automatically run the command Create-Group-Policy.
AuthLite's policy will tell the computers in your domain to watch for logons by users in the AuthLite Users group, and make sure they are 2-factor. The setup takes a backup of any policy objects before changing them, and they are stored in your user's home directory (i.e. C:\Users\<YourUsernameHere>).
You should see a printed tree of Organizational Units color-coded by whether the AuthLite policy is successfully reaching them. If you have OUs not showing as green, it may be a good moment to pause and ask for help. Yellow lines indicate some other policy line blocking a Deny item that AuthLite needs, and purple lines indicate no policy at all is reaching that Deny item.
If the OU list is too long for the screen, a copy of the file is saved (Without colors) to "GroupPolicy.txt". Look for OU lines that don't show as Type="AuthLite Policy".
You can re-run the policy checker any time you want with the command Check-Group-Policy
If you manually create your group policy instead of using the above command:
- Make sure you set all five "Deny" items under User Rights Assignment to your AuthLite 1-Factor Session Tag security group.
- For Domain Controllers, make an exception: override "Deny access from the network" so it does not block AuthLite 1-Factor Session Tag. You can do this by linking the included policy named, "Computer: Allow Network Access by AuthLite 1-Factor Session Tag (override Deny)" to the Domain Controllers OU.

Analyze your Power Users, Prepare Break-Glass Account

Run the command Print-Users-In-Power-Groups. This will list every group that has an admin-level of control over your domain, and which users are members. It will also include nested groups.
The security advice listed is tailored to each group.
You need an emergency/break-glass account to use in the event of AuthLite getting misconfigured, uninstalled, or otherwise breaking unexpectedly. Keep one Domain Admin user outside of AuthLite control. Give it a strong randomly-generated password, and save it in case of emergency. It is important to keep this password apart and not use the account for anything. If you have to log in with this user, then you should change the password again once you're done. The point is to protect the password from being recorded or the hash from being cached.
The built-in Administrator account cannot be fully secured by AuthLite since it can't be removed from the Administrators group, so that might be a good one to use for your break-glass. Or, if that account is disabled, you can make another admin account for this purpose.
Remember the break-glass admin account must be a member of Domain Admins, and must be Enabled. If it's disabled or not powerful enough, you won't be able to use it for rescue.

User Provision and test

Switch an existing admin user from Domain Admins into AuthLite-Protected Domain Admins automatically by running the Convert-Admin-Groups command, supplying your domain admin's username as a parameter.
If your user isn't a domain admin yet but you want them to be, you can just manually add them to AuthLite-Protected Domain Admins by hand. The benefit of the Convert-Admin-Groups command is that it makes sure you haven't missed any dangerous power groups.
Provision token(s) to the user
Test by RDP with that account into one of the DCs. Domain controllers will "let you in" to the first logon prompt with just password, but then prompt for the OTP at the graphical RDP window.
Test RDP into a non-DC. These systems will demand 2-factor authentication even at the first RDP prompt, so you can't just do username and password any more. If you're launching the RDP client from a machine that is not an AuthLite-aware domain member, then you have only the username and password field. Therefore, you should put your OTP code into the username field as shown here.

A Few Common Issues

If your AuthLite users have Exchange mailboxes on-premises, make a group policy exception for the Exchange server. Override the Computer->User Rights Assignment "Deny access from the network" so it does not block "AuthLite 1-Factor Session Tag". You can do this with the included policy named, "Computer: Allow Network Access by AuthLite 1-Factor Session Tag (override Deny)"
If your AuthLite users will need to access SQL Server Management Studio, then the SQL service must have its kerberos SPNs set up correctly. Microsoft supplies a tool to do this: SQL Kerberos Configuration Manager.

YubiKeys