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

Part I Installing Identity Synchronization for Windows

Sun Java System Identity Synchronization for Windows allows passwords and other specified user attributes to flow between Sun Java System Directory Server and other systems.

This part of the guide explains how to install and configure Identity Synchronization for Windows for use in a production environment.

For the latest information about new features and about enhancements in this release of Identity Synchronization for Windows, see the Sun Directory Server Enterprise Edition 7.0 Release Notes.


Note –

User interfaces that are depicted in this document are subject to change in future versions of the product.


This part includes the following chapters:

Chapter 1 Understanding the Product

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


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:


Note –

The following features are not available for Windows NT:


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 SolarisTM 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:

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:

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:

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:

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:

The two types of logs are as follows:


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.


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:


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:

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:

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


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.

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:

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

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

    Block diagram illustrating how On-Demand Password Synchronization
works.
  3. The Directory Server Connector receives the password change message from Message Queue (over SSL).

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

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

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


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

    Diagram showing how user entry and password changes are
updated on Active Directory and Directory Server.
    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:

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:

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:


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:


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:

Chapter 2 Preparing for Installation

Before installing Identity Synchronization for Windows 6.0 or before migrating from Sun Java System Identity Synchronization for Windows 1 2004Q3 SP1 to version 6.0, familiarize yourself with the installation and configuration process.

For information about the Identity Synchronization for Windows installation requirements, see Chapter 6, Identity Synchronization for Windows Bugs Fixed and Known Problems, in Sun Directory Server Enterprise Edition 7.0 Release Notes.

Identity Synchronization for Windows can also be installed in French, German, Spanish, Japanese, Korean, Simplified Chinese, and Traditional Chinese languages. All the languages are bundled in the same distribution.

For multilingual support for Identity Synchronization for Windows, use the UTF-8 encoding.

This chapter covers the following topics:

Installation Overview

This section illustrates a single-host installation procedure for Identity Synchronization for Windows.

Figure 2–1 Single-host installation procedure

single-host installation procedure

Some components must be installed in a particular order, so be sure to read all installation instructions carefully.

Identity Synchronization for Windows provides a “To Do” list, which is displayed throughout the installation and configuration process. This information panel lists all of the steps that you must follow to successfully install and configure the product.

Figure 2–2 To Do List for Identity Synchronization for Windows Installation and Configuration

This panel lists the remaining installation/configuration
steps you must perform.

As you go through the installation and configuration process, all completed steps in the list are grayed-out as shown in Figure 6–2.

The rest of this section provides an overview of the installation and configuration process.

Installing Core

When you install Core, you will be installing the following components:

Configuring the Product

After installing Core, use Console to initially configure the directory sources to be synchronized and other characteristics of the deployment, all from a centralized location.

Instructions for configuring directory resources are provided in Chapter 4, Configuring Core Resources.

Preparing the Directory Server

Before you can install Directory Server Connectors, you must prepare a Sun Java System Directory Server source for every preferred and secondary Directory Server that is being synchronized.

You can perform this task from the Console, or from the command line by using the idsync prepds subcommand.

Instructions for preparing Directory Server are provided in Preparing Sun Directory Source.

Installing Connectors and Configuring Directory Server Plug-In

You can install any number of connectors depending on the number of configured directories in your topology. Both the Console and the installation program use the directory label to associate a connector with the directory that is synchronized. The following table describes the label naming conventions.

Table 2–1 Label Naming Conventions

Connector Type 

Directory Source Label 

Subcomponent 

Directory Server Connector 

root suffix or suffix/database

Directory Server Plug-in 

Configure one Plug-in in every Directory Server (master or consumer) for the root suffix being synchronized. 

AD Connector 

Domain name 

None 

NT Connector 

Domain name 

(Automatically installed with the Windows NT Connector) Change Detector and Password Filter DLL subcomponents are installed together in the same installation.

You must install the Windows NT Connector using the graphical user interface (GUI) installer. 

Table 2–2 Label Naming Examples

Connector Name 

Directory Source 

CNN100

SunDS1 on ou=isw_data1

CNN101

AD1

CNN102

SunDS1 on ou-isw_data2

CNN103

SunDS2

Instructions for installing and configuring Connectors are provided in Chapter 3, Installing Core

Synchronizing Existing Users

After installing the connectors, plug-ins, and subcomponents, you must run the idsync resync command-line utility to bootstrap deployments with existing users. This command uses administrator-specified matching rules to do the following:

Instructions for synchronizing existing users in your deployment are provided in Chapter 6, Synchronizing Existing Users and User Groups.

Configuration Overview

After installing the product, you must configure the product deployment, which includes doing the following:

This section provides an overview of the following configuration element concepts:


Note –

Some related configuration instructions appear in Chapter 4, Configuring Core Resources.


Directories

A directory represents the following:

You can configure any number of each directory type.

Synchronization Settings

You use synchronization settings to control the direction in which object creations, object deletions, passwords and other attribute modifications are propagated between Directory Server and Windows directories. Synchronization flow options are as follows:


Note –

In a configuration that includes Active Directory and Windows NT, it is not possible to save a configuration that specifies different synchronization settings for creations or modifications between Windows NT and Directory Server, and between Active Directory and Directory Server.


Object Classes

When you configure resources, you will specify which entries to synchronize based on their object class. Object classes determine which attributes will be available to synchronize for both Directory Server and Active Directory.


Note –

Object classes are not applicable for Windows NT.


Identity Synchronization for Windows supports two types of object classes:

For instructions on configuring object classes and attributes, see Chapter 4, Configuring Core Resources

Attributes and Attribute Mapping

Attributes hold descriptive information about a user entry. Every attribute has a label and one or more values, and follows a standard syntax for the type of information that can be stored as the attribute value.

You can define attributes from the Console. See Chapter 4, Configuring Core Resources.

Attribute Types

Identity Synchronization for Windows synchronizes significant and creation user attributes, as follows:


Note –

Significant attributes are automatically synchronized as creation attributes but not the other way around. Creation attributes are only synchronized during user creations.


Parameterized Attribute Default Values

Identity Synchronization for Windows allows you to create parameterized default values for creation attributes using other creation or significant attributes.

To create a parameterized default attribute value, you embed an existing creation or significant attribute name, preceded and followed by percent symbols (%attribute_name%), in an expression string. For example, homedir=/home/%uid% or cn=%givenName%. %sn%.

When you create these attribute default values, follow these guidelines:

Mapping Attributes

After you define the attributes to synchronize, map the attribute names between the Directory Server and Active Directory/Windows NT systems to synchronize them to each other. For example, you must map the Sun inetorgperson attribute to the Active Directory user attribute.

You use attribute maps for both significant and creation attributes, and you must configure attribute maps for all “mandatory creation attributes” in each directory type.

Synchronization User Lists

You create Synchronization User Lists (SULs) to define specific users in both the Directory Server and Windows directories to be synchronized. These definitions enable synchronization of a flat Directory Information Tree (DIT) to a hierarchical directory tree.

The following concepts are used to define a Synchronization User List:

An SUL includes two definitions; where each definition identifies the group of users to be synchronized in the topology terms of the directory type.

When you are preparing to create SULs, ask yourself the following questions:

See Appendix D, Defining and Configuring Synchronization User Lists for Identity Synchronization for Windows for detailed information about creating SULs.

Synchronizing Passwords With Active Directory

The default password policy on Windows 2000 was changed on Windows 2003 to enforce strict passwords by default.

Identity Synchronization for Windows services must occasionally create entries that do not have passwords, for example, during a resync -c from Directory Server to Active Directory. Consequently, if password policies are enabled on Active Directory (on Windows 2000 or 2003) or on Directory Server, user creation errors can result.

Although you do not have to disable password policies on Active Directory or Directory Server, you need to understand the issues associated with enforcing their password policies.

The following installation information is important if you will be synchronizing passwords with Active Directory on Windows 2003 Server Standard or Enterprise Edition:

Enforcing Password Policies

This section explains how the password policies for Active Directory on Windows 2000, Windows 2003 Server, and Sun Java System Directory Server can affect synchronization results.

If you create users on Active Directory (or Directory Server) that meet the required password policies for that topology, the users may be created and synchronized properly between the two systems. If you have password policies enabled on both directory sources, the passwords must meet the policies of both directory sources or the synchronized user creations will fail.

This section discusses the following:

Directory Server Password Policies

If you create users in Active Directory with passwords that violate the Directory Server password policy, those users will be created and synchronized in Directory Server, but the entries will be created without a password. The password will not be set until the new user logs in to Directory Server, which triggers on-demand password synchronization. At this time the login will fail because the password violates the Directory Server password policy.

To recover from this situation, do one of the following:

Active Directory Password Policies

If you create users in Active Directory that do not match the Active Directory password policy, those users will be created in Directory Server.

Creating Accounts Without Passwords

In certain circumstances, such as resynchronization, Identity Synchronization for Windows must create accounts without passwords.

Directory Server

When Identity Synchronization for Windows creates entries in Directory Server without a password, it sets the userpassword attribute to {PSWSYNC}*INVALID*PASSWORD*. The user will not be able to log in to Directory Server until you reset the password. One exception is when you run resync with the -i NEW_USERS or NEW_LINKED_USERS option. In this case, resync will invalidate the new user’s password, triggering on-demand password synchronization the next time the user logs in.

Active Directory

When Identity Synchronization for Windows creates entries in Active Directory without a password, it sets the user’s password to a randomly chosen, strong password that meets Active Directory password policies. In this case, a warning message is logged, and the user will not be able to log in to Active Directory until you reset the password.

The following tables show some scenarios that you might encounter as you work with Identity Synchronization for Windows.

This section describes how password policies affect synchronization and resynchronization.

These tables do not attempt to describe all possible configuration scenarios because system configurations differ. Use this information as a guideline to help ensure that passwords will remain synchronized.

Table 2–3 How Password Policies Affect Synchronization Behavior

Scenario 

Results 

User Originally Created In

User Meets Password Policy In

User Created In

 

Directory Server

Active Directory

Directory Server

Active Directory

Comments

Active Directory 

Yes 

Yes 

Yes 

Yes 

 
 

Yes 

No 

Yes (see Comments)

No 

User will be created in Directory Server. However, if deletions are synchronized from Active Directory to Directory Server, this user will be deleted immediately. 

See Active Directory Password Policies information.

 

No 

Yes 

Yes

Yes 

See Active Directory Password Policies information.

 

No 

No 

Yes (see Comments)

No 

Users will be created in Directory Server. However, if deletions are synchronized from Active Directory to Directory Server, this user will be deleted immediately. 

See Active Directory Password Policies information.

Directory Server 

Yes 

Yes 

Yes 

Yes 

 
 

Yes 

No 

Yes 

No 

 
 

No 

Yes 

No 

No 

 
 

No 

No 

No 

No 

 

Table 2–4 How Password Policies Affect Resynchronization Behavior

Scenario 

Result

Resync Command

User Meets Password Policy In

 

Directory Server

Active Directory

resync -c -o Sun

N/A 

Yes 

User will be created in Active Directory but will not be able to log in. 

See Creating Accounts Without Passwords.

 

N/A 

No 

User will be created in Active Directory but will not be able to log in. 

See Creating Accounts Without Passwords.

resync -c -i NEW_USERS | NEW_LINKED_USERS

Yes 

N/A 

User will be created in Directory Server, and the user's passwords will be set when the user first logs in. 

See Creating Accounts Without Passwords.

 

No 

N/A 

User will be created in Directory Server but cannot log in because the password violates the Directory Server password policy. 

See Creating Accounts Without Passwords.

resync -c

Yes 

N/A 

User will be created in Directory Server but cannot log in until a new password value is set in Active Directory or Directory Server. 

See Creating Accounts Without Passwords.

 

No 

N/A 

User will be created in Directory Server but cannot log in until a new password value is set in Active Directory or Directory Server. 

See Creating Accounts Without Passwords.

Example Password Policies

This section states example password policies for Active Directory and Directory Server.

Directory Server Password Policies

Active Directory Password Policies

Error Messages

Check the central logger audit.log file on the Core system for the following error message:


Unable to update password on DS due to password policy during 
on-demand synchronization:

WARNING 125 CNN100 hostname "DS Plugin (SUBC100):
unable to update password of entry ’cn=John Doe,ou=people,o=sun’,
reason: possible conflict with local password policy"

Note –

For more information about password policies for Windows 2003, see http://technet.microsoft.com/en-us/library/cc782657(WS.10).aspx

For more information about password policies for Sun Java System Directory Server , see Chapter 7, Directory Server Password Policy, in Sun Directory Server Enterprise Edition 7.0 Administration Guide.


Configuring Windows for SSL Operation

If you are planning to propagate password changes from Directory Server to Windows Active Directory, you must configure each Active Directory to use SSL and install the high-encryption pack.

The Identity Synchronization for Windows Active Directory Connector installer can automatically setup SSL in the Active Directory Connector if you enable LDAP over SSL in Active Directory. You can automatically obtain a certificate from a Microsoft Certificate Services Enterprise Root certificate authority as described in

http://support.microsoft.com/default.aspx?scid=kb;en-us;q247078

However, LDAP over SSL can more easily be configured, as described in the technical note at http://support.microsoft.com/default.aspx?scid=kb;en-us;321051

In this case, if you decided to require trusted certificates for SSL communication, you must manually install the certificate in the Connector’s certificate database as described in Enabling SSL in the Active Directory Connector.

Installation and Configuration Decisions

This section provides installation and configuration summaries and details the choices you make when deploying Identity Synchronization for Windows. Read all of the information in this section, and complete the installation checklists before you begin the installation process.

Core Installation

You must provide the following information when you install Core:

Core Configuration

You must provide the following information when you configure Core:

Connector Installation and Configuring the Directory Server Plug-In

You must provide the following information when you install the connectors and the Directory Server Plug-in:

When you are installing Directory Server and Windows NT Connectors, you must specify an unused port.

When you are installing the Directory Server Connector and Plug-in, you must specify the host, port, and credentials for the Directory Server that corresponds to that Connector and Plugin.

Using the Command-Line Utilities

Identity Synchronization for Windows enables you to perform a variety of tasks from the command line using the idsync script with the following subcommands:

See Appendix A, Using the Identity Synchronization for Windows Command Line Utilities for detailed information about these utilities.

Installation Checklists

Use these checklists to prepare for the installation process. Print the checklists and record the appropriate information before installing Identity Synchronization for Windows.

Table 2–5 Core Installation Checklist

Required Information 

Entry 

Configuration directory host and port 

 

Root suffix for the configuration directory (such as dc=example,dc=com)

 

File system directory in which to install Identity Synchronization for Windows 

 

Configuration directory server administrator’s name and password 

 

Secure configuration password to protect sensitive configuration information 

 

Port number for the Message Queue instance 

 

User name and password for the Administration Server 

 

Table 2–6 Core Configuration Checklist

Required Information 

Entry 

Active Directory global catalog (when appropriate)

 

Directory Server schema server 

 

Directory Server user structural and auxiliary object classes 

 

Synchronized attributes 

 

Flow for user entry creations 

 

Flow for user entry modifications 

 

Flow for user entry activations and inactivations 

 

Flow for user entry deletions 

 

Sun Java System Directory Server directory sources 

 

Active Directory  

 

Synchronization User Lists 

 

Windows source filter creation expression 

 

Sun Java System source filter creation expression 

 

User name and password for the Administration Server 

 

Connector and Directory Server Plug-in Installation Checklist

Required Information 

Entry 

Configuration directory host and port 

 

Root suffix for the configuration directory 

 

File system directory in which to install the connector 

 

Configuration Directory Server administrator’s name and password 

 

Secure configuration password to protect sensitive configuration information 

 

Directory sources 

 

Unused port for Directory Server and Windows NT 

 

Host, port, and credentials for the Directory Server corresponding to the Connector and Plug-in 

 

Linking Users Checklist

Required Information 

Entry 

Synchronization User Lists to be linked. 

 

Attributes used to match equivalent users 

 

XML configuration file

 

Resynchronization Checklist

Required Information 

Entry 

Synchronization User List selection 

 

Synchronization source 

 

Create a user entry automatically if a corresponding user is not found at the destination directory source? 

 

Invalidate Directory Server passwords? 

 

Synchronize only those users that match the specified LDAP filter and are in the selected SULs?

 

Chapter 3 Installing Core

This chapter explains how to use the Identity Synchronization for Windows installation program and how to install the Identity Synchronization for Windows Core component.

The information is organized into the following sections:

Before You Begin

Before starting the Identity Synchronization for Windows installation process:

Starting the Installation Program

This section explains how to download, unpack (or unzip), and run the Identity Synchronization for Windows installation program on the following platforms:

On Solaris SPARC

Use the following steps to prepare and run the Identity Synchronization for Windows installation program on a Solaris SPARC operating system.

ProcedureTo Run Identity Synchronization for Windows on Solaris SPARC

  1. Log in as root.

  2. Change to the directory on the delivery media for Solaris SPARC containing the installation program, DSEE_Identity_Synchronization_for_Windows.

  3. Type ./runInstaller.sh to execute the installation program.

    To run the installation program in text-based mode, type the following.


    ./runInstaller.sh -nodisplay
    

    When you run the runInstaller.sh program, Identity Synchronization for Windows automatically masks passwords so they will not be echoed in the clear.

On Solaris x86

ProcedureTo Prepare and Run Identity Synchronization for Windows on Solaris x86

  1. Log in as root.

  2. Change to the directory on the delivery media for Solaris x86 containing the installation program, DSEE_Identity_Synchronization_for_Windows.

  3. Type ./runInstaller.sh to execute the installation program.

    To run the installation program in text-based mode, type the following.


    ./runInstaller.sh -nodisplay
    

    When you run the runInstaller.sh program, Identity Synchronization for Windows automatically masks passwords so they will not be echoed in the clear.

On Windows

Use the following steps to prepare and run the Identity Synchronization for Windows installation program on a Windows operating system:

ProcedureTo Run Identity Synchronization for Windows on Windows

  1. Log in as an Administrator.

  2. Change to the directory on the delivery media for Windows containing the installation program, DSEE_Identity_Synchronization_for_Windows.

  3. Type setup.exe to execute the installation program.

    The Identity Synchronization for Windows installation wizard is displayed.


    Note –

    Installing Core in the Administration Server root, makes the Identity Synchronization for Windows wizard detect most of the information required for installation, such as directory paths and names, and complete certain fields in the wizard panels automatically.

    If any of the information is missing or incorrect, you can enter the required information manually.


    Continue to the next section for Core installation instructions.

