Active Directory Security

Active Directory Domain Services is the identity control plane in a Windows domain. It supplies the directory data, authentication services, groups, and policy scope that domain members trust. Compromise the directory, and you can undermine the systems and accounts that depend on it.

This course builds the security mental model on top of what Active Directory Fundamentals already covers: objects, domains, forests, domain controllers, authentication, and groups. Here, the question changes from "how does AD work" to "how does AD get attacked, and what stops that." You will not walk away able to run a penetration test. You will walk away able to reason about privilege, trust, and exposure the way a defender needs to.

Why Active Directory is the top target

After compromising a workstation, an attacker can steal credentials from signed-in sessions and use them to reach more privileged systems. Microsoft's guidance treats privileged accounts, domain controllers, and adjacent identity infrastructure as primary credential-theft targets. Once an attacker holds privileged control of a domain controller, they can modify, corrupt, or destroy the directory itself. That threatens every AD-managed system and account in the organization.

Credential theft attacks specifically target accounts that already carry elevated privilege: permanently privileged accounts, VIP accounts, domain controllers, and adjacent infrastructure such as public key infrastructure servers. The behaviors that make this easy are common and avoidable: signing in to a privileged account on an ordinary workstation, browsing the internet from a privileged session, reusing the same local administrator password across every machine, and handing out membership in privileged groups more freely than the work requires.

The tier model: containing the blast radius

The core defensive idea in modern AD security is the tier model. It groups every identity, workstation, and server into one of three tiers based on how much control it has over the environment, and it enforces a single rule: a credential from a higher tier must never be exposed to a lower tier.

• Tier 0 is the identity control plane itself: domain controllers, AD FS, AD Certificate Services, Microsoft Entra Connect, and the administrative accounts and groups that control them.
• Tier 1 covers enterprise servers and applications: member servers, Exchange, SQL Server, line-of-business applications, and the accounts that administer them.
• Tier 2 covers end-user devices and the help desk or device-support roles that manage them.

The rule that makes tiering work is about the credential and the keyboard, not the network. An administrator signs in to a privileged access workstation, or PAW, that matches the tier of the system they're about to manage. A Tier 0 session starts from a Tier 0 PAW — never from the same laptop used for email and browsing. If a Tier 0 credential ever gets typed on a Tier 2 device, the containment boundary is already broken, regardless of firewalls or network segmentation. A jump server used to reach a domain controller inherits Tier 0 status the moment it touches a Tier 0 credential, even if the network places it in a perimeter segment.

Two anti-patterns collapse this model in practice: giving monitoring, backup, or endpoint-detection agents Domain Admins-equivalent rights on Tier 1 or Tier 2 hosts, and reusing one service account across tiers. Either one turns every lower-tier system it touches into a Tier 0 exposure point.

Harden domain controllers as Tier 0 systems

Tiering protects the path to a domain controller. The domain controller also needs a smaller attack surface of its own.

Run domain controllers on a current Windows Server version supported by your organization. Microsoft recommends Server Core for this single-purpose role. Keep browsers and general-purpose applications off domain controllers. Limit installed agents, interactive sign-ins, network paths, and physical access. Manage them remotely from dedicated, secured administrative endpoints.

Treat any system that can control a domain controller as Tier 0 too. This includes its virtualization host and the tools that patch, back up, monitor, or deploy software to it. A general management platform with code execution on every domain controller can compromise the forest even when no operator signs in locally.

Apply and audit a domain-controller security baseline. Test changes before broad enforcement, especially when older applications depend on legacy protocols. Hardening that silently breaks authentication will be rolled back under pressure, so compatibility evidence is part of the control.

Protecting the accounts that matter most

Three built-in groups carry the highest privilege in Active Directory by default: Enterprise Admins, Domain Admins, and Administrators. Active Directory treats these, and a defined set of other sensitive groups, as protected groups: Account Operators, Administrator, Administrators, Backup Operators, Domain Admins, Domain Controllers, Enterprise Admins, Enterprise Key Admins, Key Admins, Krbtgt, Print Operators, Read-only Domain Controllers, Replicator, Schema Admins, and Server Operators.

Protected groups get their permissions enforced automatically. AdminSDHolder holds a template access control list. A background process called SDProp runs on the PDC Emulator every 60 minutes by default. It compares protected-object permissions with that template and resets drift. This prevents a delegated administrator or a mistaken change from leaving an alternate access path on a protected account.

The Protected Users group adds a second, complementary layer aimed at credential theft rather than permission tampering. Adding an account to it triggers protections the account holder cannot turn off: no NTLM authentication, no DES or RC4 Kerberos encryption, no unconstrained or constrained delegation, no cached plaintext credentials for CredSSP, WDigest, or NTLM, and a hard four-hour Kerberos ticket lifetime with no renewal. That last point is also the biggest operational trap: enabling it for the wrong account, on domain controllers running an older Windows Server version than required, can lock people out because the account cannot get the AES keys it now needs. Service and computer accounts should never join this group — their credentials live on the host regardless, so membership buys nothing.

