10.9 The Active Directory Account Is Disabled After A User Add On ...

10.9 The Active Directory Account Is Disabled after a User Add on the Subscriber Channel

The default configuration maps the Identity Vault Logon Disabled attribute to the dirxml-uACAccountDisable bit of the userAccountControl attribute in Active Directory. A Subscriber Add operation might set Logon Disabled to False (account enabled), but the Publisher loopback of the Add operation reports that Logon Disabled is True (account disabled).

Additionally, inspecting the object in Active Directory might show that the account is disabled. This happens in part because of the way that the driver creates objects in Active Directory and in part because of a mismatch of policies between the driver and Active Directory itself.

If the account remains disabled in Active Directory after the provisioning cycle completes, you might have a mismatch between policies configured for the driver and policies enforced by Active Directory.

For example, consider a Password Required policy. If a user Add operation contains an invalid password (or no password at all), the account created in Active Directory should be disabled. But Active Directory might set the dirxml-uACPasswordNotRequired bit in userAccountControl without the driver’s knowledge.

This causes the logon enable action of the Add operation to fail if the Add operation does not include a policy for dirxml-uACPasswordNotRequired. Therefore, the account stays disabled.

Later (perhaps almost immediately because of a Merge operation), the driver might attempt to enable the account again by setting Logon Disabled to False. If you want to override the Active Directory policy and ensure that accounts always require a password, you should set dirxml-uACPasswordNotRequired to False whenever Logon Disabled changes on the Subscriber channel.