Sun Java System Identity Synchronization for Windows 6.0 Installation and Configuration Guide

Chapter 1 Understanding the Product

Sun Java^TM System Identity Synchronization for Windows 6.0 provides bidirectional password and user attributes synchronization between Sun Java System Directory Server and the following:

Windows 2000 or Windows 2003 Server Active Directory
Windows NT SAM Registry

Identity Synchronization for Windows 6.0 supports Sun Directory Server 7.0, 6.3, 6.2, 6.1, 6.0, and 5.2 Patch 5.

Sun Java System Identity Synchronization for Windows handles synchronization events in these ways:

Securely. It does not send passwords “in the clear,” and it restricts system access to administrators only.
Robustly. It keeps directories synchronized, even when individual components are temporarily unavailable.
Efficiently. It uses synchronization methods that place very little load on your directory servers.

Note –

Before you install Sun Java System Identity Synchronization for Windows version 6.0, you must read the Technical Note. This Technical Note provides additional installation instructions that help you to install Identity Synchronization for Windows for Directory Server Enterprise Edition 7.0.

Sun Java System Identity Synchronization for Windows version 6.0 is not bundled with the Sun Directory Server Enterprise Edition 7.0 release. You can download the Identity Synchronization for Windows software from http://www.sun.com/software/products/directory_srvr_ee/get.jsp.

You should also familiarize yourself with the concepts described in this chapter, which includes the following topics:

Product Features

Sun Java System Identity Synchronization for Windows provides the following features and functionality:

Bidirectional password synchronization. Enables you to synchronize user passwords between the following directory sources:
- Sun Java System Directory Server and Windows Active Directory
- Sun Java System Directory Server and Windows NT
Synchronizing passwords allows users to access applications using these directory sources for login authentication, so users only have to remember a single password. In addition, when users have to apply periodic password updates, they only have to update their password in one location.
Bidirectional user attributes synchronization. Enables you to create, modify, and delete selected attributes in one directory environment and propagate the values automatically to the other directory environment.
Bidirectional user account creation synchronization. Enables you to create or delete a user account in one directory environment and automatically propagate the new account to the other directory environment.
Bidirectional group synchronization. Enables you to synchronize the creation or deletion of a group, and association or disassociation of users with that group between Directory Server and Active Directory sources.
Bidirectional object deletions, activations, and inactivations. Enable you to control the flow of object deletions, activations, and inactivations between Directory Server and Active Directory sources.
Bidirectional account lockout and unlockout synchronization. Enables you to synchronize account lockout and unlockout between Directory Server and Active Directory sources.
Synchronization with multiple domains. Enables you to synchronize with multiple Active Directory and Windows NT domains, and with multiple Active Directory forests.
Centralized system auditing. Enables you to monitor from a single-centralized location, installation and configuration status, the day-to-day system operations, and any error conditions related to your deployment.

You are not required to modify entries in Windows directories or to change the applications using the directories.

If you are using Identity Synchronization for Windows to synchronize between Directory Server and Active Directory, you do not need to install any components in the Windows operating system.

If you are synchronizing between Directory Server and Windows NT, you must install the product’s NT component in the Windows NT operating system.

Note –

The following features are not available for Windows NT:

Bidirectional group synchronization
Bidirectional object deletions, activations, and inactivations
Bidirectional account lockout and unlockout synchronization

System Components

The following figure shows that Identity Synchronization for Windows consists of a set of Core components and any number of individual connectors and connector subcomponents. These system components allow for the synchronization of password and user attribute updates between Sun Java System Directory Server (Directory Server) and Windows directories.

Figure 1–1 System Components

Block diagram showing major system components.

This section defines and describes these Identity Synchronization for Windows components:

Watchdog Process

The Watchdog is an Identity Synchronization for Windows Java technology-based process (Java process) that starts, restarts, and stops individual background Java processes. The Watchdog launches and monitors the central logger, system manager, and connectors. The Watchdog does not monitor subcomponents, Message Queue, or the Identity Synchronization for Windows Console.

The Watchdog is installed where you install the Core components and it can be started as a Solaris^TM software daemon, Red Hat Linux daemon, or a Windows service.

Core

When you install Identity Synchronization for Windows, you install the Core component first, then configure it to match your environment.

The Core component consists of the following components:

Configuration Directory

Identity Synchronization for Windows stores its configuration data in a Directory Server configuration directory. The program does not install a configuration directory.

The Console, system manager, command-line utilities, and the installer all read and write the product’s configuration data to and from the configuration directory, including the following:

Installation information about each component’s health
Configuration information for every directory, domain, connector, and Directory Server Plug-in
Connector status
Synchronization settings that describe the direction of user or group creations, deletions, and attribute modifications
Attributes to be synchronized and attribute mappings between Active Directory and Directory Server or Windows NT and Directory Server
Synchronization User Lists (SULs) in each directory topology
Log settings

