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.

You can see a complete configuration for syncing users between OpenLDAP and AD here.

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

Multi valued attributes size limit

Active Directory limits the maximum number of values returned by a ldap search for multi-valued attribute. As an example, AD use Group objects which contains the multi-valued attribute member.

By default this limit in AD 2008 R2 is fixed to 1500 values.

If we have groups with more than 1500 members LSC could faild to correctly synchronize these groups.

This limit is configurable in Active Directory (Windows 2008/2008 R2) using this KB

Filter to find user objects

Active Directory defines a user objectClass, which is used to represent user accounts.

So, using a LDAP filter in a search to find users is easy, just write “(objectClass=user)”. Well, almost.

Actually, the user objectClass is also used to represent computers and trust accounts[1]. So you need to add some components to your filter to avoid selecting these as well. Two options:

  1. Select the account type specifically: (&(objectClass=user)(sAMAccountType=805306368))
  2. Exclude the sub-objectClasses explicitly, like this: (&(objectClass=user)(!(objectClass=computer)))

See [1]: SAM-Account-Type Attribute description.

Thanks to Alexey Wasilyev for this tip.

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:

  1. Open a new MMC controller: from the Start menu, choose “Execute…” and type in “mmc”, then hit enter.
  2. From the File menu, select “Add a component” and scroll down to “Active Directory schema”, add, and click OK.
  3. Select “Attributes” in the list that appears, then find the attribute(s) you want to index.
  4. Right click on each one, and open their Properties.
  5. 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:

  1. Open the Active Directory Sites and Services administration tool
  2. Find the Domain Controller you want in the Sites/Servers list, and right-click on it to open it's Properties
  3. In the window that appears, select the checkbox “Global Catalogue” and press OK

Specific attributes

Active Directory contains some very useful specific attributes.

A useful list of how these attributes map to settings in the AD user interface is available at http://portal.sivarajan.com/2010/07/aduc-and-ldap-reference-sheet.html.

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.

Password Synchronization

Overview

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.

Approaches

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.

  1. 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. here an example how to do this.
  2. 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).
  3. Configure Active Directory to capture password changes, by either:
    1. Notifying another server on user password changes, using the Password Synchronization component of Microsoft's Services For Unix addon.
    2. Capturing the passwords, using PasswdHk, a password filter DLL.

Pitfalls

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.

Non-standard objectClasses

Active Directory does not respect the inetOrgPerson objectClass definition, as specified in RFC 2798. An explanation is provided below.

LSC version 1.2.0 can synchronize to and from Active Directory despite of this.

The objectClass inheritance path defined in RFC 2798 is as follows:

  • top
    • person
      • organizationalPerson
        • inetOrgPerson

However, in Active Directory, an extra objectClass, named user is inserted in this path:

  • top
    • person
      • organizationalPerson
        • user
          • inetOrgPerson

This is documented by Microsoft in the Active Directory Schema documentation.