Knowledge Base

How do I talk to a real person?

If you have a technical question and can't find the answer here, please contact our support staff

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

Free upgrade / upgrade prices

You are always welcome to install the latest version number of any product you have licensed. As long as your platform has not changed (for example moving from ISA to TMG). You can find the latest download for each product on their respective web pages on this site.

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

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 Collective Software 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.

If for any reason the links on this page become outdated, please search directly on microsoft.com to locate the newest URL for these resources.

Microsoft .NET Framework

AuthLite version 1 and our ISA/TMG plugins require .NET version 2.

Windows Server 2003-2008, Windows XP and 7

You can install .NET v2 directly: .NET Framework 2.0 SP2 Download for x86 and x64 systems
Alternately you can also install .NET v3.5 which includes the v2 runtime.

Windows Server 2012, Windows 8

These Windows versions come with v4 or v4.5 of .NET. AuthLite version 2 supports installation with this version of the .NET Framework.

ISA TMG can't load the web filter

ISA/TMG is very particular about DLL registration, and sometimes it holds on to old DLLs or fails to load new ones during the installation.

The best steps to take to resolve the problem yourself are:

Make sure your ISA/TMG services are all started, except for the Microsoft Firewall Service
Uninstall the Collective product (if it believes that it is installed)
Install it again, with the firewall service down
Check the application event log for any error messages from the installer
Now try to start the firewall service again

If these steps don't help, please open a support request for further assistance.

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.

ISA TMG components not found

If the installer shows an error that it cannot find ISA/TMG, this usually means that the install program does not have sufficient permission to read the registry key that points to the install location.

If you launch the MSI from an elevated command prompt, this will usually resolve the problem. If not, please open a support request for assistance.

Lite versions gone

We have discontinued the Lite versions of our web filters. Now, all our filter solutions can work on either Standard or Enterprise ISA/TMG.

This change was made to alleviate market confusion between the two tiers of filter.

Unattended 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 version 2.0 or higher is installed on the system. If your workstations don't already have this installed, then you will need to create a GPO to install the framework as well. Follow the steps presented here to create an .msi file for the framework, then create a GPO to deploy it, using the pointers below.

You will need to make sure the framework .msi 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.

Setup EXE to MSI

The AuthLite version 1 core software is distributed as an .msi file wrapped inside a setup .exe file.

So, in order to apply the AuthLite install with a GPO, you need to get the actual .msi file. You can do this by one of two approaches:

Extract the .msi file out of your AuthLite_Setup_Win32.exe or AuthLite_Setup_x64.exe. You can do this by opening the .exe as an archive with 7-zip and extracting the .msi inside the archive.
Our customer support can give you links to download the latest .msi files from our web site.

AuthLite version 2 already ships with .msi install files.

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_Win32.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 * from Win32_Processor where Architecture = 0
(64 bit): select * from Win32_Processor where Architecture = 9
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).

Upgrade from ISA to TMG

Most of our ISA filter customers will one day decommission their ISA servers and move to the TMG platform. This article talks about our licensing costs for TMG filters.

ISA filters and TMG filters are separate products

Unlike moving from ISA 2004 to ISA 2006, TMG is an incompatible platform requiring different filters. So, for example, Captivate for TMG cannot use the same license as Captivate for ISA. This means to use Captivate for TMG you have to buy the TMG license, even if (at one time in the past) you bought an ISA license.

What if I won't be using my ISA filter licenses any more

Even if you are decommissioning your ISA servers, you can't use those licenses for TMG. This sounds like a mean thing to do, but there is actually a very simple reason why we have to do it:

Unlike other companies, we sell software licenses as a one time cost. We never charge any annual recurring cost or maintenance to keep a license "current". And just like you, most of our TMG users are simply upgrading from ISA. Therefore, the only way we can defray the cost of supporting our products on the TMG platform is to charge customers (one time) when they need to buy the filter for TMG. Otherwise we would net zero dollars for TMG filters, and have no motive to support it.

