Domain Controller Operations Design
What this page covers
Section titled “What this page covers”This page outlines how to place, protect, and recover Domain Controllers (DCs) in Active Directory Domain Services (AD DS). Using official Microsoft sources, it compares a typical multi-DC deployment with RODCs.
It focuses on four points:
- Multiple DCs in one domain are generally peer writable DCs, not a parent-child hierarchy.
- Operations Master / FSMO roles still exist for certain tasks that do not fit well with multi-master replication.
- A Read-Only Domain Controller (RODC) can provide local authentication at a site that is hard to secure physically while limiting credential exposure.
- Recovering from a DC failure differs from recovering from a DC compromise.
Official sources are collected under “Official references” at the end. The content is based on Microsoft Learn and other official Microsoft documentation as of July 12, 2026.
Key points
Section titled “Key points”An Active Directory environment generally does not have a “parent DC01” that DC02 and DC03 follow as subordinates.
Writable DCs in the same domain are generally peers in a multi-master configuration. Each provides Kerberos Key Distribution Center (KDC), LDAP, and Netlogon services and holds a replica of the AD DS database. Microsoft’s AD DS overview also explains that every DC in a domain holds a complete copy of that domain’s directory information and that changes to directory data are replicated to the domain’s DCs.
They are not completely identical in every respect. The Schema Master, Domain Naming Master, RID Master, PDC Emulator, and Infrastructure Master are Operations Master / FSMO roles that assign particular conflict-prone tasks to one role holder.
Deploying multiple writable DCs improves availability, but does not divide the security boundary. Microsoft explains that privileged access to a DC permits modification, destruction, or corruption of the AD DS database and threatens all systems and accounts managed by AD. Treat every writable DC as Tier 0.
An RODC comes closest to the requirement to continue local authentication while protecting the whole domain from a compromised site DC. Its read-only AD DS database, unidirectional replication, credential caching, Password Replication Policy (PRP), and dedicated RODC krbtgt account limit the impact of a site compromise.
Multiple writable DCs = Improve availability, maintainability, and geographic distribution != Separate privileges within the domain
RODC = Restrict writes and credential caching = Reduce exposure at physically less secure sites
Separate forest = Stronger administrative and security boundary = Much greater DNS, trust, certificate, and operational overheadTypical multi-DC deployment
Section titled “Typical multi-DC deployment”Suppose one domain has multiple writable DCs.
Domain: corp.example.com
DC01 Writable DC / KDC / LDAP / Netlogon / DNSDC02 Writable DC / KDC / LDAP / Netlogon / DNSDC03 Writable DC / KDC / LDAP / Netlogon / DNSIn this example, DC01 is not the parent in the AD structure, with DC02 and DC03 subordinate to it. Unlike the Windows NT Primary Domain Controller (PDC) / Backup Domain Controller (BDC) model, AD DS lets writable DCs accept changes to the same domain partition and replicate them to other DCs.
DCs generally perform these roles:
- Hold the AD DS database and provide directory services.
- Issue TGTs and TGSs as Kerberos KDCs.
- Provide LDAP directory queries and modifications.
- Run Netlogon for DC Locator and secure-channel operations.
- Provide AD-integrated DNS.
- Distribute SYSVOL and Group Policy Objects (GPOs).
- Serve as Global Catalog (GC) servers. Not every DC must be a GC, though making all DCs GCs is common in modern single-forest, single-domain deployments.
The Kerberos KDC is integrated with Windows Server security services on the DC and uses the domain’s AD DS database as its security account database. Kerberos authentication therefore originates from the KDC on a DC; a DC is more than an LDAP server.
[Client] | AS-REQ / TGS-REQ v[DC/KDC] -- Reads AD DS database --> [User / Computer / Service Account] | +-- Issues TGT / Service TicketFinding a DC: DNS and DC Locator
Section titled “Finding a DC: DNS and DC Locator”Clients usually find a DC through DNS and DC Locator rather than sending Kerberos traffic to a load balancer’s Virtual IP (VIP).
Microsoft’s Active Directory Structure and Storage Technologies explains that Active Directory uses DNS to locate domain controllers. Domain-joined computers use DNS to find DCs for authentication, updates, searches, and other operations. Locator, implemented in the Net Logon service, provides the mechanism clients use to find DCs.
Conceptually, the flow is:
Client | | DNS / DC Locator v_ldap._tcp.dc._msdcs.corp.example.com_kerberos._tcp.dc._msdcs.corp.example.com | vDC01 / DC02 / DC03In practice, define subnets and sites in AD Sites and Services so clients can select a nearby DC.
Tokyo Site Subnet: 10.10.0.0/16 DCs : DC-TKY01, DC-TKY02
Factory Site Subnet: 10.40.0.0/16 DCs : RODC-FAC01Microsoft’s replication concepts describe subnets as identifying physical proximity and sites as collections of fast, reliable TCP/IP subnets. This optimizes network use for replication and directory access.
Example commands to check the environment:
# DC currently used for logon$env:LOGONSERVER
# Find a DC through DC Locatornltest /dsgetdc:corp.example.com
# List DCs in the domainnltest /dclist:corp.example.com
# If AD PowerShell is availableGet-ADDomainController -Filter * | Select-Object HostName,Site,IsGlobalCatalog,OperationMasterRolesReplication and convergence
Section titled “Replication and convergence”AD DS uses multi-master replication. Most directory data is replicated to other DCs regardless of which writable DC receives the change.
Change a user attribute on DC01 | vReplicate to DC02 / DC03Microsoft states that AD DS supports multimaster replication of directory data: any DC can accept directory changes and replicate them to other DCs. Changes do not reach every DC instantly, however, because of intersite network latency, replication schedules, failures, and KCC topology.
The Knowledge Consistency Checker (KCC) runs on every DC and builds the forest’s replication topology. Intrasite and intersite replication use separate topologies; intrasite connections among writable DCs use a bidirectional ring and shortcut connections to reduce latency.
Operations should therefore assume eventual convergence with possible temporary differences.
1. Add a group member on DC012. Immediately query DC02 through LDAP3. DC02 does not show the change yet4. It appears on DC02 after replicationA common troubleshooting case in HTB or test environments:
bloodyAD -> Adds a group member on DC01NetExec -> Queries DC02 through LDAPResult -> The principal does not yet appear to be a memberDuring an investigation, record which DC received the change and which DC was queried.
# Replication summaryrepadmin /replsummary
# Replication state for each DCrepadmin /showrepl
# Example forced synchronization; check impact and permissions first in productionrepadmin /syncall /AdePOperations Masters and FSMO
Section titled “Operations Masters and FSMO”AD DS is multi-master, but making every operation multi-master would create conflicts or consistency problems. Therefore, certain tasks are assigned to a single holder through Operations Master / Flexible Single Master Operations (FSMO) roles.
Microsoft’s Operations Master Role Placement explains that some changes, such as schema modifications, are impractical to perform with multimaster replication, so an operations master accepts requests for those specific changes.
| Scope | Operations Master / FSMO | Main role |
|---|---|---|
| Forest | Schema Master | Manages schema changes |
| Forest | Domain Naming Master | Manages adding and removing domains or directory partitions |
| Domain | RID Master | Manages the domain’s global RID pool and allocates local RID pools to DCs |
| Domain | PDC Emulator | Important for password updates, rechecking password mismatches, and time synchronization design |
| Domain | Infrastructure Master | Maintains references to security principals in other domains |
An FSMO holder is not a “parent DC.” Normal authentication, LDAP queries, and many directory updates can be handled by DCs that do not hold FSMO roles. An FSMO role handles specific conflict-prone tasks and can be transferred or seized after a failure.
Why the PDC Emulator is mistaken for the “main DC”
Section titled “Why the PDC Emulator is mistaken for the “main DC””The PDC Emulator is prominent in operations. Microsoft explains that it handles client password changes. When logon authentication on another DC fails because of a bad password, that DC forwards the authentication request to the PDC Emulator before rejecting it.
Example:
1. A user changes a password through DC022. Immediately afterward, a client logs on through DC033. The password change has not yet replicated to DC034. DC03 checks with the PDC Emulator to account for the new passwordThis behavior leads some operators to call the DC holding the PDC Emulator role the “main DC.” It does not imply a parent-child relationship among DCs in AD’s logical structure.
An RODC cannot hold FSMO roles
Section titled “An RODC cannot hold FSMO roles”An Operations Master role holder must be able to write to the AD database. An RODC is read-only, so it cannot hold FSMO roles.
Commands to check role holders:
netdom query fsmo
Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster
Get-ADForest | Select-Object SchemaMaster,DomainNamingMasterWhy deploy multiple writable DCs
Section titled “Why deploy multiple writable DCs”Multiple DCs are deployed primarily for availability, locality, and maintainability, not security isolation.
Availability
Section titled “Availability”If DC01 stops, DC02 and DC03 can still provide Kerberos, LDAP, DNS, and Netlogon.
Client -> DC01 fails -> DNS / DC Locator -> Obtains a TGT from DC02With only one DC, its failure can stop domain logons, LDAP queries, AD-integrated DNS, GPO application, and other functions together. A single DC is sufficient for a test environment, but production environments generally deploy multiple DCs in the same domain.
Geographic distribution
Section titled “Geographic distribution”A DC or RODC at each site reduces authentication and directory queries across the WAN.
Headquarters Site DC-HQ01 DC-HQ02
Factory Site RODC-FAC01Microsoft describes RODCs as designed for remote or branch offices with relatively few users, weak physical security, limited network bandwidth, or limited IT expertise.
Maintainability
Section titled “Maintainability”DCs can be restarted, updated, and replaced in turn.
DC01 under maintenance -> DC02 / DC03 continue authenticationDC01 returnsDC02 under maintenance -> DC01 / DC03 continue authenticationHowever, multiple DCs alone may not provide the expected redundancy if FSMO roles, Global Catalog, DNS, DHCP options, firewalls, monitoring agents, backups, or certificate autoenrollment depend on one particular DC.
Risks of adding writable DCs
Section titled “Risks of adding writable DCs”Adding writable DCs improves availability but does not subdivide the security boundary.
Microsoft’s DC security guidance describes DCs as the physical storage location of the AD DS database and as providers of the services and data enterprises use to manage servers, workstations, users, and applications. It also states that privileged access to a DC can let an attacker modify, corrupt, or destroy the AD DS database, affecting every system and account managed by AD.
Thus, every writable DC in the same domain is Tier 0.
DC01 compromised | +-- Write to the AD DS database +-- Reach credentials and secrets +-- Modify GPOs / ACLs / group membership +-- Replicate changes to other DCs vEntire Domain / Forest at riskTypical effects:
- Credential exposure from
NTDS.ditor LSASS. - Abuse of Directory Replication Service Remote Protocol (DRSR) rights to extract credentials, as in DCSync.
- Compromise of the
krbtgtkey and the risk of forged Kerberos tickets, or Golden Tickets. - Changes to Domain Admins, Enterprise Admins, AdminSDHolder, GPOs, logon scripts, or startup scripts.
- Spread to other Tier 0 assets, including AD CS (Active Directory Certificate Services), Microsoft Entra Connect, backup systems, and monitoring systems.
- Malicious directory changes propagated as legitimate changes through replication.
In particular, krbtgt is the service account the KDC uses to issue Kerberos tickets. Microsoft’s description of Event 4768 also notes that DCs have a specific service account, krbtgt, used by the KDC service to issue Kerberos tickets.
Failure recovery differs from compromise recovery
Section titled “Failure recovery differs from compromise recovery”For a DC disk or OS failure, normal recovery focuses on promoting a replacement from a remaining DC, restoring from a system-state backup, or performing metadata cleanup.
A DC compromise, however, is not resolved merely by rebuilding the compromised DC.
Microsoft’s forest recovery guide includes resetting administrative account passwords, completely resetting the krbtgt account password, and resetting trust passwords when needed if a security breach is suspected. Because krbtgt retains two password generations, it explains that resetting the password twice removes the original password from history.
Failure: DC outage, replication failure, DNS failure -> Restore availability and consistency
Compromise: Attacker reaches AD's root of trust -> Requires trusted backups, privileged credential resets, krbtgt resets, and persistence investigationProtect DCs as Tier 0
Section titled “Protect DCs as Tier 0”In Microsoft’s AD DS tier model, Tier 0 is the identity control plane. It includes DCs, AD CS, AD FS, Microsoft Entra Connect, and Tier 0 admin accounts/groups. Tier 0 assets and identities effectively control one another, so protect them to the same standard.
Basic principles:
- Treat DCs as single-purpose servers: do not run business applications, file serving, web browsing, or general administration tools on them.
- Do not use high-privilege accounts such as Domain Admins for everyday work.
- Use Tier 0 admin identities only from Tier 0 Privileged Access Workstations (PAWs) or secure administrative hosts.
- Restrict principals allowed RDP or interactive logon to DCs to the smallest possible set.
- Keep DC operating systems as current as the organization can support.
- Use Server Core where possible to reduce the attack surface and human error.
- Separate DC patch and configuration management from ordinary servers so compromise of general management infrastructure does not directly compromise DCs.
- Restrict internet access and web browser use from DCs.
- Consider secure racks/cages, TPM, and BitLocker for physical DCs.
- Where possible, place virtual DCs on virtualization hosts, storage, and administrative boundaries separate from ordinary workloads.
The principle of not managing a trusted system from a less-trusted host is especially important. Entering Tier 0 credentials on a Tier 1 or Tier 2 device breaks the Tier 0 boundary.
RODCs: branch DCs without write access
Section titled “RODCs: branch DCs without write access”A Read-Only Domain Controller (RODC) provides DC functions at a branch office or remote location that is difficult to secure physically.
Headquarters DC-HQ01 Writable DC DC-HQ02 Writable DC
Factory RODC-FAC01 Read-Only DCMicrosoft describes RODCs as holding read-only partitions of the AD DS database, allowing DCs to be deployed more safely in locations that cannot provide the same physical security as writable DCs.
Main features:
| Feature | Meaning |
|---|---|
| Read-only AD DS database | Ordinary writes do not occur on the RODC’s AD DS database |
| Unidirectional replication | Changes do not replicate from the RODC to a writable DC |
| Credential caching | Only some user/computer credentials are cached according to the PRP |
| Administrator role separation | Branch staff can be delegated local RODC administration without domain admin rights |
| Read-only DNS | A DNS server can run on the RODC, but its DNS data is read-only |
| Dedicated RODC krbtgt | Each RODC has a different krbtgt account and password |
An important RODC property is that credential caching is minimal by default. Microsoft states that an RODC does not store user or computer credentials by default, except for its own computer account and its special krbtgt account. Caching any other credentials must be explicitly allowed.
Impact of compromising a writable DC versus an RODC
Section titled “Impact of compromising a writable DC versus an RODC”For a writable DC:
DC-FAC01 compromised | +-- Reach important domain credentials +-- Compromise the krbtgt key +-- Modify AD objects / GPOs / ACLs vEntire domain at riskFor an RODC:
RODC-FAC01 compromised | +-- RODC-specific krbtgt +-- Cached account credentials +-- Readable AD information vImpact mainly limited to that RODC and cached accountsMicrosoft explains that RODCs sign or encrypt TGT requests using a krbtgt account and password different from those of writable DCs. Compromising an RODC’s krbtgt therefore has a different scope from compromising the normal domain krbtgt.
This does not mean an RODC is inherently safe. It reduces the potential impact; it is not an absolute barrier.
Password Replication Policy (PRP)
Section titled “Password Replication Policy (PRP)”The PRP determines which user and computer credentials may be replicated to and cached on an RODC.
Example:
Allowed RODC Password Replication: - Factory-Users - Factory-Computers - Factory-Local-Support
Denied RODC Password Replication: - Domain Admins - Enterprise Admins - Schema Admins - Account Operators - Server Operators - HQ-AdminsAuthentication flow:
When the WAN is available:User -> RODC -> Forward authentication to a writable DC | +-- If PRP permits it, replicate/cache the credential on the RODC
When the WAN is disconnected:User -> Authenticate with credentials cached on the RODCPRP design involves a trade-off:
- A wider cache lets more users authenticate locally during a WAN outage.
- A wider cache also increases the number of credentials that may be stolen if the RODC is compromised.
- Do not cache high-privilege accounts on an RODC.
- Do not let Domain Admins log on interactively to an RODC.
Consider the choice to use an RODC as follows:
Writable DC = Can authenticate a broad range of accounts during a WAN outage = A site compromise can threaten the whole domain
RODC = Accounts that can authenticate during a WAN outage depend on the PRP / cache = Easier to limit credential exposure after a site compromiseRODC limitations
Section titled “RODC limitations”An RODC is a strong option, but poor design weakens its benefits.
Exposure of cached credentials
Section titled “Exposure of cached credentials”Accounts whose credentials are cached on an RODC are within the scope of an RODC compromise. Making the Allowed group too broad removes much of the RODC’s advantage.
Administrator sessions undermine protection
Section titled “Administrator sessions undermine protection”If a Domain Admin logs on interactively to an RODC, high-privilege credentials or tokens that the RODC should not cache may be exposed locally.
Domain Admin connects to RODC through RDP | +-- Logon session / token / credential material exposed vRODC design provides less protectionMicrosoft’s RODC documentation explains that administrator role separation allows local RODC maintenance to be delegated to a domain user without granting admin rights over the domain or other DCs. The design therefore assumes branch staff receive only local RODC administration, not domain-wide admin rights.
AD information remains enumerable
Section titled “AD information remains enumerable”Although an RODC is read-only, it holds many AD objects and attributes. Users, groups, computers, SPNs, ACLs, and GPO links can still be used to analyze attack paths.
RODC compromised | +-- LDAP read +-- SPN enumeration +-- group / ACL enumeration vProvides material for planning lateral movementBlocking writes is not a universal solution
Section titled “Blocking writes is not a universal solution”LDAP write requests on an RODC are referred to a writable DC. Some applications may have RODC compatibility issues. Its DNS is also read-only, so client updates need to be understood.
Design the filtered attribute set
Section titled “Design the filtered attribute set”The RODC filtered attribute set prevents credential-like data, such as passwords, credentials, and encryption keys, from replicating to the RODC. System-critical attributes cannot be added, however. Check the forest functional level and presence of legacy DCs because forests with older DCs have additional constraints.
Separation by domain and forest
Section titled “Separation by domain and forest”Adding DCs does not divide a security boundary. To consider separation, understand the domain and forest structure.
Forest: example.com
Root Domain: example.com
Child Domains: corp.example.com factory.example.comA child domain’s DC is not a subordinate server of the parent domain’s DC. Each domain has its own domain partition, and each DC acts as a KDC for the domain it belongs to.
DC01.example.com -> DC / KDC for example.com
DC01.factory.example.com -> DC / KDC for factory.example.comKerberos authentication to a service in another domain uses trusts and referral tickets.
A domain split does not provide complete security isolation. Microsoft’s Active Directory Structure and Storage Technologies calls the forest the security boundary of the logical structure: domains provide data and service autonomy, but not isolation. It also describes a forest as one self-contained directory whose administrators have full control over information and DCs within that forest.
Consider separate forests when stronger separation is required.
corp.example Forestfactory.example Forest | +-- Limited Forest TrustSeparate forests, however, bring these costs:
- Design for name resolution, DNS forwarding, and conditional forwarders.
- Design of forest trusts and selective authentication.
- Separation of AD CS, PKI, and certificate mapping.
- Separation of identity lifecycle, groups, GPOs, and device management.
- More application compatibility issues and operational procedures.
- Duplicate audit, SIEM, EDR, backup, and disaster recovery arrangements.
Decide first whether the goal is a separate security boundary or separate administrative delegation and replication scope.
Authentication policies, silos, and tiering
Section titled “Authentication policies, silos, and tiering”Protecting privileged accounts requires more than DC placement. Microsoft describes Authentication Policies and Authentication Policy Silos as ways to confine high-privilege credentials to systems associated with selected users, computers, and services.
Examples of what an authentication policy can do:
- Shorten an account’s Kerberos TGT lifetime and make it non-renewable.
- Restrict which devices a user can sign in from.
- Restrict which hosts can use service account credentials.
- Limit service ticket issuance based on access control conditions.
Microsoft states that authentication policies are enforced during the Kerberos AS and TGS exchanges. The KDC therefore applies the controls when issuing TGTs and TGSs.
For privileged operations, use these mechanisms together:
| Goal | Main mechanism |
|---|---|
| Keep Tier 0 credentials off lower-tier devices | Tier model / PAW / secure administrative host |
| Restrict where high-privilege accounts can be used | Authentication Policies / Silos |
| Avoid legacy authentication methods | Protected Users group / Kerberos AES |
| Reduce credentials stored at branch sites | RODC / PRP |
| Reduce the DC’s own attack surface | Server Core, no web browsing, dedicated patch management, minimal logons |
Logs to watch in operations
Section titled “Logs to watch in operations”Kerberos authentication leaves many traces in DC Security logs.
| Event ID | Meaning | Main points to inspect |
|---|---|---|
| 4768 | Kerberos TGT requested | AS-REQ / TGT issuance; generated on a DC |
| 4769 | Kerberos service ticket requested | TGS request; generated on a DC |
| 4771 | Kerberos pre-authentication failed | Password spraying, clock skew, or pre-authentication failure |
| 4776 | NTLM authentication | NTLM fallback, legacy systems, or relay risk |
Microsoft’s official Event 4768 description says the event is generated whenever the KDC issues a TGT and only on domain controllers. Event 4769 is likewise generated on domain controllers whenever the KDC receives a TGS ticket request.
Points to investigate:
- Which DC issued the TGT or TGS?
- Which client does
IpAddressidentify? - Does
ServiceNameidentifykrbtgtor a particular SPN? - Is
TicketEncryptionTypeusing a legacy type such as RC4? - Does a failure code suggest password spraying, clock skew, service ticket expiration, or policy rejection?
- Is there an Authentication Policy / Silo failure event?
# Kerberos ticket cacheklistklist tgtklist tickets
# Example of viewing the Security log on a DCGet-WinEvent -FilterHashtable @{ LogName = 'Security' Id = 4768} -MaxEvents 20Operational health checks
Section titled “Operational health checks”Representative commands:
| Goal | Command |
|---|---|
| Current logon DC | $env:LOGONSERVER |
| Check DC Locator | nltest /dsgetdc:corp.example.com |
| List DCs in the domain | nltest /dclist:corp.example.com |
| Check FSMO holders | netdom query fsmo |
| Replication summary | repadmin /replsummary |
| Replication by DC | repadmin /showrepl |
| DC / DNS / Netlogon health | dcdiag /v |
| Check secure channel | nltest /sc_verify:corp.example.com |
| Check Kerberos tickets | klist |
| Check time synchronization | w32tm /query /status |
| Check DNS SRV records | nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com |
Items to check regularly:
- Is replication succeeding on all DCs?
- Are there signs of lingering objects or USN rollback?
- Are FSMO holders as expected, and is there a standby plan?
- Is the PDC Emulator using the correct time source?
- Is a Global Catalog present at sites that need one?
- Are DNS SRV records stale?
- Are the RODC’s PRP allowed, denied, and cached lists too broad?
- Have Domain Admins or similar users logged on interactively to a DC or RODC unnecessarily?
- Have DCs accessed the internet or launched web browsers?
- Are unnecessary agents, tools, or business workloads running on DCs?
Typical design patterns
Section titled “Typical design patterns”| Goal | Configuration | Considerations |
|---|---|---|
| Resilience at one site | At least two writable DCs | Make DNS / GC / FSMO / backups redundant too |
| Faster authentication at a remote site | Branch DC or RODC | Choose based on physical security and WAN conditions |
| Site that cannot be secured physically | RODC with a strict PRP | Do not cache high-privilege accounts; avoid admin logons |
| Authenticate many accounts during WAN outages | Writable DC | A site compromise creates substantial domain-wide risk |
| Limit credential exposure after a site compromise | RODC | Smaller caches are safer but reduce who can authenticate during WAN outages |
| Strongly separate administrative boundaries | Separate forests with a trust | Greater operational effort and more application, certificate, and audit design |
| Protect privileged accounts | Tier model / PAW / Authentication Policy / Protected Users | DC placement alone does not provide protection |
| Recover from DC compromise | Forest recovery plan / trusted backup / two krbtgt resets | Procedures differ from ordinary failure recovery |
Differences between HTB and production environments
Section titled “Differences between HTB and production environments”HTB labs often have only one DC, chiefly to simplify the environment and conserve resources. In production, BloodHound or LDAP enumeration may reveal multiple DCs.
DC01.CORP.LOCALDC02.CORP.LOCALRODC01.BRANCH.CORP.LOCALThe important question is not only which DC can be reached:
- Which AD Site is your device in?
- Which DC handles an LDAP query?
- Which DC received the object change?
- Has the change replicated to the target DC?
- Which KDC issued a Kerberos TGT or TGS?
- Is the target a writable DC or an RODC?
- Where are the FSMO roles?
- Does the query need a Global Catalog?
- Are DNS SRV records stale?
Example during an attack or test:
1. Change group membership on DC012. Query DC02 through LDAP3. DC02 does not yet show the change4. Query DC01 explicitly and see the change5. See the change on DC02 after replicationDefender-side example:
1. Use Event 4768 to identify the TGT-issuing DC and client IP2. Use Event 4769 to identify the requested service / SPN3. Check replication delay with repadmin4. Use nltest to identify the DC selected by the clientDesign checklist
Section titled “Design checklist”Before placing a new DC or RODC, check:
- Does the site require a writable DC, or is an RODC sufficient?
- Are physical locks, racks, TPM, BitLocker, and host isolation adequate?
- Who must be able to authenticate during a site WAN outage?
- Are the RODC’s PRP allowed and denied groups minimized?
- Do operational procedures prevent Domain Admins and Enterprise Admins from logging on to the RODC?
- Is the DC managed as Tier 0 only from PAWs or secure administrative hosts?
- Are ordinary business workloads and web browsing absent from the DC?
- Have DC backups and forest recovery procedures been tested?
- Are FSMO holders and standby holders identified?
- Is the PDC Emulator’s time source designed?
- Do the Global Catalog, DNS, DHCP, firewall, and monitoring depend too heavily on one DC?
- Are Events 4768, 4769, 4771, and 4776 collected in a SIEM?
- Are there criteria for two
krbtgtresets, admin password resets, metadata cleanup, and trust password resets after a DC compromise?
Official references
Section titled “Official references”- Active Directory Domain Services overview: Overview of the AD DS database, security integration, and replication service.
- Active Directory Structure and Storage Technologies: Forests and domains, DNS support, DC Locator, and the forest security boundary.
- Active Directory Replication Concepts: KCC, sites, subnets, replication topology, and failover.
- Planning Domain Controller Placement: DC placement and reasons for placing RODCs.
- Planning Operations Master Role Placement: FSMO / Operations Masters, the PDC Emulator, RID Master, and why an RODC cannot hold FSMO roles.
- AD DS: Read-Only Domain Controllers: Read-only databases, unidirectional replication, credential caching, RODC krbtgt, and PRP.
- Best practices for securing Active Directory: AD attack surface, privileged accounts, and DC security.
- Securing domain controllers against attack: Impact of DC compromise, physical security, Server Core, and internet access restrictions.
- Tier model for Active Directory Domain Services: Tier 0 / Tier 1 / Tier 2, PAWs, and credential isolation.
- Kerberos authentication overview in Windows Server: The KDC and AD DS database, and Kerberos basics.
- 4768: A Kerberos authentication ticket (TGT) was requested: TGT request event.
- 4769: A Kerberos service ticket was requested: TGS request event.
- Authentication Policies and Authentication Policy Silos: Restricting high-privilege credential use, TGT lifetimes, and Kerberos AS / TGS enforcement.
- Active Directory Forest Recovery - Perform the initial recovery: Admin password resets, two
krbtgtresets, metadata cleanup, and replication health verification after a breach.