Why Two DCs Differ: Metadata, Conflict and Convergence

1. Core mechanism

10.02 described propagation. Here compare the single-valued department attribute of the same objectGUID across two replicas. SYSVOL, linked-value and naming conflicts are neighboring subjects with different rules.

Interfaces and specifications

• dwVersion increases at an originating change; replication alone does not create a new version.
• ftimeLastOriginatingChange is the last originating change time, not its arrival time.
• uuidLastOriginatingDsaInvocationID identifies the originating database instance, not a user.
• usnOriginatingChange belongs to the origin instance; usnLocalChange belongs to the observed replica.

A value and its change stamp

A department=Finance change originates at DC-A. The attribute version advances and records originating time and invocation ID. DC-B preserves that origin information when receiving the change, while assigning its own local USN when applying it.

The table’s origin-A/B values are teaching labels. The native field mapping is listed above; the worksheet is not an API dump. Metadata identifies the originating DC instance; attribution to a person requires separate audit history.

Is 9000 newer than 14000?

You cannot use localUSN=9000 at DC-A and localUSN=14000 at DC-B as a global timeline. They belong to different database instances’ local ordering. The same change can receive different local USNs on two DCs.

First establish that objectGUID, attribute and naming context match. Then compare originating metadata. Expecting convergence for different objects or a non-replicated attribute addresses the wrong question.

Conflict is not decided by time alone

In the example, A has version=4 at 09:00 and B has version=3 at 09:05. The higher version takes precedence, selecting Finance here. A rule based only on the later timestamp predicts the wrong result.

With equal versions, originating times are compared; a further deterministic originating-DSA tie-break resolves equal times. The teaching labels do not emulate UUID ordering. An equal-version/equal-time case remains an explicit limit of this model.

Separate convergence from application state

If writes stop and changes successfully propagate, this single-attribute example converges to a common value. That does not create one simultaneous forest snapshot. A multi-object read can combine objects observed across intervening changes.

Converged directory values do not recreate existing tokens, Kerberos tickets or SMB sessions. Context age in 08.01 differs from replica age here. Closure requires both directory observations and behavior under a new resource context.

Not every attribute is replicated

badPwdCount can differ while department has converged. This attribute is maintained separately at each DC and is not replicated. Its differing values are not subject to the same convergence expectation as department metadata.

State and data flow

1. Take two snapshots for the same objectGUID, attribute and naming context.
2. An originating write on DC-A produces a version and origin stamp.
3. During replication delay, DC-B can continue showing the previous value.
4. Conflicts compare version, then originating time; an exact tie requires a separate tie-break.
5. Applying the winning change preserves its origin information and changes the destination local USN.
6. Convergence aligns the relevant directory state; actor audit and sessions remain separate.

2. Exploitation

Broken trust assumption

Treating one DC’s view as forest-wide truth and the largest local USN as the latest change.

Technical prerequisites

• An impact claim requires the relevant target, effective right and observed context.

Exploitation mechanism

An invalid comparison can lead to undoing a legitimate update or trusting the wrong replica. Metadata carries origin information; attributing it to a user or malicious intent requires separate audit evidence.

Effective value and actor are different questions

A winning write does not establish that it was approved. A delayed replica does not establish deliberate interference either. Evaluate permissions and change ownership separately from the outcome.

Do not generalize the rule to other data types

This example covers the single-valued department attribute. Linked-value group membership or naming conflicts require their own rules, rather than this copied comparison.

3. Defense & Detection

Telemetry scope

• Record objectGUID, attribute, naming context, DC instance and snapshot time. Partner and last-successful-replication evidence narrow diagnosis; inspect audit separately for user attribution.

Events and relevant fields

• Event records reflect their producer’s decision under applicable generation and collection conditions; they do not establish the entire access chain.

Preserve the scope of evidence

Record objectGUID, attribute, naming context, DC instance and snapshot time. Partner and last-successful-replication evidence narrow diagnosis; inspect audit separately for user attribution.

Do not treat an absent event as negative evidence without generation and collection coverage. Verify new behavior at its responsible owner.

Detection logic · XPath

*[System[(EventID=5136)]]

Query assumptions

• This selects candidate events only in applicable Windows Security logs. The lesson JSON worksheet is not a Windows event.
• Record objectGUID, attribute, naming context, DC instance and snapshot time. Partner and last-successful-replication evidence narrow diagnosis; inspect audit separately for user attribution.

False positives

• Legitimate changes, context/cache reuse or temporary connectivity issues can produce the same symptom; this selection does not classify an attack.

Hardening

• Check replication dependencies, partner reachability and time health as distinct conditions.
• Do not close on one replica; verify views of the relevant naming context and object.
• Correlate change approval with audit sources; do not infer a person from replication metadata.

Read the examples

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "N02",
  "attribute": "department",
  "objectIdentity": "toy-17",
  "DC-A": {
    "value": "Finance",
    "version": 4,
    "originTime": "2026-10-01T09:00:00Z",
    "originInvocationId": "origin-A",
    "originUSN": 80,
    "localUSN": 9000
  },
  "DC-B": {
    "value": "Ops",
    "version": 3,
    "originTime": "2026-10-01T09:05:00Z",
    "originInvocationId": "origin-B",
    "originUSN": 120,
    "localUSN": 14000
  }
}

Two reality checks

Assumption: The greater local USN means a newer value.

In fact: A local USN orders changes within its database instance. Compare origin stamps across replicas.

Assumption: The DCs converged, so existing sessions are current.

In fact: Directory replication does not regenerate tokens, tickets or application sessions. Verify new-context behavior separately.

Sources

• AD DS replication behavior
  Replication behavior overview
• Troubleshoot AD replication
  Dependencies; resolution methods; event/error tables; showrepl fields
• Historical AD replication model
  Originating/replicated updates; metadata; filtering; conflict resolution stamp
• DS_REPL_ATTR_META_DATA
  Members: version, time, originating DSA/invocation ID, originating/local USN
• MS-ADTS glossary — replication
  originating update; replicated update; replication; stamp; USN
• Bad-Pwd-Count attribute
  Remarks: non-replicated and maintained separately on each DC