To Demonstrate That User Changes Flow to the Reciprocal Environment

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.

For an environment that is participating in bidirectional password synchronization, any existing user’s entry being tracked in both environments must be in one of the following states:

• Both Windows and the LDAP store contain current information.

  No work needs to be done on either system because the entries are current.

• Windows is current but the LDAP store is outdated or stale.

  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, properly configured Identity Synchronization for Windows software marks the corresponding entry in the LDAP store as outdated or stale.

  When a system with Directory Server and Identity Synchronization for Windows gets a bind to 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 might eventually hash the value as part of its password policy and clear 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 to the LDAP store.

• Windows is stale but the LDAP store is current.

  This state 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 for the first time.

    If multiple users logging in to your Windows systems without an effective password is not acceptable, you can set 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 logon. This policy facilitates the transformation of an end user’s password from an openly known value to a secret value.

  • When an end user changes his or her password on the LDAP store side and Identity Synchronization for Windows 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, then the entry will be synchronized.

• Both Windows and the LDAP store are stale.

  If both systems are stale, you cannot ascertain which system contains the authoritative information. You must decide where to place the true state of an entry into one of the three, previously mentioned states. For example, moving the entry from your LDAP store creates corresponds to the previous state.

This situation can lead to a very tedious process as you might have to examine every user entry.

If you created a user called George Washington on a Solaris system that operates as a PAM client, 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 as explained in the following procedure.

To Verify Entries on Windows

1. From the Windows Start menu, go to Control Panel -> Administrative Tools -> Active Directory User and Computers.

2. When the Active Directory User and Computers window is displayed, go the Active Directory Users pane (on the left) and click Users.

   

3. Right-click the George Washington entry, and choose Properties.

   When the George Washington Properties dialog box is displayed, look at the Account options section. It shows that the User Must Change Password at Next Logon check box is selected, which means that George Washington will be required to change his password the next time that he logs in.

   

4. Log in as George Washington.

   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.”

5. Click OK to close the Logon Message dialog box and to display the Change Password dialog box to provide a new password.

6. Type and confirm a new password, but do not provide a value for the Old Password field.

   This is first time the user has logged in (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.

7. 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, the George Washington entry has moved from where the Windows entry is stale and the LDAP store is current to where Windows is current and the LDAP store entry is stale.

   George Washington's entry will maintain this condition until the next time that it binds to the LDAP store. At that time, the entry will move to where the entry is current on both Windows and the LDAP store.