Active Directory Explained: Forests, FSMO Roles, SYSVOL and Group Policy

Overview: what Active Directory is

Active Directory Domain Services (AD DS) is a directory service: a database of objects such as users, computers, groups and policies, plus the services that let people and machines find those objects, prove who they are, and receive configuration. It runs on Windows Server machines called domain controllers (DCs). Every DC holds a copy of the directory and can accept changes to it, and the DCs keep each other up to date through replication.

AD DS is not one feature. It is several cooperating mechanisms, and most real-world problems come from the gaps between them. This article takes each mechanism in turn and then shows how they interlock.

A useful mental model: the directory database (NTDS.dit) holds objects and their attributes, DNS tells clients where DCs are, Kerberos proves identity, SYSVOL distributes files, and Group Policy ties configuration to the directory structure.

Clients depend on a DC for four services, DNS tells them where the DCs are, and the DCs stay in sync with each other.

Logical structure

The logical structure is how administrators organise and delegate. It has no relation to physical locations or networks.

Forest, tree, domain, OU

Microsoft describes a forest as “a collection of one or more Active Directory domains that share a common logical structure, directory schema (class and attribute definitions), directory configuration (site and replication information), and global catalog (forest-wide search capabilities). Domains in the same forest are automatically linked with two-way, transitive trust relationships.” The forest is the top-level container.

• Domain: a partition of the directory. Partitioning lets data replicate only where it is needed, so the directory can scale across networks with limited bandwidth. Domain controllers of a domain store that domain’s user accounts and credentials.
• Tree: domains that form a contiguous DNS namespace, for example a parent domain and its child domains. A forest can hold more than one tree.
• Organizational unit (OU): a container inside a domain used to group objects for administrative purposes such as applying Group Policy or delegating authority. Control over an OU and the objects inside it is determined by the access control lists (ACLs) on them.

OUs are not security principals: you cannot grant permissions to an OU, only on it, and you link Group Policy to it.

Domains inside the forest trust each other automatically; trusts to other forests are created by hand.

Objects, attributes and the schema

Everything in the directory is an object that belongs to a class and carries attributes. The schema defines the classes and attributes, and it is shared by every domain in the forest. Because of that, a schema change is a forest-wide event, which is why a single role (the Schema Master, section 5) controls it.

Directory partitions (naming contexts)

The database on each DC is split into partitions. Each partition has its own replication scope, which is the key to understanding who holds what.

Trusts inside a forest

Domains in the same forest trust each other automatically through two-way transitive trusts, so an account in any domain can be granted access to resources in any other domain of the forest. Trusts to other forests or to non-Windows realms are created manually and are covered in section 7.

Physical structure

The physical structure describes where DCs are and how well the network connects them. It is independent of the domain structure: one domain can span many sites, and one site can host DCs of many domains.

Domain controllers

A DC hosts the directory database and the services that use it. The Kerberos Key Distribution Center (KDC) runs on every DC, started automatically by the Local Security Authority (LSA), and cannot be stopped; any DC can accept authentication and ticket-granting requests for the domain. Every writable DC accepts changes to its own domain partition (the multi-master model, section 4).

A Read-only domain controller (RODC) holds a read-only copy of the domain partition. It does not accept direct directory changes and does not replicate changes out to other DCs. It is intended for locations where physical security cannot be guaranteed.

Global catalog

Microsoft defines the global catalog as “a distributed data repository that contains a searchable, partial representation of every object in every domain in a multidomain Active Directory Domain Services (AD DS) forest.” Key points:

• A global catalog server holds a full, writable copy of its own domain and a partial copy of every other domain. The attributes kept in the partial copy are the partial attribute set (PAS), defined by default by Microsoft and editable in the schema.
• It stores the membership (the member attribute) of universal groups only.
• LDAP queries on port 3268 go to a global catalog server.
• A logon needs a global catalog server to resolve universal group membership: “If a global catalog server is not available, the user logon fails.” A global catalog is also needed to resolve a UPN logon in a multi-domain forest.
• The first DC in a forest is created as a global catalog server.
• For small sites without a global catalog, universal group membership caching is an alternative. Microsoft notes that group membership updates may then not be reflected in credentials for up to eight hours.

Sites, subnets and site links

