Domain Controllers and Their Role

Core idea

A domain controller is a server that runs Active Directory Domain Services and acts as the central authority for authentication, authorization, and policy in a Windows domain. When a user logs in, the domain controller verifies their credentials. When a computer applies a security setting, the domain controller is the source of that setting. When an application needs to know whether a user belongs to a particular group, the domain controller answers that question too.

This centralization is the entire point of running a domain. Without it, every server and workstation would need its own local list of trusted users and its own local security policy, which does not scale past a handful of machines and quickly becomes inconsistent. The domain controller exists so that trust and policy live in one place instead of being duplicated and drifting across thousands of endpoints. Add a new employee once, in one place, and every machine in the domain that checks with the domain controller immediately recognizes them; disable one compromised account once, and every machine immediately stops trusting it.

Mental model

Think of a domain controller as the records office and gatekeeper for a large organization at once. Every employee's file, their credentials, their department, their access badge level, lives in that one office. Every door in the building checks with that office before letting someone through, rather than each door keeping its own private guest list. If you wanted to understand or control the entire building, that office is where you would go.

An AD domain works the same way. The domain controller holds the authoritative copy of every account, every group membership, and every policy in the domain, in a database file called NTDS.dit. Every workstation, server, and application that needs to make an access decision defers to the domain controller rather than deciding on its own. That single point of authority is what makes AD administration manageable at scale, and it is exactly what makes the domain controller the highest-value target in the environment: compromise the records office, and you compromise the trust of everything that relies on it.

The domain controller is not exclusively a Windows concept either. On Linux, a Samba server can be configured to provide a basic equivalent, answering authentication requests the same way, though most enterprise environments you will assess run Windows domain controllers.

Real-world context

During enumeration, one of the first things you establish is where the domain controllers are. You can usually identify one by its service fingerprint: a distinctive combination of open ports that Windows domain controllers expose by default. LDAP runs on 389 (and 636 for LDAP over TLS), Kerberos runs on 88, the Kerberos password-change service runs on 464, and DNS runs on 53. A scan that shows this combination together, alongside Microsoft RPC on 135 and SMB on 445, is a strong signal that you are looking at a domain controller rather than an ordinary member server.

kali@kali:~$ nmap -sV -p- someADip
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2021-11-09 20:21:06Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP
445/tcp  open  microsoft-ds
464/tcp  open  kpasswd5
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Global Catalog)
3269/tcp open  tcpwrapped

Identifying the domain controller early shapes the rest of the engagement. It tells you where the group policy objects live, where the account database lives, and which single machine, if compromised, gives an attacker visibility into the entire domain. Everything else you enumerate, workstations, file servers, applications, is ultimately a client of that one machine, which is why a scope discussion or a network diagram almost always starts by locating the domain controllers first.

This is also why client stakeholders need to understand the concept even if they never see a terminal: when you explain that "the domain controller was exposed," you are telling them their organization's entire employee directory, password hashes included, and every security policy in the building, was reachable. That framing lands with a stakeholder in a way that a technical finding name never will on its own.

Follow-up questions

• What specific data does NTDS.dit contain, and why does that make it more sensitive than any individual workstation?
• Why do most production environments run more than one domain controller, and does that reduce the risk of compromising one?
• How does DNS being co-located with the domain controller affect what an attacker can learn from it?
• What is the difference between a domain controller and an ordinary member server that happens to run Windows Server?
• Why does the service fingerprint of a domain controller (LDAP, Kerberos, kpasswd, DNS together) reliably identify it during a scan?