The next step in the installation and configuration process is to run idsync resync. In this deployment, idsync resync:
Establishes links between existing Active Directory and Directory Server users.
Resets the Directory Server password to the Active Directory password by forcing on-demand password synchronization when a user logs into Directory Server for the first time.
Primes the Active Directory Connector's object cache, so that changes to existing users are not falsely interpreted as newly created users.
Doing a full idsync resync operation is expensive in Identity Synchronization for Windows. For a deployment as large at gt.com (500K users), the operation might take a few hours to complete. It also places a heavy load on Message Queue because all users and log messages are sent over Message Queue during idsync resync operation. To reduce this load, the following is done:
Increase the Message Queue Broker's available memory to 1 GB as described in the installation guide.
Change the Identity Synchronization for Windows system-wide log level from the default FINE to INFO, using the console.
If you need to increase the log level to debug an issue, then it is recommended that you use the -a option during idsync resync operation to restrict the idsync resync operation to only the affected users.
Divide the 500K users into five separate idsync resync operations using the -a option. This process is described in more detail below.
These steps are also performed for the failover installation.
When you run idsync resync for the first time, the Active Directory users are divided into five batches to reduce the peak load on Message Queue. Use the -a <ldap-filter\> option with idsync resync to limit the scope of the idsync resync operation to a subset of Active Directory users. When dividing users, the following must be ensured:
The union of the LDAP filters includes every user that should be synchronized.
For example, all characters may not be English or even ASCII, so resynchronization based on the 26 letters of the English alphabet, will skip users with non-English characters.
The LDAP filters can overlap, however, a significant overlap will increase the total running time of the operation.
Batch sizes are not too large; otherwise, the Message Queue Broker will reach its memory limits.
The attributes in the filter are indexed in Active Directory. Consult Microsoft's documentation to determine which Active Directory attributes are indexed. The standard set of indexed attributes includes cn, sn, and samaccountname.
Certain types of searches on indexed attributes can be expensive. For example, an absence search, (!(sn=*)), will result in a time-out error even though it is indexed.
If the filter includes attributes that are not mandatory, for example, sn, then all entries must have a value for that attribute, to avoid entries being overlooked.
If a user attribute used in the filter can change value during the operation, then users whose attributes change might not be synchronized. For example, if an entry’s sn value changes from Smith to Anderson after the first batch of entries have been synchronized, then this user will be skipped. The script below exploits Active Directory's uSNChanged attribute to resynchronize all entries that changed during the sequence of idsync resync operations.
Running idsync resync in batches will not significantly increase the total time required to do a full idsync resync operation, and might even speed the operation as it prevents the Message Queue Broker from thrashing as it reaches its memory limits.
Only a single idsync resync operation can be run at a time, so these operations cannot be run in parallel.
The -a <ldap-filter\> operation always applies to the source of the idsync resync operation. When users are linked with the -f option, Active Directory must be the source of the operation, so we only consider how to divide users based on the available Active Directory attributes.
Due to these requirements, Global Telco is resynchronizing its users based on their cn attribute. cn is a mandatory attribute and is indexed. Users are categorized into the following groups
cn <= a
a <= cn <= d
d <= cn <= h
h <= cn <= m
m <= cn <= s
s <= cn
If a user's cn exactly matches one of the boundary conditions (for example, cn=d), then the user will be synchronized twice, but this introduces negligible overhead and does not cause any problems.
Global Telco then uses the following Perl script to iterate through the idsync resync operations. The resync-batch.pl script first retrieves the current maximum uSNChanged from Active Directory. The specified Active Directory host must be the same host as the one the Active Directory Connector uses for communication, because uSNChanged values differ between Active Directory domain controllers. The script then iterates through each idsync resync operation, pausing for one minute between the operations to allow the connectors to reset and settle. The last search filter will match all users that changed during the other idsync resync operations.
#! /usr/bin/perl # # This script executes a sequence of resync operations. # Each resync operation occurs on a subset of users # based on an LDAP filter. # # Parameters specific to this deployment # my $linkFile = "/var/opt/SUNWisw/samples/linkusers-simple-gt.cfg"; my $idsync = "/opt/SUNWisw/bin/idsync"; my $adHost = "ad1-us.gt.com"; my $secBetweenOps = 60; my $dsPassword = "< omitted password\>"; my $configPassword = "< omitted password"; # Guard against users whose cn changes during this operation # by retrieving the maximum uSNChanged value before we start # the operation, and later running resync for only these users. my $origUsn = ”ldapsearch -h $adHost -b ’’ -s base ’(objectclass=*)’ \\ highestCommittedUSN | grep highestCommittedUSN | sed ’s/[^0-9]//g’”; chomp $origUsn; # Run each user in a batch my @BATCH_FILTERS = (" (cn<=a)", # cn <= a "(&(cn\>=a)(cn<=d))", # a <= cn <= d "(&(cn\>=d)(cn<=h))", # d <= cn <= h "(&(cn\>=h)(cn<=m))", # h <= cn <= m "(&(cn\>=m)(cn<=s))", # m <= cn <= s " (cn\>=s)", # s <= cn "(uSNChanged\>=$origUsn)",# modified users); # Run each user in a batch for my $filter (@BATCH_FILTERS) { print "Running resync with filter ’$filter’.\\n"; my $command = "$idsync resync -a ’$filter’ -f $linkFile"." -i NEW_LINKED_USERS -q $configPassword -w $dsPassword"; system($command); print "Waiting $secBetweenOps before next iteration.\\n"; sleep $secBetweenOps; } |
Notice that the -i NEW_LINKED_USERS option is passed to idsync resync, which resets all Directory Server passwords to match their Active Directory counterparts after the entries are linked.
If Global Telco did not want to reset the passwords for the Directory Server accounts, they would not run this command with the -k option, which only links users. The idsync resync command primes the object cache database in the Active Directory Connector, which is used to detect changes to entries. When idsync resync is run with the -k option, the object cache is not primed, and if the connector detects a change to an existing user, it will erroneously assumes it is a new user. If you run idsync resync -k, then you must run the idsync resync command again with the -u option, which updates the object cache only.
You must run the idsync resync command also for the failover installation. The links between the entries are already established and idsync resync is only required to prime the object cache database for the Active Directory Connector. Therefore, it is run with the -u option. To avoid overloading Message Queue with log messages: the Message Queue Broker's maximum memory is increased, the Identity Synchronization for Windows log level is changed to INFO, and idsync resync is run over the entire user population in batches. The script above is modified slightly and run on the failover installation Core machine, config-eu.gt.com. The parameters at the top of the script are changed, and the -i NEW_LINKED_USERS option is replaced with just -u.