Chapter 1 Before You Begin Deployment

This chapter covers the following topics:

• Features of Identity Synchronization for Windows

• Pre-deployment Requirements and Guidelines

Sun Java^TM System Identity Synchronization for Windows (Identity Synchronization for Windows) synchronizes user account information, including passwords, between Solaris^TM Operating System (Solaris OS), by using Sun Java System Directory Server (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.

Features of Identity Synchronization for Windows

The Identity Synchronization for Windows solution provides the following features:

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

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

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

Pre-deployment Requirements and Guidelines

Before you begin deploying Identity Synchronization for Windows, you must be aware of the following deployment requirements and guidelines:

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

• Synchronization of the creation of new users. If Identity Synchronization for Windows does not synchronize the creation of new users, you must run the idsync resync command periodically to establish links between the 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, which must be run before you start synchronization. If more than 100,000 users are synchronized, run the idsync resync command 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, higher performance can be achieved by distributing Identity Synchronization for Windows across multiple machines. For example, install 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 domain is to be synchronized, synchronize the activedirectorydomainname, the USER_NT_DOMAIN_NAME or both attributes to a Directory Server attribute to resolve ambiguity between Synchronization User List (SUL) definitions.

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

• Security. If the Directory Server or Active Directory connectors connect to Directory Server or Active Directory over SSL, SSL must be enabled in these directories. If the connectors are configured to accept only trusted certificates, 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 plug-in and Active Directory, 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, set the symmetric password policy at both ends. For example, if the password policy for Active Directory signifies a permanent lockout then the same password policy should be set for 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.