As with multi-master replications, synchronization requires a changelog of to track directory edits and log entries for the state information for update entries, and tombstone entries for deleted entries. This information is required for synchronization. Because these log files can get very large, periodically cleaning up these files is necessary to keep from wasting disk space.
There are four attributes which can maintain the changelog. Two are under cn=changelog5 and relate directly to trimming the changelog:
nsslapd-changelogmaxage sets the maximum age that the entries in the changelog can be; once an entry is older than that limit, it is deleted. This keeps the changelog from growing indefinitely.
nsslapd-changelogmaxentries sets the maximum number of entries that are allowed in the changelog. Like nsslapd-changelogmaxage, this also trims the changelog, but be careful about the setting. This must be large enough to allow a complete set of directory information or synchronization may not function properly.
The other two attributes are under the synchronization agreement entry in cn=sync_agreement,
cn=WindowsReplica,cn=suffixDN,cn=m apping tree,cn=config. These two attributes relate to maintenance information kept in the changelog, the tombstone and state information, rather than the directory edits information.
nsDS5ReplicaPurgeDelay sets the maximum age that tombstone (deleted) entries and state information can be in the changelog. Once a tombstone or state information entry is older than that age, it is deleted. This differs from the nsslapd-changelogmaxage attribute in that the
nsDS5ReplicaPurgeDelay value applies only to tombstone and state information entries; nsslapd- changelogmaxage applies to every entry in the changelog, including directory modifications.
nsDS5ReplicaTombstonePurgeInterval sets the frequency which the server runs a purge
operation. At this interval, the Directory Server runs an internal operation to clean the tombstone and state entries out of the changelog. Make sure that the maximum age is longer than the longest replication update schedule or multi-master replication may not be able to update replicas properly. The parameters for managing replication and the changelog are described in chapter 2, "Core
Configuration Attributes," in the Configuration, Command, and File Reference.
8.3.3. Defining the Connection Type
Synchronization can occur using simple authentication over a standard port, using SSL/TLS, or using Start TLS (a secure connection over a standard port).
Although it is not required, it is strongly recommended that SSL or other secure connection be used for synchronization. If passwords are going to be synchronized from the Windows server, then SSL must be enabled on both servers so the synchronization proceeds over a secure port.
8.3.4. Considering a Data Master
The data master is the server that is the master source of data; this is the primary or authoritative source for data.
Windows and Directory Server services are kept continuously synchronized through the synchronization agreement, which minimizes potential conflicts between the two services. However, if the Directory Server is part of a replication deployment, then conflicts could arise between changes made within the Directory Server replication scenario and the Windows domain depending on the replication schedule. Consider which server will be the data master when the data resides in two different directory services, and decide how much of that information will be shared. The best course is to choose a single directory service to master the data and allow the synchronization process to add, update, or delete the entries
on the other service.
Choose one area (Windows domain or Directory Server) to master the data. Alternatively, choose a single Directory Server as a data master and synchronize it with each Windows domain. If the Directory Server is involved in replication, design the replication structure to avoid conflicts, losing data, or
overwriting data.
How master copies of the data are maintained depends on the specific needs of the deployment. Regardless of how data masters are maintained, keep it simple and consistent. For example, do not attempt to master data in multiple sites, then automatically exchange data between competing
applications. Doing so leads to a "last change wins" scenario and increases administrative overhead.
8.3.5. Determining the Subtree to Synchronize
Only a single Directory Server subtree can be synchronized to a single Windows subtree, and it is recommended that there only be a single synchronization agreement between directory services. Select or design the parts of the directory trees to synchronize; consider designing special suffixes specifically for synchronized entries.
The subtree plan should also account for entries which may correspond between the Active Directory and Directory Server directories but are out of the scope of the synced subtree. The synchronization process actually starts at the root DN to begin evaluating entries for synchronization. Entries are correlated based on the samAccount in the Active Directory and the uid attribute in Directory Server. The synchronization plug-in notes if an entry (based on the samAccount/uid relationship) is removed from the synced subtree either because it is deleted or moved. That is the signal to the synchronization plug-in that the entry is no longer to be synced. The issue is that the sync process needs some
configuration to determine how to handle that moved entry. There are three options which can be set in the sycnrhonization agreement: delete the corresponding Directory Server entry, ignore the change (the default), or unsync the entries but leave them otherwise intact.