Active Directory Fundamentals

The structure of Microsoft's on-premises directory: domains, trees and forests, domain controllers, organizational units, sites and replication, the global catalog and the FSMO roles.

What Active Directory is

Active Directory (AD) is Microsoft's directory service for Windows networks, introduced with Windows 2000 Server. Its core role, Active Directory Domain Services (AD DS), does three jobs at once:

  • Directory: it stores users, groups, computers, printers and policies in an LDAP-accessible tree (see Directory Services and LDAP).
  • Authentication: every domain controller is a Kerberos key distribution center, so a user who signs in to a domain-joined PC can reach file shares, printers and intranet sites without signing in again (see Kerberos and NTLM).
  • Policy: Group Policy pushes settings and security rules to every member computer and user (see Group Policy).

AD DS depends on DNS: clients find domain controllers through DNS records, which is why so many AD problems are DNS problems (see DNS and Active Directory). The "Active Directory" name also covers related server roles: Certificate Services (AD CS, an internal certificate authority), Federation Services (AD FS, web single sign-on) and Lightweight Directory Services (AD LDS, a plain LDAP directory for applications). On this page "AD" means AD DS. Microsoft Entra ID, formerly Azure Active Directory, is a different, cloud-based product (see Microsoft Entra ID).

Logical structure

The logical structure describes how objects are organized and administered, independent of where the servers stand.

Domains

An AD domain is a collection of objects (users, groups, computers) that share one directory database, one set of domain controllers and common policies such as the default password policy. It has a DNS name, such as ad.example.com, and a short NetBIOS name, such as AD, which you see in sign-in names like AD\t.nowak. Each domain also has a unique security identifier (SID) that prefixes the SIDs of all its users and groups.

Trees and forests

Domains can be combined. A tree is a set of domains in one contiguous DNS namespace: ops.ad.example.com is a child of ad.example.com. An AD forest is the outermost container: one or more trees that share a single schema, a single configuration (sites, services) and a global catalog, and that trust each other automatically. The first domain created becomes the forest root domain, and its name is the forest's name.

The most important design fact about AD is that the forest is the security boundary, not the domain. Administrators of any domain in a forest can, with enough effort, take control of the whole forest, because all domains share the schema, the configuration and the forest-wide groups such as Enterprise Admins. If two parts of an organization must be truly isolated from each other's administrators, they need separate forests.

An Active Directory forest named ad.example.com with two domains. The forest root domain ad.example.com contains the organizational unit Kestrel with the sub-OUs Rotterdam, Amsterdam and Servers, plus a separate OU for administrative accounts. The child domain ops.ad.example.com contains the OU Plants. A two-way transitive parent-child trust connects the domains. The schema, the configuration and the global catalog are shared by the whole forest, which is the security boundary. Forest ad.example.com: the security boundary Domain ad.example.com forest root · NetBIOS AD OU=Kestrel OU=Rotterdam OU=Amsterdam OU=Servers OU=Admin tier 0 accounts, separate OU trust Domain ops.ad.example.com child · NetBIOS OPS OU=Plants Shared by every domain: schema · configuration · global catalog Parent-child trusts are created automatically, two-way and transitive.
A forest with two domains. Each domain has its own objects and OUs; the forest shares one schema, one configuration and one global catalog, and is the real security boundary.

Organizational units

An organizational unit (OU) is a container inside a domain that groups objects for administration. OUs have two purposes:

  • Delegation: you can give the Rotterdam service desk the right to reset passwords for users in OU=Rotterdam only, without making them domain administrators.
  • Group Policy: GPOs are linked to OUs, so all computers in OU=Servers can get a different configuration from laptops.

OUs are not security principals. You cannot put an OU in the access control list of a file share or give an OU a permission in an application. Access to resources is granted to security groups, which can contain users from any OU (see Users, Groups and Computers). The default Users and Computers containers are not OUs either, which is one reason to create your own OUs: you cannot link a GPO to those containers.

Trusts

A domain trust is a relationship in which one domain accepts the authentication performed by another, so users from the trusted domain can be given access to resources in the trusting domain. The direction is easy to mix up: if domain A trusts domain B, users of B can access resources in A. Access flows against the direction of the trust.

Trust type Between Created
Parent-child, tree-root Domains in the same forest Automatically; two-way and transitive
Shortcut Two domains deep in the same forest, to shorten the authentication path Manually
Forest The root domains of two forests Manually; transitive between the two forests' domains
External One domain and one domain in another forest Manually; not transitive
Realm An AD domain and a non-Windows Kerberos realm Manually

Trusts to other forests usually come with a merger or acquisition. Treat them as a risk to be managed: restrict them with selective authentication where possible, keep SID filtering on, and remove them as soon as the migration is done.

