The purpose of this document is to explain a cause and effect of exporting user objects in a new domain utilizing FIM when the default group policy is configured to use a "strong" password and the provisioning code is not.
A customer reported that their domain failed in their test environment. They re-configured Identity Life Cycle Manager 2007 and were provisioning users from an externally populated authoritative connected data source. Upon importing the new objects from
the connected data source into active directory, a subset of the objects failed while trying to update the password policy.
After investigation into the issue it was determined that the accounts were getting provisoned into Active Directory but the accounts themselves were disabled.
The provisioning code created the accounts in Active Directory, but the password populated for the accounts upon creation in AD was not a strong password, (i.e. 098765.)
The root cause of the issue can be found in the methodology used to export the accounts into Active Directory.
During the provisioning process, the accounts were created but disabled due to the password not being a "strong" one in the provisioning code. When manually creating a user object within Active Directory Users and Computers, if the "strong" password policy
is enabled, you cannot create an account that does not have a "strong" password. With ILM 2007/FIM 2010 an export into AD will create the account, but disable it.