Previous Contents Index Next
Sun ONE Identity Synchronization for Windows Installation and Configuration Guide

> ## Chapter 1
> Understanding the Product

> To help you prepare for your Sun ONE Identity Synchronization for Windows installation, you should be familiar with the concepts contained in the following sections:

> - System Components
> - Command Line Interfaces
> - System Components Distribution
> - Deployment Example: A Two-Machine Configuration

> Identity Synchronization for Windows provides bidirectional password synchronization between the Sun ONE Directory Server 5.2 and:

> - Windows 2000 Active Directory
> - Windows NT SAM Registry.

> Users accessing applications that use these directories for login authentication need only remember a single password, and when applying periodic password updates, the user is only required to make the password update once. In addition, product features include:

> - Synchronization of selected additional attributes in the user entry, whenever any selected attribute is modified in one directory environment the new values are immediately and automatically propagated to the other directory
> - User account creation synchronization between the supported directories; whenever a user is created in one directory environment the new values are immediately and automatically propagated to the other directory

> There is no requirement to modify the Windows directories, or to change the applications using the directories.

> When using the product between Sun ONE Directory Server and Active Directory there is no requirement to install any components in the Windows operating environment. When synchronizing between Sun ONE Directory Server and Windows NT, the product’s NT component must be run in the Windows NT environment.

> ##

> System Components

> Identity Synchronization for Windows is made out of a set of core components and any number of individual connectors and connector subcomponents that allow for the synchronization of password updates between Sun ONE and Windows directories (see Figure 1-1).

> Figure 1-1 System Components

> ### Core

> Core includes the following components: console, system manager, central logger, Sun ONE Message Queue, and the product’s configuration registry, which is stored in a Sun ONE Directory Server Configuration Directory.

> #### Product’s Configuration Registry

> The product’s configuration registry is stored in a Directory Server configuration directory. The console, system manager and the install3r all read and write the product’s configuration data from the configuration registry. This registry contains:

> - Configuration information for every directory, domain, connector and connector sub-component
> - Default log settings
> - Synchronization settings describing the direction of user creation and attribute modifications
> - Attributes to be synchronized and attribute mappings between the two directory environments
> - Synchronized user lists in each directory topology

> #### Console

> The console centralizes all configuration and administration of the product’s components, it allows the user to:

> - Configure directories or domains being synchronized
> - Select user entry attributes to be synchronized, in addition to passwords
> - Specify list of users within each directory or domain topology that require synchronization
> - Monitor system status
> - Dynamically and selectively stop and start password synchronization for different directories or domains

> Selected console actions can also be performed via the product’s command line interfaces

> #### System Manager

> - Leverages the product’s backend networked facilities for dynamically delivering configuration updates to connectors
> - Keeps status on each connector and connector subcomponents

> ### Central Logger

> Connectors might be installed so that they are widely distributed across remote geographical locations; therefore, it is of great administrative value to have all logging information be centralized allowing the Administrator to easily monitor synchronization activity, detect errors and evaluate the health of the entire system from a single network location.

> The central logger logs allow a system administrator 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: error and audit.

> - The error log includes entries about conditions qualified as severe errors and warnings. All error log entries are worthy of attention, and thus the administrator cannot prevent errors from being logged--if an error condition takes place, it will always be documented in the error log
> - The audit log contains information about the day-to-day activities of the system. These include important events such as a user’s password being synchronized between directories. The administrator can control the level of information that is logged, increasing or decreasing the detail of the log messages

> ### Connectors

> Directory-specific connectors are responsible for bi-directionally synchronizing password updates between directories/domains and includes

> - Directory Server connector. It supports a single naming context (for example suffix/database) in a Sun One Directory Server 5.2
> - Active Directory connector. It supports a single domain in a Windows 2000 Active Directory environment
> - NT connector. It supports a single domain in Windows NT environment

> ### Connector subcomponents

> The Directory Server and the Windows NT connectors each make use of a lightweight subcomponent to facilitate the propagation of password updates. Connector subcomponents are installed along with the directory being synchronized and communicate with the connector over an encrypted connection.

> The Active Directory connector does not require any subcomponents.

> #### Directory Server subcomponent: plugin

> A plugin is installed in the Directory Server being synchronized. The plugin,

> - Enhances the Directory Server connector change detection features
> - Provides bi-directional support for password synchronization support between Active Directory and Directory Server without requiring the installation of the Password Filter DLL in every Windows Domain Controller

> #### NT connector subcomponents: Change Detector & Password Filter DLL

> An installation supporting synchronization with NT SAM Registries requires two small processes to be installed in the Primary Domain Controller (PCD) along with the NT connector, they are:

> - The Change Detector. It detects user entry and password change events by monitoring the Security Log, and then passes the changes to the connector
> - The Password Filter DLL. It captures passwords in the clear at the NT Domain and passes these to the NT connector

> ##

