Skip to content

Windows

Active Directory Domain Services

Active Directory Domain Services (AD DS) is the centralized identity, directory, and authentication service at the heart of almost every Windows enterprise. It stores accounts for users, computers, and groups, authenticates logons, and is the foundation that Group Policy builds on.

Tested on

Windows Server 2022 (functional level 2016, the highest available). The workflow is identical on Windows Server 2019 and 2016; only the maximum forest/domain functional level differs.

What is AD DS?

Without a directory service, every server keeps its own local user accounts — unmanageable past a handful of machines. AD DS solves this by providing a single, replicated directory where:

  • Identities (users, computers, service accounts) are defined once.
  • Authentication is centralized — a user logs on once against the domain.
  • Authorization is driven by group membership.
  • Policy (Group Policy) is pushed to thousands of machines from one place.

AD DS data is hosted on domain controllers and replicated between them, so the directory stays available and consistent.

Core concepts

Term What it is
Domain A logical boundary of identity and administration, e.g. corp.example.com. Shares one directory database and security policy.
Tree One or more domains sharing a contiguous DNS namespace (e.g. example.com and sales.example.com) with automatic trusts.
Forest The top-level security boundary — one or more trees. The first domain created is the forest root. Forests share a schema and global catalog.
Organizational Unit (OU) A container inside a domain for organizing users/computers and for targeting Group Policy and delegating admin rights.
Domain Controller (DC) A server running AD DS that holds a copy of the directory and authenticates logons. Have at least two per domain for redundancy.
Global Catalog (GC) A DC role holding a partial, searchable copy of every object in the forest — used for forest-wide searches and logon (UPN resolution). 
Forest: example.com
└── Tree: example.com
    ├── Domain: example.com            (forest root)
    │   ├── OU=Servers
    │   ├── OU=Workstations
    │   └── OU=Staff
    │       ├── User: jsmith
    │       └── Group: HR-Admins
    └── Domain: sales.example.com      (child domain — contiguous namespace)

Users, groups, and computer objects

Everything in AD is an object with attributes:

  • User objects — a person's account (logon name, password, group memberships, profile, etc.). The legacy logon is DOMAIN\jsmith; the modern form is the UPN [email protected].
  • Computer objects — created automatically when a machine joins the domain; the computer authenticates to the domain just like a user does.
  • Groups — collect accounts to simplify permission assignment. Two types and three scopes:
Security group Has a SID; used to assign permissions (file shares, GPOs). The one you usually want.
Distribution group Email lists only (Exchange); cannot be used for permissions.
Domain Local scope Used to grant access to resources in one domain.
Global scope Groups users from the same domain; commonly nests into Domain Local.
Universal scope Spans the whole forest; membership is stored in the GC.

AGDLP — the classic best practice

Put Accounts into Global groups, put those into Domain Local groups, and assign Permissions to the Domain Local groups. It keeps permission management sane as the directory grows.

AD DS requires DNS

This is the single most important dependency to understand: AD DS cannot function without DNS. Clients and DCs locate domain controllers, the global catalog, and Kerberos/LDAP services by querying special SRV records (under _msdcs, _tcp, etc.) in DNS. If DNS is broken or misconfigured, logons, replication, and Group Policy all fail.

In practice the first DC usually also runs the DNS Server role, hosting an Active Directory-integrated zone for the domain. Domain members must point their DNS settings at a DC, not at a public resolver.

Point members at the DC for DNS