• Site: a set of well-connected IP subnets. Intra-site replication is tuned for speed; inter-site replication is tuned for low bandwidth use.
• Subnet: an IP range mapped to a site. This mapping is how a client learns which site it is in and therefore which DCs are “close”.
• Site link: a logical path between sites with a cost, a replication interval and a schedule. The default replication frequency is 180 minutes, configurable from a minimum of 15 minutes to a maximum of 10,080 minutes (one week), and the value is processed as the nearest multiple of 15 minutes. It applies during the blocks of availability in the site link schedule.

The Knowledge Consistency Checker (KCC)

The KCC runs on every DC and automatically builds and regularly updates the replication topology. It builds a separate topology for each directory partition. Inside a site it builds a bidirectional ring with at least two connections to each DC (for fault tolerance) and no more than three hops between any two DCs (to limit latency), adding shortcut connections across the ring when needed. Between sites it uses the site links and their costs.

Sites group well-connected subnets; the KCC builds a ring inside each site and uses site links between them.

Replication

AD DS uses multi-master replication: any writable DC can accept a change, and the change then spreads to the others. There is no single “primary” copy for ordinary objects. The few operations that cannot safely be multi-master are the FSMO roles (section 5).

How a DC knows what to send: USNs

Each DC keeps its own 64-bit counter called the update sequence number (USN). Every change committed on that DC increments it, and the new value is stamped on the object as usnChanged. USNs are local: a USN of 5000 on one DC has no relation to 5000 on another. To track what it has already received from others, a DC uses two structures:

Together with propagation dampening (which stops changes from circulating endlessly around redundant paths), these keep replication traffic proportional to the amount of real change.

The same cycle repeats from partner to partner, which is how a change reaches every DC.

Conflicts

Because two DCs can change the same attribute at nearly the same time, AD resolves conflicts deterministically. For attribute values the winner is chosen by comparing, in order: the version number of the attribute, then the originating time stamp (one-second resolution), then the originating DC’s GUID as the final tie-breaker. Every DC applies the same rule, so all converge on the same value without coordination.

Intra-site replication

Inside a site replication is driven by change notification and uses no compression:

• After a change, the source DC waits 15 seconds and then notifies its closest replication partner. Further partners are notified at 3-second intervals so the source is not overwhelmed. A notified partner then requests the changes.
• Urgent replication skips the wait. Microsoft lists as urgent: account lockouts, changes to the account lockout policy, changes to the domain password policy, and changes to the password of a DC account.

Inter-site replication

Between sites replication follows the site link schedule and interval (default 180 minutes, section 3.3), and the data is compressed. Intra-site replication is optimised for speed and inter-site for bandwidth; that is the reason for the different behaviour.

What replicates through AD replication and what does not

AD replication carries the directory partitions only. SYSVOL is not part of it: SYSVOL content is replicated by DFSR (or the legacy FRS), a completely separate engine (section 8). This split is the source of one of the most important behaviours in Group Policy (section 9.1).

FSMO roles in depth

Why FSMO roles exist

Multi-master replication works well for ordinary changes such as resetting a password or editing a group, because conflicts can be resolved after the fact (section 4.2). A few operations are different: they must be unique or serialised, and a conflict resolved afterwards would be too late or too damaging. Examples are two DCs handing out the same security identifier, two administrators creating two different versions of the schema, or two domains being created with the same name. For these operations AD DS designates exactly one DC as the owner at any time. These are the Flexible Single Master Operations (FSMO) roles.

There are five roles: two exist once per forest and three exist once per domain.

A forest with three domains therefore has 2 + (3 x 3) = 11 role instances. By default all five roles sit on the first DC created in a forest root domain, and the three domain roles sit on the first DC of each additional domain.

Each domain has its own three role holders, so the number of role instances grows with the number of domains.

An important operational fact: a role holder only performs its role operations after it has replicated the relevant partition at least once since it started. The PDC Emulator is the exception and does not wait.

Schema Master (forest-wide)

What it does. It is the only DC on which the schema can be modified. Every change (extending a class, adding an attribute, installing an application that extends the schema) is made on the Schema Master and then replicates to all DCs through the schema partition.

Why it is single. The schema is shared by every domain in the forest. Two DCs defining the same attribute differently would corrupt a structure that all objects depend on.

If it is down. Everyday work continues unaffected: logons, password changes and Group Policy do not need it. Only schema changes fail, which in practice means a schema extension, for example during an application or Windows Server version upgrade, cannot proceed.