Console

Identity Synchronization for Windows provides a Console that centralizes all of the product’s component configuration and administration tasks.

You can use the Console to do the following:

Configure directory sources to be synchronized
Define mappings for user entry attributes to be synchronized, in addition to passwords
Specify which users and attributes within a directory or domain topology will or will not be synchronized
Monitor system status
Start and stop synchronization

Command-Line Utilities

Identity Synchronization for Windows also provides command-line utilities that enable you to perform the following tasks directly from the command line:

Display certificate information based on your configuration and Secure Sockets Layer (SSL) settings
Change the Identity Synchronization for Windows configuration password
Configure the Directory Server Plug-in for a specified Directory Server source
Prepare a Sun Java System Directory Server source for use by Identity Synchronization for Windows
Display the steps that you must perform to complete the installation or configuration process, and view the status of installed connectors, the system manager, and Message Queue
Reset connector states in the configuration directory to uninstalled
Synchronize and link existing users in two directories, and pre-populate directories as part of the installation process
Enable or disable account lockout
Enable or disable group synchronization
Start and stop synchronization

For a detailed description of the product’s command-line utilities and how to use them, see Appendix A, Using the Identity Synchronization for Windows Command Line Utilities.

System Manager

The Identity Synchronization for Windows system manager is a separate Java process that does the following:

Leverages the product’s back-end networked facilities to dynamically deliver configuration updates to connectors
Keeps the status of each connector and all connector subcomponents
Coordinates idsync resync operations that are used to initially synchronize two directories

Central Logger

Connectors may be installed so that they are widely distributed across remote geographical locations. Therefore, having all logging information centralized is of great administrative value. This centralization allows the administrator to monitor synchronization activity, detect errors, and evaluate the health of the entire system from a single location.

Administrators can use the central logger logs to perform these tasks:

Verify that the system is running correctly
Detect and resolve individual component and system-wide problems
Audit individual and system-wide synchronization activity
Track a user’s password synchronization between directory sources

The two types of logs are as follows:

Audit log. Provides information about the system’s day-to-day activities, which includes events such as a user’s password being synchronized between directories. You can control the level of information that is logged in the audit log by increasing or decreasing the detail provided in the log messages.
Error log. Provides information about conditions that are qualified as severe errors and warnings. All error log entries are worthy of attention, so you cannot prevent errors from being logged. If an error condition takes place, it will always be documented in the error log.

Note –

Identity Synchronization for Windows also writes all error log messages to the audit log to facilitate correlation with other events.

Connectors

A connector is a Java process that manages the synchronization process in a single data source type. A connector detects user changes in the data source and publishes these changes to remote connectors over Message Queue.

Identity Synchronization for Windows provides the following directory-specific connectors. These connectors bidirectionally synchronize user attributes and password updates between directories and domains.

Directory Server Connector. Supports a single root suffix (for example, suffix/database) in a Directory Server.
Active Directory Connector. Supports a single instance in a Windows 2000 or Windows 2003 Server Active Directory source. You can use multiple connectors for additional domains.
Windows NT Connector. Supports a single domain on Windows NT.

Note –

The Watchdog is installed where you install a connector, and it starts, restarts, and stops the connectors. For more information, see Watchdog Process.

Connector Subcomponents

A subcomponent is a lightweight process or library that runs separately from the connector. Connectors use subcomponents to access native resources that cannot be accessed remotely, such as capturing passwords inside Directory Server or Windows NT.

The following connector subcomponents are configured or installed with the directory being synchronized and communicate with the corresponding connector over an encrypted connection.

Note –

Active Directory Connectors do not require subcomponents.

Directory Server Plug-In

The Directory Server Plug-in is a subcomponent of the Directory Server Connector. You configure the Directory Server Plug-in on each Directory Server being synchronized.

This Plug-in does the following:

Enhances the Directory Server Connector’s change-detection features by storing encrypted passwords in the retro changelog
Provides bidirectional support for user attribute and password synchronization between Active Directory and Directory Server (see Using On-Demand Password Synchronization to Obtain Clear-Text Passwords)

Note –

Identity Synchronization for Windows used to support only two-way multimaster replication (MMR). Now, the Directory Server Plug-in is also functional in N-way MMR environments.

Windows NT Connector Subcomponents

If your installation requires synchronization with Windows NT SAM Registries, the Identity Synchronization for Windows installation program installs the following in the Primary Domain Controller (PDC) along with the Windows NT Connector:

Change Detector. Detects user entry and password change events by monitoring the Security Log, then passes the changes to the Connector
Password Filter DLL. Captures password changes made on the Windows NT Domain Controller and passes these securely to the NT Connector.

