Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide

Step 6: Demonstrating that User Changes are Flowing 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:

Case 1

Case 1 is trivial — there is no work to do on either system because the entries are current.

Case 2

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

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

Case 4

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.

Note –

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.

ProcedureVerifying the 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 right) and select Users.

    Verifying entities
  3. 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.

    Displaying properties for the selected entity
  4. 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.”

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

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

  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, 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).