Identity Synchronization for Windows Deployment Considerations

• Synchronization direction of passwords. If passwords are synchronized from Directory Server to Active Directory or in both directions, install the High Encryption Pack on Windows 2000. This installation enables 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, 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 synchronization is started. If more than 100,000 users are synchronized, run the idsync resync command in batches. This batch mode ensures optimal performance and limits the load on Sun 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 a Core and two connectors that are 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 is achieved by distributing Identity Synchronization for Windows across multiple machines. For example, the connectors can be installed 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, the activedirectorydomainname attribute or the USER_NT_DOMAIN_NAME attribute must be synchronized to a Directory Server attribute. This synchronization 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 plug-in must be enabled 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 the master is running. If this server is down, the connector can optionally apply changes at a second master. The Retro Changelog plug-in must be enabled on the preferred master. 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, SSL must be enabled on these servers. If the connectors are configured to accept only trusted certificates, extra configuration steps must be taken. These steps 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. In addition, the Certificate Authority certificate that is used to sign the Active Directory SSL certificate must be imported into the Directory Server’s certificate database.

For detailed deployment scenarios that incorporate Identity Synchronization for Windows, see Sun Java System Identity Synchronization for Windows 6.0 Deployment Planning Guide.