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.
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.
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
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:
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:
Active Directory contains some very useful specific attributes. LSC offers some functions to read and/or update some of these.
So far, we can:
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:
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.
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.