Knowledge Base

Getting an Evaluation

You can evaluate the AuthLite software at no cost. Downloads of the documentation and installers can be found on the downloads page.

To get an evaluation license, see the PDF documentation section "Licensing AuthLite". You will need to install AuthLite on your domain first. After restarting the first DC and logging on, the AuthLite Configuration application will appear, with the required License ID.

If you need to buy YubiKey tokens for testing, please contact us. You can return them in good condition for a refund (less shipping) if you decide not to keep AuthLite.

You can also get YubiKeys from many other vendors including Yubico, the manufacturer. Make sure not to get the blue "security key" model, since that is not actually a Yubikey and doesn't support the OTP and C/R modes needed by AuthLite.

You may also find the "version 2" videos to be of interest, on the videos page.

AuthLite can be very lightweight when configured properly for your environment, but it has many complex possibilities that can be confusing when you are getting started. Please do not hesitate to open a support request from our support page if you get stuck or have questions about how best to configure AuthLite!

Free upgrade / upgrade prices

You are always welcome to install the latest version number of any product you have licensed. See the Downloads page for the available versions.

For minor version updates, usually "just install over and click through" is fine. The installer or Configuration tool will alert you if any changes require your attention.

We cannot guarantee upgrades between major version changes will be easy or "just click through". For example, v1.2 -> v2.0 was a very different product, and it's best to ask for our help to plan the migration of your servers, workstations, and configuration.

If you have any questions about upgrading or changing your license, please open a support request for assistance.

How do I talk to a real person?

If you have a technical question and can't find the answer here, please open a support request from our support page.

If you have a sales question or other non-technical inquiry, please see our contact page

How to update

You can always download the newest version number of each product from this web site. In general, you can simply run the new installer to upgrade over the old copy, automatically preserving your settings.

In some cases it may be necessary to uninstall the old version first, or to reboot services or the machine afterward. The installer will tell you if any of these things are required.

If you have any questions about updating, please don't hesitate to open a support request for assistance.

Installation Prerequisites

Some of our products require certain Microsoft software to be installed first.

In order to install some products, you may need to first download and install certain Microsoft updates. The installer will tell you if you lack a necessary feature, and direct you to this page for download instructions.

Microsoft .NET Framework

AuthLite version 2.0 and earlier, and our ISA/TMG plugins require .NET version 2 or later.
AuthLite version 2.1 and later require .NET version 4 or later.

Windows Server 2003-2008, Windows XP and 7

You can install the .NET framework by downloading the installers from Microsoft.

Windows Server 2012 and later, Windows 8 and later

These Windows versions come with v4 or later of the .NET framework.

AuthLite and Citrix

You can use the Citrix W.I.'s built-in ability to use 2 factor authentication, with AuthLite Split-mode users.Citrix will authenticate the username/password combo the same way you have it set currently, and then it will send the username and OTP over RADIUS to AuthLite for the second factor authentication.

You may either use the AuthLite RADIUS service, or the IAS/NPS plugin if you require the flexibility of using IAS/NPS for your RADIUS server.

Configuring to use IAS/NPS for RADIUS

On each DC you want to use for authenticating Citrix users:

Install the Internet Authentication Service (called Network Policy Server on 2008 and higher)
In AuthLite config, go to Service Configuration -> IAS/NPS plugin
Enable IAS/NPS support on this server
Apply changes
Restart the AuthLite and IAS/NPS services to pick up those changes
In the IAS or NPS configuration panel on this server, set up the Citrix WI as a RADIUS client
Set the shared secret
Set up a connection policy that will use PAP authentication

Citrix WI configuration

An overview of settings you need in the Citrix Web Interface site:

Authentication method: explicit
Authentication type: windows
Credential format: Domain user name only
Display your domain name pre-populated, for convenience of users
Two-factor authentication
- Two-factor setting: RADIUS
- Define radius servers and ports to AuthLite DC's with their RADIUS service configured (see above)
Make a text file (seriously) called "radius_secret.txt" containing only the shared secret text string you want to use for RADIUS.
Put that text file in the Inetpub\Citrix\XenApp (or path to your W.I. site) \ conf folder.
On the firewall between W.I. server and the DC's, you'll need to allow UDP 1812 so the RADIUS traffic can pass.

When you have all this done, loading the W.I. logon screen should display an additional field "passcode", into which the AuthLite OTP key can be tapped.

Unattended/command line deployment of AuthLite

In medium/large organizations, visiting each workstation to install the AuthLite software is not practical. This article contains pointers on deploying with Group Policy Objects (GPO)

This article contains notes on deploying the AuthLite_installer_Win32.msi and AuthLite_installer_x64.msi with Group Policy Objects (GPO) If you are already familiar with using GPO to deploy software, many of these points may be redundant to you. These notes highlight issues and decision points you may encounter, but should not be considered a replacement for a good grounding in GPO deployment concepts.

Prerequisites

The AuthLite installer will fail unless the Microsoft .NET framework is installed on the system (version requirements vary by AuthLite version). If your workstations don't already have this installed, then you will need to push the appropriate version. If you do this with a GPO, make sure the framework install runs before the AuthLite .msi, otherwise the latter will fail. You can do this by setting the framework GPO's link number higher than the AuthLite GPO.

GPO deployment tips

Your GPO's should assign the package to computers, not to the users.
To apply a policy to your workstations, the computer accounts need to be placed in an OU instead of the default "Computers" container in AD
The computer accounts of the workstations must be able to access the .msi files over the network. If your workstations' App or System event logs show error 1612, that means the installer could not be accessed! The recommended way to set this up is to create your own DFS share. For testing purposes you can put the .msi files in the SYSVOL area of the domain controller, which can then be assigned and accessed as \\YourDomainName\SYSVOL\your.domain.fqdn\AuthLite_installer_x64.msi. Microsoft highly recommends not doing this in production, due to issues as noted in this kb
AuthLite uses a separate installer file for 32 and 64 bit machines. If you have 32 and 64 bit machines in your environment, you should create a separate GPO for each case, so you can use use a WMI filter to make sure the right installer is applied to the right machines. The correct WMI filter settings are, in the root\CIMv2 namespace:

(32 bit):
```
SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth ='32'
```
(64 bit):
```
SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth ='64'
```
Once you apply your GPO's to an OU containing workstations, those machines will try to install the software when they are next rebooted. Check the workstation event log for troubleshooting.
To make logons faster, workstations apply GPOs asynchronously by default, as noted here. This means if a user logs on right away, it may take an additional reboot before the install is attempted. To mitigate this, you can set the GPO item Computer\Policies\Administrative Templates\System\Logon "Always wait for the network at computer startup and logon". However if you are assigning that policy at the same time as the software install, then the "wait" policy itself will be applied asynchronously the first time, resulting in the same issue (another reboot needed).

MST Transforms

With some deployment systems (such as Group Policy) you can apply a transform (.mst file) to affect the set of features and properties selected. We have published a few common requests here:

Turn on the NFC feature: NfcOn.mst
Don't install any Shortcuts to the Start Menu: NoShortcuts.mst
Force a DC install to AVOID all partition operations. This is useful as one component of a DC automated deployment, but you must manually ensure all partition operations still get completed (i.e. using ntdsutil and ldifde). NoPartitionOperations.mst

msiexec Switches

The AuthLite MSI installer is run by msiexec.exe, so you can use all flags supported by that tool. See Microsoft's msiexec documentation.

Property Automation

You can set certain properties from the command line to control installer behavior. Call like:

AuthLite_installer_x64.msi PROPERTY=VALUE

NOSHORTCUTS=1 : Prevent all Start Menu shortcuts from being installed. Overrides feature selection.
CREATESCHEMA=0 : Prevent installer from trying to check and update the forest schema to support the current installer. If you use this option you must manage the schema manually.
CREATEPARTITION=0 : Prevent installer from trying to create the AuthLite application partition. You can use this if you are sure the partition is already set up and working, but the installer is having problems passing that step.
MACHINETYPE=MemberWorkstation : If you are trying to pre-install on a workstation image which isn't joined to the domain yet, or trying to remove from a machine that was parted from the domain, you can use this property to trick the installer into running as though the machine was on the domain. Note this will not allow you to actually use AuthLite on a workgroup machine. It will still only work on domain-joined machines.

Feature Selection

To control which features are selected from the command line, you can invoke the installer like:

AuthLite_installer_x64.msi ADDLOCAL=DataManager,Nfc

Where the comma separated list of features after ADDLOCAL will be installed. At the time of writing, AuthLite v2.4.10 has the following feature options:

Replica: On a DC, attempts to set the DC to have a replica of the AuthLite application partition. If you do not specify this feature, you must manually manage your replicas with ntdsutil, to avoid data loss!
DataManager: Installs the AuthLite Token Manager application and associated start menu shortcut.
AdminAPI: Installs a shortcut to launch AuthLite Admin Powershell prompt.
AdminShortcut: Installs a shortcut to launch the AuthLite Configuration application.
YubiKeyProgrammerShortcut: Installs a shortcut to launch the AuthLite YubiKey Programmer application.
SelfProvisionShortcut: Installs a shortcut to launch the Enroll with AuthLite self-service application.
Nfc: Installs NFC reader support.
AuthLiteDriver: Installs the AuthLite Kernel Driver

Note that presence/absence of executables or shortcuts does not actually grant or restrict the access for accounts to read/write settings or token records. Control who has token access from the Administrative Groups setting in AuthLite Configuration.

AuthLite v2 and Citrix

You can use the Citrix W.I.'s built-in ability to use 2 factor authentication, with AuthLite users. Citrix will authenticate the username/password combo the same way you have it set currently, and then it will send the username and OTP over RADIUS to AuthLite for the second factor authentication.

Configuring to use IAS/NPS for RADIUS

On each domain member server that you want to use for authenticating Citrix users:

Install the IAS (Internet Authentication Service) or NPS (Network Policy Server on 2008 and higher)
In AuthLite config, go to Service Configuration -> IAS/NPS plugin
Enable IAS/NPS support on this server
Select "One factor PAP" and the checkbox to not require domain name.
Apply changes
Restart the AuthLite service and the IAS/NPS services to pick up those changes. Or, restart the server.
In the IAS or NPS configuration panel on this server, set up the Citrix WI as a RADIUS client
Set the shared secret
Set up a connection policy that will use PAP authentication

Citrix WI configuration

An overview of settings you need in the Citrix Web Interface site:

Authentication method: explicit
Authentication type: windows
Credential format: Domain user name only
Display your domain name pre-populated, for convenience of users
Two-factor authentication
- Two-factor setting: RADIUS
- Define radius servers and ports to AuthLite DC's with their RADIUS service configured (see above)
Make a text file (seriously) called "radius_secret.txt" containing only the shared secret text string you want to use for RADIUS.
Put that text file in the Inetpub\Citrix\XenApp (or path to your W.I. site) \ conf folder.
On the firewall between W.I. server and the DC's, you'll need to allow UDP 1812 so the RADIUS traffic can pass.

When you have all this done, loading the W.I. logon screen should display an additional field "passcode", into which the AuthLite OTP key can be entered.

AuthLite on UAG

Microsoft UAG easily supports setting up two separate authentication factors, so it is most natural to use AuthLite Split mode users, and the AuthLite RADIUS service to authenticate OTPs.

You probably already have Active Directory set up as an authentication service; this does not need to be changed.
In Admin->Authentication and Authorization Servers, add a RADIUS authentication server type
Configure this to point at the AuthLite RADIUS server and port, and set the shared secret.
Follow the AuthLite pdf manual to set up the RADIUS service. You should select "Permit requests that don't send the domain name"
In your trunk configuration's Authentication section, select "Require users to authenticate to each server", and "Authenticate to each server with the same user name"

There is one more important change you need to make. By default, password input fields in UAG are limited to 20 characters! AuthLite OTPs require 64 characters. Fortunately you can customize this value in UAG as shown in this technet article.

Begin with the file: InternalSite\inc\customDefault.inc
Copy it into the subfolder InternalSite\inc\CustomUpdate
In a text editor, open the new copy of the file.
Remove the comment block at the top, and the code block at the bottom that indicates it should be removed when used with CustomUpdate
The value PasswordLimit = 20 should be changed to at least 64
Save and close the changed file
Save and apply your UAG configuration

AuthLite v2 on UAG

Microsoft UAG easily supports setting up two separate authentication factors.