We hope that makes sense. We are not trying to be greedy, but just support the filter development cost on this platform.

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 / 1001 Access is 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" and "Enterprise 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.

The first installation also creates the Application Partition. If your account is not a member of Enterprise Admins, you may not have this right.

Remember if you add your account to a 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, schema, and enterprise admins and you receive this error, it is usually caused by a disagreement between DC's about which system has the FSMO Schema Master or Naming 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 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.)

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 1.x:

AuthLite_Setup_(Win32 or x64).exe CREATESCHEMA=0

Version 2:

AuthLite_installer_(x86 or x64).msi 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.

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

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.

Captivate screen does not appear for HTTPS connections

When a new SecureNAT computer connects to an HTTPS web page the Captive portal process "does not work". Either the HTTPS site opens without Captivate, or the connection is denied.

More Information

When an HTTPS URL is entered into the browser, it creates an encrypted connection to the remote web server. Under normal circumstances, there is no way for Captivate (or anything else) to break into that encryption and issue a redirect. This behavior comes from the security design of HTTPS, and it is not possible to change this behavior. You have three basic options for how to proceed:

Redirect HTTPS requests into the Captivate process: To do this, you need to use forward HTTPS inspection. In ISA this can be done with our ClearTunnel filter. In TMG this ability is built-in. Using inspection will make ALL certificates for all sites that the user visits be signed by the web proxy, so SecureNAT clients will always get security warnings for each site. This is, again, by design of HTTPS and SSL and not something you can change. (Note however, if the client machines are managed domain members, you can push the certificate root's public key to them via group policy).
Block HTTPS connections before Captivate: In the properties of the HTTPS protocol on TMG/ISA, select the checkbox for the Captivate Application Filter. This will cause all HTTPS connections to be blocked (with errors) until the user tries to visit an HTTP page, and gets redirected through the Captivate process. Please note you must not hook the Captivate app filter to the HTTP protocol, only HTTPS.
Allow HTTPS connections before Captivate: Unhook the Captivate application filter from the HTTPS protocol. This would allow free access to HTTPS sites without blocking at all, regardless of whether the Captivate process has occurred.

Please understand, these three options are the only possible solutions, based on the cryptographic design of SSL and HTTPS. There is no way we, or anyone, could design a zero-client system to get around these limitations.

SecureNAT connections fail with Captivate

When you configure Captivate to authenticate SecureNAT users, the connections are blocked, or the captive portal screen is never shown.

This is usually caused by an incorrect configuration of the HTTP protocol. Go into the HTTP protocol properties, and make sure:

The "Web Proxy Filter" item is selected
The "Captivate" item is not selected

More information

The Captivate application filter blocks non-HTTP protocols until your users complete a captive portal process. If you hook this app filter to the HTTP protocol, you will end up in a situation where HTTP is blocked. This means the users' connections will be blocked before they can ever see the captive portal web page.

Also, if the WPF is not hooked by the HTTP protocol, then the Captivate web filter will never run. This means that the captive portal process will never be shown.

IMPORTANT: You must always have the Web Proxy Filter hooked to the HTTP protocol, otherwise all of ISA's HTTP inspection capability is completely turned off. Never unhook the filter when troubleshooting a problem. If you solve the problem that way, it means you are making ISA completely useless as an application inspection security device for HTTP.

ISA TMG can't load the web filter (1)

ISA/TMG is very particular about DLL registration, and sometimes it holds on to old DLLs or fails to load new ones during the installation.

The best steps to take to resolve the problem yourself are:

Make sure your ISA/TMG services are all started, Except for the Microsoft Firewall service
Uninstall the Collective product (if it believes that it is installed)
Install it again, with the firewall service down
Check the application event log for any error messages from the installer
Now try to start the firewall service again

If these steps don't help, please open a support request for further assistance.

Web filter is not working

You have installed a web filter and it appears to be having no effect even though you configured the settings properly.

Go into the HTTP protocol properties, and make sure the Web Proxy Filter is selected for this protocol.

IMPORTANT: You must always have the Web Proxy Filter hooked to the HTTP protocol, otherwise all of ISA/TMG's HTTP inspection capability is completely turned off. Never unhook the filter when troubleshooting a problem. If you solve the problem that way, it means you are making ISA completely useless as an application inspection security device for HTTP.

How can I determine whether LogHostname is working properly?

After installing LogHostname there are no specific rules or changes that need to be made for it to start working. The easiest way to test the filter to make sure it is working properly is to go into the monitoring->logging tab and logging all "web proxy" traffic. After this (if the filter is installed) the right-most column, "URL" will display items of the form:

http://yoursite.com/etc

If the filter is not working it would display the URL in the form:

http://1.2.3.4/etc

Certificate Wizard error

The ClearTunnel certificate wizard may fail with an RPC error even when all fields are correct. There are two possible solutions.

There is a known limitation with the ISA RPC filter that prevents the ISA server from connecting to the certificate server's RPC interface.

There are two approaches to solve this problem.

Short solution

Create a temporary "allow all" rule between ISA and the certificate server machine.
After you have run the certificate wizard successfully, disable or remove this rule.

Long but more correct solution

Disable "Strict RPC" in the System Policies, Authentication Services, Active Directory rule group
Configure the Certificate Server to operate on a predefined RPC port as outlined in http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/webenroll.mspx
Create a custom protocol that describes your custom CertSvr protocol
Create a computer set that includes all cert servers in your environment
Create an Access Rule that allows this prtoocol from the local host network to your Cert Servers computer set.

After you do this, your ISA will be able to auto-enroll for any certificates it needs (including running the ClearTunnel Certificate Wizard)

Could not find the old certificate key

Background

When the signing certificate is requested, ClearTunnel stores the keys inside the ISA configuration, so the same keys can be imported easily across all ISA servers in an array.

When renewing the signing certificate, ClearTunnel tries to re-use these keys, so that all previously signed and cached web server certificates will still remain valid.

Meaning of the error

If the keys are not found in the ISA configuration, it is not possible to get a new signing certificate using the old keys. This means every certificate cached by ClearTunnel on all servers in the array will become invalid once a new signing certificate is issued. If the old cached certificates are not deleted, then ClearTunnel will not be able to serve HTTPS requests until the problem is corrected.

Remedy procedure

In the ClearTunnel "Mode" tab, select "Disabled". Save and apply the configuration change.
In ISA Enterprise, wait for this change to be synchronized to the servers.
Close the ISA management console.
Open mmc.exe
Add the "Certificates" plugin, select "Services", "Local computer", then "Microsoft Firewall" service
In fwsrv\Personal\Certificates, select all items and delete them.
In fwsrv\Intermediate Certification Authorities\Certificates, find only the lines where the "Issued To" value is "ClearTunnelSigning" and delete them.
Do this on all ISA servers in the array before proceeding.
Open the ISA management console on an ISA server in the array
Navigate to the ClearTunnel "Certificates" dialog. The status should now read "Need to request certificate"
From this point, request a new certificate by following the normal procedure in the ClearTunnel documentation.
Save and apply the ISA changes.
Following the documentation, if you have an enterprise array, go to the ClearTunnel Certificates tab on each additional ISA server and install the certificate on them.
Restart the Microsoft Firewall service (on each array member).
Navigate to the ClearTunnel "Mode" tab and select "Full Bridge". Save and apply the changes.
Ensure that HTTPS browsing succeeds, and that the site's certificate is signed by ClearTunnel. You should also verify that the certificate is new by examining its "Valid from" and "Valid to" properties.

Exclude by IP address

It is possible to add an IP into the CT exclusions list by prepending a *, as in: *1.2.3.4

Possibly better: if you know the subject name that the SSL certificate uses, you can add that to the excluded list. Even when you connect with an IP, when CT gets the certificate and sees the name, it will match and then set the connection to excluded.

IE6 hangs

Configuration

Internet Explorer 6 using proxy settings
ISA 2004/2006 with ClearTunnel 1.2 or later

Behavior

When IE tries to make an HTTPS connection to a web server that does not respond, ClearTunnel's design triggers a browser bug. All future connection attempts stall or "spin" without actually sending any traffic to ISA. This includes http connections. Closing and re-opening IE restores its operation.

More information

In order to proxy connections, ClearTunnel must respond to the browser in place of the real server. By the time ClearTunnel finds out the real server is not available, the browser has already entered SSL mode. When ClearTunnel then closes the connection to the browser, IE6 experiences a bug and cannot open future connections even though all its old ones have closed gracefully.

Resolution

IE7 does not experience this behavior. If possible, upgrade your client systems.

Workaround

ClearTunnel can be instructed to perform an extra "test" connection to each SSL site before responding to the browser. If this test fails then the bug can be avoided by sending an error to the browser before it enters SSL mode.

To enable the workaround:

Create a text file on the ISA server, giving it a .js extension instead of txt

Enter the following code in the file with Notepad:

var root = new ActiveXObject("FPC.Root") var settingsSet = root.GetContainingArray().Extensions.WebFilters.Item("{0E5B37CA-4805-4e9d-BD18-369BBE5F3714}").VendorParametersSets.Item("{975CD532-A802-4d2b-9DFF-DF9DEB9FBFA9}") settingsSet.Value("PreConnectCheck") = "true" settingsSet.Save(false, true) WScript.echo("Done.")

Save the file
In Explorer, double-click the .js file to execute the code
The script should pop up a small dialog saying "Done." if the change was saved successfully.

To disable the workaround, follow the above steps, but substitute the line:

settingsSet.Value("PreConnectCheck") = "true"

with the line:

settingsSet.Value("PreConnectCheck") = "false"

Local Host workaround and KB941634

Overview

This article describes the Local Host issue, the workaround, and how to update ISA to a newer revision that fixes the issue.

ISA server 2006 (where the component version is less than 5.0.5721.250) has an issue that affects the operation of ClearTunnel. This problem is detailed in the following Microsoft Knowledge Base article:

http://support.microsoft.com/kb/941634/

The effect of this bug is that the Web Proxy cannot process ClearTunnel's decrypted traffic. In order to make ClearTunnel 1.2 and later work in this situation, you can either use a workaround or update ISA Server 2006 to a version that contains the fix for this problem.

Workaround

To allow ClearTunnel to work without changing the ISA software revision, it attempts to forward decrypted connections back through the Web Proxy listening port. However this means that the Web Proxy must be configured to allow traffic from Local Host, since that is where it will perceive all the ClearTunnel decrypted traffic to originate. To use the Local Host workaround, you should perform the following steps:

Create a new Access Rule (you may name it 'ClearTunnel Local Host' or choose another name)
Make it an Allow rule
Select the HTTP and HTTPS protocols
The source should contain the "Local Host" network
The destination should contain the "External" network
The rule should be applied to "All Users"
Make sure to move the new rule higher in the list than your other web rules, otherwise ISA may try to require authentication at this step (which is not desired).

Caveat: If you use this workaround, all HTTP/HTTPS connections originating from the ISA server will be allowed. This may not be desirable as it is a less secure configuration than blocking web access from the firewall.

Update

To resolve this problem without the need to forward traffic through the Local Host network, you can update your ISA 2006 software to a newer revision.

Note: All Microsoft hot fixes for ISA 2006 after a given date will include all previous fixes within them. Therefore if your ISA software is already updated to a revision greater than 5.0.5721.250 you should not need to follow these steps.

According to Microsoft, before installing the hotfix for this issue, you must first install the ISA 2006 Supportability update, KB939455.
After installing the above update, you must request the hotfix for KB942639. You can request hotfixes online here. You can also obtain the hotfix from Collective support by opening a support request.
Install the hotfix for this issue.
If you previously were using the workaround noted above, you can now remove the extra "Local Host" rule you added. ClearTunnel should now successfully work without the workaround in place.

Getting Help

If you have questions about this issue or other ClearTunnel configuration questions, please open a support request for further assistance.

OnRouting error in Alerts/ Event log

If you receive this error after setting up or changing your ClearTunnel certificate settings, then it is probably caused by the Application filter not loading the new settings.

Ensure that your configuration is synchronized with the Config. Storage Server (for Enterprise ISA)
Clear the Alert so you can more easily tell whether it is set again later.
Restart the Microsoft Firewall Service
Re-test the HTTPS page and check the Alerts section.

If this does not resolve your problem, or you have alerts or issues not covered in the Knowledge Base, please open a suppport request and we will be happy to assist you.

OpenSSL certificate authority

In your openssl.cnf in the v3_ca section:

Change basicConstraints to say:
```
critical,CA:true 
```
Uncomment the line:
```
keyUsage = cRLSign, keyCertSign 
```

Now, perform the following commands

openssl req -newkey rsa:1024 -nodes -keyout ClearTunnelSigning.key -out ClearTunnelSigning.csr

important: the common name you give below should be ClearTunnelSigning

openssl ca -config openssl.cnf -extensions v3_ca -infiles ClearTunnelSigning.csr

Sign and commit

Find the new .pem file (location depends on the openssl.conf)

openssl pkcs12 -export -out ClearTunnelSigning.pfx -keysig -inkey ClearTunnelSigning.key -in ClearTunnelSigning.pem

Take this pfx to ISA and use it with the InstallCert tool as detailed in Appendix C of the ClearTunnel documentation. You will also need a base-64 encoded file containing the trust chain (public certificates) of your openssl authority structure. These are often stored in .cer files, which can be concatenated together to produce one "chain" file.

A typical installation would use the commands:

cd "\Program Files\Microsoft ISA Server\Collective Software\ClearTunnel"  InstallCert.exe /PFX:ClearTunnelSigning.pfx /Chain:cacert.pem

Using quot Content Types quot tab

Overview

This article describes how to configure extra ISA rules that allow ClearTunnel to coexist with rules that use "Content Type" tab filtering.

Prerequisites

ISA 2006
wspsrv.exe version 5.0.5721.250 or later (see this article )
ClearTunnel 1.2 or later
A working ClearTunnel setup without using "content type" limits. I.e. don't try all this advanced config until you have a simpler config working and tested.. If your setup already doesn't work, all this will probably just confuse the issue even further.

Theory

There are three ISA limitations that need to be overcome.

Using content type restrictions on a rule causes that rule to be skipped during the initial https CONNECT request, so we have to make another rule which can handle those, or else all proxy clients will fail to establish https sessions.
Unfortunately having that special rule to satisfy #1 causes a new problem: now all the content types you meant to restrict will be able to flow through the specially created rule! So we will have to craft and place the new rule so that it can only be used for CONNECTs, and also not harm other traffic.
ISA cannot recognize the content type of some internal CT traffic, so we need another special rule to explicitly allow it, but not encounter again issue #2 where the special rule will be too widely applied.

Definitions

For the purposes of this discussion:

Proxy rules: All your normal forward web proxy rules, i.e. all http/https rules that you define to allow and control outbound web access. You wish to use the "Content Types" tab to restrict one or more of these rules.
Connect rule: The special rule created to address issues #1 and #2 above.
Certificate rule: The special rule created to address issue #3 above.
Certificate URL set: The URL set created to address issue #3 above.

Workaround

Create the Connect rule with the following properties:

Allow
HTTPS protocol
From Internal
To External
For whatever set of users you wish to allow to initiate HTTPS connections. This depends on your Proxy rules. It may be "all users", "all authenticated" or some other subset depending on your needs.
Position this rule below all your Proxy rules
Go into the Protocols tab and select Filtering and Configure HTTP
In the Methods tab, select Allow only specific methods
Add the method CONNECT to the list

Create the Certificate URL set:

A new URL set

Containing one item:

http://*/06A95EBB-2ABB-489a-B85B-0E92846F2159*

That has to be exact, so double check it

Create the Certificate rule with the following properties:

Allow
HTTP and HTTPS protocols
From Internal
To Certificate URL set
For all users
Position this rule above all your Proxy rules

After applying these settings, you should now be able to use Content Type restrictions in your Proxy rules.

Getting Help

If you have questions about this issue or other ClearTunnel configuration questions, please open a support request for further assistance.

500 or 403 error

This behavior can often be due to a simple misconfiguration, but this KB article may apply: http://support.microsoft.com/default.aspx?scid=kb;en-us;912122

In general, these errors often revolve around authentication issues. You certainly do not want to ever allow credentials to pass over unencrypted HTTP. ISA 2004 SP2 and later will disallow HTTP connections to a listener that it deems to be configued insecurely (not SSL, authentication required or even supported)

In order to use WebDirect with the minimum amount of hassle, maintain security, and not lose this important protection that ISA adds, we recommend the following type of configuration.

When you accept connections to HTTP for the purpose of redirecting them into HTTPS, use a separate HTTP-only listener that does not require authentication. Make sure all webdirect rules use listeners of this type, and have "All users" set in their Users tab.

This configuration should allow users to hit the redirect rules and then return in HTTPS mode to your true publishing rule that supports correct authentication in a secure fashion.

Redirection in ISA 2006

Well it depends on what you are trying to do. It is more flexible than the built-in options of ISA, but you should become familiar what those options are. Check out this article:

http://blogs.technet.com/isablog/archive/2007/05/07/http-to-https-redirection-options-in-isa-server-2006.aspx

We pride ourselves on excellent customer service, and part of that is being straightforward about when people might do just as well or better to not be customers in the first place. Happy redirecting!

WebDirect blocking all requests

Prior to version 1.1.7 there was a bug in the WebDirect evaluation code that caused it to reply to all web requests through ISA server with the "WebDirect has expired" message. This defect has been fixed with version 1.1.7.

To fix this problem you can download the new evaluation version and install it over the old 1.1.6 version. This will not extend your evaluation period, but it will stop the expiration message from denying your normal web traffic.

If you know that you want to purchase the software anyway, then you can simply proceed to install the licensed version instead and that will also eliminate the problem (this approach has the benefit of course that WebDirect rules will start to work again!)

We apologize for any inconvenience this has caused to our customers!

Authentication and Agreement pages load slowly

The problem here is that ISA/TMG isn't a web server and it's not particularly talented at efficiently serving files. The only affected files will be the login/agreement pages and any items they refer to (images, script, css, etc.)

Some customers have worked around this latency by placing the css, javascript, and images on an anonymously available IIS server so that the only thing ISA has to send is the very small html itself.

If you are experiencing this behavior, the above solution will probably be your best bet. You could also simply remove all images and the css declaration from the html and write an html yourself that only uses hex colors and other simple elements to save on total transfer size.

WebTOS interfaces

Currently, WebTOS only supports two TOS screens: one for internal network users and one for external network listeners (which can be enabled or disabled in each listener's properties).

If you need to further differentiate, you could code look+feel changes into the DHTML for the TOS pages that make them alter their appearance based on (for example) server name.

The WebTOS getting started guide provides help with the setup and usage of both TOS screens.

Can't authenticate via Flexauth

IP address

When the IP address is used for the URL instead of the FQDN it causes this error: "Could not log on with the information supplied. Please try again" to be thrown.

With a form authentication, the session is stored in an HTTP cookie and sent to ISA with each request from the browser. When you try to use an IP address to access your resources, FlexAuth is trying to set a cookie for your FQDN (fully qualified domain name) but your browser won't return it in the next request. Hence FlexAuth will never be able to tell that you have logged in after the first request.

To solve this problem, always access the site with the correct host name, even when testing. You can set an entry in the hosts file if necessary, as long as the browser believes it is going to the correct URL.

Wrong FQDN

In the realm settings for FlexAuth make sure the URL you enter matches the URL you are trying to access in the browser. Don't use *.example.com in the settings if your site is actually published to the Internet as something.example.NET, etc.

Error: Configuration container search failed

This error can occur when you specify a NETBIOS domain name but the Base DN to search is not set to the root of your domain LDAP tree (i.e. dc=my,dc=domain,dc=com).

This happens because FlexAuth is trying to determine the distinguished name of your domain, so that it can properly search for the user object. To accomplish this, it needs to find Active Directory's "Configuration Container" which stores the mapping from NETBIOS names to distinguished names for domains.

Also, if your LDAP server is not an AD global catalog server (or an AD server at all) then the configuration container won't exist.

In most cases this problem can be resolved by adjusting the Base DN path to be the root domain space of your AD domain.
If you are authenticating against a non-AD LDAP server, make sure you do not specify any NETBIOS domain in the FlexAuth realm settings.
In one case support observed an AD LDAP server that was (for some reason) not responding to search requests for its configuration container, even with the correct base DN. Since it was a single domain, removing the NETBIOS domain in the FlexAuth realm allowed the search to work, as FlexAuth then treated the LDAP search as if it was a non-AD server. This workaround means that the credentials forwarded to the upstream web server cannot have the domain name prepended. This may be acceptable if the upstream servers are configured to use the correct default domain setting.

FlexAuth and LockoutGuard

NOTE: Collective has a separate ISA 2006/TMG filter called LockoutGuard, which operates with the built-in web publishing authentication. This article refers to the older 2004 filter FlexAuth feature of the same name.

FlexAuth LockoutGuard works by detecting when a user account is one attempt away from lockout. When that is the case, it instructs FlexAuth not to try the login any more, but simply return the "login failed" message.

In this manner, the account can not ever be locked out through FlexAuth, and the user has (at least) one try to log in via some other means, i.e. local desktop, etc.

It is a system designed to prevent a lockout "denial of service" by a malicious outside party purposefully causing accounts to be locked out remotely.

Note that when LockoutGuard has gone into effect, there is still not a way to log in through FlexAuth of course, until the lockout count is reset by Active Directory. That occurs after the AD timeout period, or upon a successful authentication by the user.

If all that is confusing, just think of it in the following simplified way: LockoutGuard causes a "meta lockout" to occur one attempt before "real lockout" would occur. This provides the following advantages:

Brute forcing of accounts is still thwarted, via the same mechanism that normal AD lockouts employ
A local login (inside the LAN, or via vpn) on the account is still possible, since the lower LockoutGuard threshold prevents actual lockout from an remote internet-based attacker.

Thus, LockoutGuard does not in any way compromise the security of the AD lockout scheme. However depending what your needs are, it may not be right for your network.

Please note that there is a known issue regarding LockoutGuard and multiple domains. Basically: the lockoutguard will work for the domain your ISA is a member of, (or the domain the LDAP server is a member of), but it will fail to offer additional protection for other domains in the forest. For those other accounts, normal lockout is still possible.

RSA SecurID

FlexAuth does not internally support two-factor authentication.

If you can run all your SSO resources through one listener by using a wildcard certificate or publishing them as paths, then you could perform 2 factor authentication by by using two "chained" listeners, as described in the following article: isaserver.org tutorial

The first listener to accept the external connetion would do your first authentication factor (RSA SecurID for example) and then hand off the request to the localhost chained listener, which is configured to do the second factor.

FlexAuth would not be required for this scenario, unless for example you want to use its features for easy customization of the logon form.

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

Support for ISA 2006 / TMG

Our filters will install and run on both ISA 2004 and 2006. Most filters also have TMG versions (see each product for details)

Some of the older filters may no longer be required due to new functionality that has been added to the core ISA/TMG product. But you can still use them if there is a feature you need, or you prefer the filter's solution.

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 Settings" 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 provisioning a token, set the interval to 30 for Google Authenticator. You cannot make the token act differently by choosing a different number, 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.
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 Token settings, from the default "0" which means do not use OATH tokens.
In the token app on your device, make sure the code is always changing every 30 seconds. If the code seems frozen/stuck, kill and restart your app (and maybe look for a better one).

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