![]() | |
Sun Java System Identity Synchronization for Windows 1 2004Q3 Deployment Planning Guide |
Chapter 1
IntroductionSun 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 enrichred password synchronization solution for small, medium, and large enterpises.
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.
Deployment ConsiderationsYou must be aware of the following important deployment considerations before you begin deploying Identity Synchronization for Windows:
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. For details, see Periodically Linking New Users.
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 synchronization is started. 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 (Message Queue). For details, see Periodically Linking New Users
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.
If more than one Windows domain is 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. For details, see Configuring the Synchronization User Lists.
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.
If the Directory Server or the Active Directory Connectors will connect to Directory Server or Active Directory over SSL, then SSL must be enabled in these directories. If the connectors are configured to only accept 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, and the Certificate Authority certificate used to sign the Active Directory SSL certificate must be imported in the Directory Server’s certificate database.