Red Hat DIRECTORY SERVER 8.0, Руководство администратора

Страница: 466 / 552

Chapter 19. Synchronizing Red Hat Directory Server with Microsoft Active Directory
448
similar in purpose to replication agreements and contain a similar set of information, including the
hostname and port number for Active Directory. The Directory Server connects to its peer Windows
server via LDAP/LDAPS to both send and receive updates.
A single Active Directory subtree is synchronized with a single Directory Server subtree, and vice
versa. Unlike replication, which connects
databases
, synchronization is between
suffixes
, parts of the
directory tree structure. The synced 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 Sync 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 Sync 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. Because there is no changelog on the Active Directory side, the
Dirsync
search is issued periodically, every five minutes. 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 19.3.5, “Manually Updating and Resynchronizing Entries”
for more
information.
Windows Sync 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
(
nsDS7NewWinUserSync
and
nsDS7NewWinGroupSync
) 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.
See
Section 19.3, “Using Windows Sync”
for more information on creating user and group entries.
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 master in a multi-master replication
environment, and use that master to replicate the changes across the Directory Server deployment, as
shown in
Figure 19.2, “Multi-Master Directory Server - Windows Domain Synchronization”
.