Understanding AD LDS Replication and Configuration Sets
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 uses a type of replication called 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 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.
Configuration sets
AD LDS instances replicate data based on participation in a configuration set. All AD LDS instances that are joined to the same 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.
The following illustration shows an example of two AD LDS configuration sets, each with two AD LDS instances. As shown in the illustration, a single computer can run multiple AD LDS instances, each in a different configuration set.
.gif)
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 this 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 to be 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
Knowledge Consistency Checker (KCC), a process 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 Domain Services (AD DS) replication topology that might also exist. Directory partitions cannot be replicated between AD LDS instances and AD DS 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 that is 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 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 0.
| Replication security level | Authentication mode | Description | Supported environments |
|---|---|---|---|
Mutual authentication with Kerberos |
2 |
Kerberos authentication, using service principal names (SPNs), is required. If Kerberos authentication fails, the AD LDS instances will not replicate. |
The configuration set must be fully contained in an AD DS domain, forest, or forest trust. |
Negotiated |
1 |
Kerberos authentication (using SPNs) is attempted first. If Kerberos fails, NTLM authentication is attempted. If NTLM fails, the AD LDS instances will not replicate. |
The configuration set can contain Microsoft Windows NT® 4.0 member servers. |
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. |
The 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. |
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 AD DS 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 AD DS 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.
In workgroup and Windows NT 4.0 environments, do not use an account with administrative privileges as an AD LDS service account.
Use separate configuration sets for applications with strict isolation requirements.
For more information about AD LDS replication requirements for service accounts, see Service Account Selection.