Synchronizing to/from Active Directory
Microsoft's Active Directory is a standards-based LDAP directory (well, mostly). Therefore, it is quite easy to set up identity synchronization with a AD Domain Controller. Below are some tips to get around some of the specifics.
Anonymous access controls
By default, anonymous access to Active Directory servers has almost no rights to read data. Create a technical account, and use that to give LSC access to the server.
Search results size limit
As most LDAP servers, Active Directory limits the maximum number of results to a search. By default, this limit is 1000. Since LSC starts by doing a search for all identities in the directory, this means a maximum of 1000 entries will be synchronized.
To work around this, LSC can use the Paged Results control. Set the following property for the source or the destination in lsc.properties, and LSC will read results by page, with no maximum limit.
src.java.naming.ldap.pageSize = 1000
Indexing search attributes
LSC performs lots of a searches on the same attributes (those specified in lsc.tasks.<taskname>.[src|dst]Service.pivotAttrs property in lsc.properties). If this/these attributes are not indexed in Active Directory, this can make LSC seem to run very slowly.
It is easy to index an extra attribute in Active Directory. On the Schema Master domain controller:
- Open a new MMC controller: from the Start menu, choose “Execute…” and type in “mmc”, then hit enter.
- From the File menu, select “Add a component” and scroll down to “Active Directory schema”, add, and click OK.
- Select “Attributes” in the list that appears, then find the attribute(s) you want to index.
- Right click on each one, and open their Properties.
- Select the “Index this attribute in Active Directory” checkbox, and press OK.
Reading from a Global Catalogue in a multi-domain forest
If your Active Directory forest contains multiple domains, then the LDAP server on each domain controller will only offer a view of the users in that domain.
If you want to synchronize all accounts in the forest, you may access the Global Catalogue interface offered by selected Domain Controllers. This is a typical LDAP interface, on TCP port 3268, but is read-only. It is most useful to use this for your source, therefore.
To make an Active Directory Domain Controller a Global Catalogue:
- Open the Active Directory Sites and Services administration tool
- Find the Domain Controller you want in the Sites/Servers list, and right-click on it to open it's Properties
- In the window that appears, select the checkbox “Global Catalogue” and press OK
Active Directory contains some very useful specific attributes. LSC offers some functions to read and/or update some of these.
So far, we can:
- read userAccountControl (for example to check account status, etc…)
- update userAccountControl (for example, to enable/disable an account, force the user to change password on next login, set the password to never expire, etc…)
- read lastLogonTimestamp to find out the number of weeks since last successful login throughout the Active Directory domain
- set unicodePwd to create or replace the password
Detail on how to do this is here for now.
Synchronizing passwords with Active Directory is a common requirement, but generally a tricky subject. LSC does not solve this problem for you, but can help you achieve your goal. In particular:
- LSC can write a password to Active Directory, given the original password in clear text (there is no way to update a password in AD if you only have a hashed password, in MD5 or SHA, for example).
- LSC cannot read passwords from Active Directory.
There are several approaches to synchronizing passwords with Active Directory. A few we (the authors of LSC) have tried are metioned here. If you have other approaches, we'd love to hear about them.
- Store passwords in your source repository, either in clear text or in a two-way encryption scheme (LSC includes tools to encrypt and decrypt such an algorithm), then use LSC's AD tool-class to update the password in AD.
- Use AD as your main password store, and configure an OpenLDAP directory server to redirect authentications there, via SASL and LDAP binds. See detailed documentation to set up OpenLDAP and saslauthd to bind to AD (in French only).
- Configure Active Directory to notify another server on user password changes, using the Password Synchronization component of Microsoft's Services For Unix addon.
Active Directory is, er, a little peculiar in it's handling of password changes. Here are some hints, to avoid being bitten by it's weird behaviour, like we have been
Old password remains valid for an hour
As described in this Microsoft Support article, as of Windows Server 2003 SP1, once you've changed a user's password, the old password remains valid for an hour after the change. In effect, this means you can use both a users' old password and the users' new password to log in for one hour!
New password accepted in LDAP modify operation but not really accepted
In some cases (particularly with passwords containing special characters, such as non ASCII characters), Active Directory will accept a password update operation and return a “Success (0)” result for the LDAP modify operation, BUT the new password will not be useable.
For this reason, we recommend to always check that a succesful BIND operation can be performed on the Active Directory with the new password after changing it. You can use the canBind* functions to do this.
Active Directory does not respect the inetOrgPerson objectClass definition, as specified in RFC 2798. This results in broken behavior during generation with LSC 1.1.*. An explanation and a workaround are provided below.
The objectClass inheritance path defined in RFC 2798 is as follows:
However, in Active Directory, an extra objectClass, named user is inserted in this path:
This is documented by Microsoft in the Active Directory Schema documentation.
As a result, if you use LSC to perform it's generation using the objectClass inetOrgPerson, it will fail. To workaround this issue, specify the objectClass user.