Active Directory Administration

Active Directory Domain Services (AD DS) is Microsoft's directory service for Windows networks. It stores information about the objects on a network — user accounts, computer accounts, groups, printers, and shared resources — in a structured, hierarchical database, and it makes that information available to authorized users and administrators. When you sign in to a Windows domain computer, check group membership before opening a file share, or push a security setting to every machine in a department, AD DS is the system answering "who is this, and what are they allowed to do."

The useful mental model is a shared address book with a rulebook attached. The address book holds every user, computer, and group in the organization; the rulebook (security permissions and Group Policy) decides who can read or change each entry and what configuration gets pushed to which machines. Every domain controller holds a full copy of that address book for its domain and keeps it synchronized with every other domain controller, so a change made in one office is visible everywhere else within minutes.

Why AD DS exists

Before directory services, each Windows server kept its own local list of users and passwords. Ten servers meant ten separate accounts to create, update, and disable for every employee — and ten places for a former employee's access to linger. AD DS solves this by centralizing identity: create a user once, and that identity works across every computer, server, and application that trusts the domain. This is why AD DS underpins most on-premises Windows environments and remains the identity backbone that hybrid cloud setups (via Microsoft Entra Connect) synchronize into the cloud.

AD DS combines several pieces into one service:

A structured data store — the directory itself — organized hierarchically so information is easy to find.
The schema, a set of rules defining what classes of objects (users, computers, groups, and more) can exist in the directory, what attributes each object type can have, and the format of their names.
A global catalog, a searchable index containing a subset of every object's attributes across the entire forest, so a query for "find this user" doesn't need to know which domain holds the answer.
A query and index mechanism, so applications and users can search the directory efficiently.
A replication service that copies directory changes to every domain controller in a domain, so any domain controller can answer requests with current data.
Integrated security: a single username and password authenticates a user across the network, and access to directory objects is controlled the same way access to files is controlled — with permissions.

Who administers AD DS, and what they do

Systems administrators use AD DS to provision and deprovision user accounts, organize computers and users for delegated management, distribute configuration and security settings at scale, and control which users and machines can authenticate to which domains. A single AD DS environment commonly serves as the authentication source for file servers, print services, internal web applications, VPN access, and — through federation or synchronization — cloud identity providers.

AD DS scales from a single-server domain for a small office to a multi-domain, multi-forest deployment spanning a global enterprise with data centers on different continents. The concepts stay the same at every scale; what changes is how many domains, sites, and trust relationships you need to model your organization's structure and network topology.

The logical structure: forests, domains, and OUs

AD DS organizes objects into a hierarchy that is independent of physical network layout — the same logical model applies whether your domain controllers sit in one server room or ten data centers.

A domain is a partition of the directory. It's also the core administrative and security boundary: domain controllers store the accounts and credentials for that domain, provide authentication for its users, and replicate changes to every other domain controller in the same domain. Partitioning the directory into domains lets an organization replicate data only to where it's needed, so the directory can scale across a network with limited bandwidth between sites.
A domain tree is one or more domains that share a contiguous DNS namespace — for example, example.com and its child domain emea.example.com.
A forest is a collection of one or more domains (whether in one tree or several) that share a common schema, a common configuration partition, and a global catalog. Domains within the same forest are automatically linked by two-way, transitive trust relationships, so authenticated users in one domain can be granted access to resources in another domain in the same forest without any extra configuration.
An organizational unit (OU) is a container inside a domain used to group objects — typically by department, location, or function — for administrative purposes. OUs are the level at which administrators most often delegate control and link Group Policy: a well-designed OU structure lets you hand a department its own limited administrative rights, or apply a security baseline to every computer in a branch office, without touching anything outside that OU.

Trusts: extending authentication across domains and forests

A trust is a relationship that lets users in one domain be authenticated by resources in another. Every domain trust inside a single forest is created automatically as two-way and transitive: when a new domain joins a forest, AD DS creates a two-way transitive trust between it and its parent, and that trust path extends through the whole domain tree, so any two domains in one forest trust each other by default.

To connect separate forests, administrators create an explicit forest trust between the two forest root domains. A forest trust can be one-way or two-way and, when two-way, is transitive across every domain in both forests — but it is not automatically extended to a third forest even if that third forest trusts one of the first two. Trusts have a direction: in a one-way trust between Domain A and Domain B, users in the trusted domain can access resources in the trusting domain, but not the reverse. Getting trust direction right is a common source of confusion during mergers, acquisitions, or any project connecting two previously separate AD DS environments.

Domain controllers, replication, and FSMO roles

A domain controller (DC) is a server running AD DS that holds a writable copy of its domain's directory data and services authentication requests. AD DS uses multimaster replication: every domain controller in a domain can accept a directory change, and that change then replicates out to every other domain controller, rather than all writes going through one designated master. This is why AD DS tolerates the loss of any single domain controller without losing write capability for the domain.

A small number of operations don't tolerate multiple masters safely — two administrators renaming the same object differently at the same moment, for instance, or two domain controllers both trying to extend the schema. AD DS handles these with Flexible Single Master Operations (FSMO) roles, five specific responsibilities each held by exactly one domain controller at a time:

