ADDOM-006: FSMO Role Holder Identification
- Platform
- Active Directory
- Category
- AD Domain & Forest Configuration
- Severity
- Info
- Zero Trust pillar
- Governance (weight 0)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
The check resolves all five FSMO role owners by reading the fSMORoleOwner attribute (an NTDS Settings DN) from the directory object that anchors each role: - Schema Master: fSMORoleOwner on CN=Schema,CN=Configuration,DC=forestRoot - Domain Naming Master: fSMORoleOwner on CN=Partitions,CN=Configuration,DC=forestRoot - RID Master: fSMORoleOwner on CN=RID Manager$,CN=System,DC=domain - PDC Emulator: fSMORoleOwner on the domain naming context root (DC=domain) - Infrastructure Master: fSMORoleOwner on CN=Infrastructure,DC=domain Each DN points to the NTDS Settings object (CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<Site>,CN=Sites,CN=Configuration,DC=forestRoot). The check walks that DN to the parent server object and reports the holder by short name, FQDN, site, and operating system. It also records the forest functional level (msDS-Behavior-Version on the Partitions container) and the domain functional level (msDS-Behavior-Version on the domain root) because role-holder DC OS version interacts with the supported functional level. The audit logic is read-only and uses the Configuration NC and the domain NC; no role transfer is attempted.
Why it matters
FSMO roles are the single points of authority for forest-wide and domain-wide operations that must not run in a multi-master mode. The Schema Master is the only DC that accepts schema updates (extending the schema for Exchange, ADCS, or any LDAP-aware product fails if the Schema Master is unreachable). The Domain Naming Master is the only DC that can add or remove domains and application partitions. The RID Master is the only DC that hands out RID pools; if it is offline long enough for issuing DCs to exhaust their pools, new security principal creation stops domain-wide. The PDC Emulator is authoritative for time, password change replication, account lockout processing, GPO write authority via the central policy store, and DFS-N consistency; its compromise is functionally a domain compromise. The Infrastructure Master maintains phantom records for cross-domain references and must not be on a Global Catalog in a multi-domain forest with non-replicated naming contexts (the legacy guidance, still relevant where a forest has more than one domain and not every DC is a GC). From a security perspective, every FSMO holder is by definition Tier-0: it stores krbtgt, holds replication rights, and (for the PDC Emulator) is the privileged target for ms-DS-MachineAccountQuota abuse, Zerologon (CVE-2020-1472), and PetitPotam-style coercion (CVE-2021-36942) chained into ADCS ESC8 relay. Unknown or stale role placement breaks DR: a role stranded on a seized DC cannot be transferred and must be seized with ntdsutil, which is destructive if the original holder ever returns to the network. Operational risk and security risk converge on the same control: know where the roles live, keep them on hardened tier-0 DCs, and document the seizure procedure.
Attack path
1. Enumeration: any authenticated user reads fSMORoleOwner with netdom query fsmo, Get-ADForest, Get-ADDomain, or LDAP (ldapsearch -s base -b "" "(objectClass=*)" namingContexts then a base search on each anchor object). The attributes are world-readable by default. 2. Target selection: the attacker identifies the PDC Emulator as the highest-value target. PDC Emulator placement determines the host that processes NTLM pass-through, holds krbtgt, and is the canonical Netlogon endpoint for Zerologon (CVE-2020-1472) and PetitPotam coercion. 3. Coercion or RCE: the attacker triggers MS-EFSRPC EfsRpcOpenFileRaw against the PDC Emulator (PetitPotam) to coerce machine-account NTLM auth, or attempts the Netlogon secure-channel reset against the same host (Zerologon). 4. Pivot: a successful Zerologon attack resets the PDC Emulator machine account password to empty and gives the attacker DC-level DRSUAPI rights. The attacker then runs DCSync (T1003.006) to extract krbtgt and forges a Golden Ticket (T1558.001). 5. Persistence: with krbtgt extracted and the forest functional level mapped from ADDOM-006 output, the attacker calibrates the Golden Ticket lifetime to match domain ticket policy and avoid easy detection. The enumeration step is silent: fSMORoleOwner reads do not raise security events at default audit policy. Knowing the PDC Emulator host name in advance lets the attacker skip noisy DC scanning and go straight to the highest-impact target.
How Guerrilla assesses it
Guerrilla calls Get-ADForest and Get-ADDomain for each domain in the forest and reads the SchemaMaster, DomainNamingMaster, RIDMaster, PDCEmulator, and InfrastructureMaster properties. Internally these wrap the same five fSMORoleOwner reads listed above. For each holder the check resolves the NTDS Settings DN to a server object and pulls Site, OperatingSystem, OperatingSystemVersion, and IPv4Address from Get-ADComputer. Cross-checks: (a) every role holder is reachable on LDAP port 389 (a stranded role is flagged); (b) the Infrastructure Master is not a Global Catalog when the domain is one of multiple in the forest and partial attribute set replication is in scope; (c) the PDC Emulator OS is current (Windows Server 2019 or later as of 2026, fully patched against CVE-2020-1472 and CVE-2022-26923); (d) all five roles in a single-domain forest are accounted for on supported DCs. The finding is informational and lists the holder for each role, the site, and the OS; downstream checks (ADDOM-007 through ADDOM-020, ADKERB-001 through ADKERB-011, ADPRIV series) consume this map.
Recommended value
All FSMO roles documented, placed on reliable DCs, and included in DR planning
Remediation
Run 'netdom query fsmo' or query the AD schema and domain partitions to identify role holders. Document roles and verify they are on highly available DCs. Transfer roles if current holders are inappropriate
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| clean | PASS |
| known-bad | WARN |
| throttled | Not Assessed |
Framework mappings
- NIST SP 800-53
- CP-2, CM-8
- CIS AD Benchmark
- 1.1.4
- MITRE ATT&CK
- T1018