Domain Naming Master (forest-wide)

What it does. It is the DC that adds or removes domains and application partitions in the forest.

Why it is single. Domain names must be unique in the forest. A single authority guarantees that two administrators cannot create two domains with the same name at once.

If it is down. Only domain and application partition creation or removal fail. Day-to-day service is unaffected.

RID Master (per domain)

What it does. Every security principal (user, computer, group) has a security identifier (SID) made of the domain’s SID plus a relative identifier (RID) that is unique inside the domain. The RID Master gives each DC a pool of RIDs. A DC creates new security principals by consuming RIDs from its own pool, and asks the RID Master for a new pool when it runs low. A domain can use at most 2^30 RIDs in total.

Why it is single. If two DCs created accounts with the same RID, two different accounts would share a SID and therefore share access rights. A single allocator makes every pool distinct.

If it is down. Nothing happens immediately, because each DC keeps working from its current pool. The failure appears only when a DC exhausts its pool and cannot get another: it then cannot create new users, computers or groups. This delayed, hard-to-trace failure is why the RID Master needs monitoring even though it looks idle.

PDC Emulator (per domain)

The PDC Emulator is the most heavily used role and the only one that touches clients and passwords daily. It exists for backward compatibility with older domain controllers and clients, but it kept several modern duties:

• Password changes and lockouts. Password changes are preferentially directed to it, and bad password attempts are forwarded to it, so that a DC which receives a wrong password can check the latest password before failing the logon. Account lockout is processed there as well. Urgent replication (section 4.3) pushes lockouts and DC password changes out immediately.
• Time source for the domain. Domain members synchronise time to a DC, DCs synchronise to the PDC Emulator of their domain (through the hierarchy of parent domains), and the PDC Emulator of the forest root domain synchronises with an external source. Section 7 explains why time matters.
• Group Policy. Group Policy editing tools use the PDC Emulator by default as the DC to write to, so that two administrators editing at once work on the same copy.

If it is down. Password change propagation and lockout handling degrade, time synchronisation drifts, and Group Policy editing tools may fail to connect to it by default. Users usually notice first.

External time source configuration for the forest root PDC Emulator uses the standard Windows Time tool:

w32tm /config /syncfromflags:manual ^
     /manualpeerlist:"<time-server>" /reliable:yes /update

Infrastructure Master (per domain)

What it does. It keeps references to objects in other domains correct. When a group in one domain contains a member from another domain, the group stores only a reference. The Infrastructure Master checks those references and updates them when the object is renamed or moved.

Placement rule. It should not run on a global catalog server, unless every DC in the domain is a global catalog server (a global catalog holds a partial copy of every object, so it never sees a stale reference and has nothing to fix). The rule stops mattering when all DCs are global catalogs or when the AD Recycle Bin is enabled.

If it is down. Cross-domain references stay stale. In a single-domain forest the role has no practical effect.

Placement guidance

This is common engineering practice rather than a product limit:

• Put the roles on well-connected, reliable DCs in a central site, and document where they are.
• Keep the two forest roles together; the RID Master and PDC Emulator are often kept together because the PDC Emulator is the busiest role and the RID Master needs to be reachable by all DCs.
• Choose the PDC Emulator of the forest root domain deliberately, because it is the root of time synchronisation.
• Do not put the Infrastructure Master on a global catalog in a multi-domain forest unless all DCs are global catalogs.
• Before decommissioning a DC always check which roles it holds.

Transfer versus seize

Seize only when the old holder will never return to the network. If a seized-from DC comes back, two DCs believe they own the role, which for the RID Master can mean duplicate SIDs. Rebuild the old DC from scratch (or remove its metadata) instead of reconnecting it.

Standard commands with the ActiveDirectory PowerShell module:

# Who holds the roles
Get-ADForest | Format-List SchemaMaster, DomainNamingMaster
Get-ADDomain | Format-List PDCEmulator, RIDMaster, InfrastructureMaster
netdom query fsmo

# Transfer (holder online)
Move-ADDirectoryServerOperationMasterRole -Identity "DC02" `
    -OperationMasterRole PDCEmulator

# Seize (holder lost for good)
Move-ADDirectoryServerOperationMasterRole -Identity "DC02" `
    -OperationMasterRole PDCEmulator -Force

Valid role names are PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster and DomainNamingMaster.

DNS and how clients find a domain controller

