Domain controller vs. Active Directory

"Domain controller" and "Active Directory" get used interchangeably all the time, but they're not the same thing. Active Directory is the directory service that stores your organization's identity data and policies. A domain controller is the server that runs that service and makes it available to the network.

This distinction matters more than it sounds like it should. It comes up in infrastructure planning, troubleshooting, and security conversations constantly, and getting it wrong leads to confusion at best and misconfigurations at worst. This page covers what each component does, how they relate, and why both need monitoring.

What is Active Directory?

Active Directory (AD) is Microsoft's directory service for Windows domain networks, and it's been around since Windows 2000. It provides centralized identity and access management by storing user accounts, computer accounts, groups, organizational units (OUs), and Group Policy Objects (GPOs) in a hierarchical database.

When most admins say "Active Directory," they mean Active Directory Domain Services (AD DS), the core service that handles authentication and directory lookups. AD DS validates credentials, enforces Group Policy, and replicates directory data across domain controllers.

But AD also includes three other services. You may interact with them less often, but they're worth knowing about.

Group Policy is one of the most useful things AD gives you. GPOs let you control security settings, software deployment, logon scripts, and hundreds of other configuration options across every domain-joined machine from a single location.

What is a domain controller?

A domain controller (DC) is a Windows Server that hosts a writable or read-only copy of the AD DS database (stored in the NTDS.dit file) along with the SYSVOL folder. It's the physical or virtual server that makes Active Directory available to your network.

When a user enters their credentials, the DC validates them using Kerberos (the default protocol) or NTLM. It also processes Group Policy updates and replicates directory changes to other DCs in the domain.

Every DC typically runs DNS as well, because AD relies on DNS SRV records for service location. Without DNS, clients can't find a domain controller to authenticate against.

DC types and roles

The Schema Master and Domain Naming Master are forest-wide roles (one of each per forest). The RID Master, PDC Emulator, and Infrastructure Master are domain-wide roles (one of each per domain).

Microsoft recommends deploying at least two domain controllers per domain. If one DC goes offline, the second continues handling authentication so users aren't locked out.

Domain controller vs. Active Directory: key differences

The simplest way to think about it: Active Directory is the service, and a domain controller is the server that runs it.

A domain controller is part of Active Directory in the sense that it's a required component. AD DS can't function without at least one DC to host the database and respond to authentication requests. At the same time, a server only becomes a domain controller when you promote it and install the AD DS role.

If it helps, think of it like a database and a database server. The database (AD) holds the schema and data. The server (DC) runs the engine, accepts queries, and replicates data to other servers.

Active Directory in hybrid environments

Active Directory isn't going anywhere. Organizations with on-premises servers, legacy applications, and domain-joined workstations still depend on AD DS and local domain controllers. The direction is toward hybrid identity, not a wholesale replacement.

Microsoft continues to invest in both on-premises AD (Windows Server 2025 includes AD DS updates) and Microsoft Entra ID.

Security risks targeting domain controllers

Domain controllers are the most critical servers in any Windows environment. A single compromised DC can give an attacker full control over every account in the domain, because the DC holds every password hash and issues every authentication ticket.

Here's what that looks like in practice.

These attacks all target the domain controller because it's the trust anchor for the entire domain. Detecting them requires monitoring specific event patterns across every DC in real time.

ADAudit Plus detects these attacks through its Attack Surface Analyzer, which monitors indicators of compromise across all domain controllers. It flags suspicious replication requests, anomalous Kerberos ticket activity, and unauthorized LSASS modifications as they happen.

Limitations of native tools for monitoring domain controllers

Windows provides Event Viewer, PowerShell, and command-line utilities like repadmin for monitoring DCs. These tools work, but they have real gaps when you're managing more than a couple of servers.

Event Viewer logs are local to each domain controller. If you have five or ten DCs, you need to check every one separately to piece together a complete picture of logon activity or directory changes. There's no built-in way to pull logs from all DCs into a single view.

Cross-DC correlation is entirely manual. When an account gets locked out, the lockout event (Event ID 4740) may be logged on one DC, but the failed logon events that triggered it (Event ID 4625) could be on a completely different DC. Tracing the root cause means opening Event Viewer on each DC and matching timestamps by hand.

Anyone who's done this at 2am during an incident knows how old it gets.

There's no native mechanism for long-term log retention without third-party tools or custom scripting.

Native tools also lack real-time alerting. You can write scheduled tasks to check for specific Event IDs, but there are no built-in alert profiles that notify you by email or SMS when something critical happens.

AD object attribute changes are recorded without before-and-after values in many scenarios. If a user's department or manager field changes, native logs may show that a change happened but not what the old value was. That makes investigating or rolling back unauthorized modifications harder than it should be.

There's also no user behavior analytics built into Windows. Native tools can't build a baseline of normal activity per user or spot anomalies like an unusual logon time, a first-time host access, or a sudden spike in failed authentications.

Monitoring domain controllers with ADAudit Plus

What ADAudit Plus monitors on domain controllers

ADAudit Plus collects and centralizes logon and authentication events (Event IDs 4624, 4625, 4768, 4769, 4771, 4776) from every domain controller in your domain into a single console. You don't need to log into each DC individually.

For AD object changes, ADAudit Plus tracks user creation, deletion, and modification; group membership changes; OU changes; and GPO changes with old and new attribute values (Professional edition).

DC-specific reports include the Domain Controller Logon Activity report, replication health monitoring (Replica Sync History, Replication Failures), and FSMO role change tracking.

The Attack Surface Analyzer covers 25+ named AD attacks including DCSync, DCShadow, Golden Ticket, Kerberoasting, pass-the-hash, and Skeleton Key. Each detection includes a drill-down showing when the attack was attempted, by whom, from which machine, and what the impact was.

Real-time alerts can trigger automated responses: an alert fires, a ticket gets created in your service desk, and the relevant team gets notified by email or SMS.

Native tools vs. ADAudit Plus

FAQ