Active Directory Basics

Active Directory (AD) is the identity and directory system behind many Windows business networks. It keeps track of users, computers, groups, policies, and services, then helps decide who may sign in and what they may access.

What Active Directory Is

Active Directory Domain Services grew from the X.500 directory model and uses LDAP to expose a searchable directory. It was also designed for long-term Windows compatibility. That makes AD remarkably capable, but it means administrators must actively restrict legacy behavior and broad read access instead of assuming every default is hardened.

A normal authenticated domain user can usually read a large amount of directory information. This is useful for finding people, groups, computers, and services, but it also makes careful permissions, monitoring, and reduction of stale data important.

AD DS and ADFS Are Different

Active Directory Domain Services (AD DS) is the directory and domain system covered throughout this guide. Active Directory Federation Services (ADFS) is a related federation service that provides single sign-on to applications by issuing claims-based security tokens. In that model, an identity provider packages facts—called claims—about a user so a relying application can make an authorization decision.

The Mental Model

Think of Active Directory as an organization chart joined to an identity desk and a rulebook. The chart describes where things belong, the identity desk verifies people and machines, and the rulebook applies security settings across the environment.

Forest, Tree, and Domain

A forest is the largest Active Directory container and the primary security boundary. The first domain created becomes its forest-root domain. A forest can contain one or more trees, and each tree can contain one or more domains. Domains hold the directory objects that administrators manage.

Trust Relationships

A trust links the authentication systems of domains or forests. Its direction says which side accepts identities from the other; its transitivity says whether that trust can extend beyond the two endpoints. A two-way trust permits access in both directions, while a one-way trust permits it only from the trusted side toward the trusting side.

Trust type	What it connects
Parent-child	Domains in the same tree through an automatic two-way, transitive trust.
Tree-root	A forest-root domain and the root of another tree in that forest.
Cross-link	Domains in the same forest when a shorter authentication path is useful.
External	Specific domains in separate forests, normally as a non-transitive trust.
Forest	Two forest-root domains, allowing trust to extend across both forests as configured.

Trust is not the same as permission. It makes cross-boundary authentication possible; resource ACLs still determine what the authenticated identity may access. External identities added to local groups appear as Foreign Security Principal placeholder objects whose SIDs are resolved through the trust.

OUs Are Structure; Groups Are Access

An Organizational Unit (OU) arranges objects and provides a place to delegate administration or link Group Policy. A group collects identities so permissions can be assigned to many users or computers at once. The distinction is worth remembering:

OUs answer “where is this managed?” Groups answer “what should these members be allowed to do?”

Domain Controllers

A Domain Controller (DC) stores a copy of the directory, handles authentication requests, enforces policy, and replicates changes to other DCs. Multiple domain controllers provide resilience: if one is unavailable, another can continue serving the domain.

Read-Only Domain Controllers and Replication

A Read-Only Domain Controller (RODC) keeps a read-only directory and DNS copy for locations where physical or administrative security is weaker. Its password-replication policy controls which credentials may be cached, and changes do not originate from its AD database, SYSVOL, or DNS copy.

Writable DCs synchronize directory changes through replication. The Knowledge Consistency Checker (KCC) builds connection objects and a replication topology so updates can move between controllers. An AD site groups well-connected IP subnets; site links help AD choose efficient replication and logon paths across slower network boundaries.

Objects, Schema, and Attributes

Everything recorded in AD is an object. A user, computer, group, printer, and shared folder can all be represented as objects. Container objects can hold other objects; leaf objects sit at the end of a directory branch.

The schema is the blueprint. It defines object classes and the attributes each class may have. A user object, for example, can carry attributes such as a display name, logon name, email address, group memberships, and a unique identifier. LDAP names such as displayName and givenName provide consistent ways to query those attributes.

The domain’s Built-in container is created with the domain and holds predefined groups. A shared-folder object, by contrast, points to a share on another computer; it can be protected by permissions but is not itself a security principal.

How AD Names and Identifies Things

Identifier	Plain meaning	Example or use
GUID	A 128-bit identifier assigned to an object for life.	Reliable internal identity even if the object is renamed or moved.
SID	The security identifier for a user, computer, or security group.	Used in access tokens and permission checks.
RID	The final, object-specific portion of a domain SID.	The built-in Administrator account conventionally ends in -500.
DN (Distinguished Name)	The full directory path to an object.	CN=Asha,OU=IT,DC=example,DC=local
RDN (Relative Distinguished Name)	The component that uniquely names an object at its current level.	CN=Asha
sAMAccountName	The traditional Windows logon name.	asha
UPN	A user-friendly logon name in email-like form.	asha@example.local
SPN	A unique name that maps a service instance to its account.	Lets Kerberos request the correct service ticket.
FQDN	The complete DNS name of a host.	dc01.example.local

