FSMO roles: Understanding their special tasks without confusing them with a single “main DC”

1. Core mechanism

This lesson explains the scope of the five operations-master roles, the operations they coordinate, and the different recovery decisions behind transfer and seizure. A role holder is not a universal primary DC.

Interfaces and specifications

• Schema Master: coordinates forest-wide schema changes.
• Domain Naming Master: coordinates adding or removing domains and application partitions at forest scope.
• RID Master: allocates RID pools to DCs in each domain.
• PDC Emulator: has specific responsibilities for password-change priority, account lockout coordination and the domain time hierarchy.
• Infrastructure Master: updates cross-domain object references; whether this work is needed depends on GC placement and the Recycle Bin feature.
• fSMORoleOwner: stores the role holder’s NTDS Settings DN on the relevant directory object.

Five roles, two scopes

There is one Schema Master and one Domain Naming Master per forest. RID Master, PDC Emulator and Infrastructure Master exist separately in each domain. A forest with several domains therefore has the two forest roles plus three roles for each domain.

The first forest-root DC can initially hold all the roles. This does not make it a permanent main DC. Planned transfers can move the roles to other writable DCs.

Where should the Infrastructure Master run?

In a multi-domain forest where only some DCs in a domain are GCs, place the Infrastructure Master on a non-GC DC. A GC holds partial replicas of forest objects, so an Infrastructure Master on a GC does not identify cross-domain references needing updates in the same way. This placement restriction does not apply when all DCs in the domain are GCs or the forest has a single domain.

When the AD Recycle Bin optional feature is enabled, each DC updates its own cross-domain references. Current Microsoft guidance says this leaves no tasks associated with the Infrastructure Master role. The role still has an owner: not needing this work in that configuration does not remove the role or fSMORoleOwner.

A role outage has role-specific effects

If the Schema Master is unavailable, ordinary authentication and most directory writes can continue, but new schema changes cannot be made. During a temporary RID Master outage, DCs can create principals from their existing RID pools. New SID allocation is affected as those pools run out.

A PDC Emulator outage can affect password-change convergence, lockout handling and the time hierarchy. Identify the operation that depends on the role rather than describing every outage as a failed domain.

Transfer and seizure are different recovery decisions

Transfer is a planned handover with a reachable, cooperative current owner. Seizure is a disaster-recovery decision made when the former owner will not return.

Bringing the former owner back online after seizing the Schema Master, Domain Naming Master or RID Master can create conflicting ownership and inconsistent operations. Reusing the former DC requires a metadata and rebuild plan.

State and data flow

1. The request first reaches an ordinary writable DC.
2. If the operation does not require FSMO coordination, the multi-master write path continues.
3. For a role-specific operation, locate the relevant role holder.
4. A reachable owner can coordinate the special operation. Otherwise, the effect is role-specific; temporary loss of connectivity does not prove permanent loss.
5. A planned transfer with a reachable owner and seizure after confirmed permanent loss, with the former owner isolated, are separate recovery paths.

2. Exploitation

Broken trust assumption

Assume an attacker has administrative control of a role-holder DC or access to role-transfer/seizure authority. This lesson provides no attack procedure against a real system.

Technical prerequisites

• Privileged directory administration or high privileges on a role-holder DC are available.
• The organization has concentrated roles on one DC and documented its recovery decisions.

Exploitation mechanism

A role-holder DC is a critical control point for its specific operations. Compromising it does not make it the sole owner of all directory writes, but it can amplify effects on schema, domain topology, RID allocation, or password/time coordination.

A role-holder DC is an impact multiplier

Privileges on the Schema Master affect the schema-change surface; privileges on the PDC Emulator affect password and time operations. Describe impact within the responsibilities of the particular role.

An unplanned seizure can leave the defender with conflicting role ownership. Distinguishing an unreachable owner from one that is permanently lost is therefore a security decision.

3. Defense & Detection

Telemetry scope

• Inventory expected and observed FSMO owners for every forest/domain.
• Correlate fSMORoleOwner changes with change-management records; verify the target-object/attribute SACL and DC audit policy for 5136 monitoring.
• Monitor PDC Emulator time source and replication health separately from other roles.
• For seizure, retain a recovery record showing that the former DC will not return.

Events and relevant fields

