Search

Chapter 16. Synchronizing Red Hat Directory Server with Microsoft Active Directory

download PDF
Windows Synchronization carries over changes in a directory — adds, deletes, and changes in groups, users, and passwords — between Red Hat Directory Server and Microsoft Active Directory. This makes it much more efficient and effective to maintain consistent information across directories.

16.1. About Windows Synchronization

Synchronization allows the user and group entries in Active Directory to be matched with the entries in the Red Hat Directory Server. As entries are created, modified, or deleted, the corresponding change is made to the sync peer server, allowing two-way synchronization of users, passwords, and groups.
The synchronization process is analogous to the replication process: the synchronization is enabled by a plug-in, configured and initiated through a sync agreement, and record of directory changes is maintained and updates are sent according to that changelog. This synchronizes users and groups between Directory Server and a Windows server.
Windows Synchronization has two parts, one for user and group entries and the other for passwords:
  • Directory Server Windows Synchronization. Synchronization for user and group entries is configured in a synchronization agreement, much like replication is configured in a replication agreement. A sync agreement defines what kinds of entries are synchronized (users, groups, or both) and which direction changes are synchronized (from the Directory Server to Active Directory, from Active Directory to Directory Server, or both).
    The Directory Server relies on the Multi-Supplier Replication Plug-in to synchronize user and group entries. The same changelog that is used for multi-supplier replication is also used to send updates from the Directory Server to Active Directory as LDAP operations. The server also performs LDAP search operations against its Windows server to synchronize changes made to Windows entries to the corresponding Directory Server entry.
  • Password Synchronization Service. If you set the nsslapd-unhashed-pw-switch parameter in the cn=config entry to on, password changes made on Directory Server are automatically synchronized over to Active Directory. However, there must be a special hook to recognize and transmit password changes on Active Directory over to Directory Server. This is done by the Password Synchronization Service. This application captures password changes on the Active Directory domain controller and sends them to the Directory Server over LDAPS.
    The Password Synchronization Service must be installed on every Active Directory domain controller.
Active Directory — Directory Server Synchronization Process

Figure 16.1. Active Directory — Directory Server Synchronization Process

Synchronization is configured and controlled by one or more synchronization agreements, which establishes synchronization between sync peers, the directory servers being synchronized. These are similar in purpose to replication agreements and contain a similar set of information, including the host name (or IPv4 or IPv6 address) and port number for Active Directory. The Directory Server connects to its peer Windows server using LDAP/LDAPS to both send and receive updates.
LDAP, a standard connection, can be used for syncing user and group entries alone, but to synchronize passwords, some sort of secure connection is required. If a secure connection is not used, the Windows domain will not accept password changes from the Directory Server and the Password Synchronization Service will not send passwords from the Active Directory domain to the Directory Server. Windows Synchronization allows both LDAPS using TLS and STARTTLS.
Multiple subtree pairs can be configured to sync each other. Unlike replication, which connects databases, synchronization is between suffixes, parts of the directory tree structure. The synchronized Active Directory and Directory Server suffixes are both specified in the sync agreement. All entries within the respective subtrees are candidates for synchronization, including entries that are not immediate children of the specified suffix DN.

Note

Any descendant container entries need to be created separately in Active Directory by an administrator; Windows Synchronization does not create container entries.
The Directory Server maintains a changelog, a database that records modifications that have occurred. The changelog is used by Windows Synchronization to coordinate and send changes made to the Active Directory peer. Changes to entries in Active Directory are found by using Active Directory's Dirsync search feature. Directory Server runs the Dirsync search periodically by default every five minutes to check for changes on the Active Directory server. You can change this default by setting the winSyncInterval parameter in the cn=syncAgreement_Name,cn=WindowsReplica,cn=suffix_Name,cn=mapping tree,cn=config entry. Using Dirsync ensures that only those entries that have changed since the previous search are retrieved.
In some situations, such as when synchronization is configured or there have been major changes to directory data, a total update, or resynchronization, can be run. This examines every entry in both sync peers and sends any modifications or missing entries. A full Dirsync search is initiated whenever a total update is run. See Section 16.11, “Sending Synchronization Updates” for more information.
Windows Synchronization provides some control over which entries are synchronized to grant administrators fine-grained control of the entries that are synchronized and to give sufficient flexibility to support different deployment scenarios. This control is set through different configuration attributes set in the Directory Server:
  • When creating the sync agreement, there is an option to synchronizing new Windows entries (nsDS7NewWinUserSyncEnabled and nsDS7NewWinGroupSyncEnabled) as they are created. If these attributes are set to on, then existing Windows users/groups are synchronized to the Directory Server, and users/groups as they are created are synchronized to the Directory Server.
    Within the Windows subtree, only entries with user or group object classes can be synchronized to Directory Server.
  • On the Directory Server, only entries with the ntUser or ntGroup object classes and attributes can be synchronized.
The placement of the sync agreement depends on what suffixes are synchronized; for a single suffix, the sync agreement is made for that suffix alone; for multiple suffixes, the sync agreement is made at a higher branch of the directory tree. To propagate Windows entries and updates throughout the Directory Server deployment, make the agreement between a supplier in a multi-supplier replication environment, and use that supplier to replicate the changes across the Directory Server deployment, as shown in Figure 16.2, “Multi-Supplier Directory Server — Windows Domain Synchronization”.

Important

While it is possible to configure a sync agreement on a hub server, this only allows uni-directional synchronization, from Red Hat Directory Server to Active Directory. The Active Directory server cannot sync any changes back to the hub.
It is strongly recommended that only suppliers in multi-supplier replication be used to configure synchronization agreements.

Warning

There can only be a single sync agreement between the Directory Server environment and the Active Directory environment. Multiple sync agreements to the same Active Directory domain can create entry conflicts.
Multi-Supplier Directory Server — Windows Domain Synchronization

Figure 16.2. Multi-Supplier Directory Server — Windows Domain Synchronization

Directory Server passwords are synchronized along with other entry attributes because plain-text passwords are retained in the Directory Server changelog. The Password Synchronization service is needed to catch password changes made on Active Directory. Without the Password Synchronization service, it would be impossible to have Windows passwords synchronized because passwords are hashed in Active Directory, and the Windows hashing function is incompatible with the one used by Directory Server.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.