Security Principals and Access Tokens

A security principal is anything Windows can authenticate, including a user, computer, service account, or security group. When a user signs in, Windows builds an access token containing the user SID, group SIDs, and assigned rights. Resources compare that token with their ACLs. Well-known SIDs represent standard identities such as Everyone, while an object’s GUID remains stable even when its name or location changes.

The Global Catalog

A Global Catalog (GC) is a domain controller that holds a full copy of objects from its own domain and a partial copy of objects from other domains in the forest. It makes forest-wide searches practical and helps resolve group membership during authentication.

Deleted Objects: Tombstones and the AD Recycle Bin

Without the Recycle Bin, a deleted object becomes a tombstone: its isDeleted attribute is set and only a limited set of attributes survives for the tombstone lifetime. The AD Recycle Bin, when enabled, preserves far more of the object so it can be restored with its identity and attributes intact during the configured recovery window.

SYSVOL and Protected Accounts

SYSVOL is the replicated share that carries Group Policy files and logon or logoff scripts to domain controllers. Modern domains replicate it with DFS Replication.

AdminSDHolder stores the security descriptor used to protect members of privileged groups. The SDProp process periodically reapplies that descriptor. The adminCount attribute helps identify objects that have been protected, while the forest-wide dsHeuristics setting can alter selected directory behaviors and therefore deserves strict change control.

SID History

The sIDHistory attribute can retain an account’s previous SID during a domain migration so old resource permissions continue to work. Because those historical SIDs enter the access token, administrators should audit the attribute and use SID filtering across appropriate trusts.

The Protocols Working Underneath

Active Directory is not one protocol. It coordinates several services, each with a distinct job.

Kerberos in Four Steps

1. The user signs in and the client asks the Key Distribution Center (KDC) on a domain controller to verify the identity.
2. After successful verification, the KDC returns a Ticket Granting Ticket (TGT).
3. When the user needs a service, the client presents the TGT and the service’s SPN to request a service ticket.
4. The client presents that service ticket to the target service, which validates it and grants the approved access.

Every domain controller acts as a KDC. The initial authentication exchange produces the TGT; a later ticket-granting-service exchange uses the TGT and the target service’s SPN to produce the service ticket. The domain’s built-in KRBTGT account protects TGTs and is therefore one of the most sensitive identities in the domain.

Golden Ticket: The Defensive Concept

If the KRBTGT secret is stolen, an attacker may be able to forge TGTs—the persistence technique commonly called a Golden Ticket. Each domain has its own KRBTGT account, so the immediate ticket authority is domain-specific, while trusts determine which cross-domain authentication paths exist. This is why KRBTGT protection, privileged-access separation, and a tested incident-response rotation procedure matter.

DNS Discovery and Lookups

AD-integrated DNS publishes SRV records so clients can find domain controllers, Kerberos, LDAP, and other services. Dynamic DNS keeps host records aligned when addresses change.

nslookup example.local
nslookup dc01.example.local
nslookup 10.20.30.10

The first two are forward lookups from names to addresses; the last is a reverse lookup from an address to a host name. An FQDN combines host, domain, and suffix into one unambiguous DNS name.

LDAP Authentication

A domain controller acts as an LDAP server. A client can perform a simple bind or use SASL to rely on another authentication mechanism such as Kerberos. Unprotected LDAP can expose credentials and directory traffic, so production environments should require signing, channel binding where applicable, and TLS through LDAPS rather than relying on cleartext simple binds.

MSRPC Interfaces

Interface	Role in a Windows domain
lsarpc	Reads and manages Local Security Authority policy information.
netlogon	Maintains the secure channel and supports domain authentication.
samr	Provides remote account, group, and computer-management operations.
drsuapi	Supports directory replication between domain controllers.

NTLM, Password Hashes, and Cached Credentials

Kerberos is preferred in modern domains. NTLM remains for compatibility and special cases. It uses a three-message challenge-response sequence: negotiate, challenge, and authenticate. NTLM does not provide Kerberos-style ticketing or the same mutual-authentication model.

