Sun JavaTM System Identity Synchronization for Windows 6.0 provides bidirectional password and user attributes synchronization between Sun Java System Directory Server and the following:
Identity Synchronization for Windows 6.0 supports Sun Java System Directory Server 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.
Before you install (or migrate to) Sun Java System Identity Synchronization for Windows version 6.0, you should become familiar with the concepts described in this chapter, which consists of the following sections:
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.
The following features are not available for Windows NT:
Bidirectional group synchronization
Bidirectional object deletions, activations, and inactivations
Bidirectional account lockout and unlockout synchronization
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.
This section defines and describes these Identity Synchronization for Windows components:
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.
When you install Identity Synchronization for Windows, you install the Core component first, then configure it to match your environment.
Installation information about each component’s health
Configuration information for every directory, domain, connector, and Directory Server Plug-in
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
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
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.
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
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.
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
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.
Identity Synchronization for Windows also writes all error log messages to the audit log to facilitate correlation with other events.
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.
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.
The Watchdog is installed where you install a connector, and it starts, restarts, and stops the connectors. For more information, see Watchdog Process.
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.
Active Directory Connectors do not require subcomponents.
This Plug-in does the following:
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)
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.
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:
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
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.
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.
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.
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.
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.
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.
The information is organized as follows:
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 Java System Directory Server Enterprise Edition 6.2 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.
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.
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.
For a description of the Change Detector and the Password Filter DLL subcomponents, see Windows NT Connector Subcomponents.
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.
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.
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.
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.
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:
Active Directory domain controller
Windows NT Primary Domain Controller
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 SunTM 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:
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.
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.
Even though Windows NT is not used in this scenario, Identity Synchronization for Windows also supports synchronization with NT domains.
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.
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.
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.
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.
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)