Delegation: a legitimate feature with a sharp edge

Kerberos delegation lets a front-end service request access on behalf of the user who authenticated to it, so a web application can reach a back-end database as that user rather than as itself. It's necessary in multi-tier application architectures, and it's also one of the more dangerous settings in the directory if applied carelessly.

Unconstrained delegation lets the trusted service obtain a ticket to any other service, acting as whoever authenticated to it. If a Domain Admin ever authenticates to a compromised service configured this way, the service can request a ticket to a domain controller in the Domain Admin's name and modify Enterprise Admins membership directly. Constrained delegation narrows that risk by limiting which specific services the account can request tickets for. Resource-based constrained delegation (RBCD) moves the decision to the resource's owner instead of the front-end service's administrator, and it is scoped to whichever accounts that resource explicitly trusts. The defensive posture that follows from this is simple: privileged accounts — Domain Admins, Enterprise Admins, sensitive service accounts — should be flagged as sensitive and cannot be delegated, which removes them from delegation entirely regardless of what any service is configured to request.

Credential hygiene: passwords attackers can't reuse

Two specific credential problems recur across almost every AD compromise, and both have a direct fix.

The first is local administrator passwords shared across every machine in the domain. Compromise one workstation with that password and an attacker can sign in as local administrator on every other workstation that shares it — a lateral-movement shortcut with no privilege escalation required. Windows LAPS (Local Administrator Password Solution) removes this by randomizing and rotating the local administrator password independently on every domain-joined device, storing each one in Active Directory behind an access control list that only authorized accounts can read.

The second is service accounts with manually managed, rarely rotated passwords, often set to never expire because rotating them risks breaking a service. A group Managed Service Account (gMSA) solves this the same way LAPS solves local admin passwords: Windows manages and automatically rotates the account's password, and any server authorized to use the gMSA can retrieve the current password without an administrator manually synchronizing it across every host running the service.

Credentials also need protection in transit. LDAP signing verifies the integrity and authenticity of LDAP messages. LDAP channel binding ties authentication to the underlying Transport Layer Security session. Enforcing these controls blocks insecure binds and reduces relay and interception risk. Audit client compatibility first, then replace or isolate applications that still require unsigned or unprotected LDAP.

The krbtgt account deserves particular attention because it isn't like other accounts: it encrypts and signs Kerberos tickets in the domain. If its password hash is compromised, an attacker can forge Kerberos tickets — a Golden Ticket — without using the impersonated account again. Microsoft Defender for Identity flags a krbtgt password older than 180 days. Microsoft's procedure resets it twice, with at least ten hours between resets, to invalidate existing tickets.

Recovery is a security control

Replication is not recovery. A malicious change can replicate to every writable domain controller. After privileged domain-controller compromise, Microsoft says the forest cannot be considered trustworthy until you recover from a known-good backup and close the path that enabled the compromise.

A forest recovery restores at least one writable domain controller in every domain. You also need the built-in Administrator and Directory Services Restore Mode credentials required by the procedure. Protect those credentials separately from the forest they recover. Maintain multiple supported backups, identify the last trusted backup, and rehearse the ordered recovery plan on isolated infrastructure. A backup is only evidence of recoverability after you have restored it successfully.

Watching for compromise

Prevention is necessary but not sufficient. Windows exposes audit policy subcategories for Kerberos authentication, directory changes, group management, account management, and special logons. Configure the Special Groups list before relying on event 4964 to identify a privileged group member's sign-in. High-value alerts include unexpected privileged-group membership, a Domain Admin credential used on an ordinary workstation, or a non-administrator account holding Replicating Directory Changes and Replicating Directory Changes All. That permission pair enables DCSync, which abuses domain replication to request password data without reading a domain controller's disk.

Microsoft Defender for Identity builds a managed detection layer on top of this raw signal. It's a cloud service that monitors identity signals from on-premises Active Directory and Microsoft Entra ID, correlates them with behavioral analytics rather than single-event triggers, and surfaces the specific misconfigurations this course covers — unsecured Kerberos delegation, dormant privileged accounts, stale krbtgt passwords, non-admin DCSync rights — as concrete, prioritized findings rather than raw logs an administrator has to interpret from scratch.

Where this leaves you

None of this is a checklist you run once. Keep Tier 0 small. Never cross tiers with a credential. Minimize the domain-controller attack surface. Protect privileged and service accounts. Secure LDAP. Monitor identity changes. Prove that forest recovery works. Active Directory Administration covers the daily operations beneath these disciplines. The links in this course take you from the tier model through protocol hardening, detection, and recovery.