Mechanism	Core idea	Modern posture
Kerberos	KDC-issued TGTs and service tickets; supports mutual authentication.	Preferred for domain authentication.
NTLMv2	Challenge-response using the account’s NT secret.	Retain only where compatibility requires it; monitor and reduce use.
NTLMv1	Older, weaker challenge-response construction.	Disable wherever possible.
LM	Legacy case-insensitive password hashing split into two seven-character chunks.	Obsolete; keep disabled.

LM Hash and NT Hash

The obsolete LM hash uppercases a password, pads or truncates it to fourteen characters, splits it into two seven-character pieces, and derives two DES-based results. Those design choices make it far too weak for modern use. The NT hash is derived from the UTF-16LE password with MD4 and is used by NTLM challenge-response. Password-derived secrets are stored in the local SAM or, for domain accounts, within the protected NTDS database.

Domain Cached Credentials (MSCache2)

A domain-joined Windows computer can cache information for recent successful domain logons under the protected HKLM\SECURITY\Cache area. This allows a user to sign in when no domain controller is reachable. These MSCache2 values are deliberately slow to test and are not interchangeable with an NT hash for pass-the-hash authentication.

Groups, Permissions, and Policy

Group Type and Scope

Group	Purpose
Security	Assigns permissions and rights to members.
Distribution	Builds email distribution lists; it does not grant resource permissions.
Domain Local	Typically grants access to resources in the domain where the group exists.
Global	Collects accounts from one domain and can be granted access elsewhere.
Universal	Works across the forest and is recorded in the Global Catalog.

Group Conversion Rules

Scope changes are possible only when nesting remains valid. A Global group can become Universal when it is not a member of another Global group. A Domain Local group can become Universal when it contains no Domain Local groups. A Universal group can always become Domain Local, but it can become Global only when it contains no other Universal groups.

Important Built-In Groups

Domain accounts include users, computers, managed service accounts, and special identities such as KRBTGT. Membership in built-in groups can grant control far beyond an ordinary user, so it should be treated as privileged access rather than a convenient label.

Built-in group	Why it matters
Administrators	Full control of the computer, or of the domain when evaluated on a DC.
Domain Admins	Administrative control throughout one domain and local admin membership on joined computers by default.
Enterprise Admins	Forest-wide administrative control; exists in the forest-root domain.
Schema Admins	Can modify the forest schema.
Account Operators	Can manage many non-protected accounts and groups.
Backup Operators	Can back up and restore protected files; this capability is highly privileged on DCs.
Server Operators	Can manage services, shares, backups, and selected server operations on DCs.
Print Operators	Can manage printers on DCs and log on locally; membership deserves careful review.
DnsAdmins	Administers Microsoft DNS where the group exists.
Group Policy Creator Owners	Can create and manage Group Policy objects.
Protected Users	Applies additional protections against credential theft and legacy authentication.
Event Log Readers	Can read local event logs.
Remote Desktop Users	May be granted interactive Remote Desktop logon.
Remote Management Users	May be granted remote management access such as WinRM.
Hyper-V Administrators	Controls Hyper-V; control of a virtual DC’s host can imply control of the DC.
Domain Users / Computers / Controllers	Default collections for the corresponding domain object types.
Domain Guests	Contains the domain Guest identity and related guest accounts.
Read-only Domain Controllers	Contains RODC computer accounts.
Pre-Windows 2000 Compatible Access	Legacy compatibility group whose membership can expose more directory information.
IIS_IUSRS	Local group used by Internet Information Services worker processes.

ACL, ACE, DACL, and SACL

An Access Control List (ACL) describes protection on an object. Each Access Control Entry (ACE) names a security principal and states what is allowed, denied, inherited, or audited. The DACL controls access; the SACL controls which access attempts are written to the security log. An explicit deny entry overrides an allow entry.

An ACE combines a principal SID, an allow/deny/audit type, inheritance flags, and an access mask describing the granted rights. An object with no DACL is broadly accessible, while an empty DACL denies access—an important difference when reviewing or programmatically building security descriptors.

Rights, Privileges, and User Rights Assignment

A right usually describes access to an object; a privilege allows an action on the operating system. Windows exposes many privileges through User Rights Assignment.

Privilege or right	What it permits
SeRemoteInteractiveLogonRight	Interactive sign-in through Remote Desktop.
SeBackupPrivilege	Read files for backup even when ordinary file permissions would block access.
SeDebugPrivilege	Inspect and adjust other processes; should be tightly restricted.
SeImpersonatePrivilege	Act using another security token in supported service scenarios.
SeLoadDriverPrivilege	Load or unload kernel drivers.
SeTakeOwnershipPrivilege	Take ownership of securable objects.

