1 Introduction

Sun Java System Identity Synchronization for Windows synchronizes user account information, including passwords, between Sun Java System Directory Server and Windows (both Active Directory and Windows NT). Identity Synchronization for Windows helps build a scalable and security enriched password synchronization solution for small, medium, and large enterprises.

This document provides guidance through case studies that lead to deploying the solution in your test and production environments.

The Identity Synchronization for Windows solution provides:

• A robust and scalable solution that includes support for high availability.

• Synchronization of account creation, modification, inactivation, and deletion between Active Directory, Windows NT and Directory Server.

• Seamless integration with disparate and proprietary directory source to synchronize native password changes.

1.1 Identity Synchronization for WindowsDeployment Considerations

You must be aware of the following important deployment considerations before you begin deploying Identity Synchronization for Windows:

• Synchronization direction(s) of passwords. If passwords are synchronized from Directory Server to Active Directory or in both directions, then you must install the High Encryption Pack on Windows 2000 to enable 128-bit SSL, which is required when setting passwords in Active Directory over LDAP.

• Synchronizing the creation of new users. If Identity Synchronization for Windows does not synchronize the creation of new users, then you must run the idsync resync command periodically to establish links between newly created users. Changes to newly created users are not synchronized until the users are explicitly linked by running idsync resync.

• Population size. While Identity Synchronization for Windows places no upper limit on the number of users that can be synchronized, the total number of users impacts the deployment. The primary impact is on the idsync resync command that must be run before you start synchronization. If more than 100,000 users are synchronized, then the idsync resync command should be run in batches for optimal performance, and to limit the load on Sun Java System Message Queue

• Performance requirements. The performance of Identity Synchronization for Windows is limited more by the synchronization rate than by the total number of users. The only exception to this requirement is when you run the idsync resync command.

• Expected peak modification rate. An Identity Synchronization for Windows deployment with Core and two connectors running on the same system, can easily sustain a modification rate of 10 synchronizations per second. If the required synchronization rate exceeds this rate, then higher performance is achieved by distributing Identity Synchronization for Windows across multiple machines, for example, by installing the connectors on a separate machine from the Identity Synchronization for Windows Core.

• Number of Windows Domains to be synchronized. If more than one Windows domains are to be synchronized, then the activedirectorydomainname (and/or USER_NT_DOMAIN_NAME) attributes should be synchronized to a Directory Server attribute. This is required to resolve ambiguity between Synchronization User List definitions.

• Number of Directory Server masters, hubs, and read-only replicas in the deployment. In a deployment with multiple Directory Servers, the Identity Synchronization for Windows Directory Server Plugin must be installed on each master, each hub, and each read-only replica. When configuring Identity Synchronization for Windows, one Directory Server master is designated as the preferred master. The Directory Server Connector detects and applies changes at the preferred master while it is running. If this server is down, then it can optionally apply changes at a second master. The Retro Changelog Plugin must be enabled on the preferred master, and this master should be on the same LAN as the Identity Synchronization for Windows Core.

• Security. If the Directory Server or the Active Directory Connectors connect to Directory Server or Active Directory over SSL, then SSL must be enabled in these directories. If the connectors are configured to accept only trusted certificates, then extra configuration steps must be followed to import the appropriate Certificate Authority certificates into the connectors' certificate databases. If SSL is required between the Directory Server Plugin and Active Directory, then SSL must be enabled in Directory Server. The Certificate Authority certificate used to sign the Active Directory SSL certificate must also be imported in the Directory Server's certificate database.

• Bidirectional account lockout and unlockout synchronization. For Account Lockout and Unlockout to work correctly, it is recommended that you 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.

• Bidirectional group synchronization. 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.