AuthLite Interactive Documentation
Quick Start: Install and protect Domain Admins AuthLite Features Supported Tokens Installation and Upgrading Configuration Token Management How to Log In
Fig. 1) Install AuthLite and configure to protect Domain Admin accounts
Fig. 1) Install AuthLite and configure to protect Domain Admin accounts

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.
  • If your result from the "Check-Group-policy" command is straightforward, you can run "Create-Group-Policy" to initialize a new AuthLite policy at the root of the domain.  This is safe to do, and will only affect users you place into the AuthLite Users group.
  • If you have more than one LAN subnet, the Replay Window created by the script is probably not sufficient.  See this section  for details on how to set its IP ranges.

Group Policy details

  • If you manually create your group policy instead of using the above Create-Group-Policy command:
    • Make sure you set all five "Deny" items under User Rights Assignment to your "AuthLite 1F Tag" security group.
    • For Domain Controllers, make an exception: override "Deny access from the network" so it does not block AuthLite 1F Tag.
  • If you have Exchange, make an exception: override "Deny access from the network" so it does not block AuthLite 1F Tag.
  • After creating a policy, run "Check-Group-Policy" again to evaluate the change.  Yellow lines indicate either no policy applied, or else the policy applied does not contemplate AuthLite denies.
  • If you have inheritance blocked from certain OUs, you may wish to run "Apply-Policy-Everywhere".  Or manually link the policy under each inheritance block.  This is less problematic than using "Enforce" on your policy to punch through the blocks.

User Provision and test

  • Switch an existing admin user from Domain Admins into AuthLite DA automatically by running the "Convert-User-Groups" command, with your domain admin user as a parameter.
  • If your user isn't a domain admin yet but you want them to be, just manually add them to "AuthLite DA" by hand.
  • 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.