> Command Line Interfaces

> There are a number of commands. The following are most notable towards the system configuration and towards the synchronization of passwords

> - idsync linkusers. This command enables the administrator to link existing users in two directories. It is run after all connectors have been installed and while the system is not synchronizing users. This interface accepts rules for matching users between the two directories (e.g. for a user entry to be linked in the two directories both the first names and last names must match in both directory entries).
> - idsync resync. During runtime, the product synchronizes user creations and modifications in real-time, but it does not bulk synchronize existing attributes that have not changed; this command line interface (after executing linkusers) can be used to synchronize existing attribute values between existing directory populations after linkusers has been run.
> - idsync prepds. This command line interface must be run for every configured Directory Server master being synchronized; this step is a pre-requisite for installing the Directory Server Connector.

> ##

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

> Once you understand the basic concepts described in this section and in the deployment scenario example, you should be able to extrapolate the information you need to create deployment strategies for more complex, sophisticated scenarios (such as mixed environments or multi-server environments).

> #### Core

> All core components are installed at once in any of the supported OS platforms; Administration Server must be installed in the same machine as core.

> #### Directory Server connector

> Directory Server connectors can be installed in any of the supported OS platforms; there is no requirement for installation of a Directory Server connector in the same machine where the Directory Server being synchronized is running. There must be one Directory Server connector installed per Directory Server’s naming context/(database/suffix.)

> #### Directory Server (subcomponent) plugin

> The Directory Server plugin is installed in some host where the Directory Server being synchronized resides on any of the supported OS Platforms.

> Note | A single Directory Server connector is installed for a single Directory Server naming context. However, Directory server plugins are installed multiple times for every master, hub, and read-only replica for that naming context (suffix-database.)

> #### Active Directory Connector

> Active Directory connectors can be installed in any of the supported OS platforms; there is no requirement for installation of an Active Directory connector in the Windows environment. There must be one Active Directory connector installed per Active Directory domain. There is no requirement to install any subcomponents for this connector type.

> Figure 1-2 Directory Server and Active Directory Component Distribution

> #### NT Connector & NT subcomponent

> Installations that support synchronization with NT SAM Registries (seeFigure 1-3) require the NT connector to be installed in the Primary Domain Controller (PDC); in addition, the two NT connector subcomponents, the Change Detector and the Password Filter DLL, must also be installed along with the connector in the PDC of the NT Domain. A single NT connector synchronizes passwords for a single NT Domain.

> Figure 1-3 Directory Server and NT Component Distribution

> ##

> Deployment Example: A Two-Machine Configuration

> This section describes a deployment scenario in which Identity Synchronization for Windows is used to synchronize creations and bidirectional password modifications between Sun and Windows directories.

> The deployment scenario consists of two systems:

> - A system running a Sun ONE Directory Server (host name: corp.example.com)
> - A system running Active Directory on a Windows 2000 server (host name: sales.example.com)

> Note | Though NT is not used in this scenario, it is important to note that 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.

> Figure 1-4 Synchronization Requirements

> There are two goals for this scenario:

> - The first goal is 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 “flows” 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 Sun ONE Directory Server, then the new password should automatically flow to cn=Joe Smith in the cn=users container on the Active Directory server and vice versa.

> - The second goal is to synchronize or propagate user creations from the Directory Server user 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 and then create an account for WThompson (cn=William Thompson in the cn=Users container) with the same set of attributes.

> Note | Identity Synchronization for Windows supports multiple synchronization sources of the same type (for example, you can have more than one Sun ONE Directory Server in a deployment or multiple Active Directory Domains). It is important to note that creation and modification synchronization settings are global for the entire set of directories, and cannot be specified for individual directory sources.

> Note | For example, if settings are set to synchronize user creations from Sun to Windows, then user creations propagate from all Sun Directory Servers to all Windows Active Directory domains and Windows NT domains configured in the installation.

> ### Physical Deployment

> Figure 1-5 illustrates how all the product’s components are physically deployed in a single Solaris box while the Active Directory domain resides in a separate Windows 2000 Active Directory domain controller where no components have been installed.

> Figure 1-5 Directory Server and Active Directory Scenario

> ### Component Distribution

> Host ds.example.com is a Directory Server box installed in a Solaris operating environment. This machine contains:

> Directory Server being synchronized, its naming context (Root Suffix) is dc=corp,dc=example,dc=com

> - Identity Synchronization for Windows core components
> - Identity Synchronization for Windows Directory Server connector
> - Identity Synchronization for Windows Directory Server (subcomponent) plugin
> - Identity Synchronization for Windows configuration registry (in a separate Directory Server than the one being synchronized, a Configuration Directory)

> Host ad.example.com is an Active Directory domain controller named sales.example.com that contains an Active Directory domain being synchronized, its domain name is sales.

> Previous Contents Index Next

> Copyright 2003 Sun Microsystems, Inc. All rights reserved.