On Red Hat Linux

Use the following steps to prepare and run the Identity Synchronization for Windows installation program on a Red Hat Linux operating system:

ProcedureTo Prepare and Run Identity Synchronization for Windows on Linux

  1. Log in as root.

  2. Change to the directory on the delivery media for Red Hat containing the installation program, DSEE_Identity_Synchronization_for_Windows.

  3. Type ./installer.sh to execute the installation program.

    To run the installation program in text-based mode, type the following.


    ./installer.sh -nodisplay
    

    When you run the installer.sh program, Identity Synchronization for Windows automatically masks passwords so they will not be echoed in the clear.

Installing Core

This section explains the process for installing the Identity Synchronization for Windows Core on Solaris, Linux, and Windows operating systems.

Before you install Core, you should be aware of the following requirements:


Note –

You must install the program as root, but after installation you can configure the software to run Solaris and Linux services as a non-root user. (See Appendix B, Identity Synchronization for Windows LinkUsers XML Document Sample)


You must install Core into a directory that has an existing server root managed by an Administration Server (version 5 2004Q2 or higher) or the installation program will fail. (You can install Administration Server using the Directory Server 5 2004Q2 installation program.)


Note –

With Identity Synchronization for Windows 6.0, the installer checks for an existing Sun Java System Administration Server. If it is not installed, the installer will install Sun Java System Administration Server as a part of Core installation.


ProcedureTo Install Identity Synchronization for Windows Core Components Using the Installation Wizard

  1. When the Welcome screen is displayed, read the information provided and then click Next to proceed to the Software License Agreement panel.

  2. Read the license agreement, then select

    • Yes (Accept License) to accept the license terms and go to the next panel.

    • No to stop the setup process and exit the installation program.

  3. The Configuration Location panel is displayed, specify the configuration directory location.

    Figure 3–1 Specifying the Configuration Directory Location

    Enter the configuration directory host name, port, and
root suffix.

    Provide the following information:

    • Configuration Directory Host: Enter the fully qualified domain name (FQDN) of a Sun Java System Directory Server instance (affiliated with the local Administration Server) where Identity Synchronization for Windows configuration information will be stored.

      You can specify an instance on the local machine or an instance that is running on a different machine.

      Identity Synchronization for Windows allows Administrator Server to access the remotely installed instance of Directory Server.


    Note –

    To avoid warnings about invalid credentials or host names, be sure to specify a host name that is DNS-resolvable to the machine on which the installation program is running.


    • Configuration Directory Port: Specify the port where the configuration directory is installed. (Default port is 389)

      To enable secure communication, enable the Secure Port option and specify an SSL port. (Default SSL port is 636).

      Once the program determines that the configuration directory is SSL-enabled, all Identity Synchronization for Windows components will use SSL to communicate with the configuration directory.


    Note –

    Identity Synchronization for Windows encrypts sensitive configuration information before sending it to the configuration Directory Server.

    However, if you want additional transport encryption between the Console and configuration directory, be sure to enable SSL for both Administration Server and the configuration Directory Server. Then, configure a secure connection between the Administration Server to which you will be authenticating the Directory Server Console. (For information, see the Sun Java System Administration Server 5 2004Q2 Administration Guide).

    Sun Java System Administration Server installed (and configured) as a part of the core components, is installed in a non-SSL mode.


    • Configuration Root Suffix: Select a root suffix from the menu in which to store the Identity Synchronization for Windows configuration.


    Note –

    If the program could not detect a root suffix, and you have to enter the information manually (or if you change the default value), you must click Refresh to regenerate a list of root suffixes. You must specify a root suffix that exists on the configuration Directory Server.


  4. Click Next to open the Configuration Directory Credentials panel.

    Figure 3–2 Specifying the Administrator Credentials

    Enter your Administrator's credentials.

  5. Enter the configuration directory Administrator’s user ID and password.

    • If you specify admin as the user ID, you will not be required to specify the User ID as a DN.

    • If you use any other user ID, then you must specify the ID as a full DN. For example, cn=Directory Manager.


      Note –

      If you are not using SSL to communicate with the configuration directory (see Installing Core), these credentials will be sent without encryption.


  6. When you are finished, click Next to open the Configuration Password panel.

    Figure 3–3 Specifying a Configuration Password

    Enter a configuration password.

  7. You must enter and confirm a password that will be used to encrypt sensitive configuration information, such as credentials. When you are done, click Next.


    Note –

    Be sure to remember this password as it will be required whenever you want to

    • Access the Identity Synchronization for Windows Console

    • Create or edit a configuration

    • Install components

    • Run any of the command line utilities

      For information about changing the configuration password see Using changepw.

      The Select Java Home panel is displayed (see Installing Core). The program automatically inserts the location of the Java Virtual Machine directory to be used by the installed components.


    Figure 3–4 Specifying the Java Home Directory

    Enter JAVA_HOME directory.

  8. Verify the Java Home Directory (must be a JDK/JRE 1.5.0_09 or later):

    • If the location is satisfactory, click Next to proceed to the Select Installation Directories panel (Installing Core).

    • If the location is not correct, click Browse to search for and select a directory where Java is installed, for example:

    • On Solaris : /var/java

    • On Linux: /usr/bin/java

    • On Windows: C:\Program Files\j2sdk1.5

    Figure 3–5 Specifying the Installation Directories

    Enter server root directory, installation directory,
and instance directory.

  9. Enter the following information in the text fields provided or click Browse to search for and select available directories:

    • Server Root Directory: Specify the path and directory name of the Administration Server installation server root. The Console will be installed in this location.

    • Installation Directory (available only when you are installing Core on Solaris or Linux): Specify the path and directory name of the installation directory. Core binaries, libraries, and executable will be installed in this directory.

    • Instance Directory (available only when you are installing Core on Solaris or Linux): Specify the path and directory name of the instance directory. Configuration information that changes (such as log files) will be stored in this directory.


    Note –

    There is only one server root directory available on Windows operating systems, and all products will be installed in that location.



    Note –

    If an Administration Server corresponding to the Configuration Directory Host and Port number provided in step 3 is not found, the installer Administration Server will install the Administration Server as part of the core installation. The default port number for the Administration Server port assigned would be the configuration directory port plus one.


  10. Click Next to proceed to the Message Queue Configuration panel.


    Note –

    You should have installed Message Queue 3.6 Enterprise Edition before starting the Identity Synchronization for Windows installation.

    On Solaris systems: Do not install Message Queue and Identity Synchronization for Windows in the same directory.

    On Linux system: Do not install Message Queue and Identity Synchronization for Windows in the same directory.

    On Windows systems: You must close any open Service Control Panel windows before continuing, or the Core installation will fail.


    Figure 3–6 Configuring Message Queue

    Enter installation directory, configuration directory,
local host name, and broker port number.

  11. Enter the following information in the text fields provided or click Browse to search for and select available directories:

    • Installation Directory: Specify the path of the Message Queue installation directory.

    • Configuration Directory: Specify the path and directory name of the Message Queue instance directory.

    • Fully Qualified Local Host Name : Specify the fully qualified domain name (FQDN) of the local host machine. (There can only be one Message Queue broker instance running per host.)

    • Broker Port Number : Specify an unused port number for the Message Queue broker to use. (Default port is 7676)

  12. Click Next and the Ready to Install panel is displayed.

    This panel provides information about the install, such as the directory where Core will be installed and how much space is required to install Core.

    • If the displayed information is satisfactory, click Install Now to install the Core component (where the installation program installs the binaries, files, and packages).

    • If the information is not correct, click Back to make changes.

      An “Installing” message is displayed briefly, and then the Component Configuration panel is displayed while the installation program adds configuration data to the specified configuration Directory Server. This operation includes:

      • Creating a Message Queue broker instance

      • Uploading the schema to the configuration directory

      • Uploading deployment-specific configuration information to the configuration directory

        This operation will take several minutes and may pause periodically, so do not be concerned unless the process exceeds ten minutes. (Watch the progress bar to monitor the installation program’s status.)

  13. When the component configuration operation is complete, the Installation Summary panel is displayed to confirm that Identity Synchronization for Windows installed successfully.

    You can click the Details button to see a list of the files that have been installed, and where they are located.

  14. Click Next and the program will determine the remaining steps you must perform to successfully install and configure Identity Synchronization for Windows.

    A “Loading...” message, and then a Remaining Installation Steps panel each display briefly, and then the following panel (Installation Overview) is displayed. This panel contains a “To Do” list of the remaining installation and configuration steps. (You also can access this panel from the Console’s Status tab.)

    Figure 3–7 To Do List for Identity Synchronization for Windows Installation and Configuration

    This panel lists the remaining installation/configuration
steps you must perform.

    The “To Do” panel will re-display throughout the installation and configuration process. The program greys-out all completed steps in the list.

    Up to this point, the To Do list will contain a generic list of steps. After you save a configuration, the program provides a list of steps that are customized for your deployment (for example, which connectors you must install).

  15. After reading the list of steps, click Next and the Start Console Option panel is displayed to indicate you have finished the Core installation.

    Figure 3–8 Starting the Console

    Enable the box to start the Sun Java System Console.

  16. Next, you must configure the Core component, which you can do from the Sun Java System Console (the Start the Sun Java System Console option is enabled by default).

    If you are migrating from Identity Synchronization for Windows version 1.0 or SP1 to Sun Java System Identity Synchronization for Windows 6.0, you can import an exported version 1.0 or SP1 configuration XML document using the idsync importcnf command line utility.

  17. Click Finished.

  18. If you elected to use the Console, the Sun Java System Console Login dialog box is displayed (seeInstalling Core).

    Figure 3–9 Logging into the Console

    Enter Localhost Name and Port Number for Sun Java System
Message Queue.

    You must enter the following information to log into the Console:

    • User ID: Enter the Administrator’s user ID you specified when you installed the Administration Server on your machine.

    • Password: Enter the Administrator’s password specified during Administration Server installation.

    • Administration URL: Enter the Administration Server’s current URL location using the following format:

      http://hostname.your_domain.domain:port_number

      Where:

      • hostname.your_domain.domain is the computer host name you selected when you installed Administration Server.

      • port_number is the port you specified for Administration Server.

  19. After providing your credentials, click OK to close the dialog box.

  20. You will then be prompted for the configuration password. Enter the password and click OK.

    When the Sun Java System Server Console window is displayed, you can start configuring Core. Continue to Chapter 4, Configuring Core Resources for instructions.

Chapter 4 Configuring Core Resources

You must initially configure the Core resources immediately after installing the Identity Synchronization for Windows Core.

This chapter explains how to add and configure these resources using the Console, and is organized into the following sections:


Note –

To effectively configure Core resources you must know how to configure and operate Directory Server and Active Directory.

You are not required to configure these resources in a particular order (unless specifically noted in the text); however, using the configuration order presented in this chapter until you become more familiar with the product can save time and prevent errors.


Configuration Overview

This section illustrates the steps you will use to configure the Core resources for your deployment.

Figure 4–1 Configuring Core Resources for Your Deployment

Flow diagram showing steps for configuring Core resources
for your environment.

Opening the Identity Synchronization for Windows Console

The Sun Java System Server Console window lists all of the servers and resources under your control and provides information about your system.

Figure 4–2 Sun Java System Server Console

Sun Java System Server Console


Note –

If you have not logged into the Sun Java System Server Console yet, return to Figure 3–9 for instructions.


ProcedureTo Open Identity Synchronization for Windows Console

  1. On the Servers and Applications tab, select the hostname node in the navigation tree that contains the Server Group to which the Identity Synchronization for Windows instance belongs.

  2. Expand the Server Group node and select the Identity Synchronization for Windows node.

    Figure 4–3 Expanding the Server Group

    Expand the Server Group node and select Identity Synchronization
for Windows.

    The information panel changes to provide information about Identity Synchronization for Windows and your system.

    Figure 4–4 Information Panel

    Identity Synchronization for Windows Information Panel

  3. Click the Open button (located in the upper-right corner of the panel).


    Note –

    The Edit button (located at the bottom of the panel) enables you to edit the Server name and Description.


  4. You will be prompted to enter the configuration password that you specified during Core installation. Enter the password and click OK.

    The Identity Synchronization for Windows Console is displayed, as follows:

    Figure 4–5 Console: Tasks Tab

    Identity Synchronization for Windows Console opens by
default to the Tasks Tab.

    This window contains three tabs:

    • Tasks (Default): Use this tab to stop and start synchronization between your Sun and Windows systems. (Information about starting and stopping services is provided in Starting and Stopping Synchronization)


    Note –

    Do not confuse starting and stopping Synchronization Services with starting and stopping Windows services.

    To start or stop Windows services, you must do so from the Windows Console by selecting Start -> Console -> Administrative Tools -> Computer Management -> Services.


    • Configuration: Use this tab to configure your systems for synchronization.

    • Status: Use this tab to do the following:

      • Monitor the status of system components (such as Connectors).

      • View the audit and error logs generated by Identity Synchronization for Windows during configuration and synchronization.

      • Update and check the installation and configuration To Do list.

  5. Select the Configuration tab.

    Figure 4–6 Console: Configuration Tab

    Configuration Tab

    The Configuration panel consists of the following tabs:

    • Attributes: Use this tab to specify the attributes you want to synchronize between systems.

      • Attribute Modification: Use this tab to specify how passwords, attribute modifications, and object disablements are propagated between systems.

      • Object Creation: Use this tab to specify how newly created passwords and attributes are propagated between systems, and to specify initial values for the objects created by Identity Synchronization for Windows during synchronization.

      • Object Deletion: Use this tab to specify how deleted passwords and attributes are propagated between systems.

        You must configure at least one Sun Java System Directory Server directory source, and at least one Windows server directory source (either Active Directory or Windows NT). Proceed to the next section for instructions.

Creating Directory Sources

ProcedureTo Create Directory Sources

You must create directory sources in the following order (based on which sources you will be synchronizing).

  1. Creating a Sun Java System Directory Source

  2. Preparing Sun Directory Source

  3. Creating an Active Directory Source

  4. Creating a Windows NT SAM Directory Source


    Note –

    At minimum, you must configure at least one Sun Java System Directory source and at least one Windows directory source (Active Directory and/or NT SAM).


    Select the Directory Sources node in the navigation tree and the Directory Sources panel is displayed.

    Figure 4–7 Accessing the Directory Sources Panel

    Click the Directory Sources node to access the Directory
Sources panel.

Creating a Sun Java System Directory Source

Each Sun Java System directory source is associated with a Connector and set of Plug-ins that can be deployed in a replication scenario involving multiple servers. The Directory Server Connector is capable of synchronizing changes from Windows directory source to the preferred server (master). In case, the preferred server is down, the changes will failover to the secondary server in the configured secondary servers list in a sequential manner till the preferred server comes up. Directory Server replication will replicate changes made from the preferred server (master) to other preferred secondary servers configured in the topology. Any Directory Server Plug-in can handle password validity checks from Windows directory sources and users can change passwords at any server.

ProcedureTo Create a New Sun Java System Directory Source

  1. Click the New Sun Directory Source button to invoke the Define Sun Java System Directory Source wizard.

    Figure 4–8 Selecting a Root Suffix

    Use this panel to specify a root suffix.

    The program queries a known set of configuration directory sources and displays existing root suffix (also referred to as naming contexts ) in the list pane.

    By default, the program knows about the configuration directory where you installed the product, and the root suffixes known by the configuration directory will be listed in the list pane.

  2. Select the root suffix where your users are located from the list pane. (If several root suffixes are listed, select the one where your users are located.) Click Next.

    If the root suffix you want to synchronize with is not affiliated with a configuration directory registered with Identity Synchronization for Windows, then you must specify a new configuration directory, as follows:

    1. Click the Configuration Directories button to specify a new configuration directory.

    2. When the Configuration Directories dialog box is displayed ( Step 3), click the New button to open the New Configuration Directories dialog box.

      Figure 4–9 Selecting a New Configuration Directory

      Use the New Configuration Directory dialog box to specify
a new configuration directory.

    3. Enter the following information, and then click OK to save your changes and close the dialog box.

      • Host: Enter the fully qualified host name.

        For example: machine1.example.com

      • Port: Enter a valid, unused LDAP port number. (Default is 389)

        Enable the This port uses SSL box if Identity Synchronization for Windows is using an SSL (Secure Socket Layer) port to communicate with the configuration directory.

      • User DN: Enter your Administrator’s (bind) distinguished name. For example, uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot

      • Password: Enter your Administrator’s password.

        The wizard will query the specified configuration directory to determine all of the directory servers managed by that directory.


        Note –

        Identity Synchronization for Windows only supports one root suffix per Sun Java System Directory Server source.


        Editing and Removing Configuration Directories

        You can also use the Configuration Directories dialog box to manage your list of configuration directories, as follows:

      • Select a configuration directory from the list pane, and then click the Edit button. When the Edit Configuration Directories dialog is displayed, you can change the Host, Port, Secure Port, User Name, and Password parameters.

      • Select a configuration directory from the list pane, and then click Remove to delete the directory from the list.

    4. Click OK to close the Configuration Directories dialog box and the newly selected configuration directory’s root suffixes are displayed in the list pane.

      By default, Directory Server creates a root suffix whose prefix corresponds to the components of the machine’s DNS domain entry. It uses the following suffix:

      dc=your_machine’s_DNS_domain_name

      That is, if your machine domain is example.com, then you should configure the suffix dc=example, dc=com for your server. The entry named by the chosen suffix must already exist in the directory.

    5. Select the root suffix, and click Next.

      The Specify Preferred Servers panel is displayed (see Creating a Sun Java System Directory Source).

      Figure 4–10 Specifying a Preferred Server

      Use the Specify a Preferred Server panel to select a
