Continuous Monitoring for Active Directory

Active Directory sits at the center of nearly every federal and enterprise identity architecture. It controls authentication, authorization, group policy enforcement, and trust relationships across the entire environment. When it works, nobody thinks about it. When it fails or gets compromised, everything stops.

The problem is that most organizations treat Active Directory as infrastructure rather than as a security surface. They patch it on a cycle, back it up on a schedule, and monitor it the same way they monitor a file server. That approach made sense when the threat model was simpler. It does not hold up today, particularly in environments where privileged accounts are shared, service accounts proliferate without governance, and domain controllers have not been rebuilt since the original deployment.

Attackers understand Active Directory far better than most defenders do. Techniques like Kerberoasting, DCSync, pass-the-hash, Golden Ticket attacks, and group policy object manipulation all depend on the same directory infrastructure that the organization trusts without question. In many federal environments, a compromise of Active Directory is effectively a compromise of the mission.

Continuous monitoring for Active Directory is not a compliance checkbox. It is the operational practice of maintaining persistent visibility into the configuration state, authentication behavior, privilege activity, and replication health of the directory so that anomalies surface before they become incidents. This article explains what that monitoring actually requires, which telemetry sources matter most, and how to build a defensible posture around the directory without adding unsustainable operational burden.

If your current monitoring strategy treats domain controllers the same as general-purpose servers, this article is for you.

Why Active Directory Demands a Dedicated Monitoring Posture

Active Directory is not just a login service. It is the policy enforcement plane for the entire Windows environment. Group policy objects govern workstation configuration, software restrictions, logon scripts, and security settings at scale. Trust relationships determine which forests can authenticate to which systems. Service accounts carry embedded credentials that applications depend on to function. Privileged groups like Domain Admins and Enterprise Admins hold keys to the entire environment.

This architecture creates an enormous attack surface that is easy to overlook because it looks stable from the outside. Services authenticate. Users log in. Applications connect. The directory just works. The problem is that “working normally” and “being compromised” are not mutually exclusive states. An attacker who gains a foothold in Active Directory does not need to break anything. They just need to persist quietly, escalate privileges over time, and move laterally without triggering obvious alerts.

Federal environments compound this challenge. Many agency Active Directory deployments carry technical debt from multiple generations of consolidation efforts, domain migrations, and acquisitions. Service accounts created during Windows Server 2003 migrations sometimes still exist. Group policy objects from decommissioned systems remain in place. Stale user accounts linger in privileged groups because nobody confirmed they were safe to remove. This accumulated complexity creates exactly the kind of ambiguous environment that attackers exploit.

Monitoring Active Directory continuously means maintaining persistent awareness of changes to objects, configurations, permissions, and authentication patterns. It means having the ability to detect when a non-privileged account is suddenly added to a privileged group at 2:00 AM. It means knowing when a service account authenticates to a system it has never touched before. It means seeing replication failures before they cascade into authentication outages. None of that happens through periodic scanning or weekly log reviews.

Telemetry Sources That Actually Matter

Not all log data from Active Directory carries equal value. Organizations that enable verbose logging across every event category quickly discover that volume without context is a different kind of blindness. The goal is targeted telemetry that captures the actions, changes, and authentication behaviors that carry real investigative and detection value.

Windows Security Event Logs on domain controllers are the primary data source. Specific event IDs carry outsized importance: account creation and deletion events, group membership changes, logon and logoff events with their authentication type codes, privilege use events, policy change events, and Kerberos service ticket operations. The challenge is that these logs generate enormous volume on busy domain controllers, and the useful signal sits inside a stream of routine authentication noise.

Sysmon provides a secondary telemetry layer. When deployed on domain controllers, Sysmon captures process creation, network connections, and file system activity at a granularity that standard Windows logging does not provide. Detecting a LSASS memory access attempt or an unusual process establishing a network connection to another domain controller is difficult without it. The deployment of Sysmon on domain controllers is a common gap, often because teams treat domain controllers as too sensitive to touch without a formal change window.

Active Directory Change Auditing, sometimes implemented through native audit policies and sometimes through dedicated directory auditing tools, tracks object-level modifications. This includes changes to user attributes, group membership modifications, organizational unit structure changes, schema modifications, and site topology changes. These changes do not always generate prominent alerts on their own, but they are frequently part of attacker activity when reviewed after the fact.

Replication monitoring belongs in the same category. Directory replication errors are both an availability concern and a potential security indicator. Certain attack techniques generate replication-like traffic from non-domain-controller systems. Understanding what normal replication looks like between specific domain controller pairs creates the baseline necessary to detect when something else is generating similar traffic.

Domain Controllers as a Priority Monitoring Target