Message Queue

Identity Synchronization for Windows uses Sun Java SystemMessage Queue (Message Queue), a persistent message queue mechanism with a publish and subscribe model, to propagate attribute and password changes between directory sources. Message Queue also distributes administrative and configuration information to the connectors managing synchronization for those directory sources.

Message Queue is an enterprise messaging system that implements the Java Message Service open standard. This specification describes a set of programming interfaces that provide a common way for Java applications to create, send, receive, and read messages in a distributed environment.

Message Queue consists of message publishers and subscribers that exchange messages using a common message service. This service is composed of one or more dedicated message brokers that control access to the message queue, maintain information about active publishers and subscribers, and ensure that messages are delivered.

Message Queue does the following:

Establishes a system of trust between connectors
Simplifies security access controls for all components
Facilitates end-to-end encryption of passwords
Ensures that all password update messages are delivered
Reduces connector-to-connector communication complexity and security risks
Enables a central authority to distribute configuration information
Allows for the aggregation of all connector logs in a central location

System Components Distribution

Before you can develop an effective deployment, you must understand how Identity Synchronization for Windows components are organized and how the product operates. This section discuss the following:

Core
Directory Server Connector and Plug-in
Active Directory Connector
Windows NT Connector and Subcomponents

When you understand the basic concepts described in this section and in Deployment Example: A Two-Machine Configuration, you should be able to extrapolate the information to create deployment strategies for more complex, sophisticated scenarios. Such scenarios might be mixed Active Directory and Windows NT environments or multiserver environments.

Core

Note –

Install Sun Java System Message Queue 3.6 Enterprise Edition on the same machine where you are planning to instal Core.

Install all Core components only once in any of the supported operating system’s directory servers. Identity Synchronization for Windows installs Administration Server on your machine if it is not already installed.

Directory Server Connector and Plug-in

You can install Directory Server Connectors on any of the supported operating systems. You are not required to install a Directory Server Connector on the same machine where the Directory Server that is being synchronized is running. However, one Directory Server Connector must be installed for each configured Directory Server source.

You must configure the Directory Server Plug-in on every host where a Directory Server that is to be synchronized resides.

Note –

A single Directory Server Connector is installed for each Directory Server source. However, Directory Server Plug-ins should be configured for each master, hub, and consumer replica to be synchronized.

Active Directory Connector

You can install Active Directory Connectors on any of the supported operating systems. You are not required to install an Active Directory Connector on a machine running Windows. However, one Active Directory Connector must be installed for each Active Directory domain. See the following figure for a sample distribution of components.

Figure 1–2 Directory Server and Active Directory Component Distribution

Block diagram showing Active Directory components.

Windows NT Connector and Subcomponents

To synchronize with Windows NT SAM Registries, you must install the Windows NT Connector in the Primary Domain Controller (PDC). The installation program also 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. See the following figure for a sample distribution of components.

Figure 1–3 Directory Server and Windows NT Component Distribution

Block diagram showing Windows NT Connectors and subcomponents.

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 do the following:

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

