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.