Home Contact Download
Open source connector to synchronize identities to a LDAP directory from any data source including any database with a JDBC connector, another LDAP server or flat files ...
Download  |  Read more...  |  Get started!

Extended synchronization rules for Active Directory

The LSC has some built-in fonctions to interact with some specific attributes of an Active Directory. For the moment, the only attribute you can interact with is UserAccountControl.

UserAccountControl (account type and status)

This attribute is a set of bits to manage a user in an AD. You can access it the normal way in LSC (dstBean.getAttributeValueById('userAccountControl')).

Here are some methods to simplify changing values of this attribute.

userAccountControlSet

You can set specific bits with the method AD.userAccountControlSet. This method takes 2 parameters :

  1. The value (integer) of the userAccountControll
  2. An array of constants that will tell LSC to set (or unset) a specific bit

For example:

lsc.syncoptions.user.userAccountControl.default_value = \
    AD.userAccountControlSet(\
        dstBean.getAttributeValueById('userAccountControl'), \
        [AD.UAC_UNSET_ACCOUNTDISABLE])

You can find a list of all the constants in the org.interldap.lsc.utils.directory.AD class. The constants are prefixed by UAC_SET and UAC_UNSET.

Warning: to create an entry in AD, you can set userAccountControl field but the flag UAC_PASSWD_NOTREQD is mandatory if no password is submitted. So you can have a create_value like this:

lsc.syncoptions.user.userAccountControl.create_value = \
    AD.userAccountControlSet( "0", [ AD.UAC_SET_PASSWD_NOTREQD, \
        AD.UAC_SET_NORMAL_ACCOUNT ])

userAccountControlCheck

You can check if a specific bit is set with the method AD.userAccountControlCheck. This method takes 2 parameters :

  1. The value (integer) of the userAccountControl
  2. A constant that will tell LSC if a specific bit is set (or not)

For example :

AD.userAccountControlCheck(dstBean.getAttributeValueById('userAccountControl'), \
    AD.UAC_ACCOUNTDISABLE)

You can find a list of all the constants in the org.interldap.lsc.utils.directory.AD class. The constants are prefixed by UAC_ (without SET or UNSET after).

userAccountControlToggle

You can toggle a specific bit with the method AD.userAccountControlToggle. This method takes 2 parameters :

  1. The value (integer) of the userAccountControll
  2. A constant that will tell LSC which bit to toggle

For example :

AD.userAccountControlToggle(dstBean.getAttributeValueById('userAccountControl'), \
    AD.UAC_ACCOUNTDISABLE)

You can find a list of all the constants in the org.interldap.lsc.utils.directory.AD class. The constants are prefixed by UAC_ (without SET or UNSET after).

Managing password

LSC enables creating and changing passwords for users. Here are some methods to simplify changing values of this attribute.

getUnicodePwd

This method encode a string to fit the syntax of the unicodePwd attribute in AD, used to set the password.

So you can create a default password (e.g. “changeit”) for created users by setting:

lsc.syncoptions.user.unicodePwd.action = K
lsc.syncoptions.user.unicodePwd.create_value = AD.getUnicodePwd("changeit")

Warnings and various 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, see their documentation here.