2.7.5.1 Replicate Changes Within a Domain - Domain Controller

In this use case, a domain is maintained by three domain controllers; that is, copies of the domain data, or replicas, exist on three domain controllers within the domain: Domain Controller 1 (DC1), Domain Controller 2 (DC2), and Domain Controller 3 (DC3). Changes to the data have been implemented on DC1; that is, DC1 has originating updates, and those changes need to be replicated to DC2 and DC3 by using a normal, intra-site replication cycle. This replication topology between DC1, DC2, and DC3 is formed by the Knowledge Consistency Checker (KCC) based on administrator-assigned costs, as described in section 1 and [MS-ADTS] section 6.2.

Goal

Replicate originating updates that occurred on one domain controller to the other domain controllers in the domain.

Context of use

Changes need to be replicated within a domain to keep data consistent among domain controllers that store the same directory partitions. This scenario works in a replication topology built by the KCC, as described in section 1 and specified in [MS-ADTS] section 6.2.

Use case diagram for replicating changes in domain data

Figure 32: Use case diagram for replicating changes in domain data

Actors

  • Domain Controller 1 (DC1)

    DC1 is the primary actor and has originating updates to its domain data.

  • Domain Controller 2 (DC2)

    DC2 is a supporting actor that has not yet received the originating updates that were applied to DC1. DC2 is a replication partner of DC1.

  • Domain Controller 3 (DC3)

    DC3 is a supporting actor that has not yet received the originating updates that were applied to DC1. DC3 is a replication partner of DC2.

Stakeholders

  • Domain administrators and applications

    Domain administrators and applications are the entities that change attribute values in domain data.

  • Domain users

    Domain users are the people who depend on the information that is stored in the directory.

For all of these entities, the Active Directory system propagates all changes to domain data to all domain controllers in the domain so that a consistent view of the directory is maintained for all clients, regardless of which domain controller they communicate with.

Preconditions

  • The environment described in section 2.5 is in place, and the system-wide preconditions described in section 2.6 are satisfied. The Active Directory system completes initialization, as described in section 2.6.

  • The KCC has created the replication topology of the domain; that is, the physical connections among the domain controllers of the domain that are used for replication traffic.

Main Success Scenario

Note This Main Success Scenario has no dependency on replication requests between DC1 to DC2 and DC2 to DC3. The order in this scenario has been chosen to show how the changes are replicated from DC1 to DC2 and DC3. This scenario covers scheduled replication, which is described in section 1 and [MS-ADTS] section 3.1.1.1.14.

  1. Trigger: A domain administrator changes an attribute's value for an object in the domain data; the change is manifested as an originating update on DC1.

  2. DC2 identifies its replication partner as DC1.

  3. DC1 and DC2 perform mutual authentication by using Kerberos.

  4. DC2 sends a request to DC1 periodically to obtain the new value.

  5. DC2 applies the change to its replica.

  6. DC3 then identifies its replication partner as DC2.

  7. DC2 and DC3 perform mutual authentication by using Kerberos.

  8. DC3 sends a request to DC2 periodically to obtain the new value.

  9. DC3 applies the change to its replica.

Postcondition

The change to the attribute's value is replicated throughout the domain.

Extensions

None.