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 poicy 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 Identy Life Cycle Manger 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 provisining 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 an export into AD will create the account, but disable it.

RESOLUTION

There were two possible resolutions noted

1. Delete the created but disabled objects and re-export them with the default domain policy with the "strong" password creation disabled
2. Right-click and set a "strong" password for the failed accounts then enable each of them

 

See Also

How Do I Provision Users to Active Directory Domain Services
How Do I Synchronize Users from ACtive Directory Domain Services(ADDS) to Forefront Identity Manager(FIM)