Identity at Enterprise Scale
Think of Active Directory as the bouncer, the org chart, and the rulebook for an entire company — all in one system. When an employee sits down at their laptop and types their password, Active Directory is what decides whether they get in, what files they can access, what software is installed on their machine, and even what their desktop wallpaper looks like.
Active Directory (AD) is a directory service — a specialized database that stores information about users, computers, printers, and other network resources, and enforces rules about who can access what. It was introduced with Windows Server 2000 and remains the dominant enterprise identity system today. Most cloud identity systems (Azure AD, Okta, Google Workspace) can federate with or replace it, but understanding the original is essential for understanding the abstractions built on top.
The Three Protocols Under the Hood
AD is not a single protocol — it is an orchestration of three standards:
-
LDAP (Lightweight Directory Access Protocol): The query language for the directory. When you ask "give me all users in the Engineering department," that is an LDAP query. LDAP uses a tree-structured namespace. A user might have a Distinguished Name (DN) like:
CN=Alice Smith,OU=Engineering,DC=corp,DC=com. -
Kerberos: The authentication protocol. When Alice logs in, she does not send her password to every server she wants to access. Instead, she authenticates once to a Key Distribution Center (KDC) — which runs on the Domain Controller — and receives a Ticket Granting Ticket (TGT). She then uses that TGT to request service tickets for specific resources (file shares, databases, etc.) without re-entering her password. This is called Single Sign-On (SSO).
-
DNS: Active Directory is deeply dependent on DNS. Clients find Domain Controllers by querying DNS for special SRV records. If DNS breaks, AD breaks. This is a common failure mode in enterprise environments.
Key Structural Concepts
| Term | What It Is | Analogy |
|---|---|---|
| Domain Controller (DC) | The server running AD. Holds the ntds.dit database file. |
The bouncer with the master list |
| Forest | The top-level security boundary. Multiple domains can share a forest. | A country |
| Domain | A namespace within a forest (e.g., corp.com). |
A state or province |
| OU (Organizational Unit) | A folder for organizing users and computers within a domain. | A department |
| GPO (Group Policy Object) | A set of configuration rules applied to OUs. | A policy memo that auto-enforces itself |
Group Policy: The Original Configuration Management
Before Ansible, Chef, and Puppet, enterprises used Group Policy Objects (GPOs) to configure thousands of machines simultaneously. A GPO is a collection of settings — disable USB drives, enforce screen lock after 5 minutes, install a specific printer, push a registry key — that is linked to an OU. Every computer and user in that OU automatically receives those settings when they log in or on a refresh cycle (default: every 90 minutes).
From a DevOps perspective, GPOs are the Windows equivalent of a configuration management tool, but they are tightly coupled to Active Directory and only work on domain-joined machines. Modern organizations often layer Ansible or DSC (Desired State Configuration) on top of or instead of GPOs for more flexibility.
Interviewers at companies with Windows infrastructure often ask: "How does Kerberos authentication work?" The key insight is the double-hop problem: if Server A authenticates as you and then tries to access Server B on your behalf, Server B rejects it because Server A cannot forward your Kerberos ticket by default. The solution is Kerberos Constrained Delegation (KCD), which explicitly permits Server A to impersonate you to specific services. This comes up constantly in IIS, SQL Server, and SharePoint deployments.