Active Directory Domain Services (AD DS) remains the identity backbone for many enterprises, and that makes it a high-value target. Attackers don’t need to “break” AD in a traditional sense; they typically abuse legitimate features, weak configurations, or over-privileged accounts to steal credentials, escalate privileges, and move laterally until they control domain admins—or the domain itself. Because AD is both centralized and deeply trusted, small security gaps can cascade into wide compromise.
Securing AD DS is therefore less about one silver-bullet setting and more about a layered design: hardening domain controllers, tightening authentication pathways, limiting where and how privileged credentials can be used, and continuously validating that your intended security posture matches reality. The goal is to reduce the probability of compromise and, equally important, to reduce the blast radius when something inevitably goes wrong.
This guide approaches AD DS security as an engineering project. You’ll start by mapping realistic threat paths and establishing a baseline. From there, you’ll implement controls in an order that tends to minimize disruption while yielding measurable risk reduction. Throughout, you’ll see practical examples—like stopping a ransomware operator from using a helpdesk credential to reach Domain Admin, or preventing LDAP relay-based privilege escalation—so each recommendation connects to a real outcome.
Understand the AD DS threat model before changing settings
AD DS security hardening works best when you align it to how compromises actually happen. Most domain takeovers follow recognizable stages: initial foothold on a workstation or server, credential access (especially password hashes and Kerberos tickets), privilege escalation, lateral movement, and persistence inside AD.
In AD environments, credential access is disproportionately powerful. If an attacker can read password hashes, capture a privileged user’s NTLM challenge/response, or extract Kerberos tickets from memory, they can often authenticate as that user without ever knowing the plaintext password. This is why protecting credential material (on endpoints and on domain controllers) is as important as traditional “account policy” work.
A practical way to frame the threat model is to focus on three categories of attack paths:
First, attacks against authentication and directory protocols. These include abusing NTLM in ways that enable relay, downgrades, or pass-the-hash; manipulating LDAP (Lightweight Directory Access Protocol) traffic when signing or channel binding is not enforced; and attacking Kerberos via ticket theft, delegation abuse, or weak service account configurations.
Second, attacks against privileged identities and administrative workflows. Domain admins logging onto workstations, using shared admin accounts, or managing servers from untrusted endpoints is a common cause of domain compromise. The security of your admin workstation and the way privileged credentials are used often matter more than password length.
Third, attacks against AD’s control plane: domain controllers (DCs), Group Policy Objects (GPOs), certificate services (if present), and replication permissions. Attackers love persistence mechanisms that survive password resets—such as rogue adminSDHolder manipulation, malicious GPOs, or backdoor replication rights.
Before you implement changes, document which business systems depend on legacy protocols, where admins log in today, and which accounts or groups effectively control the domain. This inventory will help you apply hardening without breaking critical workloads.
Establish a baseline: what you have, what’s risky, and what’s missing
Hardening without measurement tends to create blind spots. Start by establishing a baseline of domain controller configuration, authentication protocol usage, privileged group membership, and GPO state.
From the AD perspective, identify the “control groups” that can directly or indirectly administer the domain. At minimum, review membership and nesting for Domain Admins, Enterprise Admins, Administrators (built-in), Schema Admins, Account Operators, Backup Operators, and any custom groups granted powerful rights. In many environments, nested groups and delegated permissions make “effective privilege” larger than it appears.
You also need a baseline of domain controller OS versions and patch state. Newer Windows Server versions include security improvements that materially change risk (for example, better defaults and additional controls around credential protection and SMB hardening). If you have 2008 R2-era DCs lingering, your path to modern protections is constrained.
The following PowerShell snippets are useful starting points. Run them from a workstation with the ActiveDirectory module installed (RSAT) and sufficient read rights.
# List domain controllers and OS versions
Get-ADDomainController -Filter * | Select-Object HostName, Site, OperatingSystem, OperatingSystemVersion, IsGlobalCatalog
# Review privileged group membership (direct members)
$privGroups = @(
"Domain Admins","Enterprise Admins","Schema Admins",
"Administrators","Account Operators","Backup Operators","Server Operators"
)
$privGroups | ForEach-Object {
Write-Host "`n=== $_ ==="
Get-ADGroupMember $_ -Recursive | Select-Object Name, SamAccountName, ObjectClass
}
# Identify accounts with Kerberos unconstrained delegation
Get-ADComputer -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)" -Properties userAccountControl |
Select-Object Name, DNSHostName
# Quick view of accounts marked 'Password never expires'
Get-ADUser -LDAPFilter "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=65536))" |
Select-Object SamAccountName, Enabled
As you gather this data, note areas that commonly correlate with compromise:
Overuse of Domain Admin membership and privileged groups populated with service accounts.
Admins regularly logging on interactively to servers and workstations with high-privilege accounts.
Legacy NTLM dependence and lack of LDAP signing or channel binding.
Service accounts with high privileges and static passwords.
GPO sprawl with inconsistent security filtering and weak delegation.
This baseline becomes your reference point for both hardening and validation later, and it helps you communicate risk to stakeholders in concrete terms.
Harden domain controllers as Tier 0 assets
Domain controllers are Tier 0 assets—systems whose compromise effectively equals domain compromise. Treating DCs like “just another Windows server” is one of the most common security failures in AD operations.
Start with administrative isolation. Domain controllers should not host additional server roles or third-party agents that increase attack surface unless strictly necessary. They should be placed in dedicated OUs with tightly controlled GPOs, and their local configuration should align to Microsoft security baselines for the OS version.
Patch management is non-negotiable for DCs. Many high-impact AD takeovers begin with exploitation of a server vulnerability on a DC, or on an adjacent admin system that can be used to reach a DC. Ensure DCs are on a predictable patch cycle, and align with your organization’s emergency patch process for actively exploited vulnerabilities.
Next, reduce inbound exposure. Domain controllers require a set of ports for AD functionality (Kerberos, LDAP/LDAPS, DNS, SMB/RPC, and others depending on configuration). Don’t interpret that as “allow everything.” Use Windows Firewall with Advanced Security to restrict inbound access to known subnets and management systems, and restrict administrative protocols (like WinRM) to admin networks.
Credential protection on DCs matters, too. Protecting LSASS (Local Security Authority Subsystem Service) reduces the chance that an attacker who lands on a DC can dump credential material. On modern Windows versions, enabling protections such as Credential Guard may not be feasible on DCs in all cases, but LSASS protection (RunAsPPL) and robust endpoint detection coverage on DCs are important.
Even without deploying new tooling, you can take steps to reduce credential exposure by minimizing who can log on to DCs interactively. Domain controllers should not be used for browsing, email, or general administration. Establish a strict “logon rights” model: only dedicated admin accounts in the correct tier should have interactive or remote logon rights.
Finally, lock down backup and restore pathways. Many organizations secure AD but leave DC backups accessible to a broad set of operators. A DC backup often contains secrets that can be extracted offline. Ensure DC backups are encrypted, access-controlled, and monitored, and that backup operators cannot restore to arbitrary infrastructure without oversight.
Prioritize privileged access design: reduce where high-value credentials can exist
If you implement only one strategic change, make it this: redesign privileged access so that high-value credentials are never exposed on low-trust systems. That means separating admin identities, restricting logon locations, and using tiered administrative boundaries.
A tiering model is a common approach. While implementations vary, the principle is consistent: Tier 0 includes domain controllers and identity control plane components; Tier 1 includes server workloads; Tier 2 includes user workstations and endpoints. The most important rule is that Tier 0 credentials must never log onto Tier 1 or Tier 2 systems, because those tiers are more exposed to phishing, browser-based compromise, and commodity malware.
Practically, this implies separate accounts for administrative tasks. A user who is a domain admin should have a standard user account for email and browsing, and a separate Tier 0 admin account used only from hardened admin workstations. These admin accounts should not have mailbox access, should not be used for daily productivity, and should be tightly scoped.
This design directly breaks common ransomware playbooks. Consider a scenario: a helpdesk engineer uses a single account for daily work and occasional server administration. A phishing email compromises their workstation and steals cached credentials. If that same account has local admin on servers, an attacker can use it to move laterally, harvest more credentials, and eventually reach domain admin rights. If privileged tasks require separate accounts and logon is restricted to hardened admin workstations, the same phish is far less likely to yield credentials that matter.
In Windows domains, enforce logon restrictions with “Deny log on locally,” “Deny log on through Remote Desktop Services,” and “Deny access to this computer from the network” for Tier 0 accounts on non-Tier 0 systems. Complement those with “Allow log on locally” and “Allow log on through Remote Desktop Services” for the correct admin groups on the correct admin workstations.
It’s also critical to reduce standing privilege. Where possible, replace permanent membership in high-privilege groups with just-in-time (JIT) elevation and workflow-based approval. In pure on-prem AD DS, JIT often requires additional tooling, but you can still reduce standing privileges by moving admins out of Domain Admins and delegating OU-level rights where appropriate, and by using separate privileged groups for specific tasks.
Secure authentication: Kerberos, NTLM, LDAP, and the paths attackers abuse
Once your privileged access model is defined, focus on the protocols and flows that make credential theft and relay possible. Most AD compromises leverage authentication pathways that were designed for convenience and backward compatibility.
Tighten NTLM usage and reduce relay risk
NTLM is still present in many environments for legacy compatibility, but it is a common enabler of relay and pass-the-hash techniques. “Pass-the-hash” refers to authenticating using a captured NTLM hash instead of the plaintext password; “relay” refers to forwarding an authentication attempt to another service to gain access.
Reducing NTLM begins with visibility. You can audit NTLM usage via policy settings and event logs, but the operational approach is to identify which applications still require NTLM and plan migrations. Many environments discover that NTLM is used primarily because of misconfigurations, old clients, or legacy apps that can be modernized.
On domain controllers, enforce SMB signing to reduce certain relay opportunities against SMB. Also ensure that administrative shares and remote management pathways are not exposed broadly.
Where feasible, configure policies to restrict NTLM. Windows supports policies such as “Network security: Restrict NTLM: Audit NTLM authentication in this domain” and “Network security: Restrict NTLM: NTLM authentication in this domain.” Start in audit mode to avoid breaking dependencies, then move to deny for high-value systems once you have confidence.
Enforce LDAP signing and channel binding
LDAP is fundamental to AD DS. If LDAP traffic is not protected, attackers can exploit weaknesses by relaying credentials to LDAP to modify directory objects, particularly when LDAP signing is not required. LDAP signing ensures integrity of LDAP traffic, while LDAP channel binding helps prevent certain man-in-the-middle scenarios when using TLS.
From a security perspective, enforcing LDAP signing on domain controllers is one of the most impactful controls you can implement, but it requires planning. Legacy devices and applications that perform simple binds without signing can fail.
A practical approach is to move in phases: audit LDAP binds, remediate non-compliant clients, then enforce requirements. Microsoft provides guidance and event IDs on domain controllers to identify unsigned or simple binds.
Also ensure that LDAPS (LDAP over TLS) is configured correctly if you rely on it. Certificates must be correctly deployed to domain controllers, and clients must trust the issuing CA.
Make Kerberos work for you: delegation and ticket risks
Kerberos is the default authentication protocol in AD, and it’s generally stronger than NTLM. However, attackers often abuse Kerberos tickets after stealing them from memory (pass-the-ticket) or by manipulating delegation settings.
Delegation is a feature that allows services to access resources on behalf of users. Unconstrained delegation is particularly risky because it can allow services to obtain and cache tickets in ways that are valuable to attackers. Many organizations can eliminate unconstrained delegation entirely.
Constrained delegation and resource-based constrained delegation (RBCD) are more controlled models, but still need careful governance. Misconfigured delegation can create stealthy privilege escalation paths.
From your baseline step, you likely identified systems with unconstrained delegation. The remediation path is to confirm business need, then migrate those services to constrained delegation or redesign authentication flows.
Secure DNS in AD-integrated environments
DNS is often overlooked in AD security because it “just works,” but AD relies heavily on DNS. If an attacker can manipulate name resolution, they can redirect clients to malicious services, intercept authentication, or disrupt domain operations.
In AD-integrated DNS, protect who can create and modify records. Dynamic updates should be secure where possible. Monitor for anomalous record creation and changes in critical zones, particularly records pointing to domain controllers or key services.
If you use split-brain DNS or have complex forwarding configurations, ensure that recursion and forwarding are intentional and locked down. A misconfigured DNS server can become an exfiltration or command-and-control pathway.
Operationally, ensure DNS servers are patched and monitored, and that administrative access to DNS management aligns with your tiering model. Avoid managing DNS from general-purpose workstations with high privileges.
Lock down Group Policy: prevent GPOs from becoming an attacker’s control channel
Group Policy is one of AD’s most powerful management tools, and attackers know it. If an attacker can modify a GPO linked to a broad OU, they can deploy malicious scripts, weaken security settings, or create persistent local admin access across the environment.
Start by treating GPO management as a privileged operation. Limit who can create, link, and edit GPOs, and review delegation on existing GPOs. In many environments, GPO permissions have accumulated over years and include overly broad groups like “IT Support” or even authenticated users.
Ensure that critical GPOs—those applied to domain controllers, admin workstations, and server OUs—have strict permissions. Use security filtering and WMI filters carefully, and document why each filter exists; complexity without documentation becomes a vulnerability.
Also consider the security of SYSVOL, the file share that stores GPO content. Because SYSVOL is replicated and accessible, improper ACLs can allow unauthorized modification of scripts or policy templates. Verify that only appropriate administrative principals can modify GPO content.
A real-world scenario illustrates the stakes: an attacker compromises a workstation belonging to a junior admin who has edit rights on a widely-linked GPO “for convenience.” The attacker adds a scheduled task deployment to run a PowerShell payload on all servers in the OU. Within minutes, the attacker has code execution across server infrastructure and can harvest credentials, install ransomware, or modify security settings. Tightening GPO delegation and ensuring that only Tier 0/Tier 1 admin roles can modify specific GPOs breaks this escalation route.
Strengthen identity hygiene: accounts, passwords, and service principals
Hardening AD often gets reduced to “strong passwords,” but identity hygiene is broader: account lifecycle, delegation of rights, service accounts, and authentication policies.
Start with privileged accounts. Privileged accounts should be separate from standard user identities and should have stricter controls: longer passwords or passphrases, MFA where feasible (especially for remote access), and restrictions on logon locations. They should also be excluded from broad enterprise applications that increase exposure, such as email.
Service accounts deserve special attention because they are frequently over-privileged and rarely rotated. Traditional service accounts with static passwords are a common weak point: if compromised, they provide persistent access. Where possible, use Group Managed Service Accounts (gMSA), which are designed to provide automatic password management for services on domain-joined systems.
When you cannot use gMSA, treat service accounts like high-value secrets. Scope their permissions narrowly, avoid membership in Domain Admins, and restrict where they can log on.
Also review SPNs (Service Principal Names) for exposure. Accounts with SPNs can be targets for Kerberoasting (requesting service tickets and attempting offline cracking). The risk increases when service account passwords are weak or never rotated.
You can use PowerShell to inventory SPNs and identify potentially risky accounts.
powershell
# List user accounts with SPNs (common Kerberoasting targets)
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, PasswordLastSet |
Select-Object SamAccountName, PasswordLastSet, @{n='SPNCount';e={$_.ServicePrincipalName.Count}}
# Identify members of Domain Admins with last logon information (approximate)
Get-ADGroupMember "Domain Admins" -Recursive | Where-Object {$_.objectClass -eq 'user'} | ForEach-Object {
Get-ADUser $_ -Properties LastLogonDate, Enabled | Select-Object SamAccountName, Enabled, LastLogonDate
}
Another hygiene item is the use of “Password never expires.” In many organizations, this setting exists primarily on service accounts. If those accounts are also privileged, the risk is amplified. Replace these with gMSAs or rotate them under a managed process.
Deploy Local Administrator Password Solution (LAPS) to stop lateral movement via local admin reuse
One of the most reliable attacker techniques in Windows environments is to move laterally using local administrator credentials that are shared across machines. If the local Administrator password is the same on many endpoints, compromise of one machine can quickly become compromise of many.
LAPS addresses this by ensuring that each domain-joined machine has a unique, rotated local admin password stored securely in AD and accessible only to authorized users. Microsoft has both the legacy LAPS and the newer Windows LAPS (integrated into modern Windows). Which one you use depends on your OS levels and management approach, but the core outcome is the same: eliminate password reuse.
In practice, implement LAPS in phases. Start with a pilot OU, confirm helpdesk workflows for password retrieval, and ensure that access to read LAPS passwords is tightly controlled and audited. Then expand to broader workstation and server OUs.
A scenario shows why LAPS is foundational: a malware infection on a receptionist’s PC yields local admin rights and extracts the local Administrator password. In an environment without LAPS, that same password works across hundreds of machines, and the attacker can rapidly pivot. With LAPS, the attacker gains one machine; lateral movement requires additional exploits or credentials, which is slower and noisier.
Protect administrative workstations and remote management pathways
Even if you reduce who has privileges, you still need to secure where privileged work happens. A privileged credential used on an untrusted endpoint is a gift to attackers.
A common pattern is to deploy hardened admin workstations (often called Privileged Access Workstations, or PAWs). These are devices used only for administration, with restricted internet access, minimized software, and strong endpoint protections. Whether you implement a full PAW program or a lighter version, the principle remains: separate admin activities from user productivity activities.
Remote management tools also matter. If admins RDP into servers from general workstations, credential exposure increases. Where possible, use secure management channels, restrict RDP to admin networks, and consider using jump servers or bastion hosts that are treated as Tier 0/Tier 1 assets with strong monitoring.
Windows Remote Management (WinRM) and PowerShell Remoting can be more auditable and can support constrained endpoints, but they also must be secured with proper authentication, network restrictions, and logging.
As you improve admin workstation security, align it with your tiering model. Tier 0 administration should happen only from Tier 0 admin workstations, and those workstations should not be used to administer lower tiers. This separation prevents credential material from “flowing down” into less secure systems.
Reduce attack surface with security baselines and carefully-scoped policies
Security baselines are curated sets of recommended settings that reflect current best practices for Windows. They are not perfect for every environment, but they provide a strong default posture and reduce the chance that you miss critical settings.
Apply baselines in a staged manner. Domain controllers often have specific baseline recommendations that differ from member servers and workstations. Start with audit and monitoring of changes, apply to a pilot, and expand after validation.
Use Group Policy to enforce:
Account lockout and password policies consistent with your risk tolerance and user impact.
Strong auditing policies, especially for account management, privilege use, directory service access, and policy changes.
Network hardening settings like SMB signing, disabling weak ciphers where feasible, and restricting anonymous access.
Be cautious with blanket settings that can break applications. The secure approach is to use scoping (OUs, security groups, and GPO precedence) so you can apply strong defaults broadly while carving out exceptions explicitly and temporarily.
Implement robust auditing and log collection focused on AD attack paths
Hardening without detection leaves you exposed to stealthy persistence and slow-moving attacks. AD-focused detection is about identifying changes and authentications that are meaningful: who changed a GPO, who added a user to Domain Admins, where a privileged account logged on, and whether replication permissions were modified.
Start by ensuring that domain controllers have advanced auditing enabled. Key event categories include:
Directory service changes and access, especially modifications to sensitive objects.
Account management events such as new users, group membership changes, and password resets.
Authentication events, including Kerberos ticket events and NTLM usage where logged.
Policy changes, such as audit policy or GPO modification.
Then, centralize logs. A SIEM is ideal, but even Windows Event Forwarding (WEF) can provide meaningful centralization. The practical goal is to avoid having critical AD security evidence only on the DC that might be targeted during an incident.
Operationally, define a small set of high-signal alerts:
Additions to Tier 0 groups (Domain Admins, Enterprise Admins, etc.).
Changes to GPOs linked to domain controllers or admin workstations.
Changes to delegation settings on computer accounts.
Creation of suspicious scheduled tasks or services deployed via policy.
Unusual authentication patterns for privileged accounts, such as logons from workstations.
A real-world example: an attacker obtains a service account credential and uses it to modify an ACL on a critical OU, granting themselves rights to reset passwords for an admin group. This may not trigger a simple “user added to Domain Admins” alert. If you monitor directory object ACL changes in sensitive OUs and correlate them with unusual authentications, you can detect this stealthier path.
Protect AD replication and directory permissions from abuse
AD replication is how domain controllers stay consistent, and it’s also a high-impact privilege boundary. If an attacker can gain replication rights (for example, the ability to perform DCSync), they can request password hashes from the directory and effectively dump credentials remotely.
DCSync is not a vulnerability in itself; it abuses legitimate directory replication permissions. Protecting against it means ensuring that replication rights are tightly held and monitored.
Review who has replication permissions on the domain root and configuration partitions. The set should be small and understood (typically domain controllers and certain built-in groups). Any non-standard principals with replication rights deserve immediate investigation.
You should also treat changes to AdminSDHolder and the SDProp process as critical. AdminSDHolder is an object that helps protect the security descriptors of privileged accounts and groups; attackers sometimes manipulate it to grant persistent rights. Monitoring and limiting who can modify it is essential.
Secure time synchronization and PKI dependencies
Kerberos depends on time synchronization; significant time skew can cause authentication failures and can complicate incident response and forensics. Ensure that your time hierarchy is correct: the PDC emulator in the forest root typically synchronizes with a reliable time source, and other systems synchronize appropriately.
If you use certificates for LDAPS, smart card logon, or other identity functions, then your public key infrastructure (PKI) becomes part of your identity control plane. While this guide is focused on AD DS, it’s important to recognize that mismanaged certificates can undermine authentication and enable impersonation. If Active Directory Certificate Services (AD CS) exists in your environment, treat it as Tier 0 and apply similar hardening and monitoring principles.
Build resilience: secure recovery planning for AD DS
Security controls reduce likelihood of compromise, but you also need resilience if attackers reach AD control. A secure recovery plan for AD focuses on restoring domain functionality while ensuring you don’t reintroduce attacker persistence.
Start by ensuring you can rebuild domain controllers from known-good media and configuration. Document DC build procedures, patch sequences, and baseline GPOs. In a crisis, “tribal knowledge” disappears quickly.
Backups must be both reliable and protected. If attackers can access and encrypt your backups, recovery becomes significantly harder. Ensure backups are immutable where possible, and separate backup administrative credentials from general IT admin credentials.
Practice recovery steps in a lab or isolated environment. Many organizations discover only during an incident that their authoritative restore procedures, SYSVOL recovery, or DNS recovery steps are not understood.
This planning also ties back to earlier sections: when you implement tiered admin access and restrict privileged credentials, you improve your odds that recovery credentials remain uncompromised.
Validate changes continuously: make AD security a living system
AD DS security is not a one-time project. Configuration drift, new applications, and organizational changes constantly create new risk. The most effective programs treat AD security as a living system with continuous validation.
Build periodic reviews into operations. Review privileged group membership monthly. Review GPO delegation quarterly. Audit NTLM usage regularly and ensure that exceptions are documented and time-bound. Track service accounts and enforce a lifecycle: ownership, purpose, permissions, and rotation strategy.
Automation helps keep this sustainable. Even simple scripts that snapshot privileged memberships and compare them over time can catch unauthorized changes early.
powershell
# Snapshot privileged group membership to a CSV for change tracking
$timestamp = Get-Date -Format "yyyyMMdd-HHmmss"
$groups = "Domain Admins","Enterprise Admins","Schema Admins","Administrators"
$result = foreach ($g in $groups) {
Get-ADGroupMember $g -Recursive | Select-Object @{n='Group';e={$g}}, Name, SamAccountName, ObjectClass
}
$result | Export-Csv ".\PrivilegedGroups-$timestamp.csv" -NoTypeInformation
Over time, connect validation to your incident detection. If your SIEM alerts when a new principal gains rights to modify a Tier 0 GPO, you should also have a process that checks whether that change was approved and expected.
Putting it together: a phased implementation approach that reduces risk quickly
The breadth of AD security can feel overwhelming. A phased approach helps you make progress without destabilizing production.
Start with controls that typically have high security benefit and manageable operational impact: tighten privileged group membership, deploy separate admin accounts, restrict where Tier 0 accounts can log on, and implement LAPS to break lateral movement via local admin reuse. These steps reduce the chance that a single endpoint compromise leads to domain takeover.
Next, harden domain controllers and authentication pathways. Apply DC baselines, ensure patch rigor, restrict inbound management, enforce SMB signing, and plan LDAP signing/channel binding enforcement. These changes directly target common relay and escalation techniques.
Then address deeper structural risks: service account modernization (gMSAs), delegation cleanup, NTLM reduction, and GPO permission cleanup. This phase often requires coordination with application owners but yields long-term stability and security.
Finally, operationalize monitoring and resilience: centralized logging, high-signal alerting, periodic reviews, and secure recovery exercises. This is what turns a hardened AD into a defensible AD.
Throughout these phases, use the real-world scenarios as a mental check: does this change reduce the chance that a phished helpdesk account becomes a domain compromise? Does it make it harder to relay credentials to LDAP? Does it prevent a compromised workstation from becoming a fleet-wide lateral movement platform? If the answer is yes—and you can validate it—then you’re moving in the right direction.