Active Directory Domain Services (AD DS) is Microsoft's directory service: a replicated database, run on servers called domain controllers, that stores users, computers and groups and authenticates them across a Windows network. Most organisations still run it, and most identity attacks against them end there, yet many people who administer or defend it have never had the building blocks explained. This guide explains domains, forests, trusts, organisational units, sites and replication, FSMO roles, the DNS dependency, Group Policy linking, and Kerberos and LDAP at a high level, with what each means for security. It is for new administrators, security analysts and engineers moving into identity. Hardening and attack paths are covered in the guides it links to.
Key takeaways
- The forest is the real security boundary. Domains in a forest share one schema, one configuration and one global catalog and are joined automatically by two-way transitive trusts, so a compromised domain puts the whole forest at risk.
- Every domain controller holds the keys. Each writable DC has a full copy of its domain's directory, including password hashes, so every DC must be protected like the most sensitive server you own.
- OUs are for administration, not security isolation. Organisational units scope Group Policy and delegated permissions; they do not stop a Domain Admin, and they need not mirror the org chart.
- AD cannot work without DNS. Clients find domain controllers through DNS SRV records, so broken or tampered DNS breaks or redirects authentication.
- Five FSMO roles are single points of authority. Schema and domain naming masters are forest-wide; RID master, PDC emulator and infrastructure master are per domain, and the PDC emulator anchors time for Kerberos.
What it is
Microsoft describes AD DS as a directory service that stores information about objects on a network and makes it available to authorised users and administrators. Its parts:
| Component | What it is | Security meaning |
|---|---|---|
| Data store (NTDS.dit) | The hierarchical database of objects: users, computers, groups, servers, printers | Holds credential material; a copy of it is equivalent to owning the domain |
| Schema | Rules defining object classes, attributes and their constraints | Forest-wide; changes are rare, irreversible in practice, and restricted to Schema Admins |
| Global catalog (GC) | A partial, read-only replica of every object in the forest, used for forest-wide search and logon | Lets any authenticated user enumerate the forest; GC servers are domain controllers and need DC-level protection |
| Domain controller (DC) | A server running AD DS that authenticates and replicates | Tier 0 asset; any DC compromise is domain compromise |
| Replication service | Copies changes between DCs | A rogue or compromised DC can push changes everywhere |
| Security principals | Users, computers, groups and service accounts, each with a security identifier (SID) | Service accounts are non-human identities with long-lived passwords and broad rights |
Domains, trees and forests
- Domain: Microsoft calls it a partition of the forest. It is a unit of identity, authentication, policy and replication: all its DCs are peers holding the same domain data. Example: corp.example.com.
- Tree: a parent domain and its child domains sharing a contiguous DNS namespace, such as emea.corp.example.com under corp.example.com.
- Forest: one or more domains (and trees) sharing a common schema, configuration (site and replication information) and global catalog. The first domain created is the forest root, which holds the Enterprise Admins and Schema Admins groups.
- Organisational unit (OU): a container inside a domain used to group objects for administration, apply Group Policy and delegate authority. Control is set by the access control lists on the OU and its objects.
The hierarchy is forest, then domain, then OU. Microsoft calls this the logical model because it is independent of how many DCs you run or where they sit on the network.
How it works
Trusts
A trust lets users in one domain authenticate to resources in another. If domain A trusts domain B, users in B can access resources in A, never the reverse unless a second trust exists.
| Trust | Direction and transitivity | Created | Notes |
|---|---|---|---|
| Parent-child | Two-way, transitive | Automatically when a child domain is added | All trusts inside a forest are two-way and transitive |
| Tree-root | Two-way, transitive | Automatically when a new tree joins the forest | Same behaviour as parent-child |
| Forest | One-way or two-way; transitive between the two forests only | Manually between two forest root domains | Not extended implicitly to a third forest |
| External | One-way or two-way, non-transitive | Manually to a domain in another forest | Often legacy, left over from mergers |
| Realm | One-way or two-way | Manually to a non-Windows Kerberos realm | Used with MIT Kerberos style realms |
Each trust has a shared password stored in a trusted domain object, which the trusting domain's PDC emulator changes every 30 days. Across a trust, Kerberos follows referrals from domain to domain, and NTLM uses pass-through authentication. See the Active Directory Trusts and SID Filtering Guide for how trusts are abused and restricted.
Sites and replication
AD is multi-master: any writable DC accepts changes and replicates them to the others. Physical layout is modelled separately from the logical model:
- Site: one or more IP subnets with fast, reliable connections, usually a physical location. Subnet objects map computers to sites, so clients find a nearby DC.
- Site link: a logical path between sites with a cost, schedule and interval; site links are transitive ("bridged") by default. Defaults are a cost of 100 and replication every 180 minutes.
- Knowledge Consistency Checker (KCC): a process on every DC that builds the replication topology automatically: a two-way ring inside a site, and spanning trees between sites through bridgehead servers.
- Read-only domain controller (RODC): a DC for branch offices that receives replication but never sends changes back, and caches only the passwords it is allowed to.
Security meaning: replication is fast inside a site, so a malicious change (a new admin, a modified Group Policy) spreads within seconds to minutes. Mis-mapped subnets send clients to distant DCs and hide where logons really happen.
FSMO roles
Some operations cannot be multi-master. These are held by one DC each, the flexible single master operation (FSMO) roles:
| Role | Scope | What it does | If it is unavailable |
|---|---|---|---|
| Schema master | One per forest | Processes all schema updates | Schema cannot be extended; daily operations continue |
| Domain naming master | One per forest | Adds or removes domains and cross-references | No domains can be added or removed |
| RID master | One per domain | Allocates pools of relative IDs used to build SIDs for new objects | DCs eventually cannot create new users, groups or computers |
| PDC emulator | One per domain | Time source for Kerberos, preferred target for password changes, processes account lockouts | Time drift breaks Kerberos; lockout and password change behaviour degrades |
| Infrastructure master | One per domain | Updates cross-domain object references | Stale names in group memberships across domains |
Microsoft advises configuring the forest-root PDC emulator to take time from an external source, and not placing the infrastructure master on a global catalog server unless every DC is a GC or the AD Recycle Bin is enabled.
DNS: how clients find domain controllers
Each DC registers DNS service (SRV) records through the Netlogon service, such as _ldap._tcp.dc._msdcs.<domain> and _kerberos records, plus site-specific records under _sites. A copy of what a DC should register is in %systemroot%\System32\Config\Netlogon.dns. Clients query these records to locate a DC in their site. If DNS is down, logons fail; if an attacker can write to DNS, clients can be sent elsewhere. See the DNS Protocol Fundamentals for Defenders Guide.
Group Policy linking
Group Policy Objects (GPOs) are linked to sites, domains or OUs and applied in the order local, site, domain, OU, with parent OUs before child OUs. Settings applied later overwrite earlier ones, so the GPO closest to the object usually wins. "Block inheritance" on an OU stops higher GPOs applying, except those marked "Enforced". The built-in Users and Computers folders are containers, not OUs, so GPOs cannot be linked to them, a common reason new machines miss security baselines. See the Group Policy Security Guide.
Kerberos and LDAP at a high level
- Kerberos (port 88): the default authentication protocol. Every DC runs a Key Distribution Center. At logon the user gets a ticket-granting ticket, signed with the krbtgt account's key, then exchanges it for service tickets to reach servers. Clocks must be close, which is why the PDC emulator's time role matters. See the Kerberos Security Guide.
- NTLM: the older challenge-response protocol, still used as a fallback. See the NTLM Deprecation and Elimination Guide.
- LDAP (389, LDAPS 636, global catalog 3268 and 3269): the protocol applications and tools use to query and change the directory. By default any authenticated user can read most of the directory, which is how attackers map it. See the LDAP Security Deep Dive Guide.
Why it matters
AD decides who can log on to almost every Windows server and workstation, and often to VPNs, Wi-Fi, file shares and SaaS through synchronisation to Entra ID. Each building block carries a specific security meaning:
| Building block | What goes wrong | Where to go deeper |
|---|---|---|
| Privileged groups (Enterprise Admins, Domain Admins, Administrators, Schema Admins) | Too many members, used for daily work | Tiered Administration and Enterprise Access Model Guide |
| Domain controllers | Unpatched, extra roles installed, physically exposed in branches | AD Domain Controller Hardening Guide |
| OU delegation and ACLs | Forgotten rights let helpdesk or service accounts reset admins | Active Directory ACL and Delegation Hygiene Guide |
| Group Policy | Editable GPOs linked to DC or server OUs become a push channel for attackers (ATT&CK T1484.001 Group Policy Modification) | Group Policy Security Guide |
| Trusts | Legacy trusts to acquired companies widen the attack surface (ATT&CK T1482 Domain Trust Discovery) | Active Directory Trusts and SID Filtering Guide |
| Readable directory | Any user can enumerate accounts and groups (ATT&CK T1087.002 Domain Account) | BloodHound and Active Directory Attack Path Guide |
| Service accounts | Old passwords, SPNs, excessive rights | Active Directory and Entra ID Hardening Guide |
In NIST SP 800-53 terms, AD is the main enforcement point for AC-2 Account Management and IA-2 Identification and Authentication for organisational users. Monitoring is covered in the Active Directory Security Monitoring and Event IDs Guide, and recovery in the Identity Recovery Guide.
Common misconceptions
- "A separate domain isolates a business unit." Domains in the same forest trust each other automatically, and forest-root administrators control all of them. Isolation needs a separate forest.
- "OUs are security boundaries." OUs scope policy and delegation; Domain Admins and anyone with rights on a parent OU still control what is inside.
- "Entra ID is just AD in the cloud." Entra ID has no OUs, no Group Policy and no Kerberos domain of its own in the AD sense; it uses web protocols such as OpenID Connect and SAML. Hybrid set-ups synchronise the two, so a compromise can cross from one to the other. See the Entra ID Security Guide.
- "Read-only DCs are safe to leave unprotected." An RODC still authenticates users and caches allowed passwords; it reduces, not removes, the risk.
- "Backups of a DC are ordinary server backups." A DC backup contains the directory database and its secrets, so it must be stored and handled like a DC.
- "Mirror the org chart in OUs." Microsoft says the OU hierarchy need not match departments; design it around who administers what and which policies apply, and keep it under about 10 levels.
Related concepts
- Tiering: separating control of DCs and identity systems (Tier 0) from servers and workstations. See the Tiered Administration and Enterprise Access Model Guide.
- AD Certificate Services: the PKI often bolted onto AD, a frequent route to domain compromise. See the AD CS Security Guide.
- Linux and macOS clients: non-Windows machines can join AD too. See the SSSD and Linux Active Directory Integration Guide.
- Single sign-on: how Kerberos gives desktop SSO and how it connects to cloud SSO. See How Single Sign On Works.
- Incident response: what to do when a DC or Domain Admin account is compromised. See the Active Directory Domain Compromise Response Playbook.
Practitioner checklist
- Draw your forest: domains, trusts (direction and type), sites and which DCs hold the FSMO roles and global catalog.
- List members of Enterprise Admins, Schema Admins, Domain Admins and Administrators in every domain; aim for a handful and no daily-use accounts.
- Review every trust and remove those with no current business owner.
- Check that new computers and users land in OUs with GPOs linked, not in the default containers.
- Confirm the forest-root PDC emulator takes time from a reliable external source.
- Verify each DC's SRV records and restrict who can modify DNS zones that hold them.
- Map subnets to sites so logons are attributed to the right location.
- Treat DCs, their backups and anything that can manage them as Tier 0.
Standards and references
- Microsoft Learn: Active Directory Domain Services overview
- Microsoft Learn: Understanding the Active Directory logical model
- Microsoft Learn: FSMO roles in Active Directory
- Microsoft Learn: Active Directory replication concepts
- Microsoft Learn: How trust relationships work for forests in Active Directory
- Microsoft Learn: Reviewing OU design concepts
- Microsoft Learn: Verify SRV DNS records have been created for a domain controller
- Microsoft Learn: Best practices for securing Active Directory
Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · Tiered Administration and Enterprise Access Model Guide · BloodHound and Active Directory Attack Path Guide · Kerberos Security Guide