Both Windows and the LDAP store (if so configured) use a one-way hash when storing passwords. This configuration prevents true replication of password data between the two systems, but does not prevent the password synchronization.
Case 1 (Case 1): Both Windows and the LDAP store contain current information
Case 2 (Case 2): Windows is current but the LDAP store is outdated or stale
Case 3 (Case 3): Windows is stale but the LDAP store is current
Case 4 (Case 4): Both Windows and the LDAP store are stale
Case 1 is trivial — there is no work to do on either system because the entries are current.
In Case 2, the LDAP store is in a state of waiting. Specifically, the system is waiting for an opportunity to capture the current, correct password for the LDAP store. In this case, a properly configured Identity Synchronization for Windows system marks the corresponding entry in the LDAP store as outdated or stale.
When an Identity Synchronization for Windows - enhanced Directory Server system gets a bind against a stale user, Identity Synchronization for Windows replays the given bind credentials to the configured Windows Active Directory to see if the user-supplied password is acceptable. If Active Directory authenticates the password, Identity Synchronization for Windows modifies the LDAP store so that it now possesses the password. Directory Server may eventually hash the value as part of its password policy and clears the stale status.
This process is known as on-demand synchronization, which results in both systems becoming synchronized with regard to the given entry after a successful bind occurs against the LDAP store.
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.
This case is a contradiction. If both systems are stale, then how can you ascertain which system contains the authoritative information? Human intervention will be required in this case, and you must decide where to place the true state of an entry into one of the three, previously mentioned cases.
This situation can lead you into a very tedious process as you may be required to examine every user entry
For example, moving the entry from your LDAP store creates Case 3. If you created an new user called George Washington on a Solaris PAM machine, and then use the idsync resync command to push the entry to Windows, you can verify that Identity Synchronization for Windows has also created the entry on Windows in the following section.
From the Windows Start menu, go to Control Panel -> Administrative Tools -> Active Directory User and Computers.
When the Active Directory User and Computers window is displayed, go the Active Directory Users pane (on the right) and select Users.
Right-click the George Washington entry and select Properties from the pop-up menu.
When the George Washington Properties dialog box is displayed, check the Account options section and you can see that the User must change password at next logon check box is enabled, which means George Washington will be required to change his password the next time he logs on.
If you log in as George Washington, you can see that Windows is correctly tracking the entry because the log-in attempt displays the Logon Message dialog box stating, “Your password has expired and must be changed.”
Click OK to close the Logon Message dialog box and to display the Change Password dialog box to provide a new password.
Enter and confirm a new password, but do not provide a value for the Old Password field.
This is first time the user has logged on (since being created over protocol), so supplying an old password value will cause an error message and Windows will ask you to enter the new password again.
Click OK to save the new password and close the Change Password dialog box.
If Windows accepts the new password, a message is displayed stating that the new password has been accepted.
At this point, George Washington's entry has moved from Case 3 (where the Windows entry is stale and the LDAP store is current) to Case 2 (where Windows is current and the LDAP store entry is stale).
George Washington's entry will maintain this condition until the next time he binds to the LDAP store. At that time, the entry will move to the Case 1 (where the entry is current on both Windows and the LDAP store).