Search

16.7. Configuring Uni-Directional Synchronization

download PDF
As Figure 16.1, “Active Directory — Directory Server Synchronization 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, where changes are only sent one-way. This is similar to a supplier-consumer relationship[1] as opposed to multi-supplier.
An additional attribute for the sync agreement, oneWaySync, enables uni-directional synchronization and specifies the direction to send changes. The possible values are fromWindows (for Active Directory to Directory Server sync) and toWindows (for Directory Server to Active Directory sync). If this attribute is absent, then synchronization is bi-directional.
Uni-Directional Synchronization

Figure 16.3. Uni-Directional Synchronization

The synchronization process itself is the mostly same for bi-directional and uni-directional synchronization. It uses the same sync interval and configuration. The only difference is in how sync information is requested.
For Windows Active Directory to Directory Server synchronization, 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.
For Directory Server to Active Directory synchronization, 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.
Use the --one-way-sync="direction" option to enable uni-directional synchronization in one of the following situations:
  1. If you create a new synchronization agreement in Section 16.4.9, “Step 9: Configuring the Database for Synchronization and Creating the Synchronization Agreement”, pass the option to the dsconf repl-winsync-agmt create command.
  2. If the synchronization agreement already exists, update the agreement. For example, to set synchronization from AD to Directory Server:
    # dsconf -D "cn=Directory Manager" ldap://server.example.com repl-winsync-agmt set --one-way-sync="fromWindows" --suffix="dc=example,dc=com" example-agreement

Note

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 supplier. If an entry is modified or even deleted on the Directory Server, then the Directory Server information is different than 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 unsynchronized server. Access controls for Directory Server are covered in Chapter 18, Managing Access Control. For Active Directory, see the appropriate Windows documentation.
Uni-directional sync does not affect password synchronization. Even when the synchronization direction is set to toWindows, after updating a password on the Active Directory server, the password is sent to the Directory Server.


[1] Unlike a consumer, changes can still be made on the un-synchronized server. Use ACLs to prevent editing or deleting entries on the un-synchronized server to maintain data integrity.
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.