Identity Synchronization for Windows provides bidirectional password and user attributes synchronization between the Sun Java System Directory Server 6.0 and the following:
Identity Synchronization for Windows handles synchronization events:
Securely: Identity Synchronization for Windows never sends passwords “in the clear,” and restricts system access to administrators only.
Robustly: Identity Synchronization for Windows keeps directories synchronized— even when individual components are temporarily unavailable.
Efficiently: Identity Synchronization for Windows synchronization methods 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:
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 they 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 environment.
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 create or delete a group, and associate or disassociate users with that group in a directory environment. The changes you make in one directory environment automatically propagate to the other directory environment.
Bidirectional object deletions, activations, and inactivations: Enables you to control the flow of object deletions and object activations and inactivations between Directory Server and Active Directory sources.
Bidirectional account lockout and unlockout synchronization: Enables you to synchronize the account lockout and unlockout between the 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 installation and configuration status, the day-to-day system operations, and any error conditions related to your deployment from a single, centralized location.
You will not be 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 need not install any components in the Windows operating environment.
If you are synchronizing between Directory Server and Windows NT, you must install the product’s NT component in the Windows NT environment.
The following features are not available for Windows NT:
Bidirectional group synchronization
Bidirectional object deletions, activations, and inactivations
Bidirectional account lockout and unlockout synchronization
Identity Synchronization for Windows consists of a set of Core components and any number of individual connectors and connector subcomponents that allow for the synchronization of password and user attribute updates between Sun Java System Directory Server and Windows directories.
This section defines and describes each of the Identity Synchronization for Windows components and is organized as follows:
The Watchdog is an Identity Synchronization for Windows Java process that is responsible for starting, restarting, and stopping individual background Java processes. The Watchdog launches and monitors the central logger, system manager, and connectors (but does not monitor subcomponents, Message Queue, or the Identity Synchronization for Windows Console).
The Watchdog is installed anywhere you install Core and it can be started as a Solaris daemon, Linux daemon, or a Windows service. (For information about starting and stopping services, see Starting and Stopping Services.)
When you install Identity Synchronization for Windows, you install the Core component first, and then you configure it to match your environment.
The core component consists of the following components, which are each separate Java processes. A description each component, begins on the referenced page:
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 utility, and the installer all read and write the product’s configuration data to and from the configuration directory, including:
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's creations, deletions, and attribute modifications
Attributes to be synchronized and attribute mappings between the two directory environments Active Directory and Directory Server or Windows NT and Directory Server
Synchronization User Lists in each directory topology
Log settings
The 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 be (or will not be) synchronized
Monitor system status
Start and stop synchronization
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 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 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
The Identity Synchronization for Windows system manager is a separate Java process that:
Leverages the product’s back-end networked facilities to dynamically deliver configuration updates to connectors
Keeps 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, it is of great administrative value to have all logging information centralized, which 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:
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 environments
There are two different types of logs:
The audit log provides information about the system’s day-to-day activities, which includes important 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.
Identity Synchronization for Windows also writes all of the error log messages to the audit log to facilitate easy correlation with other events.
The error log provides information about conditions 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.
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, which are responsible for bidirectionally synchronizing 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 environment. You may use multiple connectors for additional domains
Windows NT Connector: Supports a single domain in a Windows NT environment
The Watchdog is installed anywhere you install a connector, and it is responsible for starting, restarting, and stopping 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 communicated with the corresponding connector over an encrypted connection.
Active Directory Connectors do not require subcomponents.
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:
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
The Directory Server Plug-in is functional in a N-way, multimaster replication (MMR) environments. (Previously, Identity Synchronization for Windows supported two-way MMR only.)
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, and then passes the changes to the Connector
Password Filter: Captures password changes made on the NT Domain Controller and passes these securely to the NT Connector
Identity Synchronization for Windows uses Message Queue (a persistent message queue mechanism with a publish/subscribe model) to propagate attribute and password changes between directory sources and to distribute 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 (JMS) open standard. The JMS 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 message service is composed of one or more dedicated message brokers, which are responsible for controlling access to the message queue, maintaining information about active publishers and subscribers, and ensuring that messages are delivered.
Message Queue is the best approach because it:
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
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 is organized as follows:
Windows NT Connector and Subcomponents
When you understand the basic concepts described in this section and in the Deployment Scenario example (on Deployment Example: A Two-Machine Configuration), you should be able to extrapolate the information to create deployment strategies for more complex, sophisticated scenarios (such as mixed Active Directory and Windows NT environments or multi-server environments).
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. Install Message Queue 3.6 Enterprise Edition on the same machine where you are planning to instal Core.
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 being synchronized is running. However, there must be one Directory Server Connector installed for each configured Directory Server source.
You must configure the Directory Server Plug-in on every host where a Directory Server to be synchronized resides.
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 in the Windows environment; however, there must be one Active Directory Connector installed per Active Directory domain.
To synchronize with Windows NT SAM Registries you must install the Windows NT Connector in the Primary Domain Controller (PDC). In addition, the installation program 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.
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:
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
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.
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.
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
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
Using On-Demand Password Synchronization 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.
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.
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.
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.
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.
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).
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 lossy 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 once 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 without losing any changes (even to passwords). This version of Identity Synchronization for Windows does not support Sun Cluster or other true, high-availability solutions. Because Identity Synchronization for Windows is a behind-the-scenes application that users do not interact with directly, high availability is not usually required. If you ever experience a catastrophic failure, you can re-install Identity Synchronization for Windows components and use the idsync resync command to re-synchronize 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 multi-master replication (MMR) Directory Server environment, external changes to Windows users can be synchronized to the preferred or secondary Directory Server(s).
If the preferred Directory Server is unavailable, then 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 into 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 Sun and Windows directories.
The deployment scenario consists of two systems:
A system running a Sun Java System Directory Server (host name: corp.example.com)
A system running Active Directory on a Windows 2000 server (host name: sales.example.com )
Though NT is not used in this scenario, it is important to note that Identity Synchronization for Windows also supports synchronization with NT domains.
This example illustrates the synchronization requirements (node structures with associated attribute values) used for this deployment scenario.
There are two goals for this scenario:
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 on the Directory Server, then the new password should automatically be synchronized to cn=Joe Smith in the cn=users container on the Active Directory server.
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, then Identity Synchronization for Windows will create a new account for WThompson (cn=William Thompson in the cn=Users container) with the same set of attributes on 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 Windows directories, then user object creations will propagate from all Directory Servers to all Active Directory domains and Windows NT domains configured in the installation.
This section illustrates how all the product’s components are physically deployed on a single Solaris box, while the Active Directory domain resides in a separate Active Directory domain controller where no components have been installed.
Host corp.example.com is a Directory Server installed in a Solaris operating system. The root suffix for the Directory Server being synchronized is dc=corp,dc=example,dc=com.
This machine contains:
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)
Host sales.example.com is the Active Directory domain being synchronized.