PURPOSE
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.
OVERVIEW
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.
CAUSE
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.
RESOLUTION
There were two possible resolutions noted- Delete the created but disabled objects and re-export them with the default domain policy with the "strong" password creation disabled
- Delete the created but disabled objects and reprovision the accounts with a strong password (change the provisioning logic to have a strong password)
- Right-click and set a "strong" password for the failed accounts then enable each of them
Caution |
|---|
| Deleting accounts from AD, removes their security context. A newly created account has different security context. When you delete an account with permissions already set, you need to reset the permissions for the new account. |