ADDOM-006: Identificación de los titulares de roles FSMO
- Plataforma
- Active Directory
- Categoría
- AD Domain & Forest Configuration
- Severidad
- Info
- Pilar de Zero Trust
- Governance (peso 0)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
Los cinco roles FSMO (Schema Master, Domain Naming Master, RID Master, PDC Emulator, Infrastructure Master) deben documentarse y ubicarse en los controladores de dominio apropiados. Conocer la ubicación de los roles es esencial para la recuperación ante desastres y la conciencia operativa
Por qué importa
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.
Ruta de ataque
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.
Cómo lo evalúa Guerrilla
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.
Valor recomendado
Todos los roles FSMO documentados, ubicados en DC fiables e incluidos en la planificación de recuperación ante desastres
Remediación
Ejecute 'netdom query fsmo' o consulte el esquema de AD y las particiones de dominio para identificar a los titulares de los roles. Documente los roles y verifique que estén en DC de alta disponibilidad. Transfiera los roles si los titulares actuales no son apropiados
Veredictos probados con fixtures
Cada veredicto de esta tabla está probado por un fixture de referencia en la suite de pruebas que valida el módulo. La tabla se deriva de la última ejecución en verde; no puede editarse a mano.
| Escenario | Veredicto esperado |
|---|---|
| clean | PASS |
| known-bad | WARN |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- CP-2, CM-8
- CIS AD Benchmark
- 1.1.4
- MITRE ATT&CK
- T1018