Sun Java System Directory Server.

      Identity Synchronization for Windows uses the preferred Directory Server to detect changes made at any Directory Server master. The preferred server also acts as the primary location where changes made on Windows systems are applied to the Sun Java System Directory Server system.

      If the preferred master server fails, the secondary server can store these changes until the preferred server (master) comes back online.

  3. Use one of the following methods to select a preferred server:

    • Select the Choose a Known Server option, and then select a server name from the drop-down list.


      Note –

      The Directory Server must be running to appear in the list. If the server is down temporarily, select the Specify a Server by Providing a Hostname and Port option, and then enter the server information manually.


      Enable the Use SSL for secure communication box if you want the Directory Server to communicate using SSL. However, if you enable this feature there are some additional setup steps you must perform after installation. For more information, see Enabling SSL in Directory Server

    • Select the Specify a Server By Providing a Hostname and Port option, and then type the server’s Host name and Port into the text fields.

      Select the This Port Uses SSL checkbox if the port you specified uses SSL.

  4. Click Next and the Specify a Secondary Server panel is displayed.

    Figure 4–11 Specifying the Secondary Servers for Failover Support

    Select a secondary server.

    You can add, edit, or delete the Secondary Servers:

    • Click the New button to display the Add Sun Directory Source dialog box. Enter the host name, port, user DN, password, and then click OK. For more information on these fields, see Step c.

    • Click the Edit button to display the Edit Sun Directory Source dialog box. Enter the host name, port, user DN, password, and then click OK. For more information on these fields, see Step c.

    • From the Secondary Servers list, select the server you want to delete and click the Remove button.

  5. To specify the secondary Directory Servers, select a server name from list, and then click Next.


    Note –
    • The Directory Server must be running or the server name will not appear in list.

    • Do not use the same host name and port for both the preferred and the secondary servers in a Sun directory source.

    • If you enable the Secure Port feature, there are additional setup steps you must perform after installation. For more information, see Enabling SSL in Directory Server

    If you do not want to specify a secondary server, click Next.


  6. If you want to use secure SSL communication, read the notes below, and then enable one or both of the following options:

    Figure 4–12 Specifying Advanced Security Options

    Enable the Use SSL for plugin to Active Directory communication
to specify advanced security options.


    Note –

    You must install the Directory Server Plug-in on each Directory Server (any master, replica, or hub) where users will bind or where passwords will be changed.

    When the Directory Server Plug-in synchronizes passwords and attributes to Active Directory, it must bind to Active Directory to search for users and their passwords. In addition, the Plug-in writes log messages to the central log and into the Directory Server’s log. By default these communications are not accomplished over SSL.


    • To encrypt channel communication only or to encrypt channel communication and use certificates to ensure participants’ identity verification between Directory Server and the Directory Server Connector, enable the Require Certificates for SSL box.

      Clear the checkbox if you do not want to trust certificates.

    • To use secure SSL communication between the Directory Server Plug-in and Active Directory, enable the Use SSL for Plug-in to Active Directory communication box.

    If you enable these features, then additional setup is required after installation. See Enabling SSL in Directory Server

  7. When you are finished with the Specify Advanced Security Options panel, click Finish.

    The program adds the selected directory sources to the navigation tree under Directory Sources, and the Prepare Directory Server Now? dialog is displayed.

    You must prepare the Directory Server to be used by Identity Synchronization for Windows. You can choose to perform this task now, or you can do it later — but you must prepare the Directory Server before you install the Connectors. (Instructions for installing Connectors are provided in Chapter 5, Installing Connectors).

Preparing Sun Directory Source

This section explains how to prepare Sun Directory source for use by Identity Synchronization for Windows.

Preparing the Directory Server:


Note –
Figure 4–13 Entering Your Directory Manager Credentials

Enter your Directory Manager credentials.


Note –

To access this wizard, use one of the following methods:


ProcedureTo Prepare your Directory Server Source

  1. Enter the following credentials for the Directory Manager account.

    • Directory Manager User Name

    • Directory Manager Password

      If you are using a secondary host (MMR configurations), then the Secondary Host options will be active and you must specify credentials for these hosts too.

  2. When you are done, click Next and the Specify Preparation Configuration panel is displayed.

    Figure 4–14 Specifying the Preparation Configuration

    Decide whether to create indexes now, or at a later time.

    Read the warning, and then decide whether to create the Directory Server indexes now or later.


    Note –
    • This operation can take some time, depending on the size of your database.

    • While your database is in read-only mode, any attempts to update information in the database will fail.

    • Taking your database offline enables you to create the indexes much faster.

    • To create the indexes now, enable the Create indexes for database box, and then click Next.

    • To create the indexes later (either manually or by running this wizard again) clear the Create indexes for database box, and then click Next.


  3. The Preparation Status panel is displayed to provide information about the Directory Server preparation progress.

    • When a SUCCESS message is displayed at the bottom of the message pane, click Finish.

    • If error messages display, you must correct the problem(s) reported before you can continue. Check the error logs (see the Status tab) for more information.

  4. Return to the Configuration tab in the Console. Select the Sun Directory source node in the navigation tree to view the Sun Directory Source panel.

    Figure 4–15 Sun Directory Source Panel

    Sun Directory Source panel provides information about
the selected directory source.

    From this panel, you can perform the following tasks:

    • Edit servers: Click this button to reopen the Define Sun Java System Directory Source panel where you can change any of the server configuration parameters. If necessary, review the instructions provided for Creating a Sun Java System Directory Source.


      Note –

      If you recreate the Retro-Changelog database for the preferred Sun directory source, the default access control settings will not allow the Directory Server Connector to read the database contents.

      To restore the access control settings for new the Retro-Changelog database, run idsync prepds or click the Prepare Directory Server button after selecting the appropriate Sun directory source in the Console.


    • Prepare Directory Server: Click this button and follow the instructions for Preparing Sun Directory Source to prepare a Directory Server.

      If anything changes on the Directory Server after you initially prepare the server (for example, if an index is deleted or you lose the Retro-Changelog database), you can re-prepare the server.

    • Resync interval: Specify how often you want the Directory Server Connector to check for changes. (Default is 1000 milliseconds)

  5. Add a Directory Server directory source for each user population in your Sun Java System Directory Server enterprise that you want to synchronize.

    When you are finished, you must create at least one Windows directory source:

Creating an Active Directory Source

You should add an Active Directory directory source for each Windows domain in your network that you want to synchronize.

Each Active Directory deployment has at least one global catalog that knows about all the global information across all Active Directory domains. To access the global catalog, the rights assigned to a normal user are sufficient unless you change the default permissions.


Note –

It is possible for each Active Directory server to be a global catalog and a deployment can have multiple global catalogs, but you only need to specify one global catalog.


ProcedureTo Configure and Create Windows Active Directory Servers in a Network

Perform these steps if there are Windows Active Directory servers in your network:

  1. Select the Directory Sources node in the navigation tree, and then click the New Active Directory Source button on the Directory Sources panel.

    The Windows Global Catalog dialog box is displayed.

    Figure 4–16 Windows Global Catalog

    Specify the host, port, and credentials for the Active