Configuring the RADIUS server:

Install the IAS (Internet Authentication Service) or NPS (Network Policy Server on 2008 and higher)
In AuthLite config, go to Service Configuration -> IAS/NPS plugin
Enable IAS/NPS support on this server
Select "One factor PAP" and the checkbox to not require domain name.
Apply changes
Restart the AuthLite service and the IAS/NPS services to pick up those changes. Or, restart the server.
In the IAS or NPS configuration panel on this server, set up the Citrix WI as a RADIUS client
Set the shared secret
Set up a connection policy that will use PAP authentication

Configuring UAG:

You probably already have Active Directory set up as an authentication service; this does not need to be changed.
In Admin->Authentication and Authorization Servers, add a RADIUS authentication server type
Configure this to point at the IAS/NPS RADIUS server and port, and set the shared secret.
In your trunk configuration's Authentication section, select "Require users to authenticate to each server", and "Authenticate to each server with the same user name"

Begin with the file: InternalSite\inc\customDefault.inc
Copy it into the subfolder InternalSite\inc\CustomUpdate
In a text editor, open the new copy of the file.
Remove the comment block at the top, and the code block at the bottom that indicates it should be removed when used with CustomUpdate
The value PasswordLimit = 20 should be changed to at least 64
Save and close the changed file
Save and apply your UAG configuration

AuthLite Permission to program Split Keys

By default only Domain Admins are allowed to program split-mode AuthLite keys for other users. You can change a setting to allow other groups this access.

In AuthLite version 1.2 there is no user interface to set this permission, so it needs to be set manually via ADSI Edit.

Create or select a group you wish to use for key provisioning
Add a user account to that group
Log in with that user. If you are already logged in with the user, then LOG OUT and log in again to update your token.
Use the command "whoami /groups" to discover the SID of the group. You need this to construct the permission setting. To find the SID, locate the name of the group in the left hand column of the "whoami" print out, then scan to the right until you find the long string that has the form:
```
S-1-n-nn-nnnnnnnnn-nnnnnnnnnn-nnnnnnnnnn-nnn 
```
On a DC, open ADSI Edit and connect to the distinguished name of the AuthLite partition on your domain. This will be similar to:
```
DC=AuthLite,DC=sandbox,DC=collectivesoftware,DC=com 
```
but everything after "DC=AuthLite," will be based on the FQDN of your domain instead:
```
DC=AuthLite,DC=your,DC=actual,DC=domain,DC=com 
```
Expand the main DC=AuthLite item and select the sub-item "CN=AuthLiteSettings"
Right-click in the right pane, and select New->Object
Select the item "collectiveAuthLiteSetting"
The value should be set to exactly:
```
ProvisionSplitKeys 
```
Click "More attributes"
Select the property "collectiveAuthLiteSettingValue
In the Edit attribute box, enter a value similar to:
```
D:AI(A;;FR;;;DA)(A;;FR;;;S-1-n-nn-nnnnnnnnn-nnnnnnnnnn-nnnnnnnnnn-nnn) 
```
but replace the SID placeholder with the SID you found for your key provisioning group. If you want to add other groups you can append more (A;;FR;;;S-1-...) portions to the end.
Click Set, OK, and Finish
This setting will not be refreshed on client for up to 20 minutes.

AuthLite PowerShell provider

AuthLite version 1.0.6 and later registers a PowerShell provider interface (snap-in) for accessing the AuthLite data store of the local machine.

Setup

By default, this snap-in will not be loaded into your shell. To enable AuthLite PowerShell integration, you should run the following commands from inside PS:

Add-PSSnapin AuthLiteProvider  # Note this requirement will be changed in the future # once Collective begins signing our ps1 scripts Set-ExecutionPolicy Unrestricted  if("$Env:ProgramW6432" -ne "") {    Update-FormatData -PrependPath "$Env:ProgramW6432\Collective Software\AuthLite\AuthLiteProvider.format.ps1xml" } else {    Update-FormatData -PrependPath "$Env:ProgramFiles\Collective Software\AuthLite\AuthLiteProvider.format.ps1xml" }

These commands load the snap-in and default data formatting cues for AuthLite data access. You would normally place these commands into a PS profile.

Sample commands

Obtain a recursive list of information in the data store:
```
ls -r AUTHLITE:\ 
```
Go to the Keys directory (assuming your domain name is 'Sandbox'), and then obtain a list of every username that is set up with an AuthLite key. The use of ToLower, Sort-Object, and Get-Unique here ensures that you see each username only once, even if there is more than one key associated to that user.
```
cd AUTHLITE:\Sandbox\Keys ls | ForEach-Object{$_.Username.tolower()}|Sort-object|get-unique 
```
Print out the license key to the console, using variable interpolation. Again, assuming the domain name is Sandbox:
```
Write-Host "The value of the license key is: ${AUTHLITE:\Sandbox\Settings\License\Value}." 
```

Limitations

At the time of this article's writing, the provider is read-only, i.e. there is no way to add, change, or remove data from the store via this provider. This functionality is planned for a future release!

AuthLite Upgrade Advisory #1

Overview

On November 11, 2013, Collective Software discovered and fixed a potential information disclosure bug of moderate impact, that could ultimately be used to launch privilege escalation attacks against an affected AuthLite installation and its domain users. This issue can only impact customers who have AuthLite deployed in their Active Directory.

To eliminate the potential for information disclosure in your AuthLite deployment, every customer using AuthLite in their domain should take one of the following steps as soon as possible:

For AuthLite 2.0 users: Install version 2.0.33 or later from AuthLite.com.
For AuthLite 1.x users: Install version 1.2.28 or later from AuthLite.com.

If you require further details, or assistance with installing the upgrade, please open a Support Request from our Support page.

Common Questions and Answers

Should I upgrade from v1.x to version 2?

No, you should probably just update to the latest 1.2 build. Version 2 is a much more complex product and a proper upgrade requires a substantial amount of planning, configuration, and testing. We even offer professional services just to help with this. In short, it's not something to be undertaken lightly.

My Replay Windows stopped working after the update, what happened?

Thanks to a customer report we discovered a bug introduced in 2.0.30 that made previous replay window settings fail until they were re-saved in the configuration. We fixed this issue in 2.0.33. You could work around the issue by going into each replay window setting and re-applying the settings. Contact Support if you need assistance.

Where do I have to install the update?

Install the updated software on all Domain Controllers that currently have AuthLite installed.

Was this issue remotely exploitable?

No, this issue required an attacker to be inside your organization's network.

Where was information potentially disclosed?

Information could only potentially be disclosed within your organization's network. There was no exposure outside the network.

Could any information be exposed anonymously?

No, only authenticated domain users could have access to this data.

AuthLite Upgrade Advisory #2

Overview

On January 2. 2014, Collective Software identified a VPN configuration that could lead to 2-factor logons not being properly enforced. VPNs with a vulnerable configuration could allow users to log in even when the one-time passcode (OTP) supplied is incorrect.

To eliminate any potential for users authenticating without proper credentials, please check whether your configuration is affected, and deploy the new build or a configuration workaround (details below).

Affected AuthLite Versions

AuthLite version 1.x: not affected. You don't need to do anything, apart from make sure you have already updated for the older Advisory #1.
AuthLite version 2.0.18-2.0.38: potentially affected, see below for configuration details.

Affected Configurations

If your configuration matches all of the following points, then your VPN is potentially vulnerable, and AuthLite should be updated or its configuration changed.

IAS/NPS plug-in is active
IAS/NPS plug-in is set for 2-factor authentication
"Replay Behavior" configuration is set to "Retry as 1-factor"
Your IAS/NPS servers are not listed in the Forced 2-factor Computers list

What Should I Do?

If your configuration matches all the above points, you can eliminate the vulnerability by performing any one of the following options.

Option 1: Install an updated AuthLite version

On your DCs and IAS/NPS servers, install v2.0.39 or later from AuthLite.com
You must reboot the servers for the modification to become active. Prior to rebooting, the systems will still be running the old version of the software in memory.

-- or --

Option 2: Add VPN servers to Forced 2-factor Computers

If you cannot install a new AuthLite version at this time, you can work around the issue by adding all IAS/NPS servers into AuthLite's "Forced 2-Factor Computers" list.

NOTES:

This will cause all AuthLite user accounts to require 2-factor credentials when they attempt to access the IAS/NPS servers over any protocol (console, RDP, etc.)
Configuration updates take up to 20 minutes to apply, in addition to any inter-site replication delays.

-- or --

Option 3:

If you cannot install a new AuthLite version at this time, you can work around the issue by changing the "Replay Behavior" setting from "Retry" to "Fail".

NOTES:

This may break the functionality of benign 1-factor software that is currently able to use stale/expired 2-factor credentials seamlessly. These credentials will be rejected instead of succeeding as if they were entered as 1-factor logons.
For example: Outlook 2013 sends the same credentials used during desktop logon over to the Exchange server. You may be authenticating with 2-factor credentials at the desktop, but Exchange server sees the OTP as stale. Setting the Replay Behavior to "Fail" will cause Outlook single sign-on to fail, and a credential prompt to pop up. The same behavior will be observed for all software that attempts to use the NTLM "Windows Integrated" logons.
Configuration changes take up to 20 minutes to apply, in addition to any inter-site replication delays.

Common Questions and Answers

Should I upgrade from v1.x to version 2?

No, you do not need to do this. Version 2 is a much more complex product and a proper upgrade requires a substantial amount of planning, configuration, and testing. We even offer professional support just to help with this. In short, it's not something to be undertaken lightly.

Where do I have to install the update?

Install the updated software on all Domain Controllers and IAS/NPS servers that currently have AuthLite installed.

If I change my configuration with Option 2 or 3, do I have to install the upgrade?

No, you can continue using your existing build 2.0.18-2.0.38 if you deploy a configuration change (option 2 or 3) to bypass the issue.

I need help with this, what should I do?

If you require further details, or assistance with installing the update or making configuration changes, please open a Support Request from our Support page and reference Upgrade Advisory #2

AuthLite Upgrade Advisory #3

Overview

On November 25, 2014, Collective Software identified an issue with some LDAP clients where a valid 2-factor authentication could impersonate a different user account on the LDAP client.

To eliminate any potential for users authenticating as other users, please check whether your configuration is affected, and deploy the new build.

Affected AuthLite Versions

AuthLite version 1.x: not affected. You don't need to do anything, apart from make sure you have already updated for the older Advisory #1.
AuthLite version 2.0.1-2.0.56: potentially affected, see below for configuration details.

Affected Configurations

If your configuration matches the following points, then it may be possible for a valid 2-factor authenticated user to impersonate other users, and AuthLite should be updated.

You have one or more third-party (non-Microsoft) services or appliances that act as LDAP clients in order to authenticate Active Directory users.
You require 2-factor AuthLite authentication for at least some users on those LDAP-enabled systems.
The LDAP-enabled systems use "simple bind" instead of "Negotiate". You may not be able to easily determine whether this is the case, so it's best to just upgrade if #1 and #2 are true.

What Should I Do?

You can eliminate this issue by performing the following action:

Install an updated AuthLite version

Upgrade your DCs to v2.0.57 or later from AuthLite.com
You must reboot the DCs for the modification to become active. Prior to rebooting, the systems will still be running the old version of the software in memory.

Common Questions and Answers

What is my exposure? Could this issue allow outside users in to my systems?

No, this issue cannot grant any access to external malicious users. Only a valid AuthLite user in your domain who logs in with their correct OTP token and correct password could potentially impersonate a different user account than their real one. Whether this incorrect impersonation occurs also depends on the implementation of the LDAP client software in the third-party service/appliance.

Should I upgrade from v1.x to version 2?

No, you do not need to do this. Version 2 is a much more complex product and a proper upgrade requires a substantial amount of planning, configuration, and testing. We offer professional services just to help with this. In short, it's not something to be undertaken lightly.

Where do I have to install the update??

Install the updated software on all Domain Controllers that currently have AuthLite installed.

I need help with this, what should I do?

If you require further details, or assistance with installing the update, please open a Support Request from our Support page and reference Upgrade Advisory #3

Configuring Cisco ASA to use MS-CHAPv2 with AuthLite

If using the AuthLite RADIUS service

AuthLite's RADIUS service expects two-factor authentication requests to use the MS-CHAPv2 protocol, but there is no obvious way to turn this on in a Cisco ASA.