AD DS depends on DNS. DCs register SRV records that describe the services they offer and the sites they belong to, and clients query DNS to find them. When a workstation signs in to a Windows domain, it queries DNS for SRV records in the format _<service>._<protocol>.<DnsDomainName>; for an LDAP server of the domain that is _ldap._tcp.<DnsDomainName>. Records exist for key capabilities such as the Key Distribution Center and the global catalog and for locality (the AD site). Typical forms are:

_ldap._tcp.dc._msdcs.<domain>
    any DC of the domain
_ldap._tcp.<site>._sites.dc._msdcs.<domain>
    DCs in a specific site
_kerberos._tcp.<domain>    Kerberos KDC
_gc._tcp.<forest-root-domain>
    global catalog

The DC locator algorithm

The algorithm is implemented by the Netlogon service through the DsGetDcName API. Microsoft describes these steps:

1. The client collects the information needed to select a DC and calls the locator in its local Netlogon service.
2. Netlogon queries DNS for the SRV and A records of the domain.
3. Netlogon sends an LDAP UDP search (an “LDAP ping”) to the discovered DCs.
4. Each available DC responds to show it is operational, and the information from the DC that responds first is returned to the client.
5. The client caches that DC so later requests skip discovery. Caching encourages the same DC to be used, which gives a consistent view of the directory.

If the DC that answered is not in the client’s own site, the DC returns the client’s site name. The client retries to find a DC in its own site, and if the cached DC is still in a non-optimal site, the cache is flushed after 15 minutes and a better DC is sought. This is why the subnet-to-site mapping (section 3.3) matters: without it clients cannot tell which DCs are close.

The client reaches a close, working DC only if the DNS records exist and its subnet maps to a site.

NetBIOS fallback

If a short NetBIOS-style domain name cannot be mapped to a DNS name, the locator can fall back to NetBIOS-based discovery (through WINS or broadcast mailslots). Microsoft states that starting with Windows Server 2025 the BlockNetBIOSDiscovery policy defaults to TRUE, so DC locator no longer allows NetBIOS-style location.

Troubleshooting

• nslookup the SRV records above and the DC’s host record.
• To force the host record to register again: ipconfig /registerdns. To force DC service record registration: restart the Netlogon service.
• Netlogon debug logging: nltest /dbflag:0x2000ffff, with the log in %windir%\Debug\Netlogon.log.
• UDP 389 must be reachable, since it is used to discover AD services.

Authentication: Kerberos, NTLM and trusts

Kerberos in AD

The Kerberos Key Distribution Center (KDC) is implemented as a domain service that uses Active Directory as its account database. It is a single process that provides two services:

• The authentication service issues ticket-granting tickets (TGTs). A client must get a TGT from the authentication service of the user’s account domain before it can ask for tickets to services.
• The ticket-granting service issues service tickets (session tickets) for services in its own domain, or referral tickets for the ticket-granting service of a trusted domain. To reach a service, a client presents its TGT and asks for a service ticket.

The KDC runs on every DC, so any DC can authenticate. It uses a built-in account called krbtgt, created automatically with each domain, which cannot be deleted or renamed. Its password derives the secret key that encrypts and decrypts the TGTs the KDC issues. A domain trust account’s password derives the inter-realm key that protects referral tickets between domains.

In outline:

1. The user logs on: the client asks a DC’s authentication service for a TGT.
2. The client wants a file share, for example: it presents the TGT to the ticket-granting service and receives a service ticket.
3. The client presents the service ticket to the file server, which can verify it without contacting the DC.

The KDC runs on every DC, so any DC can issue the TGT and the service ticket.

Time matters. Kerberos uses timestamps to prevent replay attacks. The setting Maximum tolerance for computer clock synchronization defines how far the client and DC clocks may differ; the default is 5 minutes. This is why the time hierarchy under the PDC Emulator (section 5.5) is not optional.

Default Kerberos policy values (Microsoft documentation): maximum lifetime of a user ticket (TGT) 10 hours, maximum ticket renewal 7 days, and the 5-minute clock tolerance above.

NTLM

NTLM is the older challenge-response protocol. Kerberos is used when it can be; Windows falls back to NTLM in cases where Kerberos cannot work, for example when a service is addressed by IP address rather than by name, or when the client is not domain-joined. Reducing NTLM is a common hardening step (section 12).

Trusts

