JUMP TO SECTIONChoose a lesson section
What you'll be able to explain.
- 01Distinguish forests, domains, organizational units, sites, domain controllers, global catalogs, and directory objects.
- 02Describe how domain-joined clients locate controllers through DNS and how Kerberos, LDAP, time, and network paths affect authentication.
- 03Explain multi-master replication, site topology, SYSVOL, and the difference between a stale directory object and a permissions problem.
- 04Recognize the five FSMO roles without treating every role-holder issue as an emergency requiring seizure.
- 05Gather safe evidence using DNS SRV lookups, nltest, repadmin, dcdiag, and Active Directory PowerShell tools.
- 06Apply least privilege, account/group management, approved change controls and user-workflow validation to AD DS support tickets.
A forest is not a server. A domain is not an OU.
AD DS is a distributed directory service for domain identities, devices, groups, and access control. Its logical hierarchy describes where objects belong; its physical topology describes which domain controllers host and replicate that information. Confusing those layers leads to bad troubleshooting decisions.
Forest and domain
A forest is the top-level security and schema boundary, containing one or more domains that share the schema, configuration and forest-wide trust relationships. Domains contain directory objects and are domain naming and replication partitions. A single-domain forest is common and simpler to manage.
Organizational units
OUs organize objects within a domain for administration, policy targeting and delegated control. An OU is neither a separate domain nor a security group. Moving a user into an OU does not directly grant file access.
Domain controller and site
A domain controller (DC) stores a writable directory replica for its domain unless it is a configured read-only DC. Sites and subnets reflect physical network topology and influence controller selection and replication routing; a site is not another domain.
Forest: corp.northstar.example
Domain: corp.northstar.example
OU: Workstations / OU: Users / OU: Servers
Site: HQ (10.20.0.0/16) → DC-01
Site: Branch (10.40.0.0/16) → DC-02Operational takeawayA user object can move between OUs without changing its domain; sites and subnets describe network locality, not the logical directory container.
Objects describe identities. Groups describe access.
A directory object has attributes and an identity; security principals have identifiers that can be used in access checks. Administrative convenience and authorization must not be confused. OU design, group membership, delegated rights, and actual resource permissions solve different problems.
Users, computers and groups
Users and computers are security principals with accounts in the directory. Security groups collect principals for access control. Distribution groups are not themselves an authorization mechanism.
OUs versus groups
OUs are containers used for administrative delegation and Group Policy scope. A security group can cross organizational boundaries as permitted by its type and scope. A folder access failure should be investigated through effective permission and membership, not OU location alone.
Identity and least privilege
A domain account may access many resources, but access is evaluated by the relevant server and resource permissions. Use groups, narrowly scoped delegation, privileged-access separation and change review rather than granting Domain Admins to solve a routine support ticket.
Get-ADDomain | Select-Object DNSRoot,NetBIOSName,PDCEmulator
Get-ADOrganizationalUnit -Filter * | Select-Object Name,DistinguishedName
Get-ADGroupMember -Identity 'GG_Accounting_Read' | Select-Object Name,ObjectClassOperational takeawayAn OU is not an access list. When a user receives Access Denied, establish which identity, groups, resource and effective permissions are involved.
Domain joins and sign-ins depend on controller discovery.
AD DS clients locate services through DNS, including SRV records that advertise domain controllers. A controller can be powered on and pingable while clients use the wrong resolver or fail to discover a suitable controller. DNS Server is often hosted on DCs, but that is a deployment choice, not the definition of a DC.
Client resolver path
Domain-joined clients normally use DNS services capable of resolving their AD DS domain and service locator records. A DHCP option accidentally pointing at a public-only resolver can break domain discovery while ordinary internet browsing still works.
SRV records and controller location
Service records such as _ldap._tcp.dc._msdcs.corp.northstar.example help clients identify potential domain controllers. The DC Locator process considers DNS, sites, availability and other requirements; a returned SRV record alone is not proof of a successful logon.
DNS-integrated zones
AD-integrated DNS zones can be replicated through directory partitions where configured. Keep DNS record health, zone replication scope and connectivity separate from the health of AD DS directory replication itself.
AD DS Evidence Explorer
Explore three simulated incidents. Inspect signals before deciding whether the fault is discovery, replication or authorization.
Domain logons fail after a subnet change, but DC-01 and DC-02 remain online.
Review at least three signals before choosing an initial failure domain. A green DC dashboard does not settle a user-facing identity problem.
ipconfig /all
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.northstar.example
nltest /dsgetdc:corp.northstar.example
Get-DnsClientServerAddress -AddressFamily IPv4Operational takeawayWhen sign-in works on one subnet and fails on another, compare client DNS, site/subnet mapping and service discovery before declaring the directory broken.
Ticket: Branch subnet cannot find the domain
- Only branch workstations fail controller discovery after a DHCP scope edit.
- DC-01 and DC-02 both appear healthy in basic monitoring.
- Branch clients received DNS addresses that cannot resolve internal AD SRV records.
Verify the DHCP DNS option and client resolver configuration; compare expected SRV responses against the authorized internal resolver, then use an approved scope correction and client lease refresh process.
Rebooting DCs does not fix a client whose queries are sent to the wrong DNS resolver. Prove controller discovery and domain authentication after the scoped correction.
Kerberos, LDAP and the global catalog have different jobs.
AD DS supports authentication and directory queries, but not every request travels through the same service. Kerberos typically handles domain ticket-based authentication; LDAP provides access to directory data. The global catalog helps locate objects across a forest.
Kerberos and time
A Kerberos authentication exchange depends on reachable domain services and sufficiently synchronized clocks. Ticket behavior can be affected by SPNs, name resolution, trust relationships and authentication policy. Do not solve a time failure by disabling authentication protections.
LDAP and the global catalog
LDAP is a directory access protocol; it is not a replacement for Kerberos sign-in. A global catalog provides forest-wide searches using a partial attribute set for objects in other domains and supports certain logon scenarios.
Domain trust and identity boundaries
Domains in one forest have automatically established transitive trusts. Cross-forest trust is a separate configuration. An Entra ID tenant is not an AD DS domain; hybrid synchronization links identity systems but does not make them interchangeable.
Client finds DC via DNS SRV and DC Locator
Kerberos ticket attempt requires policy, time and SPN context
LDAP query obtains directory object attributes
Application authorization is still evaluated at its resourceOperational takeawaySuccessful DNS discovery does not prove Kerberos authentication, and successful authentication does not prove application or file authorization.
Replication is not instantaneous or topology-free.
Writable domain controllers participate in multi-master replication for many directory changes. Each domain controller has its own copy of the relevant directory partitions; replication partners exchange updates according to the configured topology. Delays, failures, lingering problems and site links can produce different observations across controllers.
Multi-master updates
Most directory changes can originate on more than one writable controller and replicate to others. The replicated object and attribute metadata, not merely wall-clock time, determine how changes converge. Design and troubleshooting should consider the correct directory partition.
Sites and connections
Intra-site and inter-site replication behavior and schedules differ. A replication delay across a slow branch link is not automatically a DC outage; compare the expected partner and topology to actual failure messages and timestamps.
SYSVOL and Group Policy
SYSVOL contains shared policy and logon script files, normally replicated with DFS Replication in supported modern domains. AD object replication and SYSVOL/DFSR health are distinct paths; a GPO can have a directory object while its files are unavailable.
repadmin /replsummary
repadmin /showrepl DC-01
dcdiag /s:DC-01 /test:Replications
Get-ADReplicationPartnerMetadata -Target DC-01 -Scope ServerOperational takeawayAn out-of-date object on one controller needs partner and partition evidence. A stale user's authorization token needs a different validation plan.
Ticket: One office still sees the old group membership
- The account's group membership was updated on DC-01.
- A branch-authenticated request still appears to use the previous membership.
- repadmin reports a failed replication partner for DC-02, with a matching timestamp.
Capture the object and partner state, recent errors, site links and replication evidence. Investigate the failed partner/root cause within approved scope; do not manually force replication or reset DC metadata as a reflex.
Group membership observations may also be affected by existing authentication tokens. Establish replication convergence and retest a fresh, legitimate authentication context.
FSMO roles coordinate exceptions to multi-master behavior.
Flexible Single Master Operations roles assign specific directory operations to particular domain controllers. Their existence does not mean all AD DS changes use a single master. Confirm role placement before planning a transfer, and treat seizure as a last-resort recovery action after proper evaluation.
Forest-wide roles (2)
Schema Master controls schema updates; Domain Naming Master coordinates adding or removing domains and certain directory partition naming tasks. Each exists once per forest.
Domain-wide roles (3)
RID Master allocates relative ID pools; PDC Emulator supports time hierarchy, password-change handling and other compatibility functions; Infrastructure Master tracks certain cross-domain object references. Each exists once per domain.
Operations and recovery
A temporary role-holder outage may affect some operations more than others. Capture which role and operation are affected, reachability, backups, replication and recovery plans before deciding whether to transfer or seize the role.
netdom query fsmo
Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMasterOperational takeawayAvoid memorizing only role names. Know which tasks are affected, the distinction between transfer and seizure, and why recovering a seized former holder requires care.
Find the smallest failure domain before making changes.
A reliable AD DS investigation moves from users and subnets to resolver path, controller location, authentication signals, replication and resource authorization. Use read-only commands first, preserve event timestamps and account for rights needed by the tools.
Scope the symptom
Distinguish one user, one client, one subnet, one domain controller and entire-domain symptoms. Determine whether failure is domain discovery, authentication, directory data, token freshness, policy processing or resource access.
Use targeted checks
Resolve-DnsName and nltest help with discovery; dcdiag assesses DC diagnostics; repadmin inspects replication; Get-AD* cmdlets query objects and metadata. Some checks require elevated authorization and installed tools.
Avoid high-risk shortcuts
Do not reboot all controllers, seize FSMO roles, clear all DNS records, change forest trusts or grant privileged groups merely because a diagnostic shows red. Record the issue, owner, change scope, recovery plan and stop conditions.
1. Identify impacted user/subnet/DC and failure time
2. Inspect client DNS and controller discovery
3. Correlate authentication and Directory Service logs
4. Inspect relevant replication/site/permission evidence
5. Propose approved targeted correction and validationOperational takeawayA good AD DS administrator explains which layer failed and why the chosen action addresses it, with no unnecessary privilege expansion.
Verify identity services from the user's point of view.
Technical health checks and user acceptance complement one another. AD DS often supplies identities to servers, file shares, and applications, while Microsoft Entra ID may support connected cloud authentication. Keep on-premises directory health and cloud identity synchronization separate when analyzing incidents.
Prove the original task
After an authorized change, check that an affected client discovers an appropriate controller, can authenticate with an approved test account and accesses the original permitted resource or application.
Check the blast radius
Verify intended access still works for unaffected users, unauthorized users remain denied, replication meets expected health, and monitoring shows no new errors. Document any follow-up or remaining convergence time.
Connect without conflating Entra
Hybrid identity involves synchronization and authentication choices. A change to AD DS doesn't immediately guarantee an Entra object or token reflects it. The Microsoft hybrid identity lessons cover cloud-side authority and authentication; this lesson stays focused on on-prem AD DS.
Operational takeawayClose the loop with original user transactions, intended access boundaries, replication monitoring and a clear support record.
Ticket: Sign-ins recover, but one app still denies access
- Branch clients again discover controllers after a DNS correction.
- A domain-joined workstation successfully obtains a fresh domain sign-in.
- One application still returns Access Denied for a particular department.
Treat the successful domain sign-in as one verified layer. Investigate application group/role assignments, authorization tokens, and resource permissions for the affected users before declaring complete recovery.
Authentication and authorization are distinct. Fixing discovery can restore sign-in while exposing an unrelated or downstream access-control problem.
Can you defend the decision?
Try answering from memory before expanding each explanation. These checks support learning; they are not an exam-readiness score.
01A technician places an employee's account into the Finance OU to restore share access. Is that action enough?+
No. An OU primarily organizes directory objects for policy and delegation. Share access is determined by effective resource permissions and relevant security group membership; OU location alone does not grant it.
02The controller replies to ping, but a branch client cannot resolve _ldap._tcp.dc._msdcs records. What does that suggest?+
Investigate the branch DNS resolver configuration, authoritative AD-integrated zone/service records, and site connectivity. Ping does not prove DNS service discovery.
03Two controllers show different group membership for a user. What should you establish before forcing synchronization?+
Identify which controllers, partitions and replicas are involved; inspect replication metadata/errors and timestamps. Also determine whether the observed access issue is a stale authentication token rather than an object replication delay.
04Why might SYSVOL be unavailable even if AD directory replication succeeds?+
SYSVOL file replication uses a separate file replication mechanism, generally DFS Replication in supported modern environments. Investigate DFSR state and SYSVOL shares alongside AD replication and client policy symptoms.
05Which FSMO roles are domain-wide and which are forest-wide?+
The per-domain roles are RID Master, PDC Emulator and Infrastructure Master. Forest-wide roles are Schema Master and Domain Naming Master. A healthy directory does not route all updates through these role holders.
06A domain logon works, but the user's application says Access Denied. Should the domain controller be rebooted?+
Not on that evidence. Domain authentication worked. Inspect authorization at the application/resource, effective group membership and whether the client or application is using a stale token.
07What proof is needed after an approved correction to a branch DNS configuration?+
Verify that affected clients receive appropriate resolver settings, can find domain controllers through DNS, complete an authorized domain authentication and perform the original permitted business action. Check related monitoring and note residual issues.
Read from the source.
Vendor procedures depend on product version, hardware compatibility, and the environment's approved change controls. Verify the current documentation for any production task.