• 5136(S) · If the target role-owner object has an attribute-specific Write-audit SACL and Audit Directory Service Changes Success is enabled on a domain controller, a directory-modification record can be generated in the Security channel. A modification typically produces Value Deleted and Value Added records with the same OpCorrelationID; the event alone does not prove an approved transfer/seizure or role-holder health.

Check ownership and the operation separately

Check the relevant directory object’s fSMORoleOwner value together with the role holder’s reachability, rather than relying only on a GUI list. Ownership and health are different observations.

An alert should connect the ownership change to its context: was it an approved transfer or a disaster-recovery seizure, and is the former owner isolated?

Detection logic · XPath

*[System[(EventID=5136)]]

Query assumptions

• This XPath is a broad candidate filter for 5136 records in the Security channel; environment-specific enrichment must identify the role-owner object and AttributeLDAPDisplayName=fSMORoleOwner.
• The event requires Audit Directory Service Changes Success on a DC and a matching Write-audit SACL ACE on the changed attribute.
• A modification typically produces Value Deleted and Value Added records with the same OpCorrelationID; inspect the Value Added record and correlate the prior value.
• The artifact is synthetic, not a Windows or SIEM record.

False positives

• A planned attribute change can occur during an approved role transfer, DC demotion, or recovery.
• Without the audit policy/SACL, 5136 may not be generated; its absence does not prove the current fSMORoleOwner value is correct or unchanged.

Hardening

• Place roles on protected, monitored writable DCs. For the Infrastructure Master, also evaluate GC placement and Recycle Bin state.
• Perform role transfers with delegated least privilege and change approval.
• Require a role-specific seizure runbook, backup, and isolation step for the former owner.
• Use a reliable upstream time source and separate availability monitoring for the PDC Emulator.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}"/><EventID>5136</EventID><Version>0</Version><Level>0</Level><Task>14081</Task><Opcode>0</Opcode><Keywords>0x8020000000000000</Keywords><TimeCreated SystemTime="2026-10-02T08:30:00.0000000Z"/><EventRecordID>1042</EventRecordID><Correlation/><Execution ProcessID="544" ThreadID="720"/><Channel>Security</Channel><Computer>DC01.outreason.example</Computer><Security/></System><EventData><Data Name="OpCorrelationID">{b92c5c32-1bf4-4fd6-a5a2-7a3c43810a21}</Data><Data Name="AppCorrelationID">-</Data><Data Name="SubjectUserSid">S-1-5-21-1111111111-2222222222-3333333333-1104</Data><Data Name="SubjectUserName">svc-change-review</Data><Data Name="SubjectDomainName">OUTREASON</Data><Data Name="SubjectLogonId">0x49001</Data><Data Name="DSName">outreason.example</Data><Data Name="DSType">%%14676</Data><Data Name="ObjectDN">DC=outreason,DC=example</Data><Data Name="ObjectGUID">{671a7f50-7950-4dce-87e5-a5f35e7e055a}</Data><Data Name="ObjectClass">domainDNS</Data><Data Name="AttributeLDAPDisplayName">fSMORoleOwner</Data><Data Name="AttributeValue">CN=NTDS Settings,CN=DC02,CN=Servers,CN=Site-A,CN=Sites,CN=Configuration,DC=outreason,DC=example</Data><Data Name="OperationType">%%14674</Data></EventData></Event>

Two reality checks

Assumption: The FSMO owner is the main DC through which every domain write passes.

In fact: No. AD DS is normally multi-master. FSMO roles assign five specific coordination responsibilities to designated role holders.

Assumption: If an FSMO owner becomes unreachable, the entire domain immediately stops working.

In fact: The effect depends on the role and the duration. Existing RID pools can support further principal creation; ordinary authentication and most writes can continue. Role-specific operations may be affected immediately or later.

Sources

• Microsoft · Planning Operations Master Role Placement
  Forest/domain role scopes, availability, and placement guidance.
• Microsoft · Transfer or seize Operation Master roles
  The distinction between transfer and seizure, and the boundary for bringing the former role owner back online.
• Microsoft · 5136(S) A directory service object was modified
  Event XML field names; DC Security channel; Audit Directory Service Changes subcategory; matching Write SACL for specific attributes; Value Deleted/Value Added and OpCorrelationID semantics.
• Microsoft · Active Directory FSMO roles in Windows
  Infrastructure Master: non-GC placement, all-GC exception and Recycle Bin optional feature behavior. Current supported Windows Server guidance checked 2026-10-03.