A trust lets authentication requests in one domain or forest reach another. Within a forest, trusts are automatic, two-way and transitive. Other kinds are created manually:

UPN logons are resolved in the global catalog of the user’s own forest, so a UPN cannot be used to log on to a domain outside the user’s forest across a trust.

SYSVOL and NETLOGON

The directory database holds objects, but some of a domain’s data is made of files: Group Policy templates, logon scripts and similar content. That is the job of SYSVOL, a folder structure that exists on every domain controller and is kept in sync between them.

Layout

On each DC, SYSVOL (by default under %SystemRoot%\SYSVOL) is shared out as a folder named after the domain, with two key subfolders:

SYSVOL share root (%SystemRoot%\SYSVOL\sysvol)
  <domain-FQDN>\
    Policies\
      {31B2F340-016D-11D2-945F-00C04FB984F9}\   (one folder per GPO)
        gpt.ini
        Machine\
        User\
      {6AC1786C-016F-11D2-945F-00C04FB984F9}\
      ...
    scripts\   (logon scripts and similar files)

Two network shares expose this content to clients:

So NETLOGON is not a separate folder: it is simply the scripts subfolder of SYSVOL published under its own share name. The GUID folders under Policies are the file halves of Group Policy objects, described in section 9.

Replication engines: FRS and DFSR

SYSVOL content is not replicated by AD replication. Two engines exist:

• FRS (File Replication Service): the legacy engine used by the original domain format.
• DFSR (Distributed File System Replication): the modern engine, available when the domain functional level is Windows Server 2008 or higher.

Microsoft states that Windows Server 2016 is the last Windows Server release that supports FRS, and that domains at the Windows Server 2016 functional level must use DFSR to replicate SYSVOL.

Migration from FRS to DFSR is one-way, done with the dfsrmig tool in four global states:

To check the current state use dfsrmig /getglobalstate.

Why SYSVOL health is domain health

Because policies and scripts are files, a DC with a broken SYSVOL (not shared, out of date, or not replicating) still logs people on but serves them stale or missing policy files. Always treat the directory and SYSVOL as two systems that need two health checks (section 11).

Group Policy

Group Policy applies configuration (security settings, scripts, software settings, registry-based policy) to users and computers centrally. Its key design feature is that a Group Policy object (GPO) is stored in two places that replicate by two different mechanisms.

The two halves of a GPO: GPC and GPT

The GPC and the GPT share the same GUID, and gPCFileSysPath is what points from the container to the folder under SYSVOL\<domain-FQDN>\Policies. Because the two halves travel through two independent replication engines, there is no atomic commit: a DC can briefly (or, when SYSVOL replication is broken, for long) hold a new GPC with an old GPT, or the reverse.

A GPO exists in two places: the container in the directory and the template in SYSVOL.

Version numbers. The GPO version is a 32-bit value: the high 16 bits count user-settings changes and the low 16 bits count computer-settings changes. The version appears both in the GPC and in gpt.ini, and clients compare it to the version they last applied to decide whether anything changed.

Linking: where a GPO applies

A GPO does nothing until it is linked to a site, a domain or an OU. The links are stored on the container as an attribute (gPLink), not in the GPO. One GPO can be linked to many containers, and one container can have many GPOs linked.

GPOs apply in this order, with later settings overriding earlier ones when they conflict:

1. Local policy of the machine
2. Site
3. Domain
4. Organizational units, from the outermost to the innermost (child OUs last)

This is known as LSDOU. Inside one container, GPOs with a lower link order number have higher precedence and win.

Conflicts are settled in favour of the policy applied last, except where Enforced is set.

Inheritance, Block Inheritance and Enforced

• By default policies flow down: a domain-linked GPO also affects every OU below.
• Block Inheritance on an OU stops policies from higher containers reaching it.
• Enforced on a link makes that GPO apply regardless, and it is not stopped by Block Inheritance. When enforced and normal GPOs conflict, enforced wins.

Filtering: deciding who actually gets a GPO

• Security filtering: the GPO applies only to security principals that have Read and Apply group policy permission on it. By default Authenticated Users have both.
• WMI filtering: the GPO applies only if a WMI query on the client returns true. A GPO can have one WMI filter.

Loopback processing

Normally user settings follow the user and computer settings follow the computer. Loopback lets the computer’s location decide the user settings too, which suits shared machines such as kiosks or lab computers. It has two modes:

• Merge: the user’s normal GPOs apply first, then the computer’s user-settings apply on top, and the computer’s win on conflict.
• Replace: the user’s own GPOs are ignored; only the user settings from the computer’s GPOs apply.

When Group Policy is refreshed

To force a refresh use gpupdate /force on a client, or Invoke-GPUpdate from PowerShell for remote machines. gpresult /r shows which GPOs applied and why others were filtered out.

What a client really does at logon

1. Locates a DC (section 6) and authenticates (section 7).
2. Reads the gPLink attributes of its site, domain and OUs from AD DS and builds the ordered list of GPOs.
3. Applies security and WMI filtering to drop GPOs that do not apply.
4. For each remaining GPO, reads the GPC version and the gPCFileSysPath, then reads the GPT files over SMB from the SYSVOL share of a DC.
5. Hands the files to the relevant client-side extensions, which apply the settings.

If the DC chosen by the client has an older GPT than the GPC says (or the reverse), the result is a mismatch: that is the classic symptom of broken SYSVOL replication.

How it all works together

A single interactive logon touches nearly every mechanism in this article:

1. A DC is built. The Domain Naming Master permitted the domain’s creation. Configuration and schema replicated to every DC in the forest. The domain partition replicated to DCs in the domain.
2. A user account is created on any writable DC. The DC takes a RID from the pool the RID Master gave it, so the user’s SID is unique. The new object replicates by AD replication.
3. A computer starts. Its Netlogon service locates a DC through DNS SRV records, using the subnet-to-site mapping to prefer a DC in its own site.
4. Time is checked. The computer’s clock must be within 5 minutes of the DC (Kerberos). The DC’s clock came from the PDC Emulator, whose clock may come from an external source.
5. The user logs on. The KDC on that DC checks the credentials against the directory and issues a TGT. If universal groups are involved, a global catalog is consulted for membership.
6. Policy is found and applied. The client reads gPLink from AD DS, filters, then reads the policy files from the SYSVOL share, which is kept in sync by DFSR.
7. Logon script runs from the NETLOGON share (the scripts folder of SYSVOL), if configured.
8. Later changes (a password reset, a changed policy) travel by change notification inside the site and by schedule between sites. Group Policy changes need both the AD half and the SYSVOL half to arrive.

The failure patterns follow from this chain. Broken DNS means no DC is found. Wrong subnet mapping means slow logons over the WAN. Clock drift means Kerberos fails. Broken SYSVOL replication means policy is stale even though AD replication is healthy. A dead RID Master surfaces weeks later as accounts that cannot be created.

Every step depends on the one before it, so a failure early on often appears as a symptom much later.

Operations

Health checks

Check the directory (repadmin) and SYSVOL (dcdiag SYSVOL tests, DFSR health) separately, since they replicate independently.

Deleted objects, tombstones and the Recycle Bin

When an object is deleted, AD does not remove it at once. A deleted object must replicate to every DC, so it is kept as a tombstone until the tombstone lifetime passes, then garbage-collected. For forests created since Windows Server 2003 SP1 the default tombstone lifetime is 180 days. If the value is unset the lifetime is 60 days.

The Active Directory Recycle Bin adds a recoverable stage. With it enabled, an object moves from deleted (recoverable with all attributes) to recycled (not recoverable) and finally to being removed after the tombstone lifetime. Facts to know:

• It requires the Windows Server 2008 R2 forest functional level or higher.
• Enabling it is irreversible.
• Enabling uses Enable-ADOptionalFeature 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target <forest>.

A DC that has been offline longer than the tombstone lifetime must not simply be reconnected, because it may re-introduce objects that other DCs already purged (lingering objects).

Backup and restore

• Back up at least two DCs per domain, including system state, and test restores. Include the DCs that hold FSMO roles and the global catalog.
• A directory restore is done in Directory Services Restore Mode (DSRM), entered with a dedicated local administrator password set when the DC was promoted.
• Never restore a DC from an old copy or virtual-machine snapshot as if it were a normal file. Rolling a DC back means its USN counter goes backwards, so other DCs believe they already have changes that this DC then re-uses USNs for. This produces silent divergence (a USN rollback). Use supported backup and restore procedures, and hypervisor features only if they are documented as safe for domain controllers.

Raising functional levels

Functional levels control which features are allowed, and affect only how DCs work as a group; clients are unaffected. Rules from Microsoft:

• To raise the domain functional level, all DCs in the domain must run the matching or a newer Windows Server version. To raise the forest functional level, all DCs in the forest must, and the domains must already be at the latest level.
• A domain level can be higher than the forest level, but not lower.
• Raising the forest level requires Enterprise Admins membership or equivalent.
• Start from an environment with no replication errors, and back up DCs holding global catalog and FSMO roles first.
• Cmdlets: Set-ADDomainMode and Set-ADForestMode.
• A Windows Server 2025 DC can be added to an existing domain only if the domain is at least at the Windows Server 2016 functional level.

Security best practices

These are widely accepted hardening practices, not statements of product limits.

• Treat DCs as the most sensitive systems. Whoever controls a DC controls every identity in the forest. Keep them physically and logically separate, patch them promptly, and run nothing else on them.
• Least privilege. Keep Domain Admins, Enterprise Admins and Schema Admins nearly empty. Use separate admin accounts that are never used for email or browsing. Use delegation on OUs rather than broad membership.
• Protect privileged logons. Administrators should log on to DCs and admin workstations only, so privileged credentials are not left on ordinary machines. The Protected Users group applies DC-side protections to its members (no NTLM, no DES or RC4 in Kerberos pre-authentication, no delegation, and TGT renewal limited to the initial four-hour lifetime).
• Control the krbtgt account. Its secret key protects every TGT in the domain; reset its password on a planned schedule and after any suspected domain compromise.
• Reduce NTLM and enforce signing for LDAP and SMB where clients support it.
• Secure replication and SYSVOL. Restrict who can edit GPOs and write to SYSVOL, since anything placed there executes on clients at the next refresh.
• Time and DNS. Give the forest-root PDC Emulator a reliable external time source and protect DNS records and zones, because both are authentication dependencies.
• Use RODCs where physical security is weak, so a stolen server does not hold every credential.
• Backups are credentials. An AD backup contains every password hash; store and access it like the DC itself.
• Audit changes to privileged groups, GPOs and AD objects, and monitor replication health.

Limitations and gotchas

• Eventual consistency. A change on one DC is not visible on every DC instantly. Inside a site it normally takes seconds; between sites it can take as long as the site link interval (180 minutes by default).
• GPC/GPT mismatch. The two halves of a GPO replicate by different engines with no atomic commit, so broken SYSVOL replication produces stale policy even when AD replication looks healthy.
• Global catalog dependency. Logon in a domain that can have universal groups needs a reachable global catalog, and multi-domain UPN logon does too. If none is available, logon fails. Universal group membership caching can reduce the dependency, with membership changes delayed by up to eight hours.
• Time dependency. Beyond the default 5-minute tolerance Kerberos stops working.
• DNS dependency. If SRV records are missing or stale, clients cannot find DCs even though the DCs are healthy.
• Hidden FSMO failures. A lost RID Master shows up only when a DC’s RID pool is empty; a lost PDC Emulator shows up first as lockout and time problems.
• Seizing is one-way. Never bring a DC back after seizing its roles to another DC.
• Schema changes are forest-wide and not reversible in the normal sense. Test extensions in a lab forest first.
• Recycle Bin and some functional-level changes are irreversible (the Recycle Bin definitely so).
• Lingering objects appear when a DC returns after being offline longer than the tombstone lifetime.
• A domain is a replication boundary, not a security boundary within a forest. Plan the forest, not just the domain, as the unit that must be trusted as a whole.
• Single DC domains have no redundancy for the directory or SYSVOL. Run at least two.

Quick reference

Ports

From Microsoft’s service overview and network port requirements. (Microsoft cautions that this article is not for configuring Windows Firewall.)

Defaults

FSMO cheat sheet

References

• Understanding the Active Directory Logical Model
• Locating domain controllers in Windows and Windows Server (DC Locator)
• Troubleshoot domain controller location issues
• Service overview and network port requirements for Windows
• Active Directory functional levels
• Raise domain and forest functional levels
• Maximum tolerance for computer clock synchronization
• Kerberos Policy (Windows 2000 Server documentation)
• Intrasite replication (Windows Server 2003 documentation)
• Global catalog (Windows Server 2003 documentation)
• Trust types (Windows Server 2008 R2 documentation)
• Site link replication frequency (Windows Server 2008 R2 documentation)
• Kerberos in Windows 2000 (KDC, TGT, krbtgt)