Schema Master (one per forest) — the only domain controller that can process changes to the directory schema.
Domain Naming Master (one per forest) — the only domain controller that can add or remove a domain from the forest.
RID Master (one per domain) — allocates pools of relative identifiers to every domain controller in the domain, so each new user, group, or computer gets a unique security identifier.
PDC Emulator (one per domain) — the authoritative source for password changes and account lockout processing in the domain, and the authoritative time source for the forest when held by the forest root domain's PDC Emulator.
Infrastructure Master (one per domain) — keeps references from objects in its domain to objects in other domains up to date, such as updating group membership when a referenced user is renamed.

Replication traffic itself is shaped by sites — objects representing groups of well-connected subnets — so that AD DS can replicate quickly and often between domain controllers on the same fast local network, while batching and scheduling replication more conservatively across slower links between sites. This is what keeps a global multi-site deployment from saturating a wide-area link with directory traffic.

Authentication: Kerberos and the domain controller's role

Windows domains authenticate primarily with the Kerberos protocol. Each domain controller runs a Key Distribution Center (KDC), which uses the domain's AD DS database as its account store. After a user signs in once, Kerberos issues tickets that let that user access other services on the network without re-entering credentials — the basis of single sign-on inside a domain or forest. Kerberos also provides mutual authentication: unlike the older NTLM protocol, which only lets a server verify a client, Kerberos lets each side of a connection verify the other's identity, and it reduces how often an application server needs to contact a domain controller directly by using renewable session tickets instead of pass-through authentication for every request.

Organizing access: security groups and Group Policy

Two mechanisms do most of the day-to-day work of AD DS administration.

Security groups collect users, computers, and other groups into manageable units so permissions and rights get assigned once, to the group, instead of repeatedly to individual accounts. Each group has a scope that determines where it can be used:

Domain local groups can be granted permissions only on resources in their own domain, but can contain members from any trusted domain.
Global groups can contain members only from their own domain, but can be granted permissions anywhere in the forest or in trusting domains.
Universal groups can contain members from anywhere in the forest and can be granted permissions anywhere in the forest.

Group Policy distributes configuration and security settings at scale. A Group Policy Object (GPO) is a collection of settings that you link to a site, a domain, or an OU; every user or computer inside that container — and inside any OU nested under it, by default — picks up the linked settings the next time policy is applied. A GPO is made of two parts that replicate separately: the Group Policy container, stored in the domain partition of AD DS, and the Group Policy template, stored in the SYSVOL folder on every domain controller. Because GPOs link to OUs, a clean OU structure and a clean Group Policy design go hand in hand — this is the main reason OU layout deserves real planning rather than mirroring an org chart by default.

DNS: the service AD DS cannot function without

AD DS depends on DNS to let computers locate domain controllers, and Windows DNS servers running on domain controllers can store their zone data inside AD DS itself — an Active Directory-integrated zone. Doing so gives every domain controller running DNS a writable copy of the zone (multimaster DNS replication, the same model as the directory) and lets administrators require secure dynamic updates, so only authenticated computers can register or change their own DNS records. If DNS is misconfigured, domain member computers cannot find a domain controller to authenticate against — DNS problems are one of the most common root causes of "the domain is broken" symptoms.

The administrative toolset, briefly

Administrators manage AD DS through a set of tools installed as part of Remote Server Administration Tools (RSAT): graphical consoles such as Active Directory Users and Computers, Active Directory Administrative Center, Active Directory Sites and Services, and Active Directory Domains and Trusts, plus the ActiveDirectory PowerShell module, whose cmdlets (Get-ADUser, Get-ADGroupMember, New-ADUser, and similar) let administrators query and change the directory from the command line or in scripts. This course orients you around the concepts those tools operate on; a follow-on, hands-on course is the place to build fluency with the tools themselves.

What AD DS is not

It is not a general-purpose database or application data store — the schema is designed around identity and network resource objects, and extending it for unrelated application data is a specialized, forest-wide operation, not routine practice.
It is not, by itself, a cloud identity provider. Hybrid organizations sync AD DS identities into Microsoft Entra ID (formerly Azure AD) with a tool like Microsoft Entra Connect; AD DS and Entra ID are related but distinct services with different protocols and management surfaces.
It is not a certificate authority, though it integrates closely with Active Directory Certificate Services, a separate server role.
It is not immediately consistent across every domain controller. Multimaster replication means a change made on one domain controller takes some time — usually seconds on a fast local link, longer across sites — to reach every other domain controller, a property administrators need to keep in mind when troubleshooting "I just made this change and it isn't showing up yet."

A practical path through this material

Stand up a lab domain (even a single domain controller in a virtual machine) and open Active Directory Users and Computers to see the default containers and built-in groups.
Create an OU structure that mirrors a small organization, then create a GPO and link it to one OU to see settings apply only within that container and its children.
Create a handful of test users and a security group of each scope, and practice adding members according to each scope's membership rules.
Open Active Directory Sites and Services and identify the default site; if you have a lab with two virtual networks, create a second site and a site link between them.
Use Get-ADDomainController (or the Active Directory Domains and Trusts console) to identify which domain controller holds each FSMO role in your lab domain.
Follow the links in this course for hands-on PowerShell-based user and group management, then move on to a dedicated Group Policy course for policy design and troubleshooting in depth, and to an Active Directory security course for hardening and attack-surface reduction.