AD compromise doesn’t stay contained. It cascades. One domain controller breach opens paths into SaaS applications, cloud storage, and federated services, usually through token theft, ADFS key extraction, or AD Connect abuse. That blast radius is the whole reason AD hardening belongs near the top of the priority list, and it starts with understanding what the other side is actually doing.<\/p>\n
Common Active Directory security vulnerabilities<\/strong><\/h2>\nAttackers tend to follow a predictable chain: initial access, credential harvesting, lateral movement, privilege escalation, and eventually domain dominance. Along the way, they lean on misconfigurations, weak service accounts, and legacy protocols. A handful of techniques show up again and again in real incidents:<\/p>\n
\n- Kerberoasting and AS-REP Roasting:<\/strong> Any domain-authenticated user can ask for Kerberos service tickets tied to accounts with Service Principal Names (SPNs). Those tickets are encrypted with a key derived from the account’s password, and attackers crack the key offline at their leisure. AS-REP Roasting is the nastier cousin, needing zero credentials when accounts have Kerberos pre-authentication disabled.<\/li>\n
- DCSync:<\/strong> Abuses AD’s Directory Replication Service Remote Protocol to pull every password hash from a domain controller. Attackers get the Replicating Directory Changes rights they need through permission misconfigurations or existing Tier 0 access.<\/li>\n
- Pass-the-Hash and Pass-the-Ticket:<\/strong> Here, attackers authenticate with stolen NT LAN Manager (NTLM) hashes or Kerberos tickets instead of plaintext passwords. Strong passwords don’t help, because the hash itself is the credential.<\/li>\n
- Golden Ticket attacks:<\/strong> Once the KRBTGT account’s password hash is in hand, usually via DCSync, attackers forge Kerberos tickets valid for any account in the domain with whatever lifetime they choose. Cleaning up means resetting KRBTGT twice with forced replication, which is disruptive by design.<\/li>\n
- Group Policy Object (GPO) abuse:<\/strong> Write access to GPOs lets attackers push malicious configurations to every computer in scope at once. Most teams over-permission GPOs early and rarely audit them afterward.<\/li>\n<\/ul>\n
None of this is fringe. The joint Cybersecurity and Infrastructure Security Agency (CISA) advisory on Akira ransomware<\/a> describes attackers dumping the AD database, password spraying against AD accounts, and enumerating users and groups through AD query tools. With that attacker playbook in mind, here’s where to focus the defense.<\/p>\n8 best practices for hardening Active Directory<\/strong><\/h2>\nHardening AD is layered work. Each of these eight practices answers a distinct attacker technique, and together they reduce credential exposure, limit privilege paths, tighten legacy settings, and make recovery possible when something slips through.<\/p>\n
Enforce least-privilege access and tiering<\/strong><\/h3>\nEvery account, whether user, admin, or service, should hold only the permissions its job actually needs. At scale, that means separating privileges by how sensitive the asset is: Tier 0 for domain controllers and identity infrastructure, Tier 1 for application servers, Tier 2 for workstations.<\/p>\n
Under that model, domain admin credentials never touch Tier 1 or Tier 2, with Authentication Policies and Silos (or User Rights Assignment via GPO) enforcing the separation.<\/p>\n
Tier 0 admins belong to privileged groups like Domain Admins, Enterprise Admins, and Schema Admins. Those memberships need regular reviews, and just-in-time elevation should replace standing access wherever you can manage it.<\/p>\n
One tier down, local admin accounts need their own control. Microsoft LAPS rotates unique passwords per machine and shuts down pass-the-hash pivots that otherwise flatten the whole tiering model. And the model only holds if the top tier is genuinely locked down.<\/p>\n
Harden domain controllers as Tier 0 assets<\/strong><\/h3>\nDomain controllers hold the highest-value credentials in the environment, so shrinking their attack surface is non-negotiable.<\/p>\n
Start with what doesn’t belong on a DC: web browsers, general internet access, unnecessary services, and the Print Spooler service that opens the door to PrintNightmare and coerced-auth attacks. What stays gets tightened through GPO-applied security baselines, application allowlists, and just-in-time (JIT) access for privileged groups.<\/p>\n
Passwords matter too, with real strength: 14+ characters, complexity, 24-password history, no reversible encryption, and fine-grained policies for privileged accounts. Operators should work from Privileged Access Workstations (PAWs), never from the same machine used for email or browsing. Even with DCs locked down this tightly, the accounts that touch them still need a second layer of identity proof.<\/p>\n
Enforce MFA for all privileged accounts<\/strong><\/h3>\nMulti-factor authentication (MFA) protects an account even when the password is already gone. Every human account with privileged access in AD needs MFA, with no carve-outs.<\/p>\n
For Tier 0 admins specifically, phishing-resistant MFA (FIDO2 keys or smart cards) is the real bar. TOTP and push can be phished through adversary-in-the-middle kits, which are widely available and surprisingly effective.<\/p>\n
That approach anchors a broader identity threat response<\/a> plan. Service accounts sit outside this rule, since they run as automated processes and need a different kind of control.<\/p>\nManage service accounts with dedicated controls<\/strong><\/h3>\nService accounts are prime targets: elevated privileges, rarely rotated passwords, and automated usage that masks anything unauthorized.<\/p>\n
The first step is inventorying every service, scheduled task, and batch job against its account and permissions. Nothing gets protected that isn’t known. From there, static passwords can be eliminated by converting accounts to Group Managed Service Accounts<\/a> (gMSAs) that rotate automatically.<\/p>\nFor accounts that have to stay on passwords, honeypot SPNs earn their keep by triggering SIEM<\/a> alerts on decoy ticket requests, so Kerberoasting attempts get caught early. Identity hardening only goes so far, though, while legacy protocols keep handing attackers easier paths to the same credentials.<\/p>\nDisable legacy protocols<\/strong><\/h3>\nNTLM, Link-Local Multicast Name Resolution (LLMNR), NetBIOS Name Service, and SMBv1 are legacy protocols attackers exploit for credential interception and relay attacks. Each has a retirement path worth running:<\/p>\n
\n- Audit and disable NTLM at the domain level via Group Policy<\/li>\n
- Enable Lightweight Directory Access Protocol (LDAP) signing and channel binding<\/li>\n
- Disable LLMNR via GPO<\/li>\n
- Disable NetBIOS over TCP\/IP<\/li>\n
- Turn off SMBv1<\/li>\n<\/ul>\n
Endpoints carrying these protocols also need the discipline covered in our patch management<\/a> guide and endpoint security<\/a> approach, since stale software reopens the same exposure. Even with that hardening in place, detection still depends on visibility into live network activity.<\/p>\nConfigure audit policy and monitor for attack indicators<\/strong><\/h3>\nWithout auditing, attackers operate undetected for weeks. Advanced Audit Policy subcategories replace legacy categories for granular control over what actually gets logged.<\/p>\n
A couple of events matter more than most. Event ID 4768 with pre-authentication type 0 flags AS-REP Roasting. Event ID 4662 for DS-Replication-Get-Changes on non-DC sources signals DCSync. Without monitoring on those events, credential theft happens silently, which is exactly where continuous threat monitoring <\/a>closes the gap. One area that rarely gets the same discipline is certificate infrastructure, which attackers have turned into a reliable privilege escalation path.<\/p>\nHarden Active Directory Certificate Services<\/strong><\/h3>\nActive Directory Certificate Services (ADCS) misconfigurations open a direct AD attack path, and most of the exploitable ones live on certificate templates.<\/p>\n
Priority actions are tight in scope: review template permissions, restrict enrollment rights, and disable the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag that enables ESC1.<\/p>\n
Template hardening addresses enrollment abuse, but the ADCS servers themselves still need protection. Disable NTLM on those servers, enable Extended Protection for Authentication (EPA) against NTLM relay on HTTP enrollment endpoints, and treat ADCS servers as Tier 0 assets alongside the DCs. The joint AD hardening guidance<\/a> from CISA and allied agencies covers these techniques in depth. Even with every preventive control in place, the last question is whether the environment can actually come back after a successful attack.<\/p>\nPlan AD backup and recovery before an incident<\/strong><\/h3>\nAD backup and recovery only works when it’s planned before the incident, not after. Immutable, tested backups of server infrastructure, including system-state backups of DCs that support authoritative restore, need verification on a regular schedule. That verification is the part that matters most when ransomware encrypts AD, because recovery speed decides whether teams face a manageable incident or an extended outage with real cost and downtime impact.<\/p>\n
Documented backup recovery<\/a> and ransomware recovery processes turn that planning into routine that holds under pressure. Pulling all eight of these practices together takes a platform that covers hardening, detection, and recovery without handoffs between disconnected tools.<\/p>\nHow N‑able strengthens your Active Directory security<\/strong><\/h2>\nN‑able solutions cover the full attack lifecycle with products matched to each phase: exposure reduction before an attack, visibility during one, and recovery when prevention fails.<\/p>\n
Before an attack<\/strong><\/h3>\nN‑able N‑central <\/a>handles patching and endpoint hardening that reduces the exposure attackers rely on to reach domain controllers. From one console, missing patches on AD-joined endpoints, outdated third-party software, and Common Vulnerability Scoring System (CVSS) findings get surfaced, prioritized, and queued for deployment.<\/p>\nPatching closes known weaknesses, but unknown endpoint behavior still needs watching. That’s where N‑able EDR<\/a>, powered by SentinelOne, looks for credential-dumping, lateral movement, and privilege escalation, containing a host autonomously before an analyst even picks up the alert. Ahead of that sits the network layer, where N‑able DNS Filtering <\/a>blocks command-and-control traffic and phishing domains attackers use to establish a foothold. Prevention reduces the attack surface, but motivated attackers still find ways through, which is where detection and response take over.<\/p>\nDuring an attack<\/strong><\/h3>\nAdlumin MDR\/XDR<\/a> catches the behaviors that define AD-targeting attacks: a user requesting dozens of service tickets, a workstation initiating replication traffic, or an account authenticating from an unexpected geography. Those signals correlate across endpoints, identity providers, and network sources, feeding playbooks that cut off compromised accounts or quarantine hosts mid-attack.<\/p>\nAutomation handles first response, and a 24\/7 Security Operations Center (SOC) then validates each incident, contains it, and closes the path against recurrence. That platform underpins N‑able’s managed detection<\/a> and identity protection<\/a> coverage. When detection and response don’t stop the damage in time, recovery determines how costly the incident actually becomes.<\/p>\nAfter an attack<\/strong><\/h3>\nCove Data Protection<\/a> shortens domain controller recovery from days to hours. Those recovery points stay protected because Cove’s backups sit in cloud storage isolated from production and locked against modification, so ransomware that encrypted production can’t touch them.<\/p>\nFrom that protected backup, Cove supports system-state recovery that enables authoritative and non-authoritative DC restores, plus file-level and full-system recovery for servers and workstations, with automated boot verification along the way. Coverage across all three phases puts the right controls in place, and tuning them against ongoing change completes the posture.<\/p>\n
Build an Active Directory security posture that survives compromise<\/strong><\/h2>\nStrong AD security comes from ongoing practice that evolves with the environment. These eight practices give you a foundation, and that foundation only holds as accounts change, permissions drift, and attacker techniques evolve. Maintaining the posture means auditing regularly, patching aggressively, monitoring for indicators, and keeping recovery tested.<\/p>\n
To strengthen AD security across your environment, contact us<\/a> to see how the platform fits your operations.<\/p>\n
None of this is fringe. The joint Cybersecurity and Infrastructure Security Agency (CISA) advisory on Akira ransomware<\/a> describes attackers dumping the AD database, password spraying against AD accounts, and enumerating users and groups through AD query tools. With that attacker playbook in mind, here’s where to focus the defense.<\/p>\n Hardening AD is layered work. Each of these eight practices answers a distinct attacker technique, and together they reduce credential exposure, limit privilege paths, tighten legacy settings, and make recovery possible when something slips through.<\/p>\n Every account, whether user, admin, or service, should hold only the permissions its job actually needs. At scale, that means separating privileges by how sensitive the asset is: Tier 0 for domain controllers and identity infrastructure, Tier 1 for application servers, Tier 2 for workstations.<\/p>\n Under that model, domain admin credentials never touch Tier 1 or Tier 2, with Authentication Policies and Silos (or User Rights Assignment via GPO) enforcing the separation.<\/p>\n Tier 0 admins belong to privileged groups like Domain Admins, Enterprise Admins, and Schema Admins. Those memberships need regular reviews, and just-in-time elevation should replace standing access wherever you can manage it.<\/p>\n One tier down, local admin accounts need their own control. Microsoft LAPS rotates unique passwords per machine and shuts down pass-the-hash pivots that otherwise flatten the whole tiering model. And the model only holds if the top tier is genuinely locked down.<\/p>\n Domain controllers hold the highest-value credentials in the environment, so shrinking their attack surface is non-negotiable.<\/p>\n Start with what doesn’t belong on a DC: web browsers, general internet access, unnecessary services, and the Print Spooler service that opens the door to PrintNightmare and coerced-auth attacks. What stays gets tightened through GPO-applied security baselines, application allowlists, and just-in-time (JIT) access for privileged groups.<\/p>\n Passwords matter too, with real strength: 14+ characters, complexity, 24-password history, no reversible encryption, and fine-grained policies for privileged accounts. Operators should work from Privileged Access Workstations (PAWs), never from the same machine used for email or browsing. Even with DCs locked down this tightly, the accounts that touch them still need a second layer of identity proof.<\/p>\n Multi-factor authentication (MFA) protects an account even when the password is already gone. Every human account with privileged access in AD needs MFA, with no carve-outs.<\/p>\n For Tier 0 admins specifically, phishing-resistant MFA (FIDO2 keys or smart cards) is the real bar. TOTP and push can be phished through adversary-in-the-middle kits, which are widely available and surprisingly effective.<\/p>\n That approach anchors a broader identity threat response<\/a> plan. Service accounts sit outside this rule, since they run as automated processes and need a different kind of control.<\/p>\n Service accounts are prime targets: elevated privileges, rarely rotated passwords, and automated usage that masks anything unauthorized.<\/p>\n The first step is inventorying every service, scheduled task, and batch job against its account and permissions. Nothing gets protected that isn’t known. From there, static passwords can be eliminated by converting accounts to Group Managed Service Accounts<\/a> (gMSAs) that rotate automatically.<\/p>\n For accounts that have to stay on passwords, honeypot SPNs earn their keep by triggering SIEM<\/a> alerts on decoy ticket requests, so Kerberoasting attempts get caught early. Identity hardening only goes so far, though, while legacy protocols keep handing attackers easier paths to the same credentials.<\/p>\n NTLM, Link-Local Multicast Name Resolution (LLMNR), NetBIOS Name Service, and SMBv1 are legacy protocols attackers exploit for credential interception and relay attacks. Each has a retirement path worth running:<\/p>\n Endpoints carrying these protocols also need the discipline covered in our patch management<\/a> guide and endpoint security<\/a> approach, since stale software reopens the same exposure. Even with that hardening in place, detection still depends on visibility into live network activity.<\/p>\n Without auditing, attackers operate undetected for weeks. Advanced Audit Policy subcategories replace legacy categories for granular control over what actually gets logged.<\/p>\n A couple of events matter more than most. Event ID 4768 with pre-authentication type 0 flags AS-REP Roasting. Event ID 4662 for DS-Replication-Get-Changes on non-DC sources signals DCSync. Without monitoring on those events, credential theft happens silently, which is exactly where continuous threat monitoring <\/a>closes the gap. One area that rarely gets the same discipline is certificate infrastructure, which attackers have turned into a reliable privilege escalation path.<\/p>\n Active Directory Certificate Services (ADCS) misconfigurations open a direct AD attack path, and most of the exploitable ones live on certificate templates.<\/p>\n Priority actions are tight in scope: review template permissions, restrict enrollment rights, and disable the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag that enables ESC1.<\/p>\n Template hardening addresses enrollment abuse, but the ADCS servers themselves still need protection. Disable NTLM on those servers, enable Extended Protection for Authentication (EPA) against NTLM relay on HTTP enrollment endpoints, and treat ADCS servers as Tier 0 assets alongside the DCs. The joint AD hardening guidance<\/a> from CISA and allied agencies covers these techniques in depth. Even with every preventive control in place, the last question is whether the environment can actually come back after a successful attack.<\/p>\n AD backup and recovery only works when it’s planned before the incident, not after. Immutable, tested backups of server infrastructure, including system-state backups of DCs that support authoritative restore, need verification on a regular schedule. That verification is the part that matters most when ransomware encrypts AD, because recovery speed decides whether teams face a manageable incident or an extended outage with real cost and downtime impact.<\/p>\n Documented backup recovery<\/a> and ransomware recovery processes turn that planning into routine that holds under pressure. Pulling all eight of these practices together takes a platform that covers hardening, detection, and recovery without handoffs between disconnected tools.<\/p>\n N‑able solutions cover the full attack lifecycle with products matched to each phase: exposure reduction before an attack, visibility during one, and recovery when prevention fails.<\/p>\n N‑able N‑central <\/a>handles patching and endpoint hardening that reduces the exposure attackers rely on to reach domain controllers. From one console, missing patches on AD-joined endpoints, outdated third-party software, and Common Vulnerability Scoring System (CVSS) findings get surfaced, prioritized, and queued for deployment.<\/p>\n Patching closes known weaknesses, but unknown endpoint behavior still needs watching. That’s where N‑able EDR<\/a>, powered by SentinelOne, looks for credential-dumping, lateral movement, and privilege escalation, containing a host autonomously before an analyst even picks up the alert. Ahead of that sits the network layer, where N‑able DNS Filtering <\/a>blocks command-and-control traffic and phishing domains attackers use to establish a foothold. Prevention reduces the attack surface, but motivated attackers still find ways through, which is where detection and response take over.<\/p>\n Adlumin MDR\/XDR<\/a> catches the behaviors that define AD-targeting attacks: a user requesting dozens of service tickets, a workstation initiating replication traffic, or an account authenticating from an unexpected geography. Those signals correlate across endpoints, identity providers, and network sources, feeding playbooks that cut off compromised accounts or quarantine hosts mid-attack.<\/p>\n Automation handles first response, and a 24\/7 Security Operations Center (SOC) then validates each incident, contains it, and closes the path against recurrence. That platform underpins N‑able’s managed detection<\/a> and identity protection<\/a> coverage. When detection and response don’t stop the damage in time, recovery determines how costly the incident actually becomes.<\/p>\n Cove Data Protection<\/a> shortens domain controller recovery from days to hours. Those recovery points stay protected because Cove’s backups sit in cloud storage isolated from production and locked against modification, so ransomware that encrypted production can’t touch them.<\/p>\n From that protected backup, Cove supports system-state recovery that enables authoritative and non-authoritative DC restores, plus file-level and full-system recovery for servers and workstations, with automated boot verification along the way. Coverage across all three phases puts the right controls in place, and tuning them against ongoing change completes the posture.<\/p>\n Strong AD security comes from ongoing practice that evolves with the environment. These eight practices give you a foundation, and that foundation only holds as accounts change, permissions drift, and attacker techniques evolve. Maintaining the posture means auditing regularly, patching aggressively, monitoring for indicators, and keeping recovery tested.<\/p>\n To strengthen AD security across your environment, contact us<\/a> to see how the platform fits your operations.<\/p>\n8 best practices for hardening Active Directory<\/strong><\/h2>\n
Enforce least-privilege access and tiering<\/strong><\/h3>\n
Harden domain controllers as Tier 0 assets<\/strong><\/h3>\n
Enforce MFA for all privileged accounts<\/strong><\/h3>\n
Manage service accounts with dedicated controls<\/strong><\/h3>\n
Disable legacy protocols<\/strong><\/h3>\n
\n
Configure audit policy and monitor for attack indicators<\/strong><\/h3>\n
Harden Active Directory Certificate Services<\/strong><\/h3>\n
Plan AD backup and recovery before an incident<\/strong><\/h3>\n
How N‑able strengthens your Active Directory security<\/strong><\/h2>\n
Before an attack<\/strong><\/h3>\n
During an attack<\/strong><\/h3>\n
After an attack<\/strong><\/h3>\n
Build an Active Directory security posture that survives compromise<\/strong><\/h2>\n
![\"create](\"https:\/\/www.n-able.com\/wp-content\/uploads\/2026\/02\/cybersecurity-incident-response-plan.jpg\")
<\/a><\/p>\n