Capture clear-text passwords by encrypting them and then making them available in the retro changelog. Without the Plug-in, only hashed passwords appear in the retro changelog, and hashed passwords cannot be synchronized.
Perform on-demand password synchronization with Active Directory. No Identity Synchronization for Windows components need to be installed in a Windows topology (See Using On-Demand Password Synchronization to Obtain Clear-Text Passwords.

Figure 1–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, an Active Directory Connector uses 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 on Windows. These connectors can also run on other operating systems such as Solaris or Red Hat Linux, and detect or make changes remotely over LDAP.

Figure 1–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. Auditing must be enabled or Identity Synchronization for Windows cannot read log messages from Windows NT machine. To verify that audit logging is enabled, see Enabling Auditing on a Windows NT Machine.

Figure 1–6 How Windows NT Connectors Detect Changes

Block diagram illustrating how Windows NT Connectors
detect changes.

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

Propagating Password Updates

This section explains two ways to obtain clear-text passwords. Clear-text passwords are needed to propagate password changes between Windows and Directory Server sources.

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, the passwords have already been encrypted.

Windows NT provides a Password Filter DLL interface that 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 (not the Primary Domain Controller used by Window NT). 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 users try to login after their password change on Windows 2000/2003.

On-demand password synchronization also allows you to synchronize passwords on Active Directory without using the Password Filter DLL.

The on-demand password synchronization process is as follows:

The user presses Ctrl-Alt-Del on a machine running Windows and changes his or her password. The 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.
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 to log in, 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 in to Directory Server.

Note –
On-demand password synchronization requires that the application use simple authentication against Directory Server instead of using a more complex authentication mechanism, such as SASL Digest-MD5.
If the bind against Active Directory succeeds, the Directory Server Plug-in sets the password and removes the invalid password flag from the user entry on Directory Server allowing the user to log in.

Note –
If user authentication fails, the user entry password remains in Directory Server and the passwords on Directory Server and Active Directory are not the same until the user logs in with a valid password, one that authenticates to Active Directory.

Reliable Synchronization

Identity Synchronization for Windows takes many precautions to ensure that you do not lose user change events, even when components become temporarily unavailable. Identity Synchronization for Windows’ reliability is similar to the TCP network protocol. TCP guarantees that even over a loosely and intermittently connected network, it will eventually deliver all data in order. Data sent during a temporary network outage is queued while the network is down and re-delivered after connectivity is restored. Identity Synchronization for Windows will eventually detect and apply user change events if one of the following components becomes temporarily unavailable:

Connector
Directory Server
Message Queue
Active Directory domain controller
Windows NT Primary Domain Controller
System manager
Configuration directory

If one of these components is not available, Identity Synchronization for Windows will delay synchronization until the affected component is available and contains all changes, even to passwords. This version of Identity Synchronization for Windows does not support Sun^TM Cluster software or other true high-availability solutions. Because users do not interact with Identity Synchronization for Windows directly, high availability is not usually required. If you experience a catastrophic failure, you can reinstall Identity Synchronization for Windows components and use the idsync resync command to resynchronize all directory sources.

In most situations, when a component is unavailable, the program queues synchronization events and applies them only when the component becomes available. There are two exceptions to this process:

In a multimaster replication (MMR) Directory Server environment, external changes to Windows users can be synchronized to the preferred or secondary Directory Servers.

If the preferred Directory Server is unavailable, the Directory Server Connector will apply changes to one of the available secondary servers from the MMR topology.
While the Active Directory Connector can communicate with a single Active Directory domain controller only, the Directory Server Plug-in can fail between all Active Directory domain controllers while performing on-demand password synchronization. This point is where failover is most important. If the Directory Server Plug-in cannot contact an Active Directory domain controller to verify a user's new password, the user cannot log in to Directory Server.

Deployment Example: A Two-Machine Configuration

This section describes a deployment scenario in which Identity Synchronization for Windows is used to synchronize user object creation and bidirectional password modification operations between Directory Server and Active Directory sources.

The deployment scenario consists of two machines:

A machine running a Sun Java System Directory Server (host name: corp.example.com)
A machine running Active Directory on a Windows 2000 Server (host name: sales.example.com)

Note –

Even though Windows NT is not used in this scenario, Identity Synchronization for Windows also supports synchronization with NT domains.

The following figure illustrates the synchronization requirements (node structures with associated attribute values) used for this deployment scenario.

Synchronization requirements showing node structures
and attribute values.

The two goals for this scenario are as follows:

To synchronize user passwords bidirectionally between the user subtrees (ou=people in Directory Server and cn=users in Active Directory), which means that whenever a user password changes in either directory, the password change is synchronized to the associated user in the other directory.

For example, if you change the password for uid=Jsmith in the ou=people container in the Directory Server, the new password should automatically be synchronized to cn=James Smith in the cn=users container in Active Directory.
To synchronize user object creation operations from the Directory Server people subtree to the Active Directory user subtree only.

For example, if you create a new user uid=WThompson in the ou=People container with a specified set of attributes, Identity Synchronization for Windows will create a new account cn=William Thompson in the cn=Users container with the same set of attributes in Active Directory.

Note –

Identity Synchronization for Windows supports multiple synchronization sources of the same type. For example, you can have more than one Directory Server in a deployment or multiple Active Directory domains.

Creation, modification, and deletion synchronization settings are global for the entire set of directories, and cannot be specified for individual directory sources. If you synchronize user object creations from Directory Server to Active Directory, user object creations will propagate from all Directory Servers to all Active Directory domains and Windows NT domains configured in the installation.

Physical Deployment

The following figure illustrates how all the product’s components are physically deployed on a single Solaris system, while the Active Directory domain resides in a separate Active Directory domain controller where no components have been installed.

Figure 1–7 Directory Server and Active Directory Scenario

Directory Server and Active Directory physical deployment.

Component Distribution

corp.example.com is a machine where Directory Server is installed on a Solaris operating system. The root suffix for the Directory Server instance being synchronized is dc=corp,dc=example,dc=com.

This topology contains the following:

Identity Synchronization for Windows Core components
Identity Synchronization for Windows Directory Server Connector
Identity Synchronization for Windows Directory Server Plug-in
Identity Synchronization for Windows configuration directory (located in a different Directory Server instance than the one being synchronized)

sales.example.com is the Active Directory domain being synchronized.