Domain controllers hold a unique position in the environment. They are simultaneously the most critical infrastructure assets and frequently among the least consistently monitored. In large multi-site federal deployments, domain controllers may span dozens of physical locations, data centers, and cloud tenancies. The team responsible for monitoring them may not be the same team responsible for administering them, and neither team may have full visibility into what the other considers normal.

Monitoring domain controllers requires treating them differently from other server infrastructure. The audit policy configuration on a domain controller should be more aggressive than on a standard member server. The log forwarding pipeline for domain controller events should be prioritized over general server log streams. Alert thresholds for domain controller events should be tuned separately from environment-wide thresholds, because what looks like normal authentication volume on a member server is a completely different signal on a domain controller.

Read-Only Domain Controllers and Branch Sites

Read-only domain controllers deployed at branch sites or forward operating locations represent a monitoring gap in many federal environments. They receive a subset of directory data, they authenticate users locally, and they may operate over constrained WAN connections that complicate log forwarding. When an RODC is compromised or misconfigured, the impact can be contained or catastrophic depending on the specifics of what credentials were cached and what trust relationships were in place. Monitoring these systems consistently, even at reduced fidelity, matters more than many program teams realize.

Domain Controller Log Forwarding Gaps

Log forwarding from domain controllers to a central collection point sounds straightforward, but in practice it breaks in several ways. Agents deployed on domain controllers sometimes get excluded from automated deployment pipelines because administrators are cautious about touching them. Event forwarding configurations get applied inconsistently across a forest because group policy scope is misconfigured. Log collectors at remote sites fill up and start dropping events during peak authentication hours. The result is a monitoring posture that looks complete in the dashboard but has actual gaps at the exact systems that matter most. Verifying log coverage on domain controllers specifically, not just assuming it based on general deployment status, should be a routine operational check.

Privilege Activity and Identity Behavior

Privilege escalation and lateral movement in Active Directory environments almost always leave traces if you know what to look for. The challenge is separating those traces from the enormous volume of normal administrative activity that flows through the same systems every day. A domain administrator logging into a domain controller at 11:00 PM on a Tuesday is either a security event or a routine maintenance activity, and context is the only thing that distinguishes them.

Effective identity monitoring in Active Directory focuses on behavior deviation from established baselines. A service account that has authenticated to the same three servers every day for two years suddenly authenticating to a new system warrants investigation. A user account added to a privileged group outside of a documented change window is worth reviewing immediately. A large spike in failed authentication attempts originating from a single workstation, or distributed across workstations in a pattern that does not match normal user behavior, is an active detection opportunity.

Service account governance is where most environments have the largest unaddressed risk. Federal environments commonly have hundreds of service accounts, many of them created years ago, some of them tied to applications that have been decommissioned. These accounts often carry elevated permissions granted for a specific integration that no longer exists. They use static passwords because the application that owns them cannot support automated rotation. They are frequently excluded from privileged account monitoring because they do not belong to any obvious privileged group, even though their permissions allow significant access.

Kerberoasting targets service accounts specifically because service principal names are enumerable by any authenticated user and service ticket encryption can be attacked offline. Detecting Kerberoasting does not require endpoint visibility. It requires watching for unusual volumes of Kerberos service ticket requests, particularly requests for SPNs that are not associated with actively used applications, from accounts or systems that have no operational reason to request them. That detection is only possible if you have a baseline of normal Kerberos traffic and you are actually collecting those event IDs from domain controllers.

Group policy object changes represent another undermonitored privilege surface. A GPO modification that disables Windows Defender, removes audit policies, or adds a local administrator account to every workstation in an OU can execute silently across thousands of endpoints before anyone notices. GPO change monitoring should be a real-time alert, not a periodic review. The combination of who made the change, what was changed, and when it was changed provides the investigative thread needed to determine whether it was authorized maintenance or an active attack.

Broadly speaking, identity behavior monitoring for Active Directory connects directly to the broader practice of continuous monitoring across the enterprise. The directory does not exist in isolation from the rest of the security program. What happens in Active Directory is often a leading indicator of what is happening or about to happen everywhere else.

Compliance, RMF, and the Authorization Connection

RMF authorization packages for systems that depend on Active Directory frequently underrepresent the directory’s actual risk contribution. The system being authorized uses Active Directory for authentication, but Active Directory itself may be a separate system authorization boundary with its own ATO. In practice, this means neither authorization package fully accounts for the combined risk surface. The system’s security assessment validates that it can authenticate to the directory. The directory’s security assessment validates that the directory service is running and patched. Neither one examines whether the privileged account management posture, service account hygiene, or group policy configuration of the directory creates exploitable risk for the dependent system.