These instructions assume Cisco ASDM v6.2 but can be easily generalized by an IOS expert.

In the "AAA Server" configuration dialog for your RADIUS server, you should select the "Microsoft CHAPv2 Capable" checkbox. But this alone won't make the ASA use this protocol.
In the "Connection Profile" (tunnel group), navigate to Advanced -> General, and select "Enable password management". Even though we are not working with password reset/expiration at all, this setting is required in order to make the ASA use MS-CHAPv2.

If using the IAS/NPS plugin (AuthLite v1.2 or higher)

You don't need to worry about this-- you can simply use a PAP connection rule in IAS/NPS, since this is what most RADIUS clients expect.

The Cisco VPN client (unless grossly misconfigured) will be using IPsec so it is not necessary to use MS-CHAPv2. (In a basic PPTP tunnel, by contrast, MS-CHAPv2 must be used to protect the confidentiality of the passwords and secure the VPN tunnel.)

General Access Denied error on install

When installing AuthLite on the first domain controller in your organization you receive a pop-up "General access denied error"

The documentation specifies that you must be a member of "Domain Admins" but you also need to be a member of "Schema Admins".

The first installation on a DC must add elements and attributes to the schema so that the AuthLite Partition can be set up. If your account is not a member of Schema Admins (by default a domain admin is not a schema admin!) then you need to have it added, or use another appropriate account.

Remember if you add your account to this group you must log out and log back in to get an updated token, or else you will not see any difference.

If your account is a member of domain and schema admins and you receive this error, it is usually caused by a disagreement between DC's about which system has the FSMO Schema Master role. We have seen it occur in cases where the old role holder has gone offline, and one or more new DC's were later added. Seizing the schema role to an active DC may resolve the issue.

Note: AuthLite schema additions only affect our own Application Partition, and do not make any changes to built-in AD objects. The additions will have no adverse or performance effect on your directory.

Install AuthLite without GINA-Credential tile

In some limited cases, you may wish to install AuthLite without the GINA / Credential Provider extension. This allows you to use the network access features of AuthLite without showing an altered UI experience to your users and admins for console logins.

In AuthLite version 1.1, the UI added a dropdown field and changed the visual appearance of the logon screen. In version 1.2, the UI uses the default Microsoft interface with a tool-tip balloon added which offers AuthLite instructions.

For either version, to omit the UI extensions during install, perform the following procedure:

Instead of launching the setup .exe visually, go into a command prompt and CD to the installer's folder
Type one of the following depending on your platform:
- AuthLite_Setup_Win32.exe SKIPGINA=1
- AuthLite_Setup_x64.exe SKIPGINA=1
You must do this any time you install or upgrade AuthLite, or else the UI extension will be installed.

Install error: The directory service is busy

When installing AuthLite on a Domain Controller, you receive a popup error stating:

Error while executing custom action: The directory service is busy.

and the install rolls back.

Each DC install runs a custom action which saves the latest definitions of the AuthLite objects to the AD schema. Even if you have the latest schema already and no changes need to be applied, AD may throw this error.

First steps

First, before troubleshooting AuthLite, you should make sure that there are no replication issues between your schema master and the DC you are installing on. When we get this condition in our test lab with VMs, sometimes restarting the Active Directory services on each of the DCs clears the error.

Apart from that, here are some ways to try and resolve this condition:

Option 1: Add registry key to the schema master

Support staff note: This procedure allegedly affects only Windows 2000, but we have repeated reports that it helped resolve the problem on 2003 and 2008 servers.

Determine the schema master, and add a registry key signifying that schema changes are allowed. This procedure is outlined in this Microsoft KB article
You must do the above on the schema master
Re-try the install.
If you still get the failure, please contact support and we can assist you.

Option 2: Manual schema installation

Please see this article

Manual Schema Additions

By default, AuthLite's installer automatically adds the lastest revision of its own items and attributes to your AD schema. If needed, you can execute these changes manually instead.

Step 1:

Obtain the most current LDIF files for your AuthLite version, by creating a support request and asking for them.

Step 2:

Bring the LDIF files to the Schema Master, and open a command prompt in the same folder. Enter the following commands:

ldifde -k -i -f AuthLiteSchemaTemplate-Attributes.ldif -c {BaseDN} CN=Schema,CN=Configuration,<dc=sandbox,dc=local> 
ldifde -k -i -f AuthLiteSchemaTemplate.ldif -c {BaseDN} CN=Schema,CN=Configuration,<dc=sandbox,dc=local>

NOTE: In the above commands you must replace the "<dc=sandbox,dc=local>" portions with the LDAP syntax distinguished directory context of YOUR domain. (It will be the FQDN of your domain with "DC=" before each part, and a comma in place of each period.) Do not keep the "<" and ">" characters in the resulting command, they are just there to show you which part must be changed.

If no errors are reported, proceed to step 3.

Step 3:

Now that you know the schema elements are updated you can run the AuthLite setup program and tell it NOT to run the schema installer. You do this by specifying the argument CREATESCHEMA=0:

Version 2:

AuthLite_installer_(x86 or x64).msi CREATESCHEMA=0

Version 1.x:

AuthLite_Setup_(Win32 or x64).exe CREATESCHEMA=0

Installation on quot Server Core quot

AuthLite can be installed on 2008 Server Core R2, but not R1 because it lacks the .NET framework

If your organization uses Server Core to run domain controllers, and AuthLite users will be authenticating to those DC's, then it is necessary to install the AuthLite software on those DC's.

It is not possible to install AuthLite on the 2008 Server Core R1 product from Microsoft, because it does not include or support Microsoft's .NET framework.

In Core R2 you can install AuthLite by first installing the .NET prerequisites with the following commands:

start /w ocsetup NetFx2-ServerCore start /w ocsetup NetFx2-ServerCore-WOW64

Then launch the AuthLite setup file:

Version 1.x:

AuthLite_Setup_x64.exe

Version 2:

AuthLite_installer_x64.msi

Migrating AuthLite Integrated users to version 2

AuthLite version 1 customers who have Integrated users need to perform these extra steps before migrating to a version 2 install.

Overview

This article first describes the security models for user authentication and endpoint protection between AuthLite versions 1 and 2 at a high level. Then information is provided about planning and executing an upgrade to a version 2 environment.

Limitations of AuthLite v1 Endpoint Security

AuthLite version 1 provides secure logon for endpoint workstations by leveraging "Integrated users". These accounts use a special augmented static secret as the account's AD password. This secret is never stored, and can only be generated by combining the user's plaintext password and a decrypted YubiKey one-time passcode. There are some important ramifications of relying on this approach:

Even though the augmented static secret is never stored anywhere, it gets assembled by the security core of each workstation each time the user authenticates. The domain controller processes the one-time passcode authentication and returns its cryptographic results to the workstation. That means any software running on the workstation with system-level privileges could theoretically see this value. A malicious workstation could collect the augmented secret and bypass the one-time passcode authentication factor in the future. This collected static value could also be used on other systems by an attacker in lieu of two-factor authentication, and the domain controller could not detect the difference.
In order to support offline (cached) logon, the workstations must store the YubiKey's shared secret so they can decrypt the one-time passcodes. The shared secret is encrypted against disclosure by a key derived from the user's plaintext password. But this is still not ideal since an attacker who can acquire or guess the password and then obtain the workstation's hard drive could bypass the one-time passcode authentication factor.
Since the AD password has been changed (it's the augmented static secret, not what the user types in as their plaintext password) this means there is no way for this account to authenticate anywhere on the domain except for systems and software that are AuthLite-aware. Although that configuration is "secure by default", in practice it is an unacceptable barrier to use for most customers, who wish certain systems and software to continue authenticating AuthLite users with one-factor only.

AuthLite v2 Endpoint Security Model

AuthLite version 2 has a more sophisticated Active Directory authentication subsystem. This allows us to dispense with the distinction between "Integrated" and "Split" users. Version 2 accounts have normal passwords whose hashes are stored in AD in the default Microsoft fashion. The domain controller makes the decision whether to allow or deny each authentication attempt based on the presence of a valid one-time passcode. This has the following ramifications:

Nothing seen by the workstation could be used to gain access to future sessions. The domain controller is making the ultimate decision each time an authentication is performed, so it can accept or reject the credentials properly. There is no augmented static secret anywhere in this model.
Version 2 software on the DC and workstation provides more secure cached/offline logons. The YubiKey challenge/response mode is used to encrypt a randomly chosen secret key that must be provided in order to decrypt the cached logon record and DPAPI keys. A new random secret is chosen each time the user authenticates to the workstation when it is online. This model means that in order to log in, an attacker would not only need the user's password, but access to the hard drive, followed by access to the YubiKey. Additionally, any partial disclosure is likely to be short-lived since the secrets are changed regularly. Finally, each secret is only useful for the workstation on which it was generated.
Logons work as one-factor by default, unless constrained by administrators. Compared to the limitations in v1, admins have finer-grained control over what systems and processes will require two-factor authentication.
WARNING: Domain controllers that do not have the AuthLite software installed will process all authentications as one-factor. They will reject AuthLite two-factor authentications, and they will ALLOW users to authenticate with one-factor even if you do not wish them to. All DCs should be made AuthLite-aware to avoid this situation. This warning may not necessarily apply if your two-factor users only log in via RADIUS or some other constrained subsystem where they are always funneled to an AuthLite-aware server.

Considerations for AuthLite version 1 customers before upgrading

If you only use Split-mode users in your version 1 deployment then your users can continue to use their existing YubiKeys in the same manner they have in the past. Read the v2 manual because replay windows and 2-factor forcing work quite differently and you will probably need to make configuration changes.

If you have Integrated users then at a minimum you will have to contend with these hurdles:

Integrated user records must be altered to split-mode in order for the installation to proceed (see below).
Currently active Integrated users will not be able to log in until their passwords are administratively reset, because v2 does not create or use augmented password values like v1.

Additional considerations for YubiKeys to support offline logons:

Your YubiKeys need to be reprogrammed if you intend to use them to log on to offline workstations, because the old records will not have challenge/response secrets associated with them either in the keys or the data store.
Your YubiKeys could be too old to program with challenge/response. The oldest supported YubiKey model is version 2.1. (YubiKey firmware cannot be updated.)
If you are using the second configuration slot on your keys for something unrelated to AuthLite, that identity will be need to be OVERWRITTEN by the version 2 key programmer. Without the C/R identity in slot 2, it will not be possible to log on to offline workstations with that key.

Prerequisite for upgrading from version 1 to version 2

WARNING: This process will cause the destruction of your current data records. If you have any possibility of taking the environment back to version 1, you MUST make a backup of all records in the Data Manager before proceeding.

Go into the AuthLite Data Manager and remove any key records that show "Integrated" unless you want to continue using those keys without offline logon support.
Open ADSI Edit and Connect to the tree "DC=AuthLite,[DC=your,DC=domain,DC=fqdn,DC=here]" where the bracketed value is replaced with your domain's FQDN such as "DC=sandbox,DC=collectivesoftware,DC=com" for "sandbox.collectivesoftware.com"
Go into the AuthLiteHashes section, and delete all records under it. This will remove the Integrated flag from the records and make them v2 compatible. See above for notes about mandatory password resets!

OpenVPN Access Server Configuration

This article describes the configurations needed to make OpenVPN Access Server work with AuthLite.

New way (separate OTP field)

Configure OpenVPN authentication to use LDAP to Active Directory, and make sure it works with username/password only.

Set up a domain member or DC as follows:

Install NPS server role
Create NPS Radius client matching the OpenVPN-AS server's IP. Create a shared secret.
Set up appropriate Connection Request Policy (the default "use windows authentication for all users" is fine)
Set up appropriate Network Policy to grant access to the Windows Group "AuthLite Users", allow PAP authentication.
install AuthLite on NPS server and restart
Enable AuthLite's NPS plugin to One-factor PAP mode, selecting "Permit requests that don't send the domain name"
Restart AuthLite service and NPS service

Log into the OpenVPN-AS appliance and enter:

cd /usr/local/openvpn_as/scripts
wget https://s3.authlite.com/downloads/ovpnas_postauth_cr.py
wget https://raw.githubusercontent.com/pyradius/pyrad/master/example/dictionary
wget https://raw.githubusercontent.com/pyradius/pyrad/master/example/dictionary.freeradius

Edit the ovpnas_postauth_cr.py file and change the following values to match your NPS server:

RADIUS_SERVER
RADIUS_SECRET

Now run the following commands to load the script and restart the service:

./sacli -k auth.module.post_auth_script --value_file=ovpnas_postauth_cr.py ConfigPut 
./sacli start

After this configuration, the OpenVPN web logon and VPN client should show an additional dialog after submitting the username and password. The new dialog will request "AuthLite OTP" (this is configurable in the ovpnas_postauth_cr.py file), and the user will have to enter a valid OTP to proceed.

Old way (no separate field)

The OpenVPN Access Server (OpenVPN-AS) uses the username field to create and push configuration files. This means it cannot tolerate an AuthLite OTP in the username field by default. To work around this problem you can either:

Use RADIUS PAP and enter credentials as follows:
- Username in the Username field
- Password and OTP together in the password field
Use AuthLite 1.2.25 or later and add a "post auth" script to the VPN server to make it tolerate an OTP in the username field. This is accomplished by making the VPN software use the username returned by AuthLite as the canonical username for its internal operations.

The remainder of this article contains the steps needed to configure option #2.

From a shell on the VPN server, cd to /usr/local/openvpn_as/scripts
Create the file authlite.py, with the following contents:
import json
from pyovpn.plugin import *

def post_auth(authcred, attributes, authret, info):

      if info.get('auth_method') in ('session', 'autologin'):
          return authret

      if 1 in info['radius_reply']:
          ul = info['radius_reply'][1]
          us = ''.join(ul)
          u = us.split("\\")[-1]
          authret['user'] = u

      return authret
Execute the following command, substituting your VPN admin username if it is not "openvpn":
```
 ./sacli -a openvpn -k auth.module.post_auth_script --value_file=authlite.py ConfigPut 
```
Execute the following command, substituting your VPN admin username if it is not "openvpn":
```
 ./sacli -a openvpn start 
```

Note that the script executes from a copy stored directly in the configuration database, NOT the .py file. So if you change the py file you need to ConfigPut it again in order for your changes to be picked up.

You can use the sacli command with the ConfigDel option if you need to remove the script.

See /usr/local/openvpn_as/doc/post_auth/post_auth.txt for more information.

Program a key over RDP

NOTE: This KB is for an outdated version of AuthLite.

Please see this sequence of pages for more updated instructions:

Normally AuthLite keys can only be programmed when directly connected to the computer running the configuration program, not over remote desktop. There is a work around.

Overview

For normal login, and changing passwords after your account is already AuthLite Integrated, the hardware keys (yubikeys) work normally over RDP.

But two situations require special attention over RDP:

When you are first setting up your user account as AuthLite Integrated, in the "change password" screen
When you are using the AuthLite configuration dialog to set up extra keys or Web/VPN (split) keys

If you attempt to do one of the above procedures in an RDP session, you will receive an error that there is no key plugged in. These programs can only write to the yubikey when it is plugged in to a USB port they can see. Over an RDP session, the yubikey is not actually connected to the remote system, only its keystrokes are sent. This is good enough to use the key, but not enough to program it.

Solution: Program keys remotely

Install the Key Programmer bundle to your local workstation: 32-bit programmer or 64-bit programmer
Set slot 1 to AuthLite OTP.
Set slot 2 to "do nothing"
on the next tab, plug in yubikey
when detected, go to the next tab and yubikey slot 1 will be programmed for AuthLite
Each new key you plug in will be programmed
click Finish and save the XML
this can be imported into the v1.2.25 (or later) Data Manager app

Now all the data for the keys has been added. The procedure to integrate a new user with a pre-programmed key is slightly different than for a blank key.

Steps the user performs:

Plug in the (already programmed) key to a USB port on your RDP client machine.
In the RDP session, press ctrl-alt-end to bring up the security screen, and go to Change Password.
Instead of typing the username, tap the AuthLite key into the first field.
Fill out the old and new password fields.
Select the checkbox "Use AuthLite with this account"
Click OK.
The key will now become associated to that user, and their account will be integrated with AuthLite.

RDP and Network Level Authentication

The RDP client version 6 and later collect credentials before establishing a remote session. AuthLite credentials must be entered into the RDP client before the connection is made.

Please see the AuthLite administrator guide for configuration steps needed on the domain controller (in particular, setting up a Replay Window)
If you are using TSG, make sure AuthLite is installed on the TSG server as well
If you are publishing TSG through ISA or TMG, please see the AuthLite administrator guide for configuration steps.

Connect to an RDP session as an AuthLite user

Open mstsc (the RDP client) and enter the server you wish to connect to.
Click Connect.
When the logon dialog opens, select the Username field, and tap your AuthLite key there instead of entering the username.
Enter your password into the password field.
Connect.

The reason you must enter the OTP into the username field is that RDP hashes the contents of the password field immediately at the client. So by the time the server gets the credentials, the OTP has been destroyed by the hashing operation. In contrast, the username field is sent to the server in clear text, so the OTP can be transmitted in this field.

Service marked for deletion

If your installer fails with this error, close all instances of the Services control pannel mmc.exe. Then run the installation again.

Share AuthLite key across multiple domains or standalone machines

Overview

Within a domain, a user can use their AuthLite keys easily across any system, because the authentication is performed by Active Directory. But between two domains or standalone (non-domain) machines, even if you have the same "username and password" on each system, using the same AuthLite key requires extra effort.

There are two main concepts to understand before proceeding:

AuthLite cannot automatically send authentication data between two domains or standalone systems, the way it can within a single domain between domain controllers and domain-joined systems. This means in order to share one key, you will have to manually copy that key's record to each domain or system.
By default, whenever you integrate an account to an AuthLite key, the old program on that key (if any) in ERASED. Therefore when you set up the same key across several domains or systems, you must be careful to only program the key ONCE, on the first system. Then, follow the special procedure described below on each additional domain or system. The AuthLite software will warn you if you attempt to overwrite a key's program. Please heed these warnings and make sure you understand what you are doing.

Security Considerations

Part of the security of AuthLite is provided by the one-time nature of the AuthLite keys. Pressing a key generates a one-time password (OTP) and that value need not be held secret because use of the same value in the future would be rejected by the system as a replay. However, when you share one key across several independent authorities as we will show here, the security of the system is weakened in the following manner.

Consider standalone SystemA and SystemB which both honor the same AuthLite key. If you log on to SystemA with an OTP and your password, then SystemA will know this OTP value should be considered a replay in the future. However SystemB has no knowledge that this value was used on SystemA. Therefore, an eavesdropper on your logon session to SystemA could take this OTP value and use it on SystemB without being rejected. If your plain text passwords are ALSO the same on each machine, then the attacker now has sufficient information to completely impersonate you on SystemB.

This issue can be partially mitigated by making sure you use different plain text passwords on each standalone system. But even with this precaution, the total security of the system is lower when the same key is shared across several authorities in this fashion. (It's still far more secure than using a password alone however).

Prerequisites

This procedure requires AuthLite version 1.2.25 or greater.
Before starting, thoroughly read Appendix A in the AuthLite administrator's manual and prepare each user account to be recovered in the event of lost access. Beware, even if you are using the same username and password on each domain or system, they are separate accounts and must each be recovered separately. A windows recovery disk/file will only work for the user and computer on which it was created.

Procedures

Summary

Note: Whether you are sharing a key across two domains, or two standalone machines, we will call them "SystemA" and "SystemB". On a domain, the AuthLite Data Manager is only visible from a domain controller. But you can perform the logon and password changes on a workstation (since normal domain users are not allowed to logon to DCs)

Here is an overview of the procedures we will perform. More detailed steps are shown below.

Integrate a UserA on SystemA with Key1
Export the data for Key1 and change the XML file to remove the Domain and Username
Import the modified data file to SystemB
Set up UserB to use Key1 through the change password screen
Add a spare Key2 to UserA (on SystemA)
Export the data for Key2 and change the XML to reflect SystemB and UserB
Import the modified data file to SystemB

In the end, this will yield two keys that can each be used on either domain/machine, for logging in as the appropriate user on that domain/machine.

Details: Integrating UserA and sharing the first key

On SystemA, log on with UserA. If UserA is already using an AuthLite key, go to step 6.
Plug in a blank AuthLite key, which we will call Key1
From the Ctrl-Alt-Delete security screen, go to Change Password
Enter your old and new passwords (or retype the same password if you don't want to change it), and select to set up a new AuthLite key.
Confirm your account is now integrated with AuthLite by logging out and logging in using Key1 and the password you set for UserA.
As an administrator, open the AuthLite Data Manager on SystemA
Select the key record for UserA, and export it using the File->Export option
Open the XML file you just saved in Notepad or other text editor.
Delete the lines containing the "Username" and "Domain" tags and values. We need to clear these out so that when we import the key it will not be associated to any user.
Save the XML, and bring the modified file to SystemB
As an administrator, open the AuthLite Data Manager on SystemB
From File->Import, import the modified XML file from SystemA
You should see a new key record with the domain and username stating they are "not set"
Log on to SystemB with UserB. This must not be an AuthLite user already. If it is, unintegrate it back to password-only before proceeding.
From the Ctrl-Alt-Delete security screen, go to Change Password
EXTREMELY IMPORTANT! Instead of leaving the username in the first field, REPLACE this value by tapping Key1 into this field. The checkbox on the screen should change to say "Use AuthLite with this account". We are doing this to tell the system you already have an existing key and don't want to program a new one.
Enter your old and new passwords (or retype the same password if you don't want to change it), and select the "Use AuthLite" checkbox
If you receive a warning about reprogramming the key, STOP! Go back two steps and read it again!
The system will find the unassociated key record and connect it to UserB with the password you have entered.
Confirm your account is now integrated to AuthLite by logging out and in using Key1 and the password you set for UserB.

Details: Adding a second key and sharing it

On SystemA, log on with UserA using Key1 and UserA's password.
Open AuthLite Configuration and Select "My Integrated Keys".
Tap Key1 into the first field "Current AuthLite Key".
Enter UserA's password in the next field.
Unplug Key1
Plug in blank Key2
Press the "Program" button
Verify you can log in to SystemA with Key2 and the password for UserA
As an administrator, open the AuthLite Data Manager on SystemA
Tap Key2 into the "Find OTP" search box on the top left of the tool.
Select the key record found, and export it using File->Export
Open the XML file you just saved in Notepad or other text editor.
Change the contents of the "Domain" tag from the name of SystemA to the name of SystemB.
Change the contents of the "Username" tag from the name of UserA to the name of UserB.
Save the XML and bring the modified file to SystemB.
As an administrator, open the AuthLite Data Manager on SystemB.
Import the modified XML file from SystemA.
Verify that UserB now has two key records. You can tap Key2 into the "Find OTP" field and make sure it finds a key record.
Confirm that Key2 is shared properly by logging in to SystemB with Key2 and the password for UserB.

Additional domains/machines

You can use the files modified from SystemA, and perform the "SystemB" steps on other domains/machines to share the same keys with those as well.

Share AuthLite v2 key across multiple domains

Overview

Within a domain, a user can use their AuthLite keys easily across any system, because the authentication is performed by Active Directory. But between two domains, even if you have the same "username and password" on each system, using the same AuthLite key requires extra effort.

There are two main concepts to understand before proceeding:

AuthLite cannot automatically send authentication data between two domains, the way it can within a single domain between domain controllers. This means in order to share one key, you will have to manually copy that key's record to each domain.
By default, whenever you program a YubiKey, the old program on that key (if any) in ERASED. Therefore when you set up the same key across several domains or systems, you must be careful to only program the key ONCE. Then, follow the special procedure described below on each additional domain.

Security Considerations

Part of the security of AuthLite is provided by the one-time nature of the YubiKey. Pressing a key generates a one-time password (OTP) and that value need not be held secret because use of the same value in the future would be rejected by the system as a replay. However, when you share one key across several independent authorities as we will show here, the security of the system is weakened in the following manner.

Consider DomainA and DomainB which both honor the same AuthLite key. If you log on to DomainA with an OTP and your password, then DomainA will know this OTP value should be considered a replay in the future. However DomainB has no knowledge that this value was used on DomainA. Therefore, an eavesdropper on your logon session to DomainA could take this OTP value and use it on DomainB without being rejected. If your plain text passwords are ALSO the same on each domain, then the attacker now has sufficient information to completely impersonate you on DomainB.

This issue can be partially mitigated by making sure you use different plain text passwords on each domain. But even with this precaution, the total security of the system is lower when the same key is shared across several authorities in this fashion. (It's still far more secure than using a password alone however).

A better solution for this scenario is to use a time-based OATH token, since there is no counter value that needs to be communicated between the domains.

Upgrading Server 2003 to 2008

In-place upgrade

You can perform an in-place upgrade of Windows Server without damaging any AuthLite data stored on your domain.

For safety, back up the existing key data with the following procedure:
- Open the AuthLite Data Manager
- Click the domain node for your domain name
- Click into the right pane, and select all records or press ctrl-A
- Go to File->Export Keys, and save the key data to an XML file
You should not need that XML file if all goes well, but put it in a safe place off of the server.
After completing the Windows upgrade, run the AuthLite installer again and select "Repair". This will refresh shortcuts in the start menu, and other installation settings.
All AuthLite accounts and settings should remain as they were prior to the upgrade.
After the upgrade, please REMOVE the backed up XML file, as it contains sensitive OTP data.

Migrating to different servers

If you will move to entirely new servers instead of doing in-place upgrades of your existing servers, then you must manually migrate the AuthLite data. However, if you are upgrading domain controllers one at a time and keeping the same domain data throughout the process, you don't need to back up/restore the AuthLite key data from the Data Manager.

On the old server:

Back up the existing key data with the following procedure:
- Open the AuthLite Data Manager
- Click the domain node for your domain name
- Click into the right pane, and select all records or press ctrl-A
- Go to File->Export Keys, and save the key data to an XML file
- Note that if you are upgrading domain controllers one at a time and keeping the same domain data throughout the process, you don't need to back up/restore the AuthLite Data Manager data.
There is not currently a way to export settings from the AuthLite Configuration tool, so make a note of your existing settings.

On the new server:

Install AuthLite
In the AuthLite Configuration app, go through each dialog and set proper values as you had in your old domain.
If moving to a fresh domain, open the AuthLite Data Manager, and import the XML file from the old server via File->Import Keys. This will restore all data that associates users and keys.
IMPORTANT note for AuthLite version 1.x: If you had AuthLite Integrated users on the old domain, and you create new user accounts (even if they have the same names as the old accounts did), the AuthLite "integration" will not carry over to the new user accounts. Integrate them again on the new server via the change password screen. If this would be too much trouble, consider doing an in-place domain upgrade so that your user accounts will be migrated intact.
After the upgrade, please REMOVE the backed up XML file, as it contains sensitive OTP data.

AuthLite Upgrade Advisory #4

Overview

On March 2, 2015, Collective Software corrected a design defect which allowed Windows workstations to cache 1-factor password hashes in some circumstances where 2-factor authentication was being used. In the worst case, this means a session might be unlockable by entering only the password (instead of also requiring the OTP).

To eliminate any potential for users logging on to workstations with 1-factor when they should be blocked, please check whether your configuration is affected, and deploy the new build.

Affected AuthLite Versions

AuthLite version 1.x: not affected. You don't need to do anything, apart from make sure you have already updated for the older Advisory #1.
AuthLite version 2.0.1-2.0.62: is affected, please see below for update instructions.

What Should I Do?

You can eliminate this issue by performing the following action:

Install an updated AuthLite version

Upgrade your workstations that have AuthLite installed, to AuthLite version 2.0.63 or later from AuthLite.com
If your servers allow logon caching (via group policy "Interactive logon: Number of previous logons to cache") then you should also upgrade AuthLite on those systems.
You must reboot the computers for the modification to become active. Prior to rebooting, the systems will still be running the old version of the software in memory.
Domain controllers are not affected by this issue because there is no offline logon caching on DCs. It is OK to run a slightly older install on the DCs during your upgrade process, but you should plan to update them when convenient.

Common Questions and Answers

What is my exposure? Could this issue allow outside users in to my systems?

An attacker who knows the password of a locked session might be able to unlock a presently locked session, thereby letting them impersonate the real user for the duration of the real user's kerberos ticket.

Should I upgrade from v1.x to version 2?

Where do I have to install the update??

Install the updated software on all workstations that currently have AuthLite installed, and all non-Domain-Controller servers that currently have AuthLite installed, if those servers allow logon caching (which is the default configuration by Microsoft, see policy "Interactive logon: Number of previous logons to cache").

I need help with this, what should I do?

If you require further details, or assistance with installing the update, please open a Support Request from our Support page and reference Upgrade Advisory #4

Allow RunAs but Block Interactive Logon

Use case

Some customers want to use an administrator account only for "elevated" tasks, much like how unix systems support the concept of "sudo". In addition, unix systems are commonly configured to block direct logon by administrator accounts. The established procedure is to log on with an unprivileged user, and then elevate tasks with the "sudo" command where necessary.

There is not an exact mapping of these concepts to the Windows environment. Microsoft made some steps in this direction with User Account Control. Also, the "run as" command allows a similar behavior pattern as the unix "sudo" (although not identical).

Since many customers have best practices to avoid use of admin accounts wherever possible, let's explore whether we can allow an account to be used with the "run as" command, but block that account from logging in interactively to the desktop.

Internals

Authentications to the Windows desktop (whether via console or Remote desktop access) are known as "Interactive" logons. Group policy allows us to restrict who can log on interactively, but this same policy also controls use of the "run as" command. (Windows uses the same logon type when you establish a secondary authentication, even though no additional desktop is shown.) Thus, there's not any direct way (via policy) to restrict one, but not the other.

Group policy does allow a user account to have a different "shell" specified (the normal shell is "Explorer.exe"). We can use this feature to force an interactive session to log off immediately instead of displaying the Windows desktop.

Procedure

Create or select an Organizational Unit that will hold your logon-restricted users.
Move users into the group (if necessary).
Create a group policy object and apply to the OU
Edit the group policy object. Navigate to:
```
User Configuration > Policies > Administrative Templates > System
```
and set the policy named "Custom User Interface" to "logoff.exe"
Note that this policy will not apply immediately; you will need to use "gpupdate" on your systems if you intend to test right away.

Cautions

Use only true group policy for this setting. Do not apply this policy using the "Local" group policy object of specific machines, because it will then apply to all users. Effectively, no users will be able to log on to the machine (which is probably not what you want).
If you apply this policy to domain admin user accounts, make sure to also change the policy that allows only Administrators to authenticate to domain controllers. Otherwise the only users allowed to log on to the DCs will immediately be logged off (which is probably not what you want).

Limitations

The purpose of this procedure is only to guide the behavior of legitimate users by preventing the inadvertent (or lazy) use of their elevated account for desktop sessions. It does not restrict what an attacker or malicious admin can do with their credentials. Recall that authenticating to the interactive desktop is not necessary in order to change any setting, including changing their shell back to "explorer.exe".

It is still important, therefore, to secure administrative users with 2-factor credentials.

Configuring AuthLite v2 for VMWare vSphere

Some issues with vSphere we need to address for AuthLite 2-factor enforcement:

vSphere is not affected by logon group policies applied to its server, because it uses its own LDAP connection to authenticate to the DCs.
It also does a static lookup of group membership over LDAP, so we cannot ask it to check for the AuthLite 2-factor Tag groups to do enforcement.
Lastly, its LDAP authentication method requires some additional configuration in order for the DC to process it properly as a 2-factor logon.

Configuration for vSphere 2-factor logon enforcement:

Set up AuthLite users, placing them into the AuthLite users group, and assigning one or more tokens
Enforce blocking 1-factor logon of AuthLite users to your vSphere servers, by adding the vSphere servers by name or IP to the Forced 2-factor Computers list in AuthLite. This is the least favored way to enforce, but we have no other option because group policy is not relevant to vSphere.
Make sure "Treat LDAP client IP as the authentication source" is selected.
Add the vSphere servers to the "LDAP Permissions" list in AuthLite Configuration. The default timeout of 5 seconds should be sufficient.
Wait 20 minutes for all DCs to synchronize with the new AuthLite settings

To authenticate to the vSphere client as a 2-factor user, you must do the following:

Uncheck the "Use Windows session credentials" checkbox
In the username field, enter the NETBIOS domain name and a backslash,
If you are using a YubiKey, now press the button to fill in the OTP after the backslash.
If you are using an OATH token, enter your username, followed by a dash, and then the current OATH OTP digits
Enter your AD password as normal
Click "Login"

Common issues with OATH tokens (Google Authenticator)

When you are first setting up AuthLite and having trouble with your OATH tokens:

When provisioning a token, set the interval to 30 for Google Authenticator. You cannot make the token act differently by choosing a different number than 30, that's not what it does. You will just make AuthLite mistakenly believe the token is running at a 60 second interval and all your OTPs will be wrong.
Check the TIME is correct on all DCs and your phone or tablet.
If you are using Google Authenticator on Android, go into Settings -> Time Correction for Codes -> Sync now.
Check that the time ZONE is set properly on the DCs (it is not enough that the clock looks right, it must know its proper offset to GMT).
Make sure "OATH digits" are set to "6" in the AuthLite Configuration app under the section "Token Settings". The default is "0" which means do not use OATH tokens. You cannot make your soft tokens use a different number of digits by changing this value, that's not what it does. You will just make AuthLite mistakenly believe the tokens use 8 digits when they do not.

If your old OATH token used to work, but then stopped working:

The time probably drifted very slowly away from reality on your servers, and then was recently re-synchronized with reality. As they drifted, the DCs did not know it was their fault. They assumed the drift was because you are using tokens with poor clocks, so they kept track of the delta over time. But then after the time fix on the servers, they now acts as if the tokens (who were right all along) have all suddenly reversed their accumulated drift. So the DCs can't understand them any longer. Make sure your servers' time is correct, and run ResetDrift.ps1

If your old OATH tokens work fine but new ones will not work:

The time has gradually drifted away from reality on your servers and is now out of sync. The DCs didn't know they were drifting. They assumed the drift was because you are using tokens with poor clocks, so they kept kept track of the delta over time. So your old tokens still work fine since the DCs are compensating for their own incorrectness (unknowingly). The new tokens have an initial drift value of zero, and so the DCs cannot understand them. Fix the time on your servers, then run ResetDrift.ps1

Stacking Credential Tiles

Normally, AuthLite overrides and adds features to the default Microsoft credential tile presented on the Windows desktop.

(AuthLite Features) -> (Default Tile)

If you have another application that does the same thing, such as the password reset feature of Forefront Identity Manager (FIM)/Microsoft Identity Manager (MIM) then you will see "double" tiles on the login screen. One tile will have the AuthLite functionality, and one will have the other application's functionality.

(AuthLite Features) -> (Default Tile)

(Other Application) -> (Default Tile)

It is possible to consolidate these feature sets down into one tile by telling AuthLite the ID of the other vendor's credential provider. Then AuthLite will override the functionality of the third party tile instead of the default one.

(AuthLite Features) -> (Other Application) -> (Default Tile)

To do this, you need to perform the following steps:

Discover the GUID of the other application's credential tile.
Create a group policy object that tells AuthLite to override this credential provider, instead of the default one.
Apply the group policy object to your workstations.

At the time of this writing, the FIM password reset GUID is: {3DD6481A-A712-4c4c-88FF-6DDCAB28DE86} . You can look in RegEdit at the

HKLM\Software\Microsoft\Windows\Current Version \ Authentication \ Credential Providers

section to see all the provider GUIDs. In each sub-key you will see the name of the provider which may be enough of a clue to discern the right one. Otherwise, contact the vendor of your other application.

When authoring a group policy object, follow these settings to create a registry value. It should be a Computer setting (so hive = HKEY_LOCAL_MACHINE), and the Key Path should be:

Software\Policies\Collective Software\AuthLite

The Value name should be:

 CredprovChain

and the Value data should be the GUID of the other application's credential provider that was discovered above.

Ensure you link the group policy in a manner to affect the workstations and/or servers that have both AuthLite and the other application installed. If the other application is not present, then this setting will break the AuthLite credential tile behavior on that host.

You may need to restart a host to cause the credential tile to reset to the new behavior.

AuthLite Installation Needed on All Domain Controllers

Short answer:

YES.

Medium answer:

YES, unless you ONLY need to use AuthLite for RADIUS authentication for a VPN, and you have installed NPS on DCs. In that case, only the NPS DCs need AuthLite. This is because NPS will always loop back to the domain services installed locally.

Longer answer:

You may consider authentication to be occurring on your workstation or your member servers, but in a domain environment all authentications ultimately involve a Domain Controller.

AuthLite is not a client-only component that prevents logons after checking the OTP with some other authority. Instead, it uses your Domain Controllers to validate the OTP as well as the password. This is very important for "zero client" use cases. AuthLite works by modifying the login request so that the Domain Controller sees the OTP in the username property. Even if you use a client that allows you to enter the OTP in the password field, it gets internally rewritten to send the OTP in the username field. This is because the password is never sent to the DC, only a hash (irrelevant exception: password changes)

There is no API or method provided to restrict what DCs a client may reach. Microsoft has a black-box protocol that makes clients favor the DCs in their local site. Even so, if all nearby DCs are unresponsive, a client WILL reach out across site links.

If a client reaches a DC that is not AuthLite aware, your 2-factor authentications will fail, and 1-factor authentications that should be blocked will be allowed.

But I still want to do it because (X)

If you want to avoid installing AuthLite on some DCs, the only secure approach is the following:

You MUST create firewall rules such that clients and member servers that participate in 2-factor authentication CANNOT REACH any DCs that lack AuthLite awareness. In other words, to these systems it should appear that every DC in your org is always down and unreachable, except for DCs that you've installed AuthLite on.

Permissions to import YubiKey records

Warning

First of all, please note that you SHOULD NOT give help desk workers these permissions, because it entails allowing them to read and write OTP secrets. This is like letting them export everyone's AD password at will.

Opening the data partition

In ADSI Edit, open the AuthLite partition, which is under distinguished name:

DC=AuthLite,<DC=sandbox,DC=local>

NOTE: In the above command you must replace the <dc=sandbox,dc=local> portion with the LDAP syntax distinguished directory context of YOUR domain. (It will be the FQDN of your domain with "DC=" before each part, and a comma in place of each period.)

Full management permissions

Add the user or group to have Full Control on the CN=AuthLiteKeys container
Go into the Security->Advanced view on the CN=AuthLiteKeys container, find the line representing the user or group you added above, and Edit that rule. Change the Applies section from This object only to be This object and all descendent objects
Add the user or group to have Read access to the CN=AuthLiteHashes container

Make RDP client stop showing old OTP

Why is this a problem?

The remote desktop client, mstsc.exe, believes it is being helpful to you by showing the most recently used username in the login dialog. For most normal users this would be true, but for AuthLite users it is annoying because the previously used OTP is not ever going to work. The normal solution is to click "Other user" and enter a new OTP and password.

There is not any setting or key you can change that will make the RD client stop trying to do this behavior, but there is an ugly workaround.

OK, how do we stop it?

I apologize in advance for the crudity of this method, but: go into the registry setting where mstsc stores its hints, and change the permission so it cannot write to the key. In more detail, under the key

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers\192.168.4.70

There will be a value called UsernameHint. This stores what the client will display next time you try to connect to the server at "192.168.4.70". Change the value from the old form

NETBIOSDOMAIN\old-otp-string

to simply:

NETBIOSDOMAIN\

After doing this, go into the Security tab of the server's key and DENY your own user the right to set values in the key. See the following image:

After applying this setting, the logon window for this connection will always show a blank username field with the correct domain defaulted.

If you want the benefit of having the domain pre-populated, then you have to make this change for every server sub-key.

If you are OK with entering the domain name every time, you can deny access on the "Servers" key itself, and it will apply for every connection to every server then.

AuthLite Upgrade Advisory #5

Overview

On November 28, 2015, Collective Software corrected a settings defect introduced in AuthLite version 2.1.7 which caused a debugging feature to be enabled all the time, regardless of the user's intent. This could cause servers to boot up with the AuthLite core disabled, which means that server would not be able to process 2-factor authentications in the manner the user expects.

The feature in question is "Single shot crash dump", which attempted to collect debugging information in the event that lsass.exe (the authentication process) encountered an unhandled exception. After such an exception, the AuthLite core on that system preemptively disables itself, so that during following reboots the system will start without AuthLite running. (The theory behind this feature is that if lsass is crashing it would be safer to have the server running but AuthLite disabled, than have the server not able to boot.)

This feature was intended to be disabled by default, and always optional to turn on. But in versions 2.1.7-2.1.13, the feature is always active. So it is therefore possible that a server could have crashed and the AuthLite core could have been subsequently disabled, without you necessarily knowing it.

Instructions are included below on how to check and upgrade your installed version, as well as check that the AuthLite core is running properly.

Affected AuthLite Versions

AuthLite version 1.x and 2.0: not affected.
AuthLite version 2.1.0-2.1.6: not affected.
AuthLite version 2.1.7-2.1.13: is affected, please see below for update instructions.

What Should I Do?

You can eliminate this issue by performing the following actions on each system where AuthLite is installed:

Install an updated AuthLite version on each system

Upgrade the software to 2.1.14 or later, from AuthLite.com

Make sure the AuthLite Core is enabled

When a system boots with the AuthLite core disabled, a Warning event with ID 1 (source AuthLite) with text "AuthLite Core is disabled!" is logged to the server's "AuthLite Security" event log, which is found under "Applications and Services Logs".

Also, when the core is disabled on a system, the registry value HKEY_LOCAL_MACHINE\SOFTWARE\Collective Software\AuthLite\Settings "AuthLiteCoreEnabled" will be set to "false". If this value does not exist or is set to "true", then the core is running on that machine.

You only need to follow these steps if

you find the above event or registry setting on a server, or
if AuthLite does not appear to be working properly on a server, or
if your server restarted unexpectedly since installing 2.1.7-2.1.13.

Procedure to re-enable the AuthLite Core on a server through the registry:

Delete the value "AuthLiteCoreEnabled" under HKEY_LOCAL_MACHINE\SOFTWARE\Collective Software\AuthLite\Settings, or set it from "false" to "true"
Restart this machine to re-enable the AuthLite core.

Procedure to re-enable the AuthLite Core on a server through UI:

Open the AuthLite Configuration application and go to the Event Log section.
Turn the slider up to Debug, so that the Advanced button becomes enabled
In Advanced, make sure the "AuthLite Core is Enabled" checkbox is checked.
If the core checkbox is not checked, then you must select it, and click OK.
Turn the slider back to Information, or whatever value you were using before.
Click "Apply"
Restart this machine to re-enable the AuthLite core.
Please note the "core enabled" checkbox only affects the machine you are currently on. Checking this box will only fix the current machine. If other machines have experienced crashes, their AuthLite core may be (and remain) disabled until you perform this procedure on them. So please check your other servers too.

Common Questions and Answers

What is my exposure?

Customers who enforce 2-factor using Group Policy are not at any risk. The group replacement feature fails safe even if a domain controller or server is not running the AuthLite core.

For other enforcement mechanisms: When servers don't load the AuthLite core, they cannot make correct decisions about 2-factor enforcement. If you are using the "Forced 2-factor Computers" then you should check that the core is enabled on all your DC's. If the core is disabled on a server, an authentication by an AuthLite user using just username and password would be allowed, even when it should have been blocked.

If you are using the "Forced 2-factor Processes" list, then check that the core is enabled on all the servers which enforce 2-factor processes. If the core is disabled on a server, an 1-factor session would be allowed even on a process that was designated to force 2-factor for AuthLite users.

Should I upgrade if I am not affected?

If you are on version 1.2, stay there unless you have consulted with our support staff. Version 2 is a much more complex product and a proper upgrade requires a substantial amount of planning, configuration, and testing. We offer professional services just to help with this. In short, it's not something to be undertaken lightly.

If you are on version 2.0, you may wish to move to the newest 2.0 build. You can upgrade to version 2.1 at your discretion, but as of this article there are no compelling reasons to do so. Be advised that version 2.1 has a new minimum .NET framework version of 4.0.

Where do I have to install the update??

Install the updated software on all systems that currently have AuthLite installed. You must restart the system for the update to take effect. If AuthLite does not appear to be working on a system, see the above section, "Make sure the AuthLite Core is enabled."

I need help with this, what should I do?

If you require further details, or assistance with installing the update, please open a Support Request from our Support page and reference Upgrade Advisory #5

Install AuthLite to an image that is not yet domain-joined

As of version 2, AuthLite can only be installed and operate on domain-joined member machines.

But if you are creating system images, the machine on which you are creating the image is not joined to a domain yet.

Starting with v2.1.18, you can specify the MACHINETYPE property on the command line to cause the installer to assume the machine is domain-joined and install the proper components.

Example:

AuthLite_installer_x64.msi MACHINETYPE=MemberWorkstation

Possible machine type values:

```
MemberWorkstation
```
```
MemberServer
```
```
DomainController
```

Note that during a domain controller install, the installer normally installs any necessary schema updates and adds a data store replica to the DC. This means if you are pre-staging an image that is not yet a domain controller, you should also specify the options:

CREATESCHEMA=0 CREATEPARTITION=0 ADDLOCAL=DataManager

(Note that the last item prevents the installation of a replica. If ADDLOCAL contained the term "Replica" then it tries to create a replica)

AuthLite Upgrade Advisory #6

Overview

On September 26, 2016, AuthLite LLC corrected a defect introduced in AuthLite version 2.1.21 which caused AuthLite to be unable to read the command-line arguments of logon processes. This could have affected the enforcement of the Forced 2-factor Processes list, and also anyone who relied on the built-in enforcement of the Network Policy Server plugin to block 1-factor AuthLite users.

This issue is fixed in v2.1.24. Instructions are included below on how to check and upgrade your installed version.

Affected AuthLite Versions

AuthLite version 1.x and 2.0: not affected.
AuthLite version 2.1.0-2.1.20: not affected.
AuthLite version 2.1.21-2.1.23: is affected, please see below for update instructions.

What Should I Do?

You can eliminate this issue by performing the following actions on each system where AuthLite is installed on an NPS server, or a system that has items defined in the "Forced 2-factor Processes" list:

Install an updated AuthLite version on each system

Upgrade the software to 2.1.24 or later, from AuthLite.com
Reboot the system to load the new version.

Common Questions and Answers

What is my exposure?

If you run an affected version on a system that uses the Forced 2-factor Processes list, or the Network Policy Server plugin, AuthLite enforcement may not be working completely as you expect. Please upgrade to the new version and then test your authentication use cases to ensure that 1-factor logins are blocked as you expect, and 2-factor logins work as you expect.

Should I upgrade if I am not affected?

If you are on version 1.2, stay there unless you have consulted with our support staff. Version 2 is a much more complex product and a proper upgrade requires a substantial amount of planning, configuration, and testing. We offer professional services just to help with this. In short, it's not something to be undertaken lightly.

If you are on version 2.0, you may wish to move to the newest 2.0 build. You can upgrade to version 2.1 at your discretion, but as of this article there are no compelling reasons to do so. Be advised that version 2.1 has a new minimum .NET framework version of 4.0.

Where do I have to install the update??

Install the updated software on all systems where AuthLite is installed on an NPS server, or a system that has items defined in the "Forced 2-factor Processes" list.

I need help with this, what should I do?

If you require further details, or assistance with installing the update, please open a Support Request from our Support page and reference Upgrade Advisory #6

Configure a Linux domain member to accept AuthLite OTPs

These legacy instructions are outdated, preserved here for customers who are already using the pam_python method and need to refer to it.

Please see the Linux systems documentation page for the updated procedure.

(Outdated)

Debian-like systems

Install packages and files

Install the pam_python library. On Debian-like systems:

sudo apt install libpam-python

Copy the file auth.py to the directory /lib/security.

Configure PAM

The PAM configuration needs to change so that the authentication calls pam_python.so before the Active Directory authentication.

If the PAM configuration is managed by auth-update-pam, you can accomplish this via:

Copy the file authlite to the directory /usr/share/pam-configs
Run the command:

sudo pam-auth-update

Now verify that the file /etc/pam.d/common-auth has the line:

auth  optional  pam_python.so auth.py

above all other "auth" lines.

If the PAM configuration is managed manually: The goal is that whatever configuration file is being used for your authentication should have a line like:

auth  optional  pam_python.so auth.py

appear above all other "auth" lines.

Now add:

try_first_pass

at the end of the auth line following (which may be pam_unix or pam_lsass depending on the system used for domain joining) if it is not already there.

Next: see "Configure AuthLite" section below.

Redhat/CentOS-like systems

Install pam_python files

There is no pre-packaged pam_python module for CentOS, so it must be built from source

tar -xzf the .tar.gz file and go into the src subfolder
In pam_python.c, move the #include for Python.h above the #include for pam_modules.h
"make pam_python.so".

Then copy pam_python.so and auth.py to /usr/lib64/security. If it is a 32-bit machine it would be /usr/lib/security.

Configure PAM

The pam configuration will vary depending on how you have joined to the domain. In our test lab using SSSD, we modified /etc/pam.d/password-auth AND /etc/pam.d/system-auth directly, adding:

auth   optional   pam_python.so /usr/lib64/security/auth.py

above the line for SSSD or Centrify. Make sure you specify the correct full path to your auth.py script (lib or lib64 security).

For SSSD, add "use_first_pass" to the pam_sss.so line, so it can see the password result from the pam_python module.

For Centrify, add "try_first_pass" to the pam_centrifydc.so line.

Configure SSSD

If using SSSD, go into the sssd.conf file and add the "ad_server" setting, to specify an exact order for your DCs to be used. This counteracts aggressive load balancing that can cause the OTP to go to one DC but the password to another. Example:

ad_server = the.fqdn.of.server1,fqdn.server2,_srv_

(put _srv_ at the end, like that)

Also set:

cache_credentials = False

After making any changes, bounce SSSD service and whatever logon system is affected by pam config updates (e.g. ssh)

Configure AuthLite

Add the linux computer account (or a security group containing the computer account) to the following AuthLite settings:

Forced 2-Factor Computers (because linux generally can't see group policy enforcement)
LDAP Permissions (because linux does an OTP lookup and then throws it away and sends the authentication request without the OTP)
Sticky 2-Factor Computers (because SSSD does several authentications in a row without the OTP)

These settings will take 20 minutes to apply (plus time for inter-site replication, if applicable)

Test authentication

YubiKey: After entering your password, tap the YubiKey button to enter the OTP. Wait for the green light to come back on, to see that the OTP is finished. Then hit enter.

OATH: After entering your password, enter a dash (-) and then the current OTP digits for this user.

Troubleshooting

Look at your system logs in /var/log. They will squawk if pam can't find the pam_python module, the auth.py script or other similar things.

RDP bug in Windows 10 (builds 1709 and 1803)

Issue description

In the Fall 2017 "Creators Update" (build 1709) of Windows 10, Microsoft created a bug that affects how Remote Desktop credentials work. If you use AuthLite with RDP and Windows 10 on either build 1709 or 1803, you may have to log in twice to establish an RDP session.

The first logon as you connect will work the same as always. But then when the RDP desktop window opens, you may be presented with a second logon prompt. (No error will be displayed, you just have to enter a fresh OTP and type your password again.)

This problem will occur if your user account already has a session open on the machine (active or disconnected). Conversely, if the user has no sessions logged on at the machine, the bug doesn't appear and everything will operate normally.

Cause

The RDP single sign-on functionality for all third-party credential providers has been affected by a bug added in Windows 10 build 1709. It also affects build 1803 prior to the June 26, 2018 update.

Resolution

Installing Microsoft's June 26, 2018 cumulative update KB4284848 resolves this issue for build 1803.

At the time of writing (July 8, 2018) there is no fix for build 1709.

Similar Issues

If your system build does not match the above, and you receive an error message after connecting to RDP, then you probably have a Replay Window issue.

Getting help

If you have any questions about this issue, or are having other problems with AuthLite, we'll be happy to help. Please visit our support page.

AuthLite Advisory #7: YubiKey FIPS series replacement

Overview

On June 13, 2019, Yubico (the manufacturer of YubiKey tokens used with AuthLite) released security advisory YSA-2019-02 affecting the YubiKey FIPS token series.

AuthLite does not directly use any of the affected features of the token, so your AuthLite deployment is not directly affected. However if you or your users use affected tokens for FIDO/U2F, smart-card, or OpenPGP, those other functions can be impacted. Even tokens not presently using those features might still use them in the future, so they are considered vulnerable.

Affected YubiKeys

YubiKey FIPS Series with firmware 4.4.2 to 4.4.4 inclusive:

YubiKey FIPS firmware 4.4.2 to 4.4.4
YubiKey Nano FIPS firmware 4.4.2 to 4.4.4
YubiKey C FIPS firmware 4.4.2 to 4.4.4
YubiKey C Nano FIPS firmware 4.4.2 to 4.4.4

Not Affected Tokens

All other YubiKeys. I.e.

YubiKey standard, versions 1-2
YubiKey Edge
YubiKey NEO
YubiKey version 4, standard and Nano, A and C
YubiKey version 5, standard and Nano, A and C

What Should I Do?

Although there is no direct security threat to AuthLite use cases, if you have affected tokens purchased through AuthLite, you should still contact support and obtain free replacement tokens. We are also pro-actively reaching out to all customers who have purchased FIPS tokens from AuthLite.

Obtain replacement tokens at no charge
Program new AuthLite secrets onto the new tokens
Import token XML file into the token manager.
(Delete XML file after import! Very important!)
Assign tokens to your users in the usual manner, either administratively, or using the self-service portal.
Once users start using the new tokens, reclaim all the old tokens and discard them. Do not keep the tokens in reserve or keep using them for other purposes. Their security should be considered compromised.

Common Questions and Answers

Does this affect the security of Active Directory logons?

AuthLite does not directly use any of the affected features of the token, so your AuthLite deployment is not directly affected. However if you or your users ever use these tokens for FIDO/U2F, smart-card, or OpenPGP, those other functions can be impacted.

If I don't use affected protocols, can't I just ignore this?

Yubico has determined, in an abundance of caution, to replace all affected devices, even if they are not currently using the affected protocols. This is because we can never be certain that the tokens won't be reconfigured one day. In particular: web sites often prompt users to add 2-factor security. Users could choose to use FIDO/U2F with their YubiKeys even without telling the enterprise AD administrator. And those secondary uses of the token would be less secure.

I need help with this, what should I do?

If you require further details, or assistance with installing the update, please open a Support Request from our Support page and reference Advisory #7 or FIPS token replacement.

AuthLite Upgrade Advisory #8

September 10, 2019

In the next upcoming Windows 10 (191X) release, Microsoft is changing an API function that AuthLite uses. All old versions of AuthLite will fail to work properly on the new Windows 10 build, when it is released.

This issue is fixed in v2.3.22, released September 10, 2019 and available from our site at the downloads page.

Affected AuthLite Versions

AuthLite version 1.x and 2.0: not affected (don't support Windows 10 anyway).
AuthLite version 2.1.x, 2.2.x: are affected, please upgrade DCs and Win10s to 2.3.22 or later
AuthLite version 2.3.1-2.3.6: are affected, please upgrade DCs and Win10s to 2.3.22 or later
AuthLite version 2.3.1-2.3.21: are affected, please upgrade Win10s to 2.3.22 or later

What Should I Do?

If you run AuthLite 2.1 or 2.2:

It's time to upgrade your organization to version 2.3. As long as your DCs are all running OS version 2008R2 or newer, you may migrate to 2.3 easily. The first DC upgrade will require Schema Admins permission, and the subsequent DCs will only require Domain Admins rights. DCs must restart after install, one at a time.

After updating the DCs, you may update member machines. For the purposes of this advisory, the only workstations that need to be updated are Windows 10 machines, so they will be ready for the next Microsoft 191X release. Workstations must restart after upgrade.

Other member machines may be updated or left as-is.

If you run AuthLite 2.3.1-2.3.6:

You must update all your DCs to a more modern 2.3.x build first, then Win10 workstations. DCs must restart after install, one at a time.

After updating the DCs, you may update member machines. For the purposes of this advisory, the only workstations that need to be updated are Windows 10 machines, so they will be ready for the next Microsoft 191X release. Workstations must restart after upgrade.

Other member machines may be updated or left as-is.

If you run AuthLite 2.3.7-2.3.21:

It is always best practice for DCs to be running a version newer or equal to all other systems. But if necessary you may leave the older install on the DCs for now. If you update, the DCs must restart after install, one at a time.

For the purposes of this advisory, the only workstations that need to be updated are Windows 10 machines, so they will be ready for the next Microsoft 191X release. Workstations must restart after upgrade.

Other member machines may be updated or left as-is.

Questions or issues:

If you have any questions about the impact of this advisory, or the update instructions, or would like to schedule support time for assistance, please click the "(?)Tech Support Question/Create Support Ticket" button on the support page and we will be happy to help.

Stop RDP client from remembering last username

Permanent

In a user's "Documents" folder there is a hidden file called "Default.rdp", which is used to store default preferences.

If you open this in a notepad and add the value:

public mode:i:1

Then that user's RDP client will no longer save credentials.

Sometimes previously saved values will still be used by the popup credential tile (which we consider to be a bug). To clear that out, find the affected server key(s) under regedit at

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers

and delete their UsernameHint. (You can just delete the whole key if you want, though it will forget its RDP certificate fingerprints, if any, and make the user re-agree to the "do you want to trust this server" popups).

Temporary

You can also perform the "public mode" behavior in a one-off fashion by launching mstsc.exe with the argument "/public"

AuthLite Upgrade Advisory #10

A bug introduced in version 2.3.26 can intermittently cause crashes at machine boot time. Thanks to the assistance of an affected customer, we were able to find and correct it.

Behavior: Normally if a crash occurs during boot, Windows recovers and boots successfully. But if the crash happens several times in a row, the machine might show a Recovery screen or be stuck in a boot loop.

What to do:

If you run any AuthLite software from 2.3.26 to 2.3.30 inclusive, please update to 2.3.31 or later. You can get the latest v2.3 Installer from the downloads page
If you run version 2.3.25 or older, this bug does not affect you.

This does not constitute a security issue, however due to the chance of causing machine boot problems we are creating this upgrade advisory.

If you have questions about this issue, please create a support ticket, and we will be happy to help.

AuthLite Upgrade Advisory #9

There are some compatibility implications for AuthLite and Windows 10 version 2004:

-   Due to an API change by Microsoft, Windows 10 version 2004 machines require AuthLite version 2.3.26 or newer to handle AuthLite User logons properly.

-   Indirectly, this means your Domain Controllers should be updated to at least v2.3.26 or newer as well, so they can serve the new client machines correctly. (AuthLite clients expect the servers' version to be at least as new as they are.)

All AuthLite customers can update for free; we do not charge anything to install new versions.

Update Procedure:

1. The newest version is always available at AuthLite.com/downloads. Get "v2.3 installer (Win64)" msi, or later

2. Update AuthLite on the DCs first, and restart (one at a time). Note that you may need the Schema Admins group permission to update the first DC.

3. Then, you may push the new AuthLite version to client machines at your convenience.

If you cannot update your DCs to version 2.3 yet (e.g. if you have any DC's that are older than Windows 2008R2) then please hold off on installing Win 10 version 2004 too.

If you have Windows 10 machines that update to version 2004 but still have an older AuthLite that v2.3.26 on them, then AuthLite users will not be able to log in. You can repair this problem by either:

-   Updating the AuthLite version on the workstation and restarting. Please make sure your DCs are also updated as soon as possible.

-   OR temporarily pull users out of the AuthLite Users group, and have them log in with just passwords until the updates can be applied. Then put the users back into the AuthLite Users group.

If you have any questions or concerns about this, please open a support ticket at AuthLite.com/support and we'll be happy to help.

Mapped Drive / File Share troubleshooting

The content of this KB entry has been moved to the following documentation page:

Mapped Drive / File Share Troubleshooting

AuthLite Security Advisory #11

Summary:

If you are using pam_authlite module version 2.3.34.1 on Linux, please update immediately and contact us to mitigate a possible local information disclosure (more info below). No other version is affected.
If you are using our older Linux plugin that uses pam_python and auth.py, please update at your next convenience to the new supported system (more info below).

Issue #11.1 Information Disclosure:

There is an information disclosure bug in the Linux module pam_authlite version 2.3.34.1. As far as we know, there aren't any customers using this version (it contained a bug preventing it from working correctly and there were not any support requests logged about it). However, this code version was available for download on our web site between December 27, 2020 and the end of January 2021, so we are notifying everyone just in case it was deployed anywhere.

If you downloaded the file pam_authlite-2.3.34.1.tar.gz, built, and installed it, then please open a support request at https://tix.authlite.com. We will assist you to upgrade and mitigate a potential local information disclosure, where privileged information could be accessed by other users logged into the same machine.

Issue #11.2 pam_python Unsupported:

Prior to 2021, all our Linux plugin support for AuthLite used the third-party module "pam_python", which relies on a now unsupported version of Python, and does not look to be updated regularly any longer.

Therefore, we have migrated away from this solution entirely, and made our own stand-alone module "pam_authlite" which does not rely on python or third party pam modules. To update:

Debian-like: Stop using the pam_python solution by removing the file "authlite" from the folder "/usr/share/pam-configs", and then running "sudo pam-auth-update". Verify that "pam_python.so" lines no longer appear in any files in your /etc/pam.d folder.
Redhat/CentOS-like: Stop using the pam_python solution by removing any "pam_python.so" lines from files in your /etc/pam.d folder.
Follow instructions at https://AuthLite.com/Linux to build and install the new module.

If you have questions about this advisory, please create a support ticket, and we will be happy to help.

AuthLite Upgrade Advisory #12 (Server 2022)

There are some compatibility implications for AuthLite and Windows Server 2022:

- Due to an API change by Microsoft, Windows Windows Server 2022 machines require AuthLite version 2.4.6 or newer. Installing an older AuthLite version will make the lsass.exe process crash on boot, causing a restart of the system.

- Indirectly, this means your Domain Controllers should be updated to at least v2.4.6 or newer as well, so they can serve the new client machines correctly. (AuthLite member servers and workstations expect the DC AuthLite version to be equal or newer.)

All AuthLite customers can update for free; we do not charge anything to install new versions.

Update Procedure:

1. The newest version is always available at AuthLite.com/downloads. Get "v2.4 installer (Win64)" msi, or later

2. Update AuthLite on the DCs first, and restart (one at a time). Note that you may need the Schema Admins group permission to update the first DC.

3. Then, you may push the new AuthLite version to other non-DC machines at your convenience.

If you cannot update your DCs to version 2.4.6 yet (e.g. if you have any DC's that are older than Windows 2008R2) then please hold off on installing Windows Server 2022 as well.

If you have any questions or concerns about this, please open a support ticket at AuthLite.com/support and we'll be happy to help.

AuthLite NOT affected by Log4j/Log4Shell CVEs

No version of AuthLite is affected by any Log4j vulnerability, as no Java is used anywhere in the product. No action is needed to mitigate CVE-2021-44228 and CVE 2021-45046

Fortinet SSO (DC Agent Mode) and AuthLite break each other

When Fortinet SSO Agent is installed on a DC and running in "DC Agent" mode instead of Polling mode, AuthLite is prevented from working. Whichever product was most recently installed (or repaired) will function, and the other will not.

Windows provides only one "Auth0" registry hook under HKLM\System\CurrentControlSet\Control\Lsa . AuthLite absolutely requires this to function, but Fortinet can be run in Polling mode instead.

Possible solutions

Multiplexer

Install the LSA Multiplexer on every DC, and restart. This watches the Auth0 hook and makes sure it remains set to the multiplexer. Then it calls dcagent (Fortinet) followed by AuthLite. So both can work correctly.

Or,

Switch to Polling Mode in Fortinet

Remove DC Agent
Uninstall AuthLite MSI on the DC (you can SKIP this reboot)
Install AuthLite MSI again to set the hook properly
Now reboot the DC

Avast/AVG breaks AuthLite: workaround

As of late April 2022, the newest version of AVG/Avast anti-virus has a feature called "LSA Protection" that appears to block AuthLite from operating, as a side effect of its protection.

This will cause problems on an increasing number of machines as the AV engines update over time.

AVG has responded to several customers as of May 10th:

Until we implement the controls of the LSA Protection in our policies, managed devices will need to perform the following to disable the feature:

Disable Self-Defense from the policy where the affected devices are assigned: Login into your Console > Polices > your Policy > General Settings > Troubleshooting > disable self defense > save.
Then you will need to create a reg file or registry change via Group Policy/some management tools you may use, to apply it for all Devices on your Network:
```
Windows Registry Editor Version 5.00 
```
```
[HKEY_LOCAL_MACHINE\SOFTWARE\AVAST Software\Avast\properties\settings\SelfDefense]
```
```
 "LsassProtection"="0" 
```
Once the registry change has been propagated to devices, re-enable Self-Defense.

Also for individual machines, we have determined the following UI workaround to be successful:

In Avast/AVG Menu -> Settings -> General -> Troubleshooting, disable "LSA Protection"
Then reboot

We will continue to update this KB if we hear of new information that AVG releases to its customers.

AuthLite-controlled Domain Admin can't log into Exchange Admin Center

Add the AuthLite DA group (AuthLite-protected Domain admins) to the Exchange Organization Admins group (or Organization Management )
Remove the Exchange Organization Admins group (or Organization Management ) from Builtin\Administrators, as well as Domain/Enterprise Admins if it is in there

AuthLite Upgrade Advisory #13 (Server 2012 R2)

Starting with the July 2023 Windows update on Server 2012 R2 Domain Controllers, AuthLite will accidentally break the thread pool when the server gets busy. The server will start fine but then return authentication errors or become unresponsive once it hits a busy period of authentications. The errors may initially involve only AuthLite users, but depending on the amount of load the entire operation of the DC can be affected. It may not be able to recover until the server is restarted, but then the problems will recur when the server goes under busy authentication load again.

Upgrading your DCs to the newest AuthLite version (2.4.11) and restarting them is sufficient to resolve this problem. You can get this from the downloads page or directly at https://s3.authlite.com/downloads/2.4/AuthLite_installer_x64.msi

Notes:

If you have 2012 R2 DCs, you should plan to upgrade them to 2.4.11 even if you have not noticed any problems yet.
Make sure you have installed the relevant Microsoft Update to fix the GetAllTrustRelationships API. See the Microsoft support page at: apps-that-acquire-or-set-active-directory-forest-trust-information-might-have-issues. Each OS version and .NET Framework version has a different relevant KB to download the update.
If the AuthLite version on your DCs right now is *older than 2.3.27* then upgrading will require a schema update. We recommend you open a support request so we can advise about this, at https://tix.authlite.com .
Even if you are not affected by this issue, you may always choose to upgrade your AuthLite version. The issue described in this message, however, is only known to affect 2012 R2 DCs.
You should maintain all DCs to be on the same AuthLite version as each other, however it is not critical to do this immediately in one batch. Please do not keep them on different versions perpetually however, as this can cause behavior to differ depending on which DC an authentication request reaches.

AuthLite Advisory 14 (2022 DCs break after 2023-10 Windows Update)

The "2023-10 Cumulative Update for Microsoft server operating system version 21H2 for x64-based Systems" (KB5031364) makes changes in the kdcsvc.dll file on 2022 Domain Controllers that cause previous versions of AuthLite to break and prevent the DC from booting or authenticating users.

Install AuthLite 2.4.14 or newer on your DCs to address this issue.
Even though the issue only affects the 2022 DCs, it is generally preferable to update all DCs to eventually have them all running the same build.
After installation, the DCs will not have problems with the 2023-10 update.
For customers using AuthLite v2.5 please install 2.5.4 or newer, available from the Downloads page.

If your DCs applied the update already and you can't log in, the simplest workaround is:

mount the filesystem of the affected machine and rename the file c:\Windows\System32\CSALsubauth.dll to any other name (e.g. append an underscore).
After this, the AuthLite core will not load at next boot, and you should be able to boot and authenticate with your emergency break-glass account at least.
At that point you can install version 2.4.14 (or newer),
and reboot, everything should work as before.

AuthLite Advisory 15 (June 2024 update to 2019 and 2022 DCs)

2024-06 Cumulative Update has an accidental Microsoft bug that will make Domain Controllers stop calling the AuthLite module (thus breaking the authentication of all AuthLite Users.)

Please install version 2.5.16 or later from the downloads page to work around this problem.

Affected OS:

Server 2022 domain controllers that have installed June 2024 (KB5039227) update or any later update containing the same change. Microsoft updates are now cumulative so you cannot simply block one update and avoid the problem.
Server 2019 domain controllers that have installed June 2024 (KB5039217) update or any later update containing the same change. Microsoft updates are now cumulative so you cannot simply block one update and avoid the problem.

Not Affected:

Other OS version domain controllers
Non-domain-controllers.

If your DCs already updated, please log in with a 1-factor break-glass/emergency account to install the new AuthLite version, then reboot.

AuthLite NOT affected by Yubico CVE-2024-45678

AuthLite is not affected by Yubico CVE-2024-45678 because AuthLite uses only the YubiOTP and HMAC/SHA1 C/R algorithms, which are not impacted in the CVE.

The vulnerability requires physically destroying the key in order to access it with specialized equipment. If you use that YubiKey for other non-AuthLite purposes, such as FIDO, it could be vulnerable to that attack.

If you have any questions please reach out to Support.

AuthLite Upgrade Advisory #16 for Server 2025 DCs

In order to operate on Windows Server 2025 Domain Controllers, it will be necessary to run AuthLite 2.5.20 or newer. If you install an older version of AuthLite on Server 2025, or upgrade a server running an older AuthLite to 2025, it will go into a boot loop. If that happens, either remove the AuthLite install or rename C:\Windows\System32\CSALsubauth.dll to any other name (e.g. append an underscore).

Recall that in general, DCs should be running the same or newer version compared to other domain member machines. It's a good idea to converge all DCs to the same build.
It is permissible to run a newer version on your DCs than your domain members, and to have different members at different versions.
To upgrade a server's AuthLite version you may simply install the newest version from the Downloads page over the existing version, then reboot servers (one at a time). All configuration and keys will be retained.

Settings and keys lost when installing on a new DC, fixing and Preventing

Note: AuthLite version 2.5.23 and newer have been modified to prevent these issues from arising.

When AuthLite is already running on your network and then you install AuthLite 2.5.22 or earlier on the first DC in a new site, there is a chance it can accidentally create extra copies of the AuthLite data partition containers instead of seeing the old ones.

These extras will replicate (after up to three replication cycles, sometimes taking 2-3 hours depending on your topology) and cause a naming conflict, and the directory will then rename the old (real) containers, accidentally hiding the real data and making everything seem broken.

If settings are already lost

If this has happened to you, log in with a break-glass DA account, and run FixConflicts.ps1 on a DC (just one, it should not matter which). See if it finds and restores any settings. After the replication has completed again between sites, everything should be restored to a working condition.

(Don't forget to re-set your break-glass DA account with a fresh random long password once you're done using it, and record the new value for an emergency.)

To prevent naming conflicts at install time

We are working on a new version of the installer that will try to detect and prevent this case from happening, but it's challenging to proactively detect. Prior to AuthLite 2.5.23, the best procedure to prevent is the following:

When installing AuthLite on new DCs, you can call it from the command line with additional argument CREATEPARTITION=0 . For example

AuthLite_installer_x64.exe  CREATEPARTITION=0

Note if this is the very first install of AuthLite on a DC you must let the partition create; do not run it with createpartition=0 , or there will be nowhere to store settings.

AuthLite version 2.5.23 and newer have been modified to prevent these issues from arising.

AuthLite Upgrade Advisory #17 (November 2025 Update breaks some 2025 DCs)

After the November 2025 Windows Update, if Windows Server 2025 Domain Controllers are running "Additional LSA Protection" they may stop being able to track the correct IP address for LDAP connections. This can lead to failure to permit 2FA logons and/or failure to enforce 2FA on LDAP clients because it doesn't see the traffic as being from an enforced IP.

Upgrade to AuthLite 2.5.29 or newer to correct this issue; a reboot is required.
You do not need to disable LSA protection, it is a security feature that you should retain. Some bad AI advice will direct you to disable it, due to the fact that AuthLite didn't support it many years ago.
As far as we can determine, this issue does not affect other DCs, but you can upgrade them, and in general DCs should be converged to run the same build whenever possible.
This issue does not affect member servers or workstations, but it is fine to upgrade them too. It is also OK to leave them on older builds.

General advice:

Recall that in general, DCs should be running the same or newer version compared to other domain member machines. It's a good idea to converge all DCs to the same build.
It is permissible to run a newer version on your DCs than your domain members, and to have different members at different versions.
To upgrade a server's AuthLite version you may simply install the newest version from the Downloads page over the existing version, then reboot servers (one at a time). All configuration and keys will be retained.