Physical structure

Domain controllers

A domain controller (DC) is a Windows Server that runs AD DS and holds a copy of its domain's directory database. It answers LDAP queries, authenticates users and computers with Kerberos, and serves Group Policy files. A domain should have at least two DCs, so that one can fail or be patched without stopping every sign-in. A read-only domain controller (RODC) holds a read-only copy and caches the passwords of only selected accounts, which suits branch offices with weak physical security.

Domain controllers are the most sensitive servers in the network: whoever controls one controls the domain. They belong in tier 0 of the administrative model, together with anything that can manage them (see Privileged Access Management).

Sites and replication

AD uses multi-master replication: you can make a change on any (writable) DC, and it replicates to all the others. When the same attribute is changed in two places at once, a version number and timestamp decide which change wins. Replication is therefore loosely consistent: for a short time, two DCs can give different answers, which explains many "I just changed it, why doesn't it work?" tickets.

An AD site represents a part of the network with fast, reliable connections, usually one location. Sites are defined by their IP subnets. They have two effects:

  • Finding the closest DC: a client uses its IP address to determine its site and prefers DCs in that site, instead of authenticating across a slow wide area network (WAN) link.
  • Replication: within a site (intrasite), DCs notify each other of changes and replicate within moments, and security-sensitive changes such as account lockouts are replicated urgently. Between sites (intersite), replication follows site links with a cost and a schedule, by default every 180 minutes, and is compressed to save bandwidth.

A built-in process, the Knowledge Consistency Checker (KCC), builds the replication topology automatically. A subnet that is missing from the site configuration is a classic cause of slow sign-ins: clients in that subnet pick a DC in a random site.

The global catalog

Each DC holds the full data of its own domain only. The global catalog (GC) is a role that some DCs take on: they also hold a partial, read-only copy of every object in every other domain of the forest, with a selected set of attributes. That makes forest-wide searches possible ("find the user with this email address, wherever they live") over LDAP on port 3268, or 3269 with TLS.

The GC is also needed at sign-in: it resolves a user principal name such as t.nowak@ad.example.com to an account, and it supplies universal group memberships. In a single-domain forest it is usual to make every DC a global catalog server.

The five FSMO roles

Multi-master replication works for most changes, but some operations would conflict if two DCs did them at the same time. These are assigned to a single DC, the holder of a FSMO role (flexible single master operation, also called operations master role). There are five: two per forest and three per domain.

Role Scope Job When it is unavailable
Schema master One per forest Processes changes to the schema Schema updates (for example before installing a product that extends AD) fail; daily work is unaffected
Domain naming master One per forest Adds and removes domains in the forest You cannot add or remove domains; daily work is unaffected
RID master One per domain Hands out pools of relative identifiers (RIDs), the unique last part of every new SID, to the DCs DCs continue until their current pool runs out; then they can no longer create users, groups or computers
PDC emulator One per domain Time source for the domain, preferred target for password changes, processes account lockouts, default DC for Group Policy editing Noticed first: clocks drift (Kerberos fails beyond 5 minutes of skew), freshly changed passwords are rejected on some DCs, lockouts behave oddly
Infrastructure master One per domain Updates references to objects in other domains, such as a renamed user who is member of a group in this domain Cross-domain references go stale; irrelevant when the AD Recycle Bin is enabled or every DC is a global catalog

In a small domain all five roles usually sit on the first DC, and that is fine. What matters is that you know where they are, that the PDC emulator syncs its clock with a reliable external time source, and that you transfer the roles before you decommission that DC. If a role holder is permanently lost, another DC can seize the role; the old DC must then never come back online.

Functional levels

A functional level sets which AD features a domain or forest can use, based on the oldest Windows Server version that may run as a DC in it. Raising the level unlocks new features but means older DCs can no longer join. There is a domain functional level and a forest functional level; the forest level can never be higher than the lowest domain level.

  • Windows Server 2019 and 2022 did not introduce a functional level of their own: they use the Windows Server 2016 level.
  • Windows Server 2025 introduced a new Windows Server 2025 level, which allows only Server 2025 DCs and enables an optional larger database page size (32k pages).
  • Server 2025 DCs need a domain and forest at the 2016 level or higher, so very old domains must be raised before you can add them.

Some security features depend on the level: the Protected Users group, for example, has its full effect only from the Windows Server 2012 R2 domain level. Lowering a level again is possible only in limited cases, so check that no older DCs remain before you raise it.

The AD database and SYSVOL