Group Policy Processing

A Group Policy Object (GPO) is a collection of settings applied to users or computers. The normal processing order is Local → Site → Domain → OU, often remembered as LSDOU. Child OUs are processed after their parents, so the closest applicable policy normally wins when settings conflict. Link order, enforcement, security filtering, and inheritance can change the final result.

GPO Precedence and Refresh Frequency

Within one container, a lower link-order number has higher precedence because it is processed later. Enforced links resist being overridden below their level, while Block Inheritance prevents ordinary higher-level links from flowing into an OU. Enforced links take priority over blocked inheritance.

Workstations and member servers normally refresh Group Policy every 90 minutes with a random offset of up to 30 minutes; domain controllers refresh more frequently, normally every five minutes. A new setting can therefore take time to appear. Administrators can request an immediate refresh with gpupdate /force, while remembering that some settings still require sign-out or restart.

Administration Tools

Tool	Primary use
Active Directory Users and Computers (ADUC)	Routine management of users, groups, computers, contacts, and OUs.
ADSI Edit	Low-level editing of directory objects and attributes; powerful enough to damage the directory if misused.
Group Policy Management Console (GPMC)	Creates, links, organizes, backs up, and reports on domain GPOs.
Group Policy Management Editor	Edits the individual settings inside a GPO, including advanced audit policy.
Local Group Policy Editor	Manages policy on one Windows computer outside domain-linked GPOs.
PowerShell	Automates repeatable queries and administration with modules such as ActiveDirectory and GroupPolicy.

NTDS.DIT and Functional Levels

NTDS.DIT is the domain directory database stored on a domain controller under C:\Windows\NTDS. It contains users, groups, memberships, attributes, and protected password-derived secrets. Enabling reversible password encryption can cause recoverable password material to be stored, so that compatibility setting should remain disabled except for a carefully justified requirement.

Domain and forest functional levels declare the oldest domain-controller generation the environment must support and unlock features that depend on newer AD DS behavior. Historic level changes introduced capabilities such as group nesting, SID history, fine-grained password policies, AES Kerberos support, managed service accounts, claims, authentication policy silos, and Protected Users. Before raising a level, confirm every DC and dependent workload supports the target.

Five Special Domain-Controller Roles

Most directory work is multi-master, but five FSMO roles have a single owner at a time.

Role	Scope	Responsibility
Schema Master	Forest	Controls changes to the AD schema.
Domain Naming Master	Forest	Coordinates adding and removing domains.
RID Master	Domain	Allocates RID pools so objects receive unique SIDs.
PDC Emulator	Domain	Coordinates time, urgent password changes, and several compatibility duties.
Infrastructure Master	Domain	Maintains references to objects in other domains.

A Practical Security Baseline

AD is powerful because identity, policy, and access are connected. That also makes privileged groups, weak delegation, stale accounts, and legacy protocols high-value risks. A sound baseline includes:

• Use Windows LAPS to rotate local administrator passwords.
• Separate everyday and administrative accounts.
• Limit Domain Admin use to domain controllers and essential tasks.
• Use gMSAs for services that need domain identities.
• Require strong passphrases and MFA where supported.
• Review privileged groups, delegated rights, and stale objects.
• Apply least privilege to RDP, local admin, and user rights.
• Patch domain controllers and minimize extra server roles.
• Enable useful audit policy and monitor authentication events.
• Protect LDAP with TLS and retire legacy authentication.
• Use WSUS or a managed update platform such as Configuration Manager to keep Windows systems current.
• Use AppLocker or Windows application-control policy where execution restrictions are appropriate.
• Manage sensitive group membership through reviewed security groups or Restricted Groups policy.
• Audit permissions, trusts, SID history, service accounts, and inactive computers on a schedule.
• Keep unnecessary roles such as IIS away from domain controllers.

Group Policy can centralize account and lockout policy, Kerberos ticket settings, local security options, software restrictions, application control, and advanced auditing. Effective monitoring then turns those controls into evidence: collect authentication, privilege-use, directory-service, and policy-change events so suspicious behavior can be investigated.

The Short Version

Question	Active Directory answer
Who are you?	A user or computer identity verified by a domain controller.
Where do you belong?	A domain and OU structure described by directory objects.
What can you access?	Group membership, security tokens, ACLs, and delegated rights.
Which settings apply?	Group Policy processed across Local, Site, Domain, and OU levels.
How are services found?	DNS records locate domain controllers and other services.
How is access authenticated?	Primarily Kerberos tickets, with NTLM retained for compatibility.