A domain-joined client whose DNS is set to 8.8.8.8 instead of the DC will fail to find the domain (SRV records won't resolve), causing "domain not available" errors. Set clients' DNS to the domain controller's IP.

See DNS and DHCP on Windows for configuring the DNS Server role, and the networking DNS primer for the underlying protocol.

Authentication: Kerberos (high level)

Within a domain, the default authentication protocol is Kerberos v5 (NTLM remains as a fallback for legacy or non-domain scenarios). At a high level:

  1. At logon, the client proves its identity to the Key Distribution Center (KDC) — a service that runs on every DC — and receives a Ticket-Granting Ticket (TGT).
  2. To access a service (e.g. a file server), the client presents the TGT and gets a service ticket for that specific service.
  3. The client presents the service ticket to the server, which trusts it because it was issued by the shared, trusted KDC.

The user's password is never sent to each service, and single sign-on falls out naturally: one logon, tickets for everything. Kerberos depends on reasonably synchronized clocks (default tolerance 5 minutes) and on DNS, which is why time and DNS hygiene matter on a DC.

Promoting a server to a domain controller

Promotion is a two-step process: install the role, then promote the server (create or join a forest/domain). Prerequisites: a static IP and a suitable computer name (set these before promotion — see Windows Server Basics).

Step 1 — install the AD DS role

# Install the role plus its management tools (ADUC, AD PowerShell module)
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

In the GUI: Server Manager → Add Roles and Features → tick Active Directory Domain Services → accept dependencies → Install.

Step 2 — promote (create a new forest)

# Create a brand-new forest with this server as the first DC.
# This also installs and configures the DNS Server role by default.
Install-ADDSForest `
  -DomainName "example.com" `
  -DomainNetbiosName "EXAMPLE" `
  -ForestMode "WinThreshold" `      # 2016 functional level
  -DomainMode "WinThreshold" `
  -InstallDns `
  -SafeModeAdministratorPassword (Read-Host -AsSecureString "DSRM password")

The server reboots and comes back up as a domain controller. To add another DC to an existing domain you would instead use Install-ADDSDomainController; to add a child domain, Install-ADDSDomain.

In the GUI, after the role installs Server Manager shows a yellow notification: Promote this server to a domain controller, which launches the same wizard (Add a forest / domain / DC, set the DSRM recovery password, and so on).

DSRM password

The Directory Services Restore Mode password is a special local recovery password for the DC. Record it securely — you'll need it for directory recovery, and it is not the same as the domain Administrator password.

Joining a client to the domain

On the client (Windows 10/11 or another server), point DNS at the DC first, then join:

# Set DNS to the domain controller, then join the domain (prompts for creds)
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 192.168.10.10
Add-Computer -DomainName "example.com" -Credential (Get-Credential) -Restart

GUI path: Settings → System → About → Domain or workgroup → Change → Member of: Domain → enter example.com → supply domain credentials → reboot. After reboot, log on as EXAMPLE\username or [email protected]. A computer object for the machine appears automatically in AD.

Everyday admin: ADUC and PowerShell

Active Directory Users and Computers (ADUC) is the classic MMC console for day-to-day work — creating users, resetting passwords, managing groups and OUs. Open it with dsa.msc or from Server Manager → Tools → Active Directory Users and Computers. (Install it on a workstation via RSAT to administer remotely.)

The ActiveDirectory PowerShell module does the same things scriptably:

# Create an OU
New-ADOrganizationalUnit -Name "Staff" -Path "DC=example,DC=com"

# Create a user (enabled, must change password at next logon)
New-ADUser -Name "Jane Smith" -GivenName "Jane" -Surname "Smith" `
  -SamAccountName "jsmith" -UserPrincipalName "[email protected]" `
  -Path "OU=Staff,DC=example,DC=com" `
  -AccountPassword (Read-Host -AsSecureString "Initial password") `
  -ChangePasswordAtLogon $true -Enabled $true

# Create a security group and add the user to it
New-ADGroup -Name "HR-Admins" -GroupScope Global -GroupCategory Security `
  -Path "OU=Staff,DC=example,DC=com"
Add-ADGroupMember -Identity "HR-Admins" -Members "jsmith"

# Look things up
Get-ADUser -Identity jsmith -Properties MemberOf
Get-ADGroupMember -Identity "HR-Admins"

AD is the backbone — and feeds Group Policy

Because every user and computer is an object placed in an OU, AD becomes the delivery mechanism for centrally managed configuration: Group Policy Objects (GPOs) are linked to sites, domains, and OUs and applied to the accounts they contain. Master AD's structure and your Group Policy design follows naturally — continue to Group Policy.

Verify your work

# Confirm the DC and forest/domain
Get-ADDomainController -Discover | Format-List Name,Domain,Forest,Site
Get-ADDomain  | Format-List DNSRoot,NetBIOSName,DomainMode
Get-ADForest  | Format-List Name,ForestMode,GlobalCatalogs

# Confirm AD DS-related services are running
Get-Service NTDS,DNS,Kdc | Format-Table Name,Status

# Confirm the DNS SRV records that locate DCs exist
Resolve-DnsName -Type SRV "_ldap._tcp.dc._msdcs.example.com"

# Confirm an object you created
Get-ADUser jsmith -Properties MemberOf | Format-List Name,Enabled,MemberOf

# On a joined client: confirm domain membership
Get-ComputerInfo -Property CsDomain,CsDomainRole

Expected: CsDomainRole reads Primary/Backup Domain Controller on a DC and Member Workstation/Server on a client; the SRV lookup returns the DC; and the NTDS, DNS, and KDC services are Running.

Summary

  • AD DS is the centralized identity, authentication, and directory service for Windows enterprises; it runs on domain controllers and replicates.
  • Core hierarchy: forest (security boundary) → tree (contiguous DNS namespace) → domain → OU (organization + GPO targeting). The global catalog holds a forest-wide searchable index.
  • Users, computers, and groups are objects; use security groups (not distribution) for permissions, and follow AGDLP.
  • Promote a server in two steps: Install-WindowsFeature AD-Domain-Services, then Install-ADDSForest (which also sets up DNS).
  • AD requires DNS (SRV records locate DCs); members must point DNS at a DC.
  • Kerberos provides ticket-based single sign-on and depends on synced clocks and DNS.
  • Administer with ADUC (dsa.msc) or the ActiveDirectory PowerShell module (New-ADUser, Add-ADGroupMember). AD is the backbone that feeds Group Policy.

Related: Windows Server Basics, DNS and DHCP on Windows, Group Policy, File Sharing and Permissions, PowerShell Basics. For contrast, see the Linux track and the networking DNS/DHCP primer.

Test yourself