Each DC stores its copy of the directory in a single database file, NTDS.dit, in %SystemRoot%\NTDS by default. It holds every object and attribute of the domain, including the password hashes of all accounts. A copy of NTDS.dit, or a backup of a DC, is therefore as sensitive as the domain itself: store DC backups encrypted and accessible only to tier 0 administrators.

SYSVOL is a shared folder on every DC (\\ad.example.com\SYSVOL) that holds the files of Group Policy Objects and logon scripts. It is replicated between DCs by DFS Replication (DFSR), separately from the directory database. Clients read their policies from it, so a DC whose SYSVOL is not replicating hands out outdated policies.

How a typical organization designs AD

For small and medium organizations, and many large ones, the right design is simple:

  • One forest, one domain. Extra domains add DCs, trusts and administration without adding a security boundary. Separate domains used to be needed for different password policies; fine-grained password policies have removed that reason.
  • A DNS name you own, usually a subdomain of the public domain such as ad.example.com, not an invented suffix such as .local (see DNS and Active Directory).
  • OUs designed for administration: top level by location or by object type, then by function. For example OU=Kestrel with OU=Rotterdam and OU=Amsterdam (each with users and computers) plus OU=Servers. The structure should answer "who manages this?" and "which policies apply?", not mirror the org chart, which changes every year.
  • A separate OU for administrative accounts and groups, delegated to nobody except tier 0 administrators.
  • At least two DCs, both DNS servers and global catalogs, with sites and subnets defined for every location.

Inspecting AD with PowerShell

The ActiveDirectory PowerShell module (part of the Remote Server Administration Tools, RSAT) is the standard way to query and manage AD from the command line. These read-only commands give a quick overview of a domain and forest: 

Get-ADDomain | Select-Object DNSRoot, NetBIOSName, DomainMode, PDCEmulator, RIDMaster, InfrastructureMaster
DNSRoot              : ad.example.com
NetBIOSName          : AD
DomainMode           : Windows2016Domain
PDCEmulator          : dc01.ad.example.com
RIDMaster            : dc01.ad.example.com
InfrastructureMaster : dc01.ad.example.com
Get-ADForest | Select-Object Name, ForestMode, Domains, SchemaMaster, DomainNamingMaster, GlobalCatalogs
Name               : ad.example.com
ForestMode         : Windows2016Forest
Domains            : {ad.example.com, ops.ad.example.com}
SchemaMaster       : dc01.ad.example.com
DomainNamingMaster : dc01.ad.example.com
GlobalCatalogs     : {dc01.ad.example.com, dc02.ad.example.com, dc01.ops.ad.example.com}

The older command-line tool netdom shows all five role holders at once: 

netdom query fsmo
Schema master               dc01.ad.example.com
Domain naming master        dc01.ad.example.com
PDC                         dc01.ad.example.com
RID pool manager            dc01.ad.example.com
Infrastructure master       dc01.ad.example.com
The command completed successfully.

DomainMode and ForestMode show the functional levels; here both are at the 2016 level, which allows Windows Server 2016 to 2025 DCs. Moving roles is done with Move-ADDirectoryServerOperationMasterRole; do it as a planned change, not as a troubleshooting step.

Active Directory in 2026

Cloud identity has grown, but as of 2026 AD DS is still the backbone of most Windows networks: domain-joined servers, file shares, Group Policy, Kerberos-based applications and industrial systems all depend on it. What has changed is that AD rarely stands alone. Most organizations run hybrid identity: users and groups are synchronized from AD to Microsoft Entra ID, so the same account signs in to on-premises resources and cloud services (see Microsoft Entra ID).

AD is also being hardened by default. Recent Windows Server releases and updates removed NTLMv1, made AES the Kerberos default and disabled RC4 unless it is explicitly configured per account (enforced from 2026), and turned on LDAP signing by default on new Windows Server 2025 deployments (see Kerberos and NTLM and LDAP signing). Old applications and devices that relied on the weaker defaults are the usual obstacle, so inventories and audit logs come before enforcement. Because AD is so central, it is also a prime target; see Attacks on Identity.

Common mistakes

  • Creating extra domains "for security" or per department. The domain is not a security boundary; every extra domain is more DCs to patch and more trusts to understand.
  • Running a single DC. When it fails, nobody signs in. Two DCs per domain is the minimum.
  • Forgetting the PDC emulator's clock. If it drifts or syncs with a bad source, the whole domain drifts with it, and Kerberos starts failing once clients are more than 5 minutes off.
  • Decommissioning a DC without moving its roles or cleaning up its metadata, which leaves FSMO roles and replication partners pointing at a server that no longer exists.
  • Using Domain Admins for daily work. Domain admin accounts belong on domain controllers and admin workstations only, never on a normal laptop or in an email client.