Active Directory Deployment Notes

Licensing

Enter the license code on one Domain controller where AuthLite is installed, and it will propagate to other DC's via replication. Member servers and workstations will read the license value from the directory as well.

Due to replication delays, some servers may temporarily still believe they are unlicensed.

Software Installation

In order to authenticate AuthLite users, a Domain Controller must have the AuthLite infrastructure software installed. If a workstation (or member server) connects to a DC where AuthLite is not  installed, all the AuthLite operations will fail on that machine, and AuthLite users will not be required to use two-factor authentication, since this enforcement is done at the domain controller.

Domain Controllers with AuthLite software installed will still function normally for all their normal roles, including authentication of non-AuthLite users. AuthLite does not replace or remove built-in Microsoft components or behaviors.

Application Partition (database)

AuthLite takes advantage of the robust, multi-master replication offered by Active Directory by using an Application Partition to store all its user data and domain-wide settings. This is the same method that Microsoft's own DNS server uses to manage its data.

The first installation of AuthLite on a Domain Controller in your enterprise will automatically create this partition, and the schema additions necessary to support it. Thus, the first DC you install AuthLite on will be a replication host for the partition, by default.

AuthLite does not add or change any schema properties on the "user" or other built-in objects in Active Directory. All AuthLite data is stored separately in the AuthLite Application Partition. Adding the AuthLite schema elements will have no performance impact on user object replication since we don't touch those objects at all.

Replication hosts

By design, AD Application Partitions do not automatically replicate to every DC in your enterprise, because it is assumed that the data they contain may only be needed by a subset of the enterprise. If a DC receives a directory query for a partition that's not stored locally, it will refer the request to a remote DC that stores the partition.

This referred connection can be slow if the remote DC is in another site. Since AuthLite requires access to its partition in order to operate, any AD site where AuthLite is used should have at least one DC that hosts a replica of the AuthLite data partition.

Also, to support redundancy if the first partition host goes offline, you may wish to host the partition on more than one Domain Controller in the same site. (Without access to the AuthLite partition, all AuthLite operations will not function.)

You can easily specify whether a DC should host a replica the AuthLite partition at install time, by enabling or disabling the installer feature “Create a Data Store Replica on this DC”. This feature is selected by default when installing AuthLite onto a DC. Thus if you do not change the selection, every Domain Controller where AuthLite is installed will also have a replica of its data partition, which is a reasonable default.

This option in the AuthLite installer doesn't perform any proprietary operations when making a replica, it is just a convenience. You can also use the Microsoft command ntdsutil to control the replication hosts for Application Partitions. The partition's distinguished name will be

Content

Although not necessary for normal operation, you can browse and change the partition content with the Microsoft MMC plugin adsiedit.

To browse the AuthLite key data, you can use the AuthLite Token Manager application installed on the domain controllers.

Deletion

Uninstalling AuthLite does not remove the data partition or affect which DC's host its replicas. This way, if AuthLite is reinstalled, all the existing data can be used again, and users can continue to authenticate. If removal of the partition is desired, this can be accomplished with the Microsoft ntdsutil command.