Case 3

Case 3 can occur under normal circumstances, but most frequently occurs due to one of the following situations:

• When the LDAP store possesses all the entries and Windows is waiting to be populated by Directory Server entries.

  This situation requires the most attention to get the system into a synchronized state because existing entries in the LDAP store presumably have one-way, hashed passwords. When Identity Synchronization for Windows tries to migrate data to Windows, there are no usable values to push when propagating the user’s password. In this case, Windows will request a password when a user logs in first time.

  If multiple users' sign-on to your Windows environment without an effective password is not acceptable, you can address this issue by setting a password programmatically for each entry in question. After Identity Synchronization for Windows reports that the system is synchronizing, you can use LDAP operations to specify the generated passwords on the LDAP store side or the Windows side of your environment.

  To complete this process, you must specify a must-change password policy after the user’s next log on. This policy facilitates the transformation of an end user’s password from an openly known value to a secretly known value.

• When an end user changes their password on the LDAP store side and the Identity Synchronization for Windows system is propagating the change through the system (either actively or by scheduling the work).

  In this situation, the information on Windows remains stale for just a short time. The Identity Synchronization for Windows components have captured all of the information needed to bring the Windows system into a synchronized state. Identity Synchronization for Windows takes the time only to process the information and then the entry will be synchronized.