Sun Java System Directory Server Enterprise Edition 6.0 Installation Guide

How Identity Synchronization for Windows Detects Changes in Directory Sources

This section explains how user entry and password changes are detected by Sun Java System Directory Server (Directory Server), Windows Active Directory, and Windows NT Connectors.

The information is organized as follows:

How Directory Server Connectors Detect Changes

The Directory Server Connector examines the Directory Server retro changelog over LDAP to detect user entry and password change events. The Directory Server Plug-in helps the Connector to do the following:

For more information about retro changelog, see Replication and the Retro Change Log Plug-In in Sun Java System Directory Server Enterprise Edition 6.0 Reference in Sun Java System Directory Server Enterprise Edition 6.0 Reference

Capture clear-text passwords by encrypting and then making them available in the Retro-Changelog. Without the Plugin, only hashed passwords appear in the Retro-Changelog and hashed passwords cannot be synchronized.
Perform On-Demand Password Synchronization with Active Directory; removing the need to install any Identity Synchronization for Windows components in a Windows environment (See Using On-Demand Password Synchronization to Obtain Clear-Text Passwords

Figure 3–4 How Directory Server Connectors Detect Changes

Block diagram illustrating how Directory Server Connectors
detect changes.

How Active Directory Connectors Detect Changes

The Windows 2000/2003 Server Active Directory Connector detects user entry and password changes by examining the Active Directory USNChanged and PwdLastSet attribute values.

Unlike the Directory Server’s Retro Changelog, when you change attributes in an entry, Active Directory does not report which attributes changed. Instead, Active Directory identifies entry changes by incrementing the USNchanged attribute. To detect changes to individual attributes, Active Directory and Windows NT Connectors use an in-process database called the object cache. The object cache stores a hashed copy of each Active Directory entry, which allows the Connector to determine exactly which attributes were modified in the entry.

You are not required to install Active Directory Connectors in the Windows environment. They can run also on other platforms such as Solaris or Linux and detect or make changes remotely over LDAP.

Figure 3–5 How Active Directory Connectors Detect Changes

Block diagram illustrating how Active Directory Connectors
detect changes.

How Windows NT Connectors Detect Changes

The Windows NT Connector detects user entry and password changes by examining the Security log for audit events about user objects.

To synchronize with Windows NT SAM Registries (see Windows NT Connector and Subcomponents) you must install the Windows NT Connector in the Primary Domain Controller (PDC). In addition, the installer installs the two NT Connector subcomponents (the Change Detector and the Password Filter DLL) along with the Connector in the PDC of the NT Domain. A single NT Connector synchronizes users and passwords for a single NT Domain.

Figure 3–6 How Windows NT Connectors Detect Changes

Block diagram illustrating how Windows NT Connectors
detect changes.

Note –

If you have a Windows NT machine in your deployment, auditing must be enabled or Identity Synchronization for Windows cannot read log messages from that machine. To verify whether audit logging is enabled on your Windows NT machine, see Enabling Auditing on a Windows NT Machine

For a description of the Change Detector and the Password Filter DLL subcomponents, review Windows NT Connector Subcomponents

Propagating Password Updates

This section explains the following methods for obtaining clear-text passwords needed to propagate password changes between Windows systems and Directory Server systems:

Using the Password Filter DLL to Obtain Clear-Text Passwords

Windows NT Connectors must obtain clear-text passwords to propagate password updates to the Sun Java System Directory Server. However, you cannot extract clear-text passwords from a Windows directory. By the time passwords are stored in the directories, they have already been encrypted.

Windows NT provides a Password Filter DLL interface, which allows components to capture clear-text passwords before they are stored in a directory permanently.

Using On-Demand Password Synchronization to Obtain Clear-Text Passwords

While Active Directory supports the same password filter as Windows NT, you must install the password filter DLL on every domain controller instead of just the Primary Domain Controller (PDC). Because this can be a significant installation burden, Identity Synchronization for Windows uses a different approach, called on-demand password synchronization, to synchronize password changes from Active Directory to Directory Server.

On-demand password synchronization provides a method to obtain new password values on Directory Server when the user tries to log-in after their password changes on Windows 2000.

On-demand password synchronization also allows you to synchronize passwords on Active Directory without the need of a password filter DLL.

The on-demand password synchronization process occurs as follows:

User presses Ctrl-Alt-Del on a Windows workstation and changes his or her password. New passwords are stored in Active Directory.

The Active Directory Connector polls the system at scheduled intervals.

When the Connector detects the password change (based on changes made to the USNchanged (Update Sequence Number) and PwdLastSet attributes), the Connector publishes a message on Message Queue about the password change. The message is transferred on an SSL-encrypted channel.

Figure 3–7 On-Demand Password Synchronization-Part 1

The Directory Server Connector receives the password change message from Message Queue (over SSL).

The Directory Server Connector sets the user entry’s dspswvalidate attribute to true which invalidates the old password and alerts the Directory Server Plug-in of the password change.

When the user tries logging on, using an LDAP application (such as Portal Server) to authenticate against the Directory Server, the Sun Java System Directory Server Plug-in detects that the password value in the Directory Server entry is invalid.

The Directory Server Plug-in searches for the corresponding user in Active Directory. When the Plug-in finds the user, the Plug-in tries to bind to Active Directory using the password provided when the user tried logging into Directory Server.

Note –
On-demand password synchronization requires the application to use simple authentication against the Directory Server instead of using a more-complex authentication mechanism, such as SASL Digest-MD5.

If the bind against Active Directory succeeds, then the user provided his or her new Active Directory password and the Directory Server Plug-in set the password and removed the invalid password flag from the user entry on Directory Server.

Figure 3–8 On-Demand Password Synchronization-Part II

Note –
If the user authentication fails, the user entry password remains in Directory Server and the passwords on Directory Server and Active Directory will be out-of-sync until the user logs in with a valid password (one that authenticates to Active Directory).