Cl?ment OUDOT a ?crit :
>> Cl?ment OUDOT wrote:
>>>> It is only for AD as a destination directory.
>>>>
>>>> But it will not be hard to code some function to access specific
>>>> attributes of UserAccountControl in a source directory.
>>>
>>> Ok, I now really need some examples ;) Long life to LSC tutorials!
>> The userAccountControl attribute in Active Directory controls various
>> options for user accounts (objectclass=user). The most useful are
>> probably:
>> - "account disabled" (AD_VALUE_ACCOUNTDISABLE)
>> - "password never expires" (AD_VALUE_DONT_EXPIRE_PASSWORD)
>> - "password is expired" (AD_VALUE_PASSWORD_EXPIRED)
>>
>> This attribute is actually a field of bits, where each of the above
>> values is one bit. So, to modify one of these elements, you need to add
>> or subtract the bit value from the current value of userAccountControl,
>> thus R?my's example, slightly reworked:
>>
>> lsc.syncoptions.<taskname>.userAccountControl.default_value =
>> AD.set(dstBean.getAttributeById("userAccountControl"),
>> [AD.AD_VALUE_ACCOUNTDISABLE, AD_VALUE_PASSWORD_EXPIRED])
>>
>> On an existing account in AD (as a destination) this will disable the
>> account and mark the password as expired, stopping the user from logging
>> in or ever using his password again.
>>
>> For reading from AD as a source directory, it should be easy to add a
>> function to interpret an existing userAccountControl value. Something
>> like this, maybe:
>> isUserAccountControlValueSet(currentValue, AD.AD_VALUE_ACCOUNTDISABLE)
>> that returns a boolean. Then we could used this as a condition for
>> synchronization, or otherwise.
>
>
> Ok, I work a little with userAccountControl, so you confirm what I've
> learned. One important thing is you can only set this parameter inside a
> SSL connection. And setting SSL in AD is not evident...
I'm not sure about this. I remember changing it without SSL, but I don't
have an AD controller here to check. I will try at work this week and
let you know.
> Another question, can we push the password into AD? I've read somewhere
> that this operation has to be done after entry creation, and not inside
> entry creation, is it right?
I read that also, but it turns out you can do it all in one operation.
The following LDIF is accepted by an AD controller in a large and quite
secure company, when applied over an encrypted connection:
dn: CN=Jonathan Clarke,OU=Technical Users,DC=test,DC=lan
objectClass: user
cn: Jonathan Clarke
sAMAccountName: jclarke
userPrincipalName: jclarke at test.lan
userAccountControl: 66048
unicodePwd:: IgBMADEAbgBhAGcAbwByAEAAIgA=
displayName: Another Example (TEST LAN)
givenName: Jonathan
sn: CLARKE
mail: jonathan.clarke.ext at test.lan
The format to encode the password is base64("\"<password in
unicode>\""). Note the quotes are part of the base64 encoded value, and
the password MUST be in UTF-8. We should add a function to do this in
our AD library, now one exists! :)
Jonathan
