It may be useful to assess the type of information, Windows servers, and other considerations before setting up synchronization, similar to the site surveys for organizing data or planning replication.
8.3.1. Resource Requirements
Synchronization uses server resources. Consider the following resource requirements when defining the replication strategy:
Disk usage — The changelog is written after each update operation. Servers receiving many update operations may see higher disk usage. In addition, a single changelog is maintained for all replication databases and synchronized databases. If a supplier contains multiple replicated and synchronized databases, the changelog is used more frequently, and the disk usage is even higher.
Server threads — The synchronization agreement uses one server thread.
File descriptors — The number of file descriptors available to the server is reduced by the changelog (one file descriptor) and each replication and synchronization agreement (one file descriptor per agreement).
Quality of the LANs and WANs connecting different buildings or remote sites and the amount of available bandwidth.
The number and size of the entries stored in the directory.
A site that manages human resource databases or financial information is likely to put a heavier load on the directory than a site containing engineering staff that uses the directory for simple telephone book purposes.
8.3.2. Managing Disk Space for the Changelog
As with multi-master replications, synchronization requires a changelog 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=mapping 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 TLS/TLS, or using Start TLS (a secure connection over a standard port).
Although it is not required, it is strongly recommended that TLS or other secure connection be used for synchronization. If passwords are going to be synchronized from the Windows server, then TLS 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 synchronization agreement: delete the corresponding Directory Server entry, ignore the change (the default), or unsync the entries but leave them otherwise intact.
8.3.6. Interaction with a Replicated Environment
Synchronization links a Directory Server suffix and subtree (for example,
ou=People,dc=example,dc=com) to a corresponding Windows domain and subtree (
cn=Users,dc=test,dc=com). Each subtree can be synchronized only to one other subtree to avoid naming conflicts and change conflicts.
To take advantage of Windows Sync, use it with a Directory Server supplier in multi-master replication synchronized to a member of a Windows domain. This propagates changes through both directory systems while keeping the information centralized and easy to maintain. It also makes it easier to master the data.
Figure 8.2. Multi-Master Directory Server — Windows Domain Synchronization
Only create one synchronization agreement to any given Windows domain. To propagate the changes and information synchronized from the Windows server throughout the Directory Server, create the synchronization agreement with a multi-master supplier, preferably a data master for the replication deployment.
8.3.7. Controlling the Sync Direction
As Figure 8.1, “The Sync Process”
illustrates, synchronization is bi-directional
by default. That means that changes in Active Directory are sent to Directory Server and changes on Directory Server are sent to Active Directory.
It is possible to create uni-directional synchronization by adding the
oneWaySync parameter to the sync agreement. This attribute defines which direction to send changes.
To send changes from the Active Directory server to the Directory Server, the value is
fromWindows. In this case, during the regular synchronization update interval, the Directory Server contacts the Active Directory server and sends the DirSync control to request updates. However, the Directory Server does not send any changes or entries from its side. So, the sync update consists of the Active Directory changes being sent to and updating the Directory Server entries.
To sync changes from the Directory Server to the Active Directory server, the value is
toWindows. The Directory Server sends entry modifications to the Active Directory server in a normal update, but it does not include the DirSync control so that it does not request any updates from the Active Directory side.
Enabling uni-directional sync does not automatically prevent changes on the un-synchronized server, and this can lead to inconsistencies between the sync peers between sync updates. For example, uni-directional sync is configured to go from Active Directory to Directory Server, so Active Directory is (in essence) the data master. If an entry is modified or even deleted on the Directory Server, then the Directory Server information is different then the information and those changes are never carried over to Active Directory. During the next sync update, the edits are overwritten on the Directory Server and the deleted entry is re-added.
To prevent data inconsistency, use access control rules to prevent editing or deleting entries within the synchronized subtree on the un
synced server. Access controls for Directory Server are covered in Section 9.7, “Designing Access Control”
. For Active Directory, see the appropriate Windows documentation.
8.3.8. Controlling Which Entries Are Synced
Windows Sync provides some control over which entries are synchronized to give sufficient flexibility to support different deployment scenarios. This control is set through different configuration attributes set in the Directory Server:
Within the Windows subtree, only user and group entries can be synchronized to Directory Server. When creating the synchronization agreement, there is an option to synchronize new Windows user and group entries as they are created. If these attributes are set to
on, then existing Windows entries are synchronized to the Directory Server, and entries as they are created in the Windows server are synchronized to the Directory Server.
As with Active Directory entries, only user and group entries in Directory Server can be synchronized. Entries which will be synchronized must have the
ntGroup object classes and required attributes; all other entries are ignored.
Directory Server passwords are synchronized along with other entry attributes because plaintext passwords are retained in the Directory Server changelog. The Password Sync Service is needed to catch password changes made on the Windows server. Without the Password Sync Service, it would be impossible to have Windows passwords synchronized because passwords are hashed in the Windows server, and the Windows hashing function is incompatible with the one used by Directory Server.
8.3.9. Identifying the Directory Data to Synchronize
Windows Sync synchronizes user and group entries between directory services. After deciding which subtrees to synchronize, plan the information to store in those subtrees, such as the following:
Contact information for directory users and employees, such as telephone numbers, home and office addresses, and email addresses.
Contact information for trading partners, clients, and customers.
User's software preferences or software configuration information.
Group information and group membership.
Group members are synchronized only if they are within the synchronized suffix. Group members that are not within the scope of the agreement are left unchanged on both sides; that is, they are listed as members of the group on the appropriate directory service, but their
member attribute in the group entry is not synchronized with the synchronization peer.
Which entries are synchronized is set in the synchronization agreement. User entries are synchronized separately from group entries. Additionally, deleting entries is configured separately; deletions have to be specifically synchronized.
In the Directory Server, only entries that contain the
ntUser object classes and required attributes are synchronized; determine what existing and future entries should be synchronized with the Windows server.
After determining what entries should be present in the directory, determine what attributes of these objects need to be maintained in the directory. Only a subset of the possible attributes for Directory Server or for Active Directory are synchronized. Additionally, this subset of attributes can be limited even more by excluding certain attributes through the sync agreement (fractional synchronization).
8.3.10. Synchronizing POSIX Attributes for Users and Groups
A subset of all possible user and attributes are synchronized between Active Directory and Red Hat Directory Server. Some attributes are mapped, where there are differences between Active Directory and Directory Server schemas, and some attributes are matched directly. By default, only those attributes are synchronized.
One type of attribute that is missing from that sync list is any POSIX-related attribute. On Linux systems, system users and groups are identified as POSIX entries, and LDAP POSIX attributes contain that required information. However, when Windows users are synced over, they have
ntGroup attributes automatically added which identify them as Windows accounts, but no POSIX attributes are synced over (even if they exist on the Active Directory entry) and no POSIX attributes are added on the Directory Server side.
The Posix Winsync API Plug-in synchronizes POSIX attributes between Active Directory and Directory Server entries. This plug-in is disabled by default, but when enabled, it allows identifying POSIX attributes to be set in the data master and then synchronized over to the peer server. This is beneficial if Active Directory is used as the user account store since the POSIX attributes can be set directly in the Active Directory entries and then synced and preserved over in the Directory Server directory.
All POSIX attributes (such as
homeDirectory) are synchronized between Active Directory and Directory Server entries if the plug-in is enabled. However, if a new POSIX entry or POSIX attributes are added to an existing entry in the Directory Server, only the POSIX attributes are synchronized over to the Active Directory corresponding entry. The POSIX object class (
posixAccount for users and
posixGroup for groups) is not added to the Active Directory entry.
8.3.11. Synchronizing Passwords and Installing Password Services
While the DirSync plug-in is installed with the Directory Server and enabled by default, an additional Windows service, Password Sync, must be installed on the Windows machine to synchronize passwords. This service is required to transfer any password changes made on the Windows server over to the Directory Server.
Unless the Password Sync service is installed, password synchronization (synchronizing the
userPassword attribute) is not enabled. What this means is that even if Directory Server user entries are synchronized over to the Windows server, the user entries are not active on the Windows domain (meaning, among other things, those synced users cannot log into the domain, since they do not have a password).
There is a password policy attribute called
passwordTrackUpdateTime which records a separate timestamp for the last update of the user password. This can make it simpler to synchronize password changes between Active Directory and Directory Server or with other clients.
8.3.12. Defining an Update Strategy
Existing Directory Server entries that are modified to contain the necessary synchronization attributes are not synchronized until the next total update. Modifications to Windows entries and Directory Server entries that have already been synchronized are carried at the next incremental update. As a part of this strategy, try to master data in a single place, limiting the applications that can change the data, and schedule necessary total updates (these updates do not overwrite or delete existing information; they add new entries and send modifications).
By default, the Windows and Directory Server instances are kept constantly in sync and have changes published every five minutes. This schedule can be altered by manually setting the sync agreement attributes to change the update interval (
winSyncInterval) or by setting a different update schedule (
8.3.13. Editing the Sync Agreement
The basic sync agreement configured through the Directory Server Console sets very simple information about synchronization, like the host and port information, synchronized subtrees, and connection types.
However, many configurations available to multi-master replication, like fractional replication and sync schedules, are available to Windows-Directory Server synchronization. These settings must simply be added to the sync agreement manually.
Changing the default sync agreement is described in the Administration Guide, and the available sync agreement attributes are listed in the Configuration, Command, and File Reference.