Active Directory Domain Services: forests, domains, controllers and DNS
Understand how Active Directory domains, forests, domain controllers and DNS fit together. Diagnose a branch-office sign-in failure without treating every symptom as a password problem.
TL;DR: Active Directory Domain Services stores directory objects and supports domain authentication through domain controllers. Diagnose it as a distributed identity service: discovery, replication and time can fail independently of the user's password.
A directory has both logical and physical structure
A domain contains users, computers and other objects under an administrative namespace. Domain controllers hold directory data and provide services used by domain members. Organizational units arrange objects for delegated administration and policy targeting. An OU is not a separate domain controller or an isolated authentication system.
A forest contains one or more domains sharing a schema and configuration. Avoid promising isolation between domains inside the same forest as though they were unrelated security environments. Privileged administration and trust relationships require their own threat model. A subsidiary needing independent control of privileged administrators presents a different problem from a department needing a separate policy.
Microsoft's AD DS overview describes the directory, schema, global catalog and replication components. The operational consequence is that successful authentication on one machine cannot prove every directory replica is healthy.
Follow the dependencies from the workstation
The application remains a separate authorization boundary. A directory account may authenticate successfully and still lack permission to a share. Diagnose the failed operation at the component that rejected it. For applications querying users and groups, LDAP search scope and secure transport explain another distinct part of the access path.
DNS provides service discovery, including SRV records used to locate domain controllers. Giving a domain member a public resolver that cannot resolve its internal directory records can break discovery while ordinary websites continue working. See DNS resolution and caching before changing resolver configuration during an incident.
Worked example: only one office cannot sign in
Consider an illustrative company with two offices and two domain controllers. After a DHCP change, new laptops at the smaller office can browse external sites but cannot join the domain. Existing users sometimes reach their desktops, which tempts the responder to dismiss identity infrastructure as healthy.
Start by comparing resolver settings on an affected laptop and a known working laptop. Query the domain's service records against the configured resolver. Check whether the returned controller is reachable over the required protocols. Cached interactive sign-in can explain why an existing user reaches a desktop; it does not demonstrate fresh contact with a domain controller.
If discovery works, separate account state from replication state. Record the controller contacted, the account's relevant status and the timing of recent changes. A password reset followed by inconsistent results across controllers suggests a different investigation from an unreachable controller. Repeated resets add noise and can make the timeline harder to understand.
The repair for the hypothetical DHCP mistake is a reviewed resolver correction and a small verification cohort. Rejoining every computer is a disruptive response unsupported by the initial evidence. Verify new domain discovery and a representative application access after correction, then check machines that retain old lease settings.
| Symptom | First evidence to collect | Unsupported conclusion to avoid |
|---|---|---|
| External websites work, domain join fails | Resolver and directory SRV responses | The network is healthy everywhere |
| A reset password works intermittently | Controller contacted and replication status | The user is typing it incorrectly |
| Sign-in succeeds, share access fails | Ticket identity and share/file permissions | Authentication implies authorization |
| One office is slower | Site/subnet mapping and controller reachability | Add controllers before checking discovery |
Availability needs more than a second controller
Place redundant controllers across appropriate failure domains, verify replication and protect administrative access. Two controllers behind the same failed power supply or network path do not provide the resilience the inventory suggests. Backups also need an AD-aware recovery procedure; a VM snapshot alone is not a tested forest recovery plan.
Describe recovery objectives separately for workstation sign-in, application authentication and privileged administration. Some users may keep existing sessions while new service-ticket requests fail. That distinction improves incident scope and prevents a misleading binary statement that the directory is either completely up or down.
Microsoft's domain-controller location guidance explains discovery behavior. Pair that with the Kerberos ticket model when tracing an actual authentication attempt.
Directory placement also affects endpoint configuration. Group Policy processing traces OU links, filtering and the winning setting through to evidence on the affected Windows endpoint.
Check your reasoning
A user reaches a Windows desktop during a WAN outage. Does that prove AD is available? No. Cached sign-in and existing tickets can preserve some local activity. Test the specific fresh directory or service operation required, and record which controller was contacted.
Would moving an application to Microsoft Entra ID remove its LDAP dependency automatically? No. Inventory its authentication and directory-query protocols first. The AD DS and Entra comparison explains why an identity migration also needs an application compatibility decision.