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

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