Continuous monitoring requirements under NIST SP 800-137 and supporting NIST SP 800-53 controls like AU-2, AU-6, AC-2, and AC-6 create obligations that apply directly to directory monitoring. The challenge is that control assessments often check whether a monitoring capability exists rather than whether it covers the right telemetry sources at appropriate fidelity. An organization can have a fully deployed SIEM and still have no meaningful detection capability for the Active Directory attack techniques most likely to be used against their environment.

ISSOs and ISSMs supporting systems with Active Directory dependencies should push for explicit coverage of domain controller telemetry in continuous monitoring plans. The monitoring strategy section of a system security plan should name Active Directory as a monitored component, identify the specific event categories being collected, and describe how alerts for directory-specific threat behaviors are generated and routed. Leaving this to a generic statement about SIEM coverage is a documentation gap that tends to surface as a finding during third-party assessments.

Common Mistakes

Treating domain controllers as standard servers in the monitoring pipeline is the most common mistake, and it has consequences that go beyond a simple coverage gap. The audit policy settings that make sense for a member server are insufficient for a domain controller. The log retention period appropriate for a workstation is too short for a directory service that attackers may persist in for weeks before acting. The alert rules tuned for general server activity will miss the specific event combinations that indicate Active Directory exploitation.

Relying on periodic scanning to substitute for continuous telemetry is another pattern that does not hold up under scrutiny. Vulnerability scanners can identify known misconfigurations and missing patches, but they cannot detect an unauthorized group membership change that occurred at 3:00 AM on Saturday. The operational tempo of Active Directory attacks does not align with weekly scanning windows.

Monitoring without baselines generates alert fatigue rather than detection value. Organizations that enable verbose Active Directory logging and forward everything to a SIEM without tuning rules often find that analysts stop reviewing alerts because the volume is unmanageable. Effective monitoring requires understanding what normal looks like for each account type, each system role, and each site, so that deviations carry real meaning.

Excluding service accounts from behavioral monitoring because they are not in an obvious privileged group is a consistent blind spot. Service accounts used by legacy applications frequently have permissions that are not reflected in their group memberships. Mapping service account permissions against actual system access, not just group membership, is a step many organizations skip because the discovery process is tedious and the results tend to be uncomfortable.

Finally, treating an Active Directory security assessment as a one-time event creates false confidence. Active Directory configurations drift over time. New service accounts get created. Group memberships get modified through exception processes that bypass normal reviews. Schema changes from application deployments introduce new attack surface. Continuous monitoring means continuous, not annual.

Recommended Federal Approach

Start with verified coverage. Before tuning any detection rules, confirm that every domain controller in the forest is actually forwarding logs to the central collection point. Break domain controllers out as a distinct inventory category in the monitoring platform and verify them specifically. Gaps at the domain controller level cannot be compensated for by broad coverage metrics.

Establish targeted audit policies on domain controllers that prioritize the event categories carrying detection value: account management, logon events, privilege use, policy change, directory service access, and object access where scoped to sensitive objects. Work with the systems administration team to document what normal activity looks like at each DC tier before enabling alerting, because alert rules written without baselines produce noise that erodes analyst confidence.

Build a service account inventory with associated permissions and system dependencies. This is an uncomfortable project in most federal environments because it surfaces debt that nobody wants to own. But it is a prerequisite for meaningful monitoring of service account behavior. Without knowing what normal looks like for each service account, you cannot detect when something abnormal is happening.

Prioritize real-time alerting for a specific, manageable set of high-confidence indicators: privileged group membership changes outside of change windows, domain controller logons by non-administrative accounts, GPO link and setting modifications, account creation in sensitive OUs, and unusual Kerberos ticket request patterns from systems not associated with expected service principals. Keep the initial alert set narrow enough to be actionable. Expand it as the team develops confidence in baseline accuracy and response processes.

Integrate Active Directory monitoring outcomes into the RMF continuous monitoring strategy. Document the specific controls supported by directory monitoring, identify the review frequency, and establish a process for reporting significant directory configuration changes to the ISSO for SSP update consideration. When third-party assessors review the monitoring program, Active Directory should appear as an explicitly addressed component with traceable telemetry coverage, not as an implied assumption under general server monitoring.

Test the monitoring capability periodically. Simulating a non-destructive privileged group membership change during a scheduled test window, then verifying that the alert fired and was correctly routed, confirms that the detection chain actually works. Organizations that only verify log ingestion and never test alert generation discover gaps the hard way. If you want to learn more about building a defensible monitoring program across the enterprise, the Anchor Defense solutions portfolio covers the operational approach across identity, infrastructure, and mission systems. For teams building or maturing their programs, the Anchor Defense resources page offers practical reference material built for federal environments.