Directory Global Catalog.

  2. Enter the following information and then click OK:

    • Host: Enter the fully qualified host name of the machine that holds the global catalog for the Active Directory forest.

      For example: machine2.example.com

    • This port uses SSL: Enable this option if Identity Synchronization for Windows is using an SSL port to communicate with the global catalog.

    • User DN: Enter your fully qualified Administrator’s (bind) distinguished name. (Any credentials that enable you to browse the schemas and determine which Active Directory domains are available on your system will suffice.)

      For example: cn=Administrator,cn=Users,dc=example,dc=com

    • Password: Enter a password for the specified user.

  3. The Define Active Directory Source wizard is displayed, as follows.

    Figure 4–17 Define an Active Directory Source Wizard

    Select an Active Directory Domain.

    This wizard queries the Active Directory global catalog to determine what other domains exist, and displays those domains in the Domains list pane.

  4. Select a name from the list pane to specify an Active Directory domain and click OK.

    If the domain you want to use is not displayed in the list, you must add the global catalog that knows about that domain using the following steps:

    1. Click the Global Catalogs button and the Global Catalogs wizard is displayed.

      Figure 4–18 Specifying a New Global Catalog

      Create a new Active Directory Global Catalog.

    2. Click the New button.

    3. When the Windows Global Catalog dialog box is displayed, provide the global catalog’s Host name and your Directory Source credentials (as described in Step 2), and then click OK

    4. The new global catalog and port, are displayed in the Global Catalogs list panel. Select the catalog name, and then click OK.

    5. Repeat these steps if you want to add more global catalogs (domains) to the system.

    6. When you are done, click the Next button in the Select a Domain pane.

  5. When the Specify Credentials panel is displayed, review the value in the User DN field.

    Figure 4–19 Specifying Credentials for This Active Directory Source

    Provide your administrator credentials.

    If the program did not automatically enter the Administrator’s distinguished name in the User DN field (or you do not want to use the Administrator’s credentials) enter a User DN and password manually.

    When configuring an Active Directory source, you must provide a user name and password that the Active Directory Connector can use to connect to Active Directory.


    Note –

    The Connector requires specific access rights. Minimum rights will depend on the direction of synchronization, as follows:

    • If you are configuring synchronization flow from Active Directory to Directory Server only, then the user provided for the Active Directory Connector does not require many special privileges. A normal user with the extra privilege to “Read All Properties” in the domain being synchronized will suffice.

    • If you are configuring synchronization flow from Directory Server to Active Directory, then the Connector user must have more privileges because, synchronization changes the user entries in Active Directory. In this setup, the Connector user must have either the “Full Control” privilege or be a member of the Administrators group.


  6. Click Next to open the Specify a Domain Controller panel.

    Figure 4–20 Specifying a Domain Controller

    Select an Active Directory domain controller.

    Use this panel to select a controller to synchronize within the specified domain. (The domain controller is similar in concept to a Directory Server’s preferred server.)

    If the selected Active Directory domain has multiple domain controllers, select the domain controller with the Primary Domain Controller flexible single master operation (FSMO) role for synchronization.

    By default, password changes made at all domain controllers will be replicated immediately to the Primary Domain Controller FSMO role owner, and if you select this domain controller, Identity Synchronization for Windows will synchronize these password changes immediately to the Directory Server.

    In some deployments, the AvoidPdcOnWan attribute may be set in the Windows registry because there is a significant network “distance” to the PDC, which will delay synchronization significantly. (See Microsoft Knowledge Base Article 232690 for more information.)

  7. Select a domain controller from the drop-down list.

  8. If you want the Identity Synchronization for Windows Connector to communicate with the domain controller over a secure port, enable the Use a Secure Port box.


    Note –

    The program automatically installs the CA certificate in the Active Directory Connector if you are using Microsoft certificate server. If you are not, then you must manually add the CA certificate in the Active Directory Connector (see Enabling SSL in the Active Directory Connector change your flow settings after initial configuration these procedures apply as well.


  9. When you are done, click Next.

    The Specify Failover Controllers panel is displayed (see Creating an Active Directory Source ). You can use this panel to specify any number of failover domain controllers.

    Figure 4–21 Specifying Failover Controllers

    Use this panel to specify failover domain controllers.

    The Active Directory Connector communicates with only one Active Directory domain controller, and Identity Synchronization for Windows does not support failover changes applied by that Connector. However, the Directory Server Plug-in will communicate with any number of domain controllers when validating password changes to Directory Server.

    If Directory Server tries connecting to an Active Directory domain controller and that domain controller is not available, Directory Server will iteratively try connecting to the failover domain controller(s) specified.

  10. Select one or more of the server names listed in the Failover Servers list pane (or click the Select All button to specify all of the servers in the list), and then click Next.

  11. The Specify Advanced Security Options panel is displayed.

    The Require trusted SSL certificates option is active (available for selection) only if you enabled the Use SSL for Secure Communication box on the Specify a Domain Controller panel.

    Figure 4–22 Specifying Advanced Security Options

    Use this panel to require trusted SSL certificates for
communication between Active Directory and the Active Directory Connector.

    • If the Require trusted SSL certificate box is disabled (Default setting ), the Active Directory Connector will connect to Active Directory over SSL and does not verify that it trusts the certificates passed by Active Directory.

      Disabling this option simplifies the setup process because you do not have to put an Active Directory Certificate in the Active Directory certificate database.

    • If you enable the Require trusted SSL certificate box, the Active Directory Connector will connect to Active Directory over SSL and it must verify that it trusts the certificates passed by Active Directory.


      Note –

      You must add Active Directory Certificates to the Active Directory Connector’s certificate database. For instructions, see Adding Active Directory Certificates to the Connector’s Certificate Database.


  12. When you are finished with the Advanced Security Options panel, click the Finish button.

    The program adds the newly specified Active Directory source to the navigation tree under Directory Sources.

  13. Select the Active Directory source node to view the Active Directory Source panel.

    Figure 4–23 Active Directory Source Panel

    Use this panel to change any of the server parameters,
specify a resync interval, or change the required directory source credentials.

    From this panel, you can perform the following tasks:

    • Edit Controllers: Click this button to reopen the Specify a Domain Controller panel where you can change any of the domain controller configuration parameters. If necessary, review the instructions provided for Creating an Active Directory Source.

    • Resync Interval: Specify how often you want the Active Directory Connector to check for changes. (Default is 1000 milliseconds)

    • Directory Source Credentials: Change the specified User DN and/or password.

Creating a Windows NT SAM Directory Source

This section explains how to create a Windows NT SAM Directory Source where you can deploy Identity Synchronization for Windows.

ProcedureTo Deploy Identity Synchronization for Windows on Windows NT

  1. Select the Directory Sources node in the navigation tree, and then click the New Windows NT SAM Directory Source button.

    Figure 4–24 Directory Sources Panel

    Click the New Windows NT SAM Directory Source button
to create a  Windows NT directory source.

  2. When the Define a Windows NT SAM Directory Source panel is displayed, follow the instructions for locating the Windows NT domain name, and enter the unique NT directory source domain name in the Domain field. When you are done, click Next.

    Figure 4–25 Specifying a Windows NT SAM Domain Name

    Enter a name for your Windows NT SAM domain.

  3. When the Specify the Computer Name for the Primary Domain Controller panel is displayed, follow the instructions for locating the Primary Domain Controller computer name, and enter the information in the Computer Name field.

    Figure 4–26 Specifying a Name for the Primary Domain Controller

    Enter a Windows NT NETBIOS computer name for the Primary
Domain Controller.

  4. Click Finish.

    The program adds the newly specified Windows NT SAM directory source to the navigation tree under Directory Sources. Select the new directory source node to view the Windows NT SAM Source panel.

    Figure 4–27 Windows NT SAM Directory Source Panel

    Use the Windows NT SAM Directory Source panel to edit
the domain name or change the resync interval.

    From this panel, you can perform the following tasks:

    • Edit: Click this button to reopen the Specify a Domain Controller panel where you can change any of the domain controller configuration parameters. If necessary, review the instructions provided for Creating an Active Directory Source.

    • Resync interval: Specify how often you want Identity Synchronization for Windows to check for changes made on Windows NT. (Default is 1000 milliseconds)

  5. Add a Windows NT directory source for each Windows NT machine in your network.

    When you are finished creating Windows NT SAM directory sources, you are ready to create and map attributes to be synchronized, continue to Selecting and Mapping User Attributes

Selecting and Mapping User Attributes

After you have created and configured your Directory Server and Windows directory sources, you must decide which user attributes you want to synchronize and then map those attributes between systems.

The information in this section is organized as follows:

Selecting and Mapping Attributes

There are two types of attributes:

ProcedureTo Select and Map Attributes for Synchronization

  1. Select the Identity Synchronization for Windows node at the top of the navigation tree.

    Figure 4–28 Attributes Tab

    Select the Attributes Tab.


    Note –

    When the Group Synchronization feature has been enabled, the uniquemember (Directory Server) attribute and member attribute (Active Directory) are internally mapped and would be indicated as shown in the console.


  2. Select the Attributes tab and then click the New button.

    The Define Significant Attribute Mappings dialog box is displayed. Use this dialog box to map attributes from Directory Server to your Windows Systems (Active Directory and/or Windows NT).

    Figure 4–29 Defining Significant Attribute Mappings

    Use this dialog to map the attributes between systems.


    Note –

    Which creation attributes are mandatory for Directory Server (or for Active Directory) will depend on the objectclass configured for your Sun-side (or Active Directory-side) user entries.

    The program automatically uses inetOrgPerson as the default objectclass for Directory Server, and you loaded the Active Directory schema when you specified the global catalog. So you do not use the Load Schema buttons unless you want to change the default schema.

    If you want to change the default schema source, see Changing the Schema Source


  3. Select an attribute from the Sun Java System attribute drop-down list (for examplecn), and then select the equivalent attribute from the Active Directory attribute and/or Windows NT SAM attribute drop-down menus.

  4. When you are finished, click OK.

  5. To designate additional attributes, repeat steps 2 through step 4.

    A finished Synchronized Attributes table might look something like the following example, which shows the userpassword, cn, and telephonenumber Directory Server attributes mapped to unicodepwd, cn, and telephonenumber Active Directory attributes.

    Figure 4–30 Completed Synchronized Attributes Table

    A completed synchronized attributes table.

Creating Parameterized Default Attribute Values

Identity Synchronization for Windows allows you to create parameterized default values for attributes using other creation or significant attributes.

To create a parameterized default attribute value, you embed an existing creation or significant attribute name— preceded and followed by percent symbols (% attribute_name %) — in an expression string. For example, homedir=/home/%uid% or cn=%givenName% %sn%.

When you create these attribute values:


Note –

When Group Synchronization is enabled, the following are important:

  1. The creation expression supported at Active Directory is cn=%cn%.

  2. The creation expression must contain valid attribute names belonging to the group objectclass also since the creation expression is common to both user as well as the group.

    For example: The attribute sn is not part of the groupofuniquenames objectclass at the Directory Server. Hence the following creation expression would be invalid for a group object. (Though it would work fine for user.)

    cn=%cn%.%sn%

  3. The attribute used in the creation expression must be provided with a value for every user/group entry created. The value maybe provided using the command line interface, if the console does not have the provision.


Changing the Schema Source

The program automatically provides default schema sources, but allows you to change the default schema.

ProcedureTo Change the Default Schema Source

  1. Click the Load Schema button on the Define Significant Attribute Mappings dialog box.

    The Select Schema Sources panel is displayed.

    Figure 4–31 Selecting Schema Sources

    Use this panel to select a schema source.

    Use this panel to specify from which Sun Java System Directory Server schema server you want to read the schema. This schema contains the object classes that are available on your system, and object classes define which attributes are available for users on your system.

    The program adds your configuration directory to the Sun Java System Directory schema server field by default.

  2. To select a different server, click the Choose button.

    The Select a Sun Schema Host dialog box is displayed. This dialog box contains a list of the configuration directories that gather administrative information about your directory sources.

    From this dialog box, you can:

    • Create new configuration directories and add them to the list.

      Click New, and when the New Configuration Directory dialog box displays; specify a Host, Port, User DN, and Password. Click OK when you are done.

    • Edit existing directories.

      Click Edit, and when the Edit Configuration Directory dialog box displays, you can change the Host, Port, User DN, and/or Password. Click OK when you are done.

    • Remove directories from the list.

      Select a directory name from the list and then click the Remove button.

  3. Select a server from the list and click OK when you are done. (Generally, one of your Sun synchronization host(s) is a good choice as a schema source.)

  4. Click the Next button and the Select Structural and Auxiliary Object Classes panel is displayed.

    Figure 4–32 Selecting Structural and Auxiliary Object Classes

    Use this panel to specify structural and auxiliary object
classes.

    Use this panel to specify the object classes to synchronize, as follows:

    • Structural Object Class: Every entry that is created or synchronized from the selected Directory Server must have at least one structural object class.

    • Auxiliary Object Classes: These object classes augment the selected structural class and provide additional attributes for synchronization.

      To specify structural and auxiliary object classes:

    1. Select a structural object class from the drop-down list. ( Default is inetorgperson.)

    2. Select one or more object classes from the Available Auxiliary Object Classes list pane, and then click Add to move your selection(s) to the Selected Auxiliary Object Classes list pane.

      The selected object class(es) determine which Directory Server source attributes will be available for selection as significant or creation attributes. The object class(es) also determine the mandatory creation attributes.

      To delete selections from the Selected Auxiliary Object Classes list, click the object class name and then click the Remove button.

    3. When you are done, click Finish and the program loads the schema and selected object classes.

Propagating User Attributes Between Systems

After you create and map the user attributes you want to synchronize, you must tell Identity Synchronization for Windows how to propagate (flow) the attribute creations, modifications, and deletions between your Directory Server and Windows Systems.

By default, Identity Synchronization for Windows:

Specifying How Object Creations Flow

ProcedureTo Specify How Object Creations Should Flow Between Directory Server and Active Directory Systems

  1. Click the Object Creation tab.

    Figure 4–33 Selecting and Propagating Creations

    Use this panel to specify new creation attributes and
to configure how creations will flow between systems.

  2. You can enable or disable the flow of creations as follows:

    • Enable Object creations flow from Sun Java System Directory Server to Windows to propagate creations from the Directory Server environment to your Windows servers.

    • Enable Object creations flow from Windows to Sun Java System Directory Server to propagate creations from the Windows environment to your Directory Servers.

    • Enable both options for bidirectional flow.

    • Disable both options to prevent user creations from propagating from one system to the other. (Default).

  3. To add, edit, or delete creation attributes to synchronize between systems, click the Creation Attributes button located under the selected option(s).

    The Creation Attribute Mappings and Values dialog box displays.

    Figure 4–34 Creation Attributes Mappings and Values: Directory Server to Windows

    Use this dialog box to map Active Directory creation
attributes to Directory Server.

    Figure 4–35 Creation Attributes Mappings and Values: Windows to Directory Server

    Use this dialog box to map Active Directory creation
attributes to Directory Server.

    You can use either of the dialog boxes to specify new creation attributes, edit, or delete existing attributes. For more information, see Specifying New Creation Attributes.


    Note –

    To satisfy schema constraints regarding required attributes for user object classes, you may have to specify additional attributes to flow through the system during a user creation.

    Additional attributes are not necessary if you specified the required attributes as modification attributes (as described in Selecting and Mapping User Attributes).


Specifying New Creation Attributes

The following instructions explain how to add and map creation attributes from Active Directory to Directory Server. (The procedure for adding and mapping creation attributes flowing from Directory Server to Windows and from Windows to Directory Server is similar.)

ProcedureTo Specify New Creation Attributes

  1. Click the New button in the Creation Attribute Mappings and Values dialog box.

    The Define Creation Attribute Mappings and Values dialog box is displayed.

    Figure 4–36 Defining Creation Attribute Mappings and Values

    Use this dialog box to map creation attributes and add
values to those attributes.

  2. Select an attribute value from the Active Directory attribute drop-down list.

    Figure 4–37 Selecting a New Active Directory Attribute

    Specify a new Active Directory attribute.

    Identity Synchronization for Windows allows you to initialize an attribute with multiple values— if the attribute itself accepts multiple values.

    For example, if your company has three fax telephone numbers, you can specify the facsilimiletelephonenumber attribute for both Sun Java System Directory Server and Active Directory, and specify the three numbers.

    You must know which attributes will accept multiple values. If you try adding multiple values to an attribute that does not accept them, an error will result during runtime when the program attempts to create the object.

  3. Enter a value in New value field and click Add.

    The program adds the attribute value to the list pane. Repeat this step as many times as necessary to add multiple attribute values.

    Figure 4–38 Specifying Multiple Values for a Creation Attribute

    You can specify multiple values for certain creation
attributes.

  4. To map the attribute to Directory Server, select an attribute name from the Directory Server attribute drop-down list.

    Figure 4–39 Mapping the Directory Server Attribute

    Map the Directory Server attribute to the Windows attribute.

  5. When you are finished, click OK.

    Based on the example, the finished Creation Attributes and Mappings table would look like the one in the following figure.

    Figure 4–40 Completed Creation Attributes and Mappings Table

    Finished Creation Attributes and Mappings table.

  6. To designate additional attributes, repeat these steps.

Editing Existing Attributes

ProcedureTo Edit Creation Attributes Mapping or Values

  1. Select the Object Creation tab, and click on the Creation Attributes button located under the selected creation option.

  2. When the Creation Mappings and Values dialog box is displayed, select the attribute from the table, and then click the Edit button.

    The Define Creation Mappings and Values dialog box is displayed.

  3. Use the drop-down menus to change the existing mapping between Directory Server and Active Directory (or Windows NT).

    For example, if you have Sun Java System Directory Server’s homephone attribute mapped to Active Directory’s othertelephone attribute. You could use the Active Directory attributes drop-down list to change the mapping to homephone.

  4. You can also add or remove attribute values:

    • To add a value, enter the information in the New Value field and click Add.

    • To remove a value, select the value from the list pane and click Remove.

  5. When you are done, click OK to apply your changes and close the Define Creation Mappings and Values dialog box.

  6. Click OK again to close the Creation Mappings and Attributes dialog box.

Removing Attributes

ProcedureTo Remove Creation Attributes Mapping or Values

  1. Select the Object Creation tab, and click the Creation Attributes button located under the selected creation option.

  2. When the Creation Mappings and Values dialog box is displayed, select the attribute from the table, and then click the Delete button.

    The attribute is removed from the table immediately.

  3. When you are done, click OK to close the Creation Mappings and Attributes dialog box.

Specifying How Object Modifications Flow

Use the Attribute Modification tab to control how modifications made to user attributes and passwords will be propagated (flow) between your Sun and Windows systems.

Figure 4–41 Attribute Modification Tab

Specify how attribute and password changes will flow
between Sun and Windows systems, synchronize inactivations, and specify inactivation
methods.

You use this tab to configure the following:


Note –

You cannot synchronize account statuses with Windows NT directory sources.


Specifying Direction

Select one of the following buttons to control how changes made in the Directory Server and Windows environments will be propagated between systems.

Configuring and Synchronizing Object Activations and Inactivations

If you enable the Synchronize Object Activations/Inactivations with Active Directory box you can synchronize object activations and inactivations (known as enables and disables on Active Directory) between Directory Server and Active Directory sources.


Note –

You cannot synchronize activations and inactivations with Windows NT directory sources.


Figure 4–42 Synchronizing Object Activations and Inactivations

Use this panel to specify how the program will detect
and synchronize activated and inactivated objects between Sun and Active Directory.

ProcedureTo Synchronize Object Activations/Inactivations:

  1. Enable the Synchronize Object Inactivations between Directory Server & Active Directory box.

  2. Enable one of the following buttons to specify how Identity Synchronization for Windows will detect and synchronize object activations and inactivations:

Interoperating with Directory Server Tools

Select this option if you use the Directory Server Console or command line tools to activate/inactivate an object. With this option selected Identity Synchronization for Windows cannot set or remove the nsAccountLock attribute directly. In addition, the program cannot detect objects that have been inactivated using other roles such as cn=nsdisabledrole, database suffix or roles that nest within other roles, such as cn=nsdisabledrole, database suffix or cn=nsmanageddisabledrole, database suffix .


Note –

If you enable the Interoperate with Directory Server Tools option, Identity Synchronization for Windows cannot set or remove the nsAccountLock attribute directly. In addition, Identity Synchronization for Windows cannot detect objects have been inactivated using other roles.

For example, cn=nsdisabledrole, database suffix or roles that nest within other roles such as cn=nsdisabledrole, database suffix or cn=nsmanageddisabledrole, database suffix.


Interoperating with Directory Server Tools describes how Identity Synchronization for Windows detects and synchronizes object activations/inactivations when you enable the Interoperate with Directory Server Tools option.

Table 4–1 Interoperating with Directory Server Tools

Activations 

Inactivations 

Identity Synchronization for Windows detects an activation only when the cn=nsmanageddisabledrole, database suffix role is removed from the object.

Identity Synchronization for Windows detects an inactivation only when the entry’s nsroledn attribute includes the cn=nsmanageddisabledrole, database suffix role.

When synchronizing an object activation from Active Directory, Identity Synchronization for Windows activates the object by removing the cn=nsmanageddisabledrole,database suffix role from the object.

When synchronizing an object inactivation from Active Directory, Identity Synchronization for Windows inactivates the object by adding the cn=nsmanageddisabledrole, database suffix role to the object.

Modifying Directory Server’s NsAccountLock Attribute Directly

Use this method when Directory Server activations and inactivations are based on Directory Server’s operational attribute, nsAccountLock.


Note –

When the Modify Directory Server’s nsAccountLock attribute option is enabled, Identity Synchronization for Windows will not detect objects that are activated/inactivated using the Directory Server Console or command line utilities.


This attribute controls object states as follows:

Table 4–2 Modifying Directory Server’s nsAccountLock Attribute Directly

Activation 

Inactivation 

Identity Synchronization for Windows detects an inactivated object only when the nsAccountLock attribute is set to true.

Identity Synchronization for Windows detects an activated object only when the nsAccountLock attribute is absent or set to false.

When synchronizing an object inactivation from Active Directory, Identity Synchronization for Windows removes the nsAccountLock attribute.

When synchronizing an object activation from Active Directory, Identity Synchronization for Windows sets the nsAccountLock attribute to true.

Using a Custom Method for Directory Server

Use this method when Directory Server activations and inactivations are controlled exclusively by an external application such as Sun Java System Access Manager (formerly Sun JES Identity Server).

When you configure a custom method for Directory Server, you must specify the following:


Note –

If you enable the Use custom method for Directory Server option, Identity Synchronization for Windows cannot lock objects out of the directory unless access to the directory is controlled by an external application, such as Access Manager.


To configure a Custom method for activations and inactivations, click the Configure button and the Configure Custom Method for Directory Server dialog box is displayed.

Figure 4–43 Configuring a Custom Method for Activations and Inactivations

Use this dialog to specify inactivation attributes and
to specify values the program can use to detect and set object states.

This dialog contains the following features:

ProcedureTo Configure Identity Synchronization for Windows to Detect and Synchronize Object States between Directory Server and Active Directory

  1. Select an attribute from the Activation state attribute drop-down list.

  2. Click the New button to add attribute values to the Value column of the table.

  3. Click in the State column next to each of the Value entries and when the drop-down list is displayed, select Activated or Inactivated.

    Figure 4–44 Selecting a State

    Specifying State.

    For example, if you were using Access Manager:

  4. Select the inetuserstatus attribute from the Activation state attribute drop-down list.

  5. Click the New button and enter active, inactive, and deleted attribute values to the Value column of the table.

  6. Click in the State column and select Activated or Inactivated for each value as follows:

    • No Value: Activated

    • active: Activated

    • inactive: Inactivated

    • deleted: Inactivated

    • All Other Values: Inactivated

    Based on this example, Using a Custom Method for Directory Server describes how Identity Synchronization for Windows will detect and synchronize activations/inactivations when you enable the Use Custom Method for Directory Server option (using the inetuserstatus example).

    Value 

    State 

    Result 

    No Value

    Activated 

    If the inetuserstatus attribute is missing or does not have a value, Identity Synchronization for Windows detects the object as activated.

    active

    Activated 

    If the attribute is active Identity Synchronization for Windows detects the object as activated.

    inactive

    Inactivated 

    If the attribute value is inactive Identity Synchronization for Windows detects the object as inactivated.

    deleted

    Inactivated 

    If the attribute value is deleted Identity Synchronization for Windows detects the object as inactivated.

    All Other Values

    Inactivated 

    If the attribute has a value, but that value is not specified in the table, Identity Synchronization for Windows detects the object as inactivated. 

    Setting Activations and Inactivations

    As you populate the Value and State table with entries, Identity Synchronization for Windows automatically populates the Activated value and Inactivated value drop-down lists as follows:

    • The Activated value list contains all values with an Activated status (for example No Value and active).

    • The Inactivated value list contains all values with an Inactivated status (for example inactive and deleted).

    • Neither list will contain the All Other Values value.

      Select a value from the Activated value and/or the Inactivated value drop-down lists to specify how Identity Synchronization for Windows will activate and/or inactivate an object when synchronizing from Active Directory.

    • Activated value: Controls the object’s active state.

      • No Value: If the object contains the active value, Identity Synchronization for Windows will set the state to activated in Directory Server.

      • active: If the object contains the active value, Identity Synchronization for Windows will set the state to activated in Directory Server.

    • Inactivated value: Controls the object’s active state.

      • inactive or deleted: Identity Synchronization for Windows will set the object’s state to inactive in Directory Server.

      • none: Not a valid setting. You must select a value.


      Note –

      You must specify an Inactivated value or your configuration will be invalid.


      Using a Custom Method for Directory Server illustrates a completed Configure Custom Method for Directory Server dialog box.

    Figure 4–45 Example: Completed Dialog

    Example of a completed Configure Custom Inactivation
Mechanism for Directory Server dialog box.

Specifying Configuration Settings for Group Synchronization

If you enable Group Synchronization between Directory Server and Active Directory, you can synchronize the creation of groups, deletion of groups, and the membership changes within that group .


Note –

Group Synchronization is not supported on Windows NT directory sources.


ProcedureTo Synchronize Groups:

  1. Under the Groups tab, select the Enable Group Synchronization check box.

  2. Select one of the following Group Synchronization methods to specify how Identity Synchronization for Windows will detect and synchronize various groups:

    • Domain Global Security

    • Domain Global Distribution

    Figure 4–46 Enable Group Synchronization

    Enable Group Synchronization and specify the way the
groups will flow from Directory Server to Active Directory.


    Note –

    For more information about Domain Global Security, Domain Global Distribution, and Active Directory; see the Microsoft Active Directory documentation.


Configure Identity Synchronization for Windows to Detect and Synchronize Groups Related Changes between Directory Server and Active Directory

You do not need to map any attribute manually for the group synchronization. When you press Save, Identity Synchronization for Windows maps the attributes automatically.

Figure 4–47 Attribute Mapping for Group Synchronization

Select the attributes that you want to synchronize and
click Save.


Note –
  1. Do not modify the mapping between the userpasswordand unicodepwd attributes.

  2. To disable the group synchronization, deselect the Disable Group Synchronization check box.

  3. Alternatively, you can enable or disable group synchronization using command line idsync groupsync. For more information, see Appendix A, Using the Identity Synchronization for Windows Command Line Utilities.


Configuring and Synchronizing Account Lockout and Unlockout

To enable the Account Lockout feature, you must do the following:

Identity Synchronization for Windows can synchronize the following events between Active Directory and Directory Server:


Note –

Account lockout and unlockout synchronization is not supported on Windows NT directory servers.


Prerequisites for Account Lockout

The attribute lockoutDuration should be set to the same value at both the places before enabling the account lockout feature. Make sure that the system time is also uniform across the distributed setup. Otherwise, the lockout events can expire if the lockoutDuration is less than the difference in the system dates.


Note –

Set the symmetric password policy at both ends. For example, if the password policy at Active Directory signifies a permanent lockout then the same password policy should be set at Directory Server.


Using the Account Lockout Feature

Enable Account Lockout Synchronization between Directory Server and Active Directory.

Use these settings to enable and disable the account
lockout synchronization.

No explicit mapping of the pwdaccountlockedtime (Directory Server) and lockoutTime (AD) attributes is required to enable account lockout. Select Enable Account Lockout Synchronization from the Account Lockout tab in Identity Synchronization for Windows configuration panel.

Select the attributes that you want to synchronize and
click Save
Note –

You can enable or disable the account lockout synchronization using command line tool idsync accountlockout. For more information, see Appendix A, Using the Identity Synchronization for Windows Command Line Utilities.


Specifying How Deletions Flow

Use Object Deletions tab to specify how deleted user entries should flow between Directory Server and Active Directory systems.


Note –

You cannot specify Object Deletions flow for Windows NT.


ProcedureTo Specify how Deleted Entries Flow Between Directory Server and Active Directory Systems

  1. Select the Identity Synchronization for Windows node at the top of the navigation pane, and then click the Object Deletion tab.

    Figure 4–48 Propagating User Entry Deletions

    Use this panel to control how deleted user entries  are
propagated between systems.

  2. Enable or disable the flow of deletions as follows:

    • Enable Object deletions flow from Sun Java System Directory Server to Active Directory to propagate deletions from the Sun Directory Server environment to your Active Directory servers.

    • Enable Object deletions flow from Active Directory to Sun Java System Directory Server to propagate deletions from the Active Directory environment to your Sun Directory Servers.

    • Enable both options for bidirectional flow.

    • Disable both options to prevent user deletions from propagating from one system to the other (Default setting).

Creating Synchronization User Lists

A Synchronization User List (SUL) specifies which users in Active Directory and Sun Directory Server will be synchronized. Every entry in the SUL passes through the Connector and is evaluated against the constraints you configured for that SUL.

Each SUL contains two elements, one to identify which Directory Server users to synchronize and one to identify which Windows users to synchronize.


Note –

To synchronize users in a Directory Server with multiple Active Directory domains, you must define one SUL for each Active Directory domain.

For more information about defining and configuring SULs (including components of a definition, how to define multiple SULs, how multiple SULs are processed, and how to configure multiple Windows domain support) refer to Appendix D, Defining and Configuring Synchronization User Lists for Identity Synchronization for Windows


Both of the SUL elements contain three definitions that identify which users to synchronize:

ProcedureTo Identify and Link User Types Between Servers

  1. Select the Synchronization User Lists node in the navigation tree, and then click New Synchronization User List button.

    Figure 4–49 Creating a New Synchronization User List

    Click the New Synchronization User List button to create
a new SUL.

    The Define a Synchronization User List wizard is displayed.

    Figure 4–50 Specifying a Name for Your SUL

    Provide a unique name for your Synchronization User List.

    The program default for your first Synchronization User List is SUL1.

    • If the default name is acceptable, click Next.

    • If you want to use a different name, type a different name into the Name field and then click Next.

    • Do not use spaces or any kind of punctuation in the SUL name.

    • You must specify a name that is unique within the system.

      The Windows Criteria panel is displayed.

    Figure 4–51 Specifying the Windows Criteria

    Specify Windows directory sources, Base DN, filters,
and creation expressions.

  2. Select a Windows Directory Source from the drop-down list.


    Note –

    You cannot edit the Active Directory or Directory Server directory sources included in this SUL after you click the Finish button to create the SUL. When the Group Synchronization feature is enabled, the creation expression would be uid=%uid% or cn=%cn% in the Sun Java System Directory Server Criteria panel.


  3. AUser Set Domainis the set of all the users to be synchronized. Enter the User Set Domain's Base DN, using one of the following methods:

    • Type the name into the text field (for example, DC=example,DC=com).

    • Click the Browse button, to open the Set Base DN dialog box so you can look for, and select a Base DN.

      All users under the specified Base DN will be included in this SUL, unless you explicitly exclude them using a filter.


      Note –

      Base DNs and creation expressions are not allowed for Windows NT machines.

      You cannot edit the Active Directory or Directory Server directory sources included in this SUL after you click the Finish button to create the SUL. When the Group Synchronization feature is enabled, then the creation expression should be uid=%uid% in the Sun Java System Directory Server Criteria panel.


    Figure 4–52 Selecting a Base DN

    Click on an entry in this list to select a Base DN.

  4. You can enter an equality, a presence, or a substring Filter to specify which users in this base DN are synchronized. For example, if you are using the same base DN for multiple synchronization user lists, you may want to use a filter to distinguish between them.

    The equality filter syntax is similar to LDAP query syntax, except that equality substrings allow *, &, |, =, ! characters only. For example, you can use the following filter to exclude the Administrator from your SUL:

    (!(cn=Administrator))

    The program should populate the Creation Expression field automatically.


    Note –

    A creation expression defines the parent DN and naming attribute used when new entries are propagated from Active Directory to Directory Server.

    A creation expression is not allowed for Sun directories unless you configured user attribute creations to flow from Active Directory to Directory Server. For more information, see Specifying How Object Creations Flow.


  5. If the creation expression is missing or you want to change the existing entry, you can enter a creation expression for all Windows Active Directory synchronization user lists; for example:

    cn=%cn% ,cl=users,dc=example,dc=com

    If you are going to change the creation expression, you must select an attribute that you will be synchronizing. If necessary, go back to the Object Creation tab and use the Creation Attribute button to add and map this attribute.

  6. Click Next to specify the Sun Java System Directory Server criteria.

  7. When the Specify the Sun Java System Directory Server Criteria panel is displayed repeat Step 2 through Step 5 to provide the Directory Server criteria.

    Figure 4–53 Specifying Directory Server Criteria

    Specify Sun Java System Directory Server directory sources,
Base DN, filters, and creation expressions.


    Note –

    You cannot edit the Active Directory or Directory Server directory sources included in this SUL after you click the Finish button to create the SUL.


  8. When you are done, click Finish.

  9. The program adds your new SUL node to the navigation tree and the Synchronization User List panel is displayed on the Configuration Tab.

    Figure 4–54 Synchronization List Panel

    Use the Synchronization List panel to edit your Windows
and Sun directory sources, Base DNs, filters, and creation expressions.

  10. In cases where a user matches multiple lists, click the Resolve Domain Overlap button to define a preference for the synchronization user list.

  11. Create a Synchronization User List that includes every directory source in your network except for the Directory Server.

Saving a Configuration

ProcedureTo Save your Current Configuration from the Console Panels

  1. Click Save to store your settings at this point.

  2. The Configuration Validity Status window is displayed as the program evaluates your configuration settings.

    Figure 4–55 Configuration Validity Status Window

    Showing configuration validity status

    This panel confirms that your configuration is valid or identifies configuration problems that must be fixed.

    Saving your configuration may take a few minutes because the program rewrites the information out to the configuration directory and notifies the system manager.

    The system manager (a Core component) is responsible for distributing your configuration settings out to the components that need the information.


    Note –

    Configuration validation errors are red and warnings are yellow.

    • You cannot save a configuration with errors.

    • You can save configurations with warnings, but it is better to try and clear the warnings first.


  3. If your configuration is valid, click Continue to save the configuration.

    A Connector Installation Instructions dialog box is displayed, giving instructions about how to proceed with installing the Identity Synchronization for Windows Connectors and subcomponents.

    This list has now been updated with a To Do list that is customized for your deployment. (Up to this point, the steps were generic.) Note that you can also access and update the To Do list from the Status tab on the Identity Synchronization for Windows Console.

    Figure 4–56 Instructions for Installing the Connectors

    Instructions for installing connectors and subcomponents.

  4. Read the information carefully and click OK.

    After finishing the initial Core configuration, you are ready to install the Identity Synchronization for Windows Connectors and subcomponents. Continue to Chapter 1, Understanding the Product for instructions.

Chapter 5 Installing Connectors

This chapter provides instructions for installing the Identity Synchronization for Windows Connectors. The information is organized as follows:

Identity Synchronization for Windows uses Connectors to synchronize user passwords between directory sources, and uses subcomponents to enhance the Connector’s change-detection and bidirectional synchronization support.

Before You Begin

Before starting the Connector configuring process, you should be aware of the following:

You must run the installation program each time you install a Connector.

For example, if you are installing a Directory Server Connector and an Active Directory Connector, you will run the installation program twice after the Core is installed.

Running the Installation Program

Repeat the following steps each time you install a Connector.

ProcedureTo Restart and Run the Installation Program

  1. Run the installation program again on the machine where you want to install the Connector, as follows:

    • On Solaris: Change to the installer directory and then type ./runInstaller.sh to execute the installation program.


      Note –

      To run the installation program in text-based mode, type ./runInstaller.sh -nodisplay.

      When you run the runInstaller.sh program, Identity Synchronization for Windows automatically masks passwords so they will not be echoed in the clear.


    • On Linux: Change to the installer directory and then type ./installer.sh to execute the installation program.


      Note –

      To run the installation program in text-based mode, type ./installer.sh -nodisplay.

      When you run the installer.sh program, Identity Synchronization for Windows automatically masks passwords so they will not be echoed in the clear.


    • On Windows: Change to the installer directory and then type setup.exe to execute the installation program.

  2. When the Welcome screen is displayed, read the information provided and then click Next to proceed to the Software License Agreement panel.

  3. Read the license agreement, then select

    • Yes (Accept License) to accept the license terms and go to the next panel.

    • No to stop the setup process and exit the installation program.

  4. The Sun Java System Directory Server panel is displayed. Specify the configuration directory location as follows:

    • Configuration Directory Host: Enter the fully qualified domain name (FQDN) of a Sun Java System Directory Server instance (affiliated with an Administration Server) where Identity Synchronization for Windows configuration information is stored. You must specify the same instance that you specified during the Core installation.

    • Configuration Directory Port ( Defaults to port 389): Specify a port for the configuration directory. You can leave the port set to the default or change to a different, available port.

      To enable SSL (Secure Socket Layer) between Core and the configuration directory, enable the Secure Port option and specify an SSL port ( default SSL port is 636). Enabling this option prevents sensitive information from being passed in the clear over the network.

    • Configuration Root Suffix: Select the root suffix that you specified during the Core installation from the menu. The Identity Synchronization for Windows configuration will be stored in this root suffix.


      Note –

      If the program could not detect a root suffix, and you enter the server information manually, you must click Refresh to repopulate the list of root suffixes.


  5. Click Next to open the Configuration Directory Credentials panel.

  6. Enter the configuration directory Administrator’s user ID and password.

    • If you specify admin as the user ID, you will not be required to specify the User ID as a DN.

    • If you use any other user ID, then you must specify the ID as a full DN. For example, cn=Directory Manager.


      Note –

      These credentials will be sent without encryption unless you enabled SSL in.


  7. Click Next to open the Configuration Password panel where you must enter the configuration password you specified when you installed Core.

    Also, if Core has not been installed on this machine, you will be prompted to provide the location of the Java Home directory (see Installing Core).

  8. When you are finished, click Next.


    Note –

    At this point, the installation process becomes specific to the type of Connector you are installing.


Installing Connectors

This section explains how to install the three types of Identity Synchronization for Windows Connectors, as follows


Note –

You are not required to install Connectors in any particular order, but do not attempt to install any Connectors simultaneously.


Installing the Directory Server Connector

After completing the steps described in Running the Installation Program

Figure 5–1 Selecting the Directory Server Connector

Select a connector to install

The Select components to install list contains only those Connector components that have not yet been installed. For example, after you install the Directory Server Connector (dc=example,dc=com), the program will remove the entry from the list pane.

The following table contains some example directory source entries.

Table 5–1 Directory Source Examples

Directory Source 

Example Entry 

Sun Java System Directory Server 

dc=example,dc=com

Windows Active Directory

example.com

Windows NT SAM 

EXAMPLE

ProcedureTo Install the Directory Server Connector

  1. Enable the button next to the Directory Server Connector component and then click Next.

    The Directory Server Connector Credentials panel is displayed.

    Provide your User DN and password for the primary Directory
Server, and for the secondary server (if applicable).
    Note –

    The program automatically completes the User DN fields with your fully qualified Directory Manager distinguished name, but you can change the information if necessary.


    Enter the following information:

    • Primary Directory Server User DN: If necessary, change the default user DN by entering a fully qualified Directory Manager distinguished name.

    • Primary Directory Server Password: Enter your Directory Manager password.

      If you are using a secondary master, the Secondary Directory Server User Name and Password fields will be active. The program automatically completes the Directory Manager DN field with the same entries provided for the Primary Directory Server User DN and Password fields. You can change this information if necessary.

      The program will verify that the Directory Server was prepared and ready to synchronize data. When you prepared Directory Server (Preparing Sun Directory Source), the program creates an account that the Connector will use to connect to Directory Server (for example, uid=PSWConnector,suffix).

  2. Click Next to proceed to the Connector Port Configuration pane.

    Enter your fully qualified local host name and a connector
port number.
  3. Enter the Fully Qualified Local Host Name with the domain and an available port number where the Connector will listen. (Specifying a port already in use will result in an error message.)

  4. Click Next and the Ready to Install pane is displayed to provide information about the Connector’s installation location and how much disk space is required for the installation. When you are ready, click the Install Now button.

    This pane reports which connector is being installed,
the directory location, and the amount of disk space required for the installation.
    Note –

    If you installed Core on the local machine, the Ready to Install pane will indicate that zero space is required to install the Connector. This situation occurs because the Core installation has already installed the Connector binaries. Because there are no additional binaries to install, no additional space is required.

    If you are installing the Connector on a machine other than where you installed Core, then the Ready to Install pane will indicate how much space is required to complete the Connector installation on the local machine.


    The Connector installation is accomplished in two steps:

    • An Installing pane is displayed, with a progress bar, while the program installs the binaries.

    • Next, the Component Configuration pane displays a progress bar. This step takes several minutes to complete.


      Note –

      If you did not close the Console before starting the installation, the following warning displays (Installing the Directory Server Connector). Click Reset in the Console to reload the Connector’s configuration settings.


      This pane reports which connector is being installed,
the directory location, and the amount of disk space required for the installation.

      When both steps are complete, an Installation Summary pane is displayed.


    Note –

    Directory Server plugin gets configured for preferred and secondary hosts (if any).


    Installation of Directory Server Plug-in
    Note –
    1. Clicking Yes configures the Directory Server plugin in all the hosts (preferred and secondary).

    2. Clicking No enables you to configure the plugin later using command line idsync dspluginconfig. For more information, see Appendix A, Using the Identity Synchronization for Windows Command Line Utilities.


  5. Click the Details button if you want to review the installation log.

    • On Solaris: Installation logs are written to /var/sadm/install/logs/

    • On Linux: Installation logs are written to /var/sadm/install/logs/

    • On Windows: Installation logs are written to the %TEMP% directory, which is usually a subdirectory of the Local Settings folder located underC:\Documents and Settings\Administrator


      Note –

      On some Windows systems (such as Windows 2000 Advanced Server), the Local Settings folder is a hidden folder.

      To view this folder and the Temp subdirectory, open your Windows Explorer and select Tools -> Folder Options from the menu bar. When the Folder Options dialog box is displayed, select the View tab and enable the Show Hidden Files option.


  6. Click Next to display the “To Do list” panel, which shows the list of successfully completed and pending steps.

    This panel reports which steps are finished and which
steps remain.
  7. When you are done with the panel, click Finished.

    After installing the Directory Server Connector, you can install other Connectors that you configured when you configured the resources (Chapter 4, Configuring Core Resources):

Configuring Identity Synchronization for Windows Plug-in when Chained Suffix exists

This configuration is needed only when the chained suffix exists in the Directory Server instance where Identity Synchronization for Windows Plug-in is installed. If Identity Synchronization for Windows Plug-in is not configured to search on chained suffix, MODIFY and BIND operations performed on the Directory Server where the Identity Synchronization for Windows Plug-in is installed, will fail.

In the Directory Server instance where the chained suffix is created, perform the following operations:

Execute the following LDIF script using ldapmodify utility:

dn: cn=config,cn=chaining database,cn=plugins,cn=config 
changetype: modify 
add: nspossiblechainingcomponents 
nspossiblechainingcomponents: cn=pswsync,cn=plugins,cn=config 

You can perform the similar operation by using the following procedure:

  1. Select the Configuration tab.

  2. Click the Data node that displays in the left pane.

  3. Select the Chaining tab in the right pane.

  4. Add Identity Synchronization for Windows Plug-in (cn=pswsync,cn=plugins,cn=config) to the components that are allowed to chain.

  5. Save the changes and exit.

Installing an Active Directory Connector

After you install the Directory Server Connector and if you have other configured Connectors to install, the installation program will give you the option of installing the Connectors before you see the Connector Configuration pane.

Figure 5–2 Selecting the Connector

Select a connector to install.

The component list contains only those Connector components that have not yet been installed. For example, if you already installed the Directory Server Connector (dc=example,dc=com in this case), it will not be listed.

ProcedureTo Install an Active Directory Connector

  1. Enable the Connector button and click Next.

    The Connector Configuration panel displays.

    Select a connector to install.

    The Select components to install list contains only those Connector components that have not yet been installed. For example, after you install the Directory Server Connector (dc=example,dc=com in this case), the program will remove the entry from this list pane.

  2. Enable the button next to the Active Directory component and then click Next.

    The Ready to Install pane is displayed to provide information about the Connector’s installation location and how much disk space is required for the installation.

    This pane reports which connector is being installed,
the directory location, and the amount of disk space required for the installation.
    Note –

    If you installed Core on the local machine, the Ready to Install pane will indicate that zero space is required to install the Connector. This situation occurs because the Core installation has already installed the Connector binaries. Because there are no additional binaries to install, no additional space is required.

    If you are installing the Connector on a machine other than where you installed Core, then the Ready to Install pane will indicate how much space is required to complete the Connector installation on the local machine.


  3. When you are ready, click the Install Now button.

    An Installing pane is displayed, with a progress bar, while the program installs the binaries, and then an Installation Summary pane is displayed to confirm the installation is finished.

  4. Click the Details button if you want to review the installation log.

    • On Solaris: Installation logs are written to /var/sadm/install/logs/

    • On Linux: Installation logs are written to /var/sadm/install/logs/

    • On Windows: Installation logs are written to the %TEMP% directory, which is a subdirectory of the Local Settings folder located underC:\Documents and Settings\Administrator


      Note –

      On some Windows systems (such as Windows 2000 Advanced Server), the Local Settings folder is a hidden folder.

      To view this folder and the Temp subdirectory, open your Windows Explorer and select Tools -> Folder Options from the menu bar. When the Folder Options dialog box is displayed, select the View tab and enable the Show Hidden Files option.


  5. Click Next to display the “To Do list” panel, which shows the list of successfully completed and pending steps.

    This panel reports which steps are finished and which
steps remain.
  6. When you are done with the panel, click Finished to exit the installation program.

    After installing the Active Directory Connector, you can install other Connectors that you configured when you configured resources (Chapter 4, Configuring Core Resources):

Installing the Windows NT Connector

You must install the Windows NT Connector on the Primary Domain Controller (PDC) of the domain you configured.

ProcedureTo Install a Windows NT Connector and the NT subcomponents

  1. Enable the Windows NT Connector button and click Next.

  2. When the Connector Port Configuration pane is displayed, enter the Fully Qualified Local Host Name with the domain and an available port number where the Connector will listen. (Specifying a port already in use will result in an error message.)

  3. When you are done, click Next.

    The Ready to Install pane is displayed to provide information about the Connector’s installation location and how much disk space is required.

  4. When you are ready, click the Install Now button.

    The Connector installation is accomplished in two steps:

    • An Installing pane is displayed, with a progress bar, while the program installs the binaries.

    • Next, the Component Configuration pane displays a progress bar. This step takes several minutes to complete.


      Note –

      If you did not close the Console before starting the installation, a warning displays (see Installing the Directory Server Connector). Click Reset in the Console to reload the Connector’s configuration settings.


      When both steps are complete, an Installation Summary pane is displayed.

  5. Click the Details button if you want to review the installation log.

    Installation logs are written to the %TEMP% directory, which is C:\TEMP on most Windows NT systems.

  6. Click Close to exit the installation program.

    After installing the Windows NT Connector, you can install other Connectors that you configured when you configured resources (Chapter 4, Configuring Core Resources):

Chapter 6 Synchronizing Existing Users and User Groups

The Identity Synchronization for Windows command line utility provides the idsync resync subcommand to bootstrap deployments with existing users or groups. This command uses administrator-specified matching rules to link existing entries, to populate an empty directory with the contents of a remote directory, or to bulk-synchronize attribute values (including passwords) between two existing user and group populations.

This chapter explains how to use the idsync resync subcommand and synchronize existing users and groups for new Identity Synchronization for Windows installations. In addition, this chapter provides instructions for starting and stopping synchronization and services. The information is organized as follows:


Note –

You must finish installing Core and the Connectors before trying to synchronize existing users.

For more information about the idsync resync subcommand, see Appendix A, Using the Identity Synchronization for Windows Command Line Utilities


Synchronizing Existing Users and User Groups summarizes the post-installation steps to follow based on existing user and group populations:

Post-Installation Steps Based on Existing User and Group Populations

Table 6–1 Post-Installation Steps Based on Existing User Populations

Users Exist In 

 

Post-Installation Steps 

 

Windows 

Directory Server 

Synchronize Existing Users 

Do NOT Synchronize Existing Users 

No 

No 

None 

None 

No 

Yes 

Run idsync resync -o Sun -c to create existing Directory Server users in Windows.

None 

Yes 

No 

Run idsync resync -c to create existing Windows users in Directory Server.

Run idsync resync -u to populate the connector’s local cache of user entries.

Yes 

Yes 

Run idsync resync -f <filename> -k to link the users only, and then run idsync resync -o Sun to resynchronize existing users from Directory Server.

Run idsync resync -u to populate the connector’s local cache of user entries.


Note –

If Group Synchronization is enabled then the groups are synchronized in the same way as the users are synchronized.


Using idsync resync

This section explains the synchronizing processes, describes the proper syntax for using the idsync resync subcommand, and explains how to verify that the processes completed successfully. The information is organized as follows:

Resynchronizing Users or Groups

You need to resynchronize the user entries when two directory sources become out of sync. Use the idsync resync command to create users, user groups, and synchronize user and user group attributes in two directory sources. Specifically, you can use the idsync resync command to populate an empty Directory Server with the existing Active Directory or Windows NT SAM domain users.

The idsync resync command can be used in any of the following ways:


Note –

You cannot use the idsync resync command to synchronize passwords (except to invalidate Directory Server passwords to force on-demand password synchronization in an Active Directory environment).


When the Group Synchronization feature is enabled, both the users as well as the groups associated with the users are synchronized between the data sources configured. No additional options are required while using the resync command for Group Synchronization.

Linking Users

After populating Active Directory and Directory Server with users and installing the Active Directory and Directory Server Connectors (before starting synchronization), you must use the idsync resync command to ensure that all existing users are linked in the two directory sources.

What is linking? Identity Synchronization for Windows correlates the same user on Directory Server and on Windows by storing the following unique, immutable identifiers:

Storing this immutable identifier allows Identity Synchronization for Windows to synchronize other key identifiers, such as uid and cn. The dspswuserlink attribute is populated when:

To link existing users, you must provide rules for matching users between the two directories. For example, to link a user entry in two directories, both the first names and last names must match in both directory entries.

Linking user entries and resolving data conflicts could be described as more art than science. There are many reasons why the idsync resync subcommand might fail to link two users in opposing directory sources and depends to a large extent on the consistency of the data in the linked directories.

One strategy for using idsync resync is to use the -n argument, which runs the operation in “ safe mode” so you can preview the effects of an operation with no actual changes. Running in safe mode allows you to refine the linking criteria gradually until you find an optimum set of user matching criteria.

However, you should be aware that there is a balance to be achieved through linkage accuracy and linkage coverage.

For example, if both directory sources contain an employee ID or social security number, you might begin with linking criteria that includes this number only. You might think that to improve linkage accuracy, you should include a last name attribute in the criteria as well. However, you could lose linkages because entries that would have matched on ID alone did not match because there were inconsistent last name values in the data. You will have to go through a data cleansing process for entries that fail to link.


Note –

If Group Synchronization is enabled then the groups are linked in the same way as the users are linked.


idsync resync Options

The idsync resync command accepts the following options.

Table 6–2 idsync resync Usage

Argument 

Meaning

-a <ldap-filter>

Specifies an LDAP filter to limit the entries to be synchronized. The filter will be applied to the source of the resynchronization operation. For example, if you specify idsync resync -o Sun -a “usid=*” all Directory Server users that have a uid attribute will be synchronized to Active Directory.

-l <sul-to-sync>

Specifies individual Synchronization User Lists (SULs) to resynchronize 

Note: You can specify multiple SUL IDs to resynchronize multiple SULs or, if you do not specify any SUL IDs, the program will resynchronize all of your SULs.

-o (Sun | Windows)

Specifies the source of the resynchronization operation 

  • Sun: Sets attribute values for Windows entries to corresponding attribute values in Sun Java System Directory Server directory source entries.

  • Windows: Sets attribute values for Sun Java System Directory Server entries to corresponding attribute values in Windows directory source entries.

    (Default is Windows)

-c

Creates a user entry automatically if the corresponding user is not found at destination 

  • Randomly generates a cryptographically secure password for users created in Active Directory or Windows NT.

  • Automatically creates a special password value ({PSWSYNC} *INVALID PASSWORD*) for users created in Directory Server (unless you specify the -i option)

    Note: Identity Synchronization for Windows will attempt to create users even if you have not configured creations in that direction. For example, if you have not configured Identity Synchronization for Windows to synchronize from Windows to Sun (or vice versa), but you specify the -c argument, Identity Synchronization for Windows will try to create users that are not found.

-i (ALL_USERS | NEW_USERS |)

Resets passwords for user entries synchronized in a Sun directory source, forcing password synchronization within the current domain for those users the next time the user password is required. 

  • ALL_USERS: Forces on-demand password synchronization for all synchronized users

  • NEW_USERS: Forces on-demand password synchronization for newly created users only

-u 

Updates the object cache. 

This argument updates the local cache of user entries for a Windows directory source only, which prevents existing Windows users from being created in Directory Server. If you use this argument, Windows user entries are not synchronized with Directory Server user entries. This argument is valid only when the resync source is Windows. 

-x 

Deletes all destination user entries that do not match a source entry. 

-n

Runs in safe mode so you can preview the effects of an operation with no actual changes. 

Table 6–3 Will idsync resync invalidate the user’s password on Directory Server?
 

User has an entry on Active Directory and on Directory Server that is linked. 

User has an entry on Active Directory and on Directory Server that are not linked. 

User has an entry on Active Directory, but not on Directory Server. 

-i ALL_USERS

Yes 

Yes 

Yes 

-i NEW_USERS

No 

No 

Yes 

No -i value

No 

No 

No 

The following table provides examples to illustrate the results of combining different arguments (The – h, -p, -D, -w, -, and -s arguments are defaulted and have been omitted for brevity).

Table 6–4 idsync resync Usage Samples

Arguments 

Result 

idsync resync

Displays a resync usage statement.

idsync resync -i ALL_USERS

Invalidates the passwords of all users to force on-demand password synchronization (valid in Active Directory environments only). 

In mixed environments (with both Active Directory and NT domains), you must explicitly list Active Directory SULs. 

idsync resync -c -i NEW_USERS

Creates users that are not found on Directory Server and invalidates their passwords to force on-demand password synchronization. Use this command to populate an empty Directory Server instance with existing Windows users. 

idsync resync -c -l SUL_sales
 -l SUL_finance

Creates all existing Active Directory users on Directory Server for the SUL_sales and SUL_finance SULs only (but does not force on-demand password synchronization). 

idsync resync -n

Runs in safe mode so you can preview the effects of the resync operation with no actual changes.

idsync resync -o Sun
 -a "(sn=Smith)"

Synchronizes all Directory Server users with the last name (sn) Smith, on Windows.

idsync resync -u

Updates the object cache for Windows Connectors only to prevent existing users from being created in Directory Server. No users are actually synchronized. 

idsync resync -f link.cfg

Links unlinked users based on linking criteria specified in the link.cfg file. Identity Synchronization for Windows does not create or modify users, but the Directory Server passwords of newly linked users will be set to the Active Directory users’ passwords.


Note –

When you use idsync resync to link users, be aware that you should use indexes for the operation. Non-indexes can affect performance.

If there are multiple attributes in the UserMatchingCriteria set, and at least one of them is indexed, then performance will probably be acceptable. However, if there are no indexes in UserMatchingCriteria, then performance will be unacceptable with a large directory.


Checking Results in the Central Log

The results of all idsync resync operations are reported in a special central log named resync.log. This log lists all of the users that were properly linked and synchronized, those that failed to link, and those that were previously linked.


Note –

Some pre-existing special Active Directory users (such as Administrator and Guest) might appear in this log as failures.


Starting and Stopping Synchronization

Starting and stopping synchronization does not start or stop individual Java processes, daemons, or services. Once you begin synchronization, stopping synchronization only pauses the operation. When you restart synchronization, the program resumes synchronization from where it stopped and no changes will be lost.

ProcedureTo Start or Stop Synchronization

  1. In the Sun Java System Server Console navigation pane, select the Identity Synchronization for Windows instance.

  2. When the Identity Synchronization for Windows pane is displayed, click the Open button in the upper right corner.

  3. When you are prompted, enter the configuration password.

  4. Select the Tasks tab.

    Figure 6–1 Starting and Stopping Synchronization

    Start or stop the synchronization service.

    • To start synchronization, click Start Synchronization.

    • To stop synchronization, click Stop Synchronization.


    Note –

    You can also start and stop synchronization using the idsync startsync and idsync stopsync command line utilities. For detailed instructions, see Using startsync and Using stopsync


Resynchronized Users/Groups

To resynchronize groups, the Group Synchronization feature must be enabled either through the console or through the command line interface.

To know about how to enable the Group Synchronization feature, see Specifying Configuration Settings for Group Synchronization

Starting and Stopping Services

Identity Synchronization for Windows and Message Queue are installed as daemons on Solaris and Linux, and as services on Windows. These processes start automatically when the system boots, but you can also start and stop them manually, as follows:

Chapter 7 Removing the Software

This section contains procedures for removing Identity Synchronization for Windows 6.0 in the following sections:

Planning for Uninstallation

Before removing the software keep in mind the following points:


Note –

You must follow the instructions for uninstalling product components and subcomponents explicitly, and verify that you have uninstalled all components successfully.


Uninstalling the Software

Your system may contain any or all of the following Identity Synchronization for Windows components:

This section provides instructions for the following:

Uninstalling Connectors

ProcedureTo Uninstall the Connectors

  1. Start the uninstaller program (runUninstaller.sh on Solaris, uninstaller.sh on Linux, or uninstall.cmd on Windows).

    These programs are located in the installation directory (which is the /opt/SUNWisw directory by default).

  2. At the Welcome screen click Next.

  3. Enter the Configuration Directory Host name and Port number.

    • Select the root suffix of the configuration directory. (If necessary, click Refresh to see the list of suffixes.)

    • For secure communication between the uninstall program and the configuration directory server, enable the Secure Port box and specify the Directory Server’s SSL port number.

  4. Enter your administrator’s name and password for the configuration directory.

  5. Select the connector(s) to be uninstalled.


    Note –

    The selected connectors must be present on the target host.


  6. Click Next to perform further uninstallation related tasks.

  7. A summary window appears. Please follow the instructions presented in this window.

    • On Solaris systems: Uninstallation logs are written to /var/sadm/install/logs/

    • On Linux systems: Uninstallation logs are written to /var/sadm/install/logs/

    • On Windows systems: Uninstallation logs are written to the %TEMP% directory, which is a subdirectory of the Local Settings folder located in

      C:\Documents and Settings\Administrator


      Note –

      On some Windows systems such as Windows 2000 Advanced Server, the Local Settings folder is a hidden folder. To view this folder and the Temp subdirectory:

      Open your Windows Explorer and select Tools -> Folder Options from the menu bar. When the Folder Options dialog box is displayed, select the View tab and enable the Show Hidden Files option.


  8. Click Close to exit the program.

  9. If there are no other connectors installed on the target host, then you can safely remove the isw-hostname folder.

  10. Repeat Uninstalling Connectors for all hosts where connectors are installed.

ProcedureTo Uninstall Core


Note –

You must uninstall the Directory Server Plug-in before you uninstall Core.

Uninstalling Core before the Plug-in removes the Plug-in bits without unregistering them from the Directory Server, which will prevent the Directory Server from starting unless you manually remove cn=pswsync,cn=plugins,cn=config.


Use the following instructions to uninstall Core:

  1. Start the uninstaller program:

    • On Windows machines:

      1. Click Start, and then choose Settings -> Control Panel.

      2. Double-click Add/Remove Programs.

      3. In the Add/Remove Programs window, select Identity Synchronization for Windows, then click Remove.

    • Execute runUninstaller.sh on Solaris, uninstaller.sh on Linux, or uninstall.cmd on Windows.

      These programs are located in the installation directory (which is the /opt/SUNWisw directory on Solaris and /opt/sun/isw directory on Linux by default).

  2. In the Welcome screen click Next.

  3. Enter the Configuration Directory Host name and Port number.

    1. Select the root suffix of the configuration directory. (If necessary, click Refresh to see the list of suffixes.)

    2. For secure communication between the uninstall program and the configuration directory server, enable the Secure Port box and specify the Directory Server’s SSL port number.

  4. Enter your administrator’s name and password for the configuration directory.

  5. Select Core to be uninstalled and click Next.

  6. Enter the configuration directory URL, click Refresh, and select the appropriate root suffix from the drop-down list.

  7. Click Next to perform further uninstallation related tasks.

  8. A summary window appears. Please follow the instructions presented in this window.

    1. On Solaris systems: Uninstallation logs are written to /var/sadm/install/logs/

    2. On Linux systems: Uninstallation logs are written to /var/sadm/install/logs/

    3. On Windows systems: Uninstallation logs are written to the %TEMP% directory, which is a subdirectory of the Local Settings folder located under

      C:\Documents and Settings\Administrator


    Note –

    On some Windows systems (such as Windows 2000 Advanced Server), the Local Settings folder is a hidden folder.

    To view this folder and the Temp subdirectory:

    Open your Windows Explorer and select Tools -> Folder Options from the menu bar. When the Folder Options dialog box is displayed, select the View tab and enable the Show Hidden Files option.


  9. Click Close to exit the program.


    Note –

    If you are unable to run the connector uninstaller for a given connector for any reason (for example, if you lost the connector files during a hard drive failure), use the idsync resetconn subcommand (see Using resetconn).

    This command resets the connector state in the configuration directory to uninstalled so that you can reinstall it elsewhere. The resetconn subcommand is similar to other commands that access the configuration directory, and it provides two options:

    • -e dir-source: Specifies the name of the directory source to be reset. (Connectors are identified in the installers by their directory source name.)

    • -n (safe mode): Indicates whether the arguments specified for the command are correct without doing any work.

      Example command:


      idsync resetconn -D “cn=Directory Manager”-w [-h CR-hostname]
      [-p 389] [-s dc=example,dc=sun,dc=com] -q [-Z] [-P “cert8.db“]
       [-m “secmod.db“] -e “dc=central, dc=example,dc=com“ [-n]

      resetconn Output:


      NOTICE: This program will reset the installation state
      to UNINSTALLED for the Connector associated with the 
      specified DirectorySource ’dc=central,dc=example,dc=com’.
      Changing the Connector to an UNINSTALLED state is a 
      last resort. This is NOT meant to be used for 
      uninstalling connectors.It is typically used if you 
      lost a machine with the connector on it and can not 
      run the uninstaller.  Additionally, this program will
      rewrite the existing configuration. This can be a 
      lengthy process. Before proceeding, you should stop 
      the Console, any running installers, and all other 
      system processes. You may want to export the ou=Services 
      tree in the configuration directory to ldif as a backup.
      Do you want to reset the installer settings
      for the connector (y/n)?

Uninstalling the Console Manually

After you have removed all other Identity Synchronization for Windows components, you may have to manually uninstall the Console.

From Solaris or Linux Systems

ProcedureTo Uninstall the Console from Solaris or Linux

  1. Delete the following subtree from the configuration directory:


    cn=Sun Java (TM) System Identity Synchronization for Windows,
    cn=server_group,cn=hostname,
    ou=domain_ name, o=netscaperoot
  2. For all console installations, remove all of the .jar files with an isw prefix from the following directory:


    serverroot/server/java/jars

From Windows Systems

ProcedureTo Uninstall the Console from a Windows Active Directory or NT system

  1. Delete the following subtree from the configuration directory:


    cn=Sun Java (TM) System Identity Synchronization for Windows,
    cn=server_group, cn=hostname,
    ou=domain_name, o=netscaperoot
  2. For all console installations, remove all of the .jar files with an isw prefix from the following directory:


    serverroot/server/java/jars

Chapter 8 Configuring Security

This chapter provides important information about configuring security for your deployment. The information is organized as follows:


Note –

This chapter assumes that you are familiar with the basic concepts of public-key cryptography and Secure Sockets Layer (SSL) protocol, and that you understand the concepts of intranet, extranet, Internet security, and the role of digital certificates in an enterprise. If you are new to these concepts, please refer to the security-related appendixes of the Managing Servers with iPlanet Console 5.0 manual.


Security Overview

Passwords are sensitive information; therefore, Identity Synchronization for Windows takes security precautions to ensure that user and administrative password credentials used to access the directories being synchronized are not compromised.

This section covers the following security methodologies:

This security approach aims to prevent the following events from taking place:

Specifying a Configuration Password

To protect sensitive information while it is stored in the product’s configuration directory and while it is transferred over the network, Identity Synchronization for Windows uses a configuration password. You (the administrator) specify a configuration password when you install Core, and you must provide this password when you open the Console or run the Identity Synchronization for Windows installation program.


Note –

The system manager must access the configuration password before passing it to the connector; consequently, the system manager stores this password in its initialization file.

File system access controls prevent non-privileged users from accessing the system manager’s initialization file. The Identity Synchronization for Windows installation program does not enforce a password policy for this password.

To increase security when you select a configuration password, see Hardening Your Security.


Using SSL

You can configure Identity Synchronization for Windows to use LDAP over SSL everywhere that components use LDAP. All access to Message Queue is protected with SSL.

You must use SSL between the Active Directory Connector and Active Directory when you are synchronizing from Directory Server to Active Directory.

Requiring Trusted SSL Certificates

By default, connectors configured to use SSL will accept any SSL certificate that the server (i.e. Directory Server or Active Directory) returns — which includes untrusted, expired, and invalid certificates. All network traffic between the connector and server will be encrypted, but the connector will not detect a server that is impersonating the true Active Directory or Directory Server.

To force the connector to accept only trusted certificates, use the Console to enable the Require trusted SSL certificates option on the Specify Advanced Security Options panel of the Directory Source Configuration wizard (see Creating an Active Directory Source). After enabling this option, you must add the appropriate CA certificates to the connector’s certificate database as reported by idsync certinfo.

Generated 3DES Keys

A 3DES key generated from the configuration password is used to secure all sensitive information in the product’s configuration directory. With the exception of log messages, all messages to the Message Queue are encrypted with per-topic 3DES keys. Messages sent between connectors and subcomponents are encrypted with per session 3DES keys. The Directory Server Plug-in encrypts all user password changes with a 3DES key.

SSL and 3DES Keys Protection Summary

SSL and 3DES Keys Protection Summary summarizes how Identity Synchronization for Windows protects sensitive information that is sent over the network.

Table 8–1 Protecting Sensitive Information Using Network Security

Use this Protection Method 

Between the Following Information Types: 

LDAP over SSL (optional) 

  • Directory Server Connector and Directory Server, Active Directory Connector and Active Directory

  • Directory Server Plug-in and Active Directory

  • Command line interfaces and the product’s configuration directory

  • Console and the product’s configuration directory

  • Console and Active Directory Global Catalog

  • Console and Active Directory domains or Directory Servers being synchronized

  • Message Queue broker and the product’s configuration directory

  • Connectors, system manager, central logger, command line interfaces, and Console may authenticate the Message Queue over LDAPS

  • Installer and the Configuration Directory Server

  • Installer and Active Directory

  • Installer and the Directory Server being synchronized

Encrypted with 3DES keys (default)

  • Directory Server Connector and Directory Server Plug-in (all data)

  • Windows NT Connector, Windows NT Password Filter DLL, and Windows NT Change Detector (all data)

  • All sensitive information in the product’s configuration directory

  • All messages sent between connectors and subcomponents (encrypted with per-session 3DES keys)

  • All (non-log) messages sent over Message Queue

SSL and 3DES Keys Protection Summary contains an overview of the security features discussed in this section.

Figure 8–1 Security Overview for Identity Synchronization for Windows

Physical deployment of Identity Synchronization for Windows
Components

Message Queue Access Controls

Identity Synchronization for Windows uses Message Queue’s access control to prevent unauthorized access to message subscription and publishing, allowing each connector to trust messages that it receives.

Unique username and passwords known only to Message Queue and to the connector are provided to access the Message Queue broker. Each message sent over the Message Queue is encrypted with a per topic 3DES key, which protects the message contents and prevents outsiders who do not know the topic key from sending meaningful messages. These measures prevent (a) an attacker from sending falsified password synchronization messages to connectors and (b) an attacker from impersonating a connector and receiving actual password updates.


Note –

By default, clients of the Message Queue, such as the connectors and system manager, accept any SSL certificate that the Message Queue broker returns. See Hardening Your Security for more information to enhance Message Queue certificate validation and other Message Queue-related security issues.


Directory Credentials

Privileged credentials are required by the connectors to change passwords in Active Directory and the Directory Servers being synchronized. These privileged credentials are encrypted before they are stored in the product’s configuration directory.

Persistent Storage Protection Summary

Persistent Storage Protection Summary summarize how Identity Synchronization for Windows protects sensitive information that is stored on disk.

Table 8–2 Persistent Storage Protection

Persistent Storage 

Confidential Information 

Protection 

Product’s Configuration Stored in a Configuration Directory Server 

Credentials for accessing the directories and per Message Queue topic 3DES keys are stored in the product’s configuration directory. 

All sensitive information stored in the product’s configuration directory is encrypted with a 3DES key that is generated from the configuration password. See Hardening Your Security for recommendations to further protect the product’s configuration directory.

Directory Server Retro Changelog 

The Directory Server Plug-in captures password changes and encrypts them before writing them to the Directory Server Retro Changelog. 

The Directory Server Plug-in encrypts all user password changes with a 3DES key that is unique to each deployment. 

Message Queue Broker Persistent Storage 

The Message Queue broker stores password synchronization messages sent between all connectors. 

With the exception of log messages, all persisted messages are encrypted with per-topic 3DES keys. 

Message Queue Broker Directory Credentials 

The Message Queue broker authenticates users against the product’s configuration directory. It connects to the configuration directory using the directory administrative user name and password provided during Core installation. 

The directory password is stored in a passfile, which is protected with file system access controls. 

System Manager Boot File 

The system manager’s boot file contains information for accessing the configuration. This includes the configuration password and the directory administrative user name and password provided during Core installation. 

This file is protected with file system access controls. 

Connectors and Central Logger Boot Files 

Each connector as well as the central logger have an initial configuration file with credentials for accessing the Message Queue. 

These files are protected with file system access controls. 

Directory Server Plug-in Boot Configuration 

The Plug-in’s configuration, stored in cn=config, includes credentials for connecting to the connector.

The cn=config subtree is protected with ACIs and the dse.ldif file, which mirrors this tree, is protected with file system access controls.

NT Password Filter DLL and NT Change Detector Boot Configuration 

The NT subcomponent’s configuration, which is stored in the Windows registry, includes credentials for connecting to the connector. 

If access to the PDCs registry is not secure, these registry keys can be protected with access controls. 

Windows Connector’s Object Cache 

Windows connectors store hashed user passwords in the connector’s object cache. 

The passwords are not stored in the clear but encrypted with MD5 hashes. These database files are protected with file system access controls. (see Hardening Your Security

Hardening Your Security

This section depicts potential security weaknesses in the current release of the product and recommendations as to how to extend and harden security outside the product’s default configuration. It includes the following:

Configuration Password

The configuration password is used to protect sensitive configuration information but the installation program does not enforce any password policy for this password; be sure that this password follows some strict guidelines choose a complex password that is not easily guessed and follow standard policy guidelines for strong passwords.

For example, it should be at least eight characters long, include upper case letters, lower case letters, and non-alphanumeric characters. It should not include your name, initials, or dates.

Creating Configuration Directory Credentials

To access the Directory Server where the product’s configuration directory resides, your credentials must be in the Configuration Administrators group. However, if you need to create credentials other than admin for any reason, consider the following:

The installation program requires you to provide credentials for a user stored in the Console administrative subtree. However, the Core installation program will not expand users other than admin into “uid=admin,ou=Administrators, ou=TopologyManagement, o=NetscapeRoot”. Therefore, you must specify the entire DN during Core installation.

ProcedureTo Create a New User Other Than admin

  1. Create a user in:


    ou=Administrators, ou=TopologyManagement, o=NetscapeRoot
  2. Add the new credentials to the Configuration Administrators group.

  3. Set ACIs to allow only this user or all users in the Configuration Administrators group to access the Directory Server where the product’s configuration directory is stored.

  4. Specify entire DN during Core installation.

    For more information about managing access controls in the Directory Server, see Chapter 6, Directory Server Access Control, in Sun Directory Server Enterprise Edition 7.0 Administration Guide

Message Queue Client Certificate Validation

By default, clients of the Message Queue, such as the connectors and system manager, accept any SSL certificate that the Message Queue broker returns.

ProcedureTo Validate the Message Queue Client Certificate

  1. To override this setting and force Message Queue clients to validate the Message Queue broker’s certificate, edit:

    installation_root/resources/WatchList.properties

  2. Add the following to the JVM arguments of each process in Watchlist.properties :

    -Djavax.net.ssl.trustStore=keystore_path-DimqSSLIsHostTrusted=false

  3. Restart the Identity Synchronization for Windows daemon or service.

    The javax.net.ssl.trustStore property should point to a JSEE keystore that trusts the broker certificate, for example, /etc/imq/keystore can be used on the machine where Core was installed because this is the same keystore used by the broker.

Message Queue Self-Signed SSL Certificate

By default, the Message Queue broker uses a self-signed SSL certificate. To install a different certificate, use the keytool utility that ships with Java to modify the broker’s keystore (/var/imq/instances/isw-broker/etc/keystore on Solaris, /var/opt/sun/mq/instances/isw-broker/etc/keystore on Linux, and mq_installation_root /var/instances/isw-broker/etc/keystore on Windows 2000). The alias of the certificate must be imq.

Access to the Message Queue Broker

By default, the Message Queue uses dynamic ports for all services except for its port mapper. To access the broker trough a firewall or restrict the set of hosts that can connect to the broker, the broker should use fixed ports for all services.

This can be achieved by setting the imq.service_name protocol_type .port broker configuration properties. Refer to the Sun Java System Message Queue Administration Guide for more information.

Configuration Directory Certificate Validation

The system manager accepts any certificate when connecting to the product’s configuration directory over SSL; the Message Queue broker accepts any certificate when connecting to the product’s configuration directory over SSL. Currently, there is no way to make either the system manager or the Message Queue broker validate the product’s configuration directory SSL certificates.

Restricting Access to the Configuration Directory

When Core is installed, the process of adding information to the Directory Server where the product’s configuration directory is stored does not include adding any access control information. To restrict access to only configuration Administrators, the following ACI can be used:

(targetattr = "*")
(target = "ldap://ou=IdentitySynchronization,
ou=Services,dc=example,dc=com")
(version 3.0;acl "Test";deny (all)
(groupdn != "ldap://cn=Configuration Administrators,
ou=Groups, ou=TopologyManagement, o=NetscapeRoot");)

For more information about managing access controls in the Directory Server, see Chapter 6, Directory Server Access Control, in Sun Directory Server Enterprise Edition 7.0 Administration Guide

Securing Replicated Configurations

Deployments connecting to Directory Servers using replication follow the same rules identified in Security Overview. This section gives an example replicated configuration and explains how to enable use of SSL in this configuration.


Note –

For an overview of planning, deploying, and securing replicated configurations see Appendix D, Defining and Configuring Synchronization User Lists for Identity Synchronization for Windows


Securing Replicated Configurations lists the configuration components requiring CA certificates and identifies which certificates are required where.

Table 8–3 MMR Configuration Components Requiring CA Certificates

Component 

Required CA certificates 

Preferred Directory Server Replicated Master 

Active Directory System 

Secondary Directory Server Replicated Master 

Active Directory System 

Read-only Directory Server Hub(s) 

Preferred Directory Server Replicated Master 

Secondary Directory Server Replicated Master 

Directory Server Connector 

Preferred Directory Server Replicated Master 

Secondary Directory Server Replicated Master 

Active Directory Connector

Active Directory System 

Replicated configuration shows Identity Synchronization for Windows installed in an MMR configuration, where there are two replicated Directory Server masters with multiple Directory Server read-only hubs or consumers. Each Directory Server has a Plug-in and there is only one Directory Server Connector, one Active Directory system, and one Active Directory Connector.

Figure 8–2 Replicated Configuration

Replicated deployment of Identity Synchronization for
Windows Components

When the Directory Server source is configured for SSL, you must make sure that both the preferred and secondary Directory Server certificates are trusted by the replica Directory Server. This is true for every Directory Server Plug-in of type other that you install on a system with a Directory Server hub or read-only replica.


Note –

Directory Server Plug-ins have access to the same CA certificates as its associated Directory Server.

The above diagram is specific to two Directory Server masters. But you can extended this to contain multiple masters.


Using idsync certinfo

Use the idsync certinfo utility to determine what certificates are required based on the current Identity Synchronization for Windows SSL settings. Execute idsync certinfo to retrieve information about what certificates are required in each certificate database.


Note –

You must be sure that when you are configuring the Directory Server source for SSL, both the preferred and secondary Directory Server source certificates are trusted by the replica Directory Server for all Directory subcomponents or Plug-ins.

If Identity Synchronization for Windows tries to establish SSL connections (with the trust all certificates setting enabled), and the server’s hostname does not match the hostname provided in the certificate presented by the server during the SSL negotiation phase, the Identity Synchronization for Windows Connector will refuse to establish the connection.

The directory source hostname in the Identity Synchronization for Windows configuration must always match the hostname embedded in the certificate used by that directory source.


Arguments

Arguments describes the arguments you can use with the idsync certinfo subcommand.

Table 8–4 certinfo Arguments

Argument 

Description 

-h CR-hostname

Specifies the configuration directory hostname. This argument defaults to the values specified during Core installation. 

-p CR-port-no

Specifies the configuration directory LDAP port number. (Default is 389)

-D bind-DN

Specifies the configuration directory bind distinguished name (DN). This argument defaults to the values specified during Core installation. 

-w bind-password | -

Specifies the configuration directory bind password. The - value reads the password from standard input (STDIN).

-s rootsuffix

Specifies the configuration directory rootsuffix. Where rootsuffix is a distinguished name such as dc=example,dc=com. This argument defaults to the values specified during Core installation.

-q configuration_password

Specifies the configuration password. The - value reads the password from standard input (STDIN).

Usage

The following example uses idsync certinfo to search for system components designated to run under SSL communications. The results of this example identifies two connectors (CNN101 and CNN100) and provides instructions as to where to import the appropriate CA certificate.


:\Program Files\Sun\MPS\isw-
hostname\bin idsync certinfo -h
CR-hostname -p 389 -D 
"cn=Directory Manager" -w dirmanager -s dc=example,dc=com
 -q password
Connector: CNN101
Certificate Database Location: C:\Program Files\Sun\MPS\isw-
hostname\etc\CNN101
Get ’Active Directory CA’ certificate from Active Directory 
and import into Active Directory Connector certificate db
for server ldaps::/
hostname.example.com:636
Connector: CNN100 Certificate Database Location:
C:\Program Files\Sun\MPS\isw-
hostname\etc\CNN100
Export ’Directory Server CA’ certificate
from Directory Server certificate db and
import into Directory Server Connector certificate db
ldaps://hostname.example.com:636
Export ’Active Directory CA’ certificate
from Active Directory Server
hostname.example.sun.com:389 
and import into Directory Server Server certificate db
for server ldaps://hostname.example.com:638
SUCCESS

Enabling SSL in Directory Server

Follow these steps to enable SSL in a Directory Server using a self-signed certificate.


Note –

These abbreviated procedures are for your convenience. Refer to the Sun Directory Server Enterprise Edition 7.0 Administration Guide for more information.


ProcedureTo Enable SSL in Directory Server

Refer to the following procedure to enable SSL in Directory Server:

  1. Create a DS instance

    /opt/SUNWdsee/ds6/bin/dsadm create -p non-ldap-port-P ldap-secure-port <DS-server-root>/slapd-<hostname>

  2. Start the instance

    /opt/SUNWdsee/ds6/bin/dsadm start <DS-server-root>/slapd-<hostname>

  3. Create a self-signed certificate

    /opt/SUNWdsee/ds6/bin/dsadm add-selfsign-cert -S "cn=<machine name with domain>,O=<preferred root suffix>"/<DS-server-root>/slapd-<hostname>/<certificate name>

    Where S = Create an individual certificate and add it to database, the second variable represents the path of Directory Server instance and the last variable is for the certificate alias.

  4. Set the server properties to this certificate

    /opt/SUNWdsee/ds6/bin/dsconf set-server-prop -p non-ldap-port ssl-rsa-cert-name:<certificate name>

  5. Restart the DS

    /opt/SUNWdsee/ds6/bin/dsadm restart /<DS-server-root>/slapd-<hostname>/

  6. Now stop the DS and remove the default certificate (this ensures that the above generated certificate will be the default certificate)

    /opt/SUNWdsee/ds6/bin/dsadm stop /<DS-server-root>/slapd-<hostname>/

  7. Now remove the default certificate

    /opt/SUNWdsee/ds6/bin/dsadm remove-cert /<DS-server-root>/slapd-<hostname>/ defaultCert

    where the first variable represents the slapd-path and the second variable represents the alias of the certificate. In case you want to export the above default certificate, following is the command

    /opt/SUNWdsee/ds6/bin/dsadm export-cert -o /<any path>/slapd-cert.export /<DS-server-root>/slapd-<hostname>/ <original default cert alias>

    where o=output file (/<any path>/slapd-cert.export), the second variable represents the slapd-path and the third variable represents the certificate alias.

Retrieving the CA Certificate from the Directory Server Certificate Database

Ensure that you have enabled SSL in Directory Server. To export the Directory Server certificate to a temporary file so that you can import it into the certificate database of the Directory Server Connector, issue the following command:

<ISW-server-root>\shared\bin\certutil.exe -L -d . 
-P slapd-hostname- -n server-cert -a \ > C:\s-cert.txt

ISW-server-root is the path where ISW-hostname directory is present.

These examples are run in the alias directory immediately below the server root. Otherwise, Directory Server will not find the certificate database.

Retrieving the CA Certificate from the Directory Server (using dsadm command on Solaris platform)

Ensure that you have enabled SSL in Directory Server. To retrieve the CA certificate issue the following command:

/opt/SUNWdsee/ds6/bin/dsadm export-cert -o /<any path>
/slapd-cert.export /<DS-server-root>/slapd-<hostname>/
<original default cert alias>

Enabling SSL in the Active Directory Connector

Identity Synchronization for Windows automatically retrieves Active Directory SSL certificates over SSL and imports them into the Connector’s certificate database using the same credentials you provided for the Connector.

However; if an error occurs (for example, invalid credentials or no SSL certificates were found), you can retrieve an Active Directory CA certificate and add it to the Connector certificate database. See the following sections for instructions:

Retrieving an Active Directory Certificate

If an error occurs, you can use certutil (a program that ships with Windows 2000/2003) or LDAP to retrieve an Active Directory certificate, as described in the following sections.


Note –

The certutil command discussed in this section is not the same as the certutil command that ships with the Directory Server and discussed previously in this publication.


Using Window’s Certutil

ProcedureTo Retrieve an Active Directory Certificate Using the certutil program

  1. Run the following command from the Active Directory machine to export the certificate.


    C:\>certutil -ca.cert cacert.bin
  2. You can then import thecacert.bin file into a certificate database.

Using LDAP

ProcedureTo Retrieve an Active Directory Certificate using LDAP

  1. Execute the following search against Active Directory:


    ldapsearch -h CR-hostname -D administrator_DN -w administrator_password 
    -b "cn=configuration,dc=put,dc=your,dc=domain,dc=here" "cacertificate=*"

    Where the administrator_DN might look like:


    cn=administrator,cn=users,dc=put,dc=your,dc=domain,dc=here

    In this example, the domain name is: put.your.domain.name.here.

    Several entries will match the search filter. You probably need the entry using cn=Certification Authorities, cn=Public Key Services in its DN.

  2. Open a text editor and cut the first value of the first CA certificate attribute (it should be a base64 encoded text block). Paste that value (text block) into the text editor (only the value). Edit the contents, so that none of the lines start with white space.

  3. Add-----BEGIN CERTIFICATE----- before the first line and -----END CERTIFICATE----- after the last line. See the following example:


    -----BEGIN CERTIFICATE-----
    MIIDvjCCA2igAwIBAgIQDgoyk+Tu14NGoQnxhmNHLjANBgk
    qhkiG9w0BAQUFADCBjjEeMBwGCSqGSIb3DQEJARYPYmVydG
    9sZEBzdW4uY29tMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV
    FgxDzANBgNVBAcTBkF1c3RpbjEZMBcGA1UEChMQU3VuIE1p
    Y3Jvc3lzdGVtczEQMA4GA1UECxMHaVBsYW5ldDEUMBIGA1U
    EAxMLUmVzdGF1cmFudHMwHhcNMDIwMTExMDA1NDA5WhcNMT
    IwMTExMDA1OTQ2WjCBjjEeMBwGCSqGSIb3DQEJARYPYmVyd
    G9sZEBzdW4uY29tMQswCQYDVQQGEwJVUELMAkGA1UECBMCV
    FgxDzANBgNVBAcTBkF1c3RpbjEZMBcGA1UEChMQU3VuIE1p
    Y3Jvc3lzdGVtczEQMA4GA1UECxMHaVBsYW5ldDEUMBIGA1U
    EAxMLUmVzdGF1cmFudHMwXDANBgkqhkiG9w0BAQEFAANLAD
    BIAkEAyekZa8gwwhw3rLK3eV/12St1DVUsg31LOu3CnB8cM
    HQZXlgiUgtQ0hm2kpZ4nEhwCAHhFLD3iIhIP4BGWQFjcwID
    AQABo4IBnjCCAZowEwYJKwYBBAGCNxQCBAYeBABDAEEwCwY
    DVR0PBAQDAgFGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBB
    YEFJ5Bgt6Oypq7T8Oykw4LH6ws2d/IMIIBMgYDVR0fBIIBK
    TCCASUwgdOggdCggc2GgcpsZGFwOi8vL0NOPVJlc3RhdXJh
    bnRzLENOPWRvd2l0Y2hlcixDTj1DRFAsQ049UHVibGljJTI
    wS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZm
    lndXJhdGlvbixEQz1yZXN0YXVyYW50cyxEQz1jZW50cmFsL
    RPXN1bixEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9u
    TGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGl
    vblBvaW50ME2gS6BJhkdodHRwOi8vZG93aXRjaGVyLnJlc3
    RhdXJhbnRzLmNlbnRyYWwuc3VuLmNvbS9DZXJ0RW5yb2xsL
    1Jlc3RhdXJhbnRzLmNybDAQBgkrBgEEAYI3FQEEAwIBADAN
    BgkqhkiG9w0BAQUFAANBAL5R9R+ONDdVHWu/5Sd9Tn9dpxN
    8oegjS88ztv1HD6XSTDzGTuaaVebSZV3I+ghSInsgQbH0gW
    4fGRwaI BvePI4=
    -----END CERTIFICATE-----
  4. Save the certificate into a file (such as ad-cert.txt).

  5. You can then import that file (for example, ad-cert.txt) into a certificate database. Continue to the next section, Adding Active Directory Certificates to the Connector’s Certificate Database

Adding Active Directory Certificates to the Connector’s Certificate Database

Use this procedure only if you enabled SSL for the Active Directory Connector after installing the Connector or if invalid credentials were provided during installation.

ProcedureTo Add Active Directory Certificate to the Connector's Certificate Database

  1. On the machine where the Active Directory Connector is installed, stop the Identity Synchronization for Windows service/daemon.

  2. Retrieve the Active Directory CA certificate using one of the following methods:

  3. Assuming the Active Directory Connector has connector ID CNN101 (see logs/central/ error.log for a mapping from connector ID to the directory source it manages), go to its certificate database directory on the machine where it was installed, and import the certificate file:

    • If the certificate was retrieved using certutil, type:

      <ISW-server-root>\shared\bin\certutil.exe -A -d . -n ad-ca-cert -t C,, -i \cacert.bin
    • If the certificate was retrieved using LDAP, type:

      <ISW-server-root>\shared\bin\certutil.exe -A -d . -n ad-ca-cert \
      -t C,, -a -i \ad-cert.txt

      ISW-server-root is the path where ISW-hostname directory is present

    On Solaris, the certificate can be imported using the dsadm command in the following manner:

    /opt/SUNWdsee/ds6/bin/dsadm add-cert -C <DS-server-root>/slapd-<hostname>/ ad-ca-cert cacert.bin

    where ad-ca-cert is the name of the certificate assigned after the import and cacert.bin is the certificate about to be imported

  4. Restart the Identity Synchronization for Windows service/daemon.


    Note –

    Because the Directory Server certutil.exe is installed automatically when you install Directory Server, you will not be able to add a CA certificate to a connector installed on a machine with no Directory Server.

    At a minimum, you must install the Sun Java System Server Basic Libraries and Sun Java System Server Basic System Libraries from the Directory Server package on the server where the Active Directory Connector is installed. (You do not have to install the Administration Server or Directory Server components.)

    In addition, be sure to select the JRE subcomponent from the Console (to ensure your ability to uninstall).


Adding Active Directory Certificates to Directory Server


Note –

Make sure that you have enabled SSL in Directory Server.


ProcedureTo Add the Active Directory CA certificate to the Directory Server Certificate Database

  1. Retrieve the Active Directory CA certificate using one of the following methods:

  2. Stop Directory Server.

  3. Import cacert.bin into the <DS-server-root>\slapd-hostname\alias folder on Windows and for Solaris and Linux import it into <DS-server-root>/slapd-hostname/alias directory.

  4. On the machine where Directory Server is installed, import the Active Directory CA certificate as follows:

    • If the certificate was retrieved using certutil, type:


      <ISW_server_root>\shared\bin\certutil.exe -A -d . 
      -P slapd-hostname- -n ad-ca-cert -t C,, -i \cacert.bin
    • If the certificate was retrieved using LDAP, type:


      <ISW_server_root>\shared\bin\certutil.exe -A -d . 
      -P slapd-hostname- -n ad-ca-cert -t C,, -a -i \ad-cert.txt

      ISW-server-root is the path where ISW-hostname directory is present

    • If the certificate was retrieved using the dsadm command (on Solaris), type:


      /opt/SUNWdsee/ds6/bin/dsadm add-cert -C <DS-server-root>
      /slapd-<hostname>/ ad-ca-cert cacert.bin

      Where ad-ca-cert is the name of the certificate assigned after the import and cacert.bin is the certificate about to be imported

  5. Start Directory Server.

Adding Directory Server Certificates to the Directory Server Connector

If you enable SSL communication between the Directory Server Plug-in and Active Directory, then you must add the Active Directory CA Certificate to the certificate database of each Directory Server master.

ProcedureTo Add the Directory Server Certificates to the Directory Server Connector

  1. On the machine where the Directory Server Connector is installed, stop the Identity Synchronization for Windows service/daemon.

  2. Retrieve the Directory Server CA certificate.

  3. Assuming the Directory Server Connector has connector ID CNN100 (see logs/example/ error.log for a mapping from connector ID to the directory source it manages), go to its certificate database directory on the machine where it was installed, and import the cacert.bin file:

    <ISW_server_root>\shared\bin\certutil.exe -A -d . -n ds-cert -t C,, -i C:\s-cert

    ISW-server-root is the path where ISW-hostname directory is present.

  4. Restart the Identity Synchronization for Windows service/daemon.

Chapter 9 Understanding Audit and Error Files

Identity Synchronization for Windows provides information about the installation and configuration status, the day-to-day system operations, and any error conditions that are related to your deployment.

This chapter explains how to access and understand this information in the following sections:

Understanding the Logs

You can view various types of information from the Status tab of the Identity Synchronization for Windows Console.

If you select one of the following nodes in the navigation tree pane (on the left), the content presented on the Status tab changes to provide specific information about that item.

Log Types

This section describes the different kinds of logs that are available for Identity Synchronization for Windows:

Central Logs

As long as Identity Synchronization for Windows components can access Message Queue, all audit and error messages will be logged in the Identity Synchronization for Windows central logger. Consequently, these central logs (which include messages from all components) are the primary logs to monitor.

The centralized logs are located on the machine where Core is installed, in the following directories:

Table 9–1 Log Types for Identity Synchronization for Windows

Log Name 

Description 

error.log

Warning and Severe messages are reported here.

audit.log

A superset of error.log that includes messages about each synchronization event.

resync.log

Messages generated by the resync command are reported here.

Each central log also includes information about each component ID. For example,


[2003/03/14 14:48:23.296 -0600] INFO 13 
"System Component Information:
SysMgr_100 is the system manager (CORE);
console is the Product Console User Interface;
CNN100 is the connector that manages 
[example.com (ldaps:// server1.example.com:636)];
CNN101 is the connector that manages
[dc=example,dc=com (ldap:// server2.example.com:389)];"

In addition to the central logger, each component has it’s own local logs. You can use these local logs to diagnose problems with the connector if it cannot log to the central logger.

Local Component Logs

Each connector, the system manager, and the central logger have the following local logs:

Table 9–2 Local Logs

Log Name 

Description 

audit.log

A superset of error.log that includes messages about each synchronization event. These messages are also written to the central audit.log.

error.log

Warning and Severe messages are reported here. These messages are also written to the central error.log.

These local logs are located in the following subdirectories:


Note –

By default, Identity Synchronization for Windows deletes connector logs after ten days. You can extend this period by editing the com.sun.directory.wps.logging.maxmiumDaysToKeepOldLogs value in the Log.properties file and restarting the service daemon.


Local Windows NT Subcomponent Logs

The following Windows NT subcomponents also have local logs:

Directory Server Plug-in Logs

The Directory Server Plug-in logs information through the Directory Server connector to the central log and through the Directory Server logging facility. Consequently, local Directory Server Plug-in log messages will also be saved in the Directory Server error log.

Directory Server saves information into the error log from other Directory Server Plug-ins and components. To identify messages from the Identity Synchronization for Windows Directory Server Plug-in, you can filter out lines containing the isw string.

By default, only minimal Plug-in log messages are displayed in the error log. For example:

[14/Jun/2004:17:08:36 -0500] - ERROR<38747> - isw - conn=-1 
op=-1 msgId=-1 - Plug-ins unable to establish connection to DS Connector 
at attila:1388, will retry later

ProcedureTo Change the Verbosity Level of the Error Logs

You can change the default verbosity level of the Directory Server error log through DSCC as follows:

  1. Log in to Directory Service Control Center.

  2. On the Directory Servers tab page, click the server whose log level you want to configure.

  3. Select the Server Configuration tab, then the Error Logging tab.

  4. In the General -> Additional Items to Log section, select Plug-Ins.

  5. Click Save.

    You can enable plug-in logging using the command line.

    $ dsconf set-log-prop errors level:err-plugins

    For more information about Directory Server logging, refer to Chapter 14, Directory Server Logging, in Sun Directory Server Enterprise Edition 7.0 Administration Guide.

Reading the Logs

Every log message includes the following information:

Table 9–3 Log Levels

Log Level 

Description 

INFO 

These messages provide a minimum amount of information about each action so you can see that the system is running correctly. For example, you can see when a change is detected and when synchronization occurs. These messages are always logged to the audit log. 

FINE 

These messages contain more information about an action as it travels through the system. 

FINER 

These messages contain even more information about an action as it travels through the system. Turning the logging level to FINER for all components may impact performance. 

FINEST 

These messages contain the most information about an action as it travels through the system. Turning the logging level to FINEST for all components may significantly impact performance.

Configuring Your Log Files

ProcedureTo Configure Logging for Your Deployment

  1. Open the Console and select the Configuration tab.

  2. In the navigation tree pane, and expand nodes until you see the Logs node.

  3. Select the Logs node and the Log Files panel is displayed on the Configuration tab.

    Configure log files.
  4. Use the Log Files pane to configure your log files, as follows:

    • Write logs to file. Enable this option to write logs to a file on the Core host.

      After selecting this option you can:

      • Enable the default log directory and file (for example, /var/opt/SUNWisw/logs/central ).

      • Enable the Write log files to directory option, and then specify a path and file name for the log file.


        Note –

        The Console does not verify whether a specified log file location actually exists. The central logger will try to create the log directory if it does not exist. Consequently, there is no indication that you specified and saved a nonexistent log location until you try to view the logs. After several attempts to view the logs, a message displays to report the Console’s inability to find logs at the specified location.


    • On Solaris OnlyWrite logs to syslog daemon: Enable this option if Identity Synchronization for Windows resides on a Solaris platform. Use the drop-down list to select a category for writing the log. (Default is DAEMON)


      Note –

      When you select this option, Identity Synchronization for Windows logs everything to the syslog; however, the syslog is configured by default to log WARNING and SEVERE messages only.

      To configure syslog to log INFO messages, edit /etc/syslog.conf and change the following line:


      *.err;kern.debug;daemon.notice;mail.crit /var/adm/messages

      to


      *.err;kern.debug;daemon.notice;daemon.info;mail.crit /var/adm/messages

      After making this change, you must restart the syslog daemon as follows:


      /etc/init.d/syslog stop ; /etc/init.d/syslog start

      To enable FINE, FINER, and FINEST logging, include daemon.debug in the semicolon separated list.


    • Remove Old Logs: The number of log files will continue to grow (one per day) indefinitely. To avoid running out of disk space, enable this option and specify when the program can delete old logs from the central log file.

      For example, if you specify 30 days, Identity Synchronization for Windows will delete all files when they become 31 days old.

    • Log Level. Use the drop-down list to select the level of detail you want to see in your system logs. (Review Reading the Logs)

  5. Click the Save Log Configuration button to create log files based on the selected options.

Viewing Directory Source Status

ProcedureTo View the Status of your Directory Sources

  1. From the Identity Synchronization for Windows Console, select the Status tab.

  2. In the navigation tree pane, expand the Directory Source node, and then select the directory source node (such as dc=example,dc=com).

    The Status tab content changes to provide information related to the selected directory source.

    Directory source contents displayed.
    Note –

    When viewing the Directory Source status you are essentially viewing the status of the connector associated with that Directory Source.


    Click Update to refresh the information on this tab. The following information is provided on the Status tab:

    • State: Reflects the current state of the directory source. Valid states include:

      • Uninstalled: The connector has not been installed.

      • Installed: The connector is installed, but is not ready for synchronization because it has not received its runtime configuration yet. If the connector remains in this state for more than a minute, something is probably wrong.

      • Ready: The connector is ready for synchronization, but it is currently not synchronizing any objects. A connector remains in the Ready state if synchronization has not been started or if synchronization has been started but not all subcomponents have established connections with the connectors.

      • Syncing: The connector is synchronizing objects. There might still be errors, so consult the error log if you notice that changes are not synchronized.

    • Active: Indicates whether the directory source is active or down.

    • Last Communication: Indicates the time of the last response from this directory source’s connector.

Viewing Installation and Configuration Status

ProcedureTo View the Remaining Steps of the Installation and Configuration Process

  1. From the Identity Synchronization for Windows Console, select the Status tab.

  2. In the navigation tree pane, expand the To Do node.

    The Status tab content changes to provide a checklist of the installation and configuration steps (for example, see Viewing Directory Source Status).

    Viewing the To Do list.
  3. Click the Update button (upper right) to refresh the list.

    Completed steps will be check-marked and greyed-out. You must complete the remaining steps to successfully complete the installation and configuration process.

Viewing Audit and Error Logs

ProcedureTo View Your Error Logs

  1. From the Identity Synchronization for Windows Console, select the Status tab.

  2. In the navigation tree pane, expand the Audit File or the Error File node.

    The Status tab content changes to display the current logs.

    Viewing your logs.

    Click Refresh to load the latest audit or error information.

    The following information is provided on the Status tab:

    • Continuous: Updates and displays the latest audit or error information constantly.

    • Log File: Displays the full path name of the audit or error log being read; for example:

      C:\Program Files\Sun\MPS\isw-hostname\logs\central\audit.log
      
    • Lines to show: Specifies how many audit or error entries to display. (Default is 25.)

Enabling Auditing on a Windows NT Machine

If you have a Windows NT machine in your deployment, verify that auditing is enabled or Identity Synchronization for Windows cannot log messages from that machine.

ProcedureTo Enable Audit Logging on Your Windows NT Machine

  1. From the Windows NT Start menu, select Programs > Administrative Tools > User Manager for Domains.

  2. When the User Manager dialog box is displayed, select Policies > Audit from the menu bar.

    The Audit Policy dialog box is displayed.

  3. Enable the Audit These Events button and then enable the Success and Failure boxes.

  4. Click OK to close the dialog box.

    These settings will remain in effect until you change them again.