Introduction to Administering AD LDS Replication and Configuration Sets

Article
07/02/2012

Applies To: Windows Server 2008

Replication and configuration sets

Active Directory Lightweight Directory Services (AD LDS) uses replication to provide fault tolerance and load balancing for directory services. AD LDS supports multimaster replication. Through replication, AD LDS copies directory data updates that are made to a directory partition on one AD LDS instance to other AD LDS instances that hold copies of the same directory partition. AD LDS instances that hold copies of the same directory and schema partition or partitions form a logical grouping called a configuration set.

Multimaster replication

Multimaster replication simply means that you can make changes to directory data on any AD LDS instance. AD LDS replicates these changes to other members of the configuration set automatically. Multimaster replication is characterized by loose data consistency with convergence. When you make changes to data on a given directory partition at one AD LDS instance, replicas of that directory partition that are stored on other AD LDS instances become inconsistent with the most up-to-date replica of the directory partition (the partition where the changes were made). However, as changes get replicated through the configuration set, all partition replicas once again become identical; that is, they converge to the most recent data.

Pull replication

AD LDS (same as Active Directory Domain Services (AD S)) uses pull replication. In pull replication, a destination replica requests information from a source replica. The request specifies the information that the destination must have, based on its knowledge of changes already received from the source and from all other domain controllers in the domain. When the destination receives information from the source, it applies that information, and brings itself up-to-date. The destination's next request to the source excludes the information that has already been received and applied.

The alternative is push replication. In push replication, a source sends information to a destination unsolicited, in an attempt to bring the destination up-to-date. Push replication is problematical because it is difficult for the source to know what information the destination needs. Perhaps the destination has received the same information from another source. If a source sends information to a destination, there is no guarantee that the destination is going to apply it; if the source assumes otherwise, the system is unreliable.

Configuration sets

AD LDS instances replicate data based on participation in a configuration set. All AD LDS instances that are joined to the same a configuration set must replicate a common configuration directory partition and a common schema directory partition. AD LDS instances in a configuration set can also replicate any number of application directory partitions. AD LDS instances in a configuration set are not required to replicate all application directory partitions in the configuration set. A single AD LDS instance can replicate all—or any subset of—the application directory partitions in its configuration set. An AD LDS instance cannot, however, replicate an application directory partition from a different configuration set. For more information about the types of directory partitions in AD LDS, see Introduction to Administering AD LDS Directory Partitions.

Note

An AD LDS instance can be joined to a configuration set only during installation of the instance.

Preventing replication conflicts

What if two different users make changes to the same data on replicas of the same directory partition on two different AD LDS instances? In such a case, each AD LDS instance attempts to replicate the changes, creating a conflict. To resolve this conflict, replication partners that receive these conflicting changes examine the attribute data that is contained in the changes, each of which holds a version and a time stamp. AD LDS instances accept the change with the higher version and discard the other change. If the versions are identical, AD LDS instances accept the change with the more recent time stamp.

If two or more values in a multivalued attribute on an object are updated simultaneously on two different AD LDS instances, only one of the updated values will be replicated. In other words, simultaneous updates to a multivalued attribute that occur on two different AD LDS instances are considered in conflict, even if the updates apply to different values within the multivalued attribute. The only exception to this rule is for linked value attributes (such as group memberships), which do allow for simultaneous updates to different values within the linked value attribute.

Replication topology

The Knowledge Consistency Checker (KCC), a component that runs as part of each AD LDS instance, automatically constructs the most efficient topology for replication traffic to follow, based on the network. The KCC regularly recalculates the replication topology to adjust for any network changes that occur in the environment.

Note

An AD LDS configuration set maintains its own replication topology, separate from any Active Directory replication topology that might also exist. Directory partitions cannot be replicated between AD LDS instances and Active Directory domain controllers.

Ensuring replication security

To ensure replication security, AD LDS authenticates replication partners before replication, and replication authentication always occurs over a secure channel. AD LDS uses Security Support Provider Interface (SSPI) to establish the appropriate authentication security level between replication partners. The method used for replication authentication within a configuration set depends on the value of the msDS-ReplAuthenticationMode attribute on the configuration directory partition. After replication partners have successfully authenticated, all replication traffic between the two partners is encrypted.

The following table describes the security levels for replication authentication and the corresponding msDS-ReplAuthenticationMode attribute value for each security level. The default replication security level for a new, unique AD LDS instance is one (1), unless a local workstation user account is specified as the AD LDS service account. If a local workstation account is specified as the AD LDS service account, the replication security level is set to zero (0).

Replication security level	Authentication mode	Description	Supported environments
Mutual authentication with Kerberos	2	Kerberos authentication, using service principal names (SPNs), required. If Kerberos authentication fails, the AD LDS instances will not replicate.	Configuration set must be fully contained in an Active Directory domain, forest, or forest trust.
Negotiated	1	Kerberos authentication by using SPNs is attempted first. If Kerberos fails, NTLM authentication is attempted. If NTLM fails, the AD LDS instances will not replicate.	Configuration set must be fully contained in an Active Directory domain, forest, or forest trust.
Negotiated pass-through	0	All AD LDS instances in the configuration set use an identical account name and password as the AD LDS service account.	Configuration set can include computers that are joined to one or more workgroups or that are joined to multiple domains or forests without trust relationships.

For information about modifying the replication security level of a configuration set, see Modify the Replication Security Level of a Configuration Set.

To help maintain AD LDS replication security, the following best practices are recommended:

Use the highest level of replication security that your environment can support.
In Active Directory environments, run AD LDS on member servers, rather than on domain controllers, whenever possible.
If you run AD LDS on a domain controller in an Active Directory environment, do not use the Network Service account as the AD LDS service account. Instead, use a domain user account that does not have administrative privileges.
Use separate configuration sets for applications with strict isolation requirements.

For more information about AD LDS replication requirements for service accounts, see Selecting an AD LDS Service Account. For more information about service principal names (SPNs) and replication security, see Administering AD LDS Service Principal Names.

Share via