What is the one change you make first when a domain controller hardening checklist has twenty non-negotiable items and you have exactly one maintenance window this quarter? Most teams answer with the item that feels scariest: block NTLM, kill RC4, require LDAP signing. That is also the fastest way to lock out a building full of users on a Tuesday morning. The order the settings go in matters as much as the settings themselves, and almost nothing written about Active Directory hardening says so out loud.
Microsoft's own eight-part Active Directory Hardening Series gets this mostly right, one control at a time. What it does not give you is the sequence across all eight, updated for what changed in 2026: the Kerberos RC4 retirement tied to CVE-2026-20833, and the new defaults Windows Server 2025 ships out of the box. This is that sequence, plus where the individually-correct settings become dangerous when you enforce them in the wrong order.
Settings enforced out of order break more domains than the settings you skipped
If you do not run on-premises or cloud-hosted writable or read-only domain controllers, none of this is yours. Pure Entra ID tenants with no hybrid join, no on-prem footprint, can stop here. If you run even one domain controller, on a rack in a closet or on a VM in Azure, the rest of this applies, and the sequencing is the part that decides whether your rollout is a quiet Tuesday or an outage postmortem.
The pattern shows up the same way every time: a well-intentioned admin enables Require signing on LDAP or flips the domain-wide NTLM block before confirming which service accounts, backup agents, and line-of-business applications still depend on the thing being disabled. Authentication breaks first, replication or backups second, and the rollback happens under pressure instead of on a plan. The fix is not a different set of controls. Microsoft's guidance, joint CISA/NSA guidance on detecting and mitigating AD compromises, and every incident Red Hound has walked into after a botched hardening pass agree on the same order: recover and observe first, fix clients and identities second, enforce protocols third, block NTLM last. Reverse any of those and you trade an attacker's problem for your own outage.
Prove you can recover before you touch a GPO
The step everyone skips is the one with no visible security benefit: proving the domain can actually be restored. A successful backup job is not restore evidence. Before any enforcement GPO goes near the Domain Controllers OU, close these gaps:
- System State backups exist for at least one DC per domain, younger than the forest tombstone lifetime, stored somewhere a ransomware operator with domain admin cannot reach.
- A nonproduction forest recovery has been tested, not just a backup job that reported success. Document the DNS dependencies, FSMO decisions, and SYSVOL authoritative restore steps while you still have time to get them wrong safely.
- DSRM credentials are current and retrievable by an authorized operator, ideally through Windows LAPS DSRM management rather than a spreadsheet.
- Centralized logging is live for Security, Directory Service, NTLM, and LDAP interface events, forwarded to a collector the DC compromise itself cannot silence.
This is not busywork before the "real" hardening starts. It is the control that determines whether a bad enforcement GPO costs you an hour or a week. Microsoft's AD backup and recovery guidance and the joint CISA/NSA guidance on detecting and mitigating AD compromises both treat recoverability as the prerequisite, not a parallel workstream.
Retire NTLMv1, SMBv1, and get ahead of the 2026 Kerberos RC4 cutover
Once you can prove recovery works, the next phase is protocol cleanup on the client and service side, before you enforce anything on the DCs. Two of these are old news that most environments still have not finished. One is new for 2026 and has a hard deadline.
NTLMv1 and SMBv1. DC Event 4776 proves credential validation happened but does not reliably show which NTLM version was used. Pull that evidence from Event 4624 and its LmPackageName field on the resource servers instead, remediate what still sends NTLMv1, then move the DCs to Send NTLMv2 response only. Refuse LM & NTLM. For SMBv1, Microsoft's removed and deprecated features list confirms the feature is gone from every current Windows Server release; the work is finding what still depends on it, not the removal command.
The Kerberos RC4 cutover. Microsoft's phased retirement of RC4 service-ticket issuance, tied to CVE-2026-20833, moved the KDC default for DefaultDomainSupportedEncTypes to 0x18 (AES128 and AES256 only) starting with the April 2026 enforcement phase. The July 2026 phase went further: it removed the temporary RC4DefaultDisablementPhase rollback key entirely and put every domain controller into enforcement mode, blocking connections from non-compliant devices outright. If you have not inventoried which service principals still lack AES-capable keys, do it now, not after a service outage tells you:
Get-ADUser -LDAPFilter '(&(servicePrincipalName=*)(!(objectClass=computer)))' `
-Properties ServicePrincipalName,msDS-SupportedEncryptionTypes,PasswordLastSet |
Select-Object SamAccountName, PasswordLastSet,
@{N='EncTypes';E={$_.'msDS-SupportedEncryptionTypes'}},
ServicePrincipalNameAny service principal missing an AES flag needs a password roll or a keytab regeneration once AES support is confirmed on the client side. Do not set msDS-SupportedEncryptionTypes mechanically across every account; target the SPN-bearing services and trusts that actually need it. See Microsoft's CVE-2026-20833 KDC guidance for the exact phase dates and the registry keys involved.
Enforce LDAP signing, channel binding, and SMB signing without a lockout
This is the phase most environments get half right: they enforce the DC side before confirming the client side is ready. The order that avoids a lockout is audit, remediate, then enforce, for each of the three protocols.
For LDAP, set 16 LDAP Interface Events to 2 on the DCs during a diagnostic window and watch Events 2887 and 2889 for unsigned binds before you touch the Domain controller: LDAP server signing requirements policy. Windows Server 2025 changes the default here: Microsoft's current documentation confirms that new AD deployments on Server 2025 require LDAP signing by default through a dedicated enforcement policy, while environments upgraded from earlier versions keep their existing settings until you change them. Do not assume an upgraded domain inherited the new default; verify it.
LDAP channel binding only protects SASL-over-TLS traffic, not Simple Bind, so pair it with signing and correct certificates rather than treating it as a substitute. Move the value from When supported to Always only after Events 3039, 3074, and 3075 stop showing unexplained failures.
For SMB, Windows Server 2025 tightens the default further: both inbound and outbound SMB connections now require signing out of the box, broadening a requirement that previously applied mainly to inbound SYSVOL and NETLOGON traffic on the DCs themselves. Confirm the effective state before you assume the new default covers you:
Get-SmbServerConfiguration | Select-Object EnableSecuritySignature,RequireSecuritySignature
Get-SmbClientConfiguration | Select-Object EnableSecuritySignature,RequireSecuritySignatureDisable LLMNR through Group Policy in the same phase, and start planning the removal of NetBIOS name resolution dependencies. Both feed the relay attacks that SMB and LDAP signing are meant to close off.
Block NTLM last, and treat the whole identity plane as Tier 0
NTLM blocking goes last because it breaks the widest range of dependencies: trusts, appliances, scheduled tasks, and applications that hard-code an IP address instead of a valid Kerberos service name. Pilot it in rings, starting with Protected Users for eligible human admins and Tier 0 workstations, before expanding to incoming and outgoing blocks on well-understood servers, and only then to a domain-wide restriction.
While you are in the privileged-access layer, audit who actually holds DCSync rights. Three extended-right GUIDs matter, not one: Replicating Directory Changes (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2), Replicating Directory Changes All (1131f6ad-9c07-11d1-f79f-00c04fc2dcd2), and Replicating Directory Changes In Filtered Set (89e95b76-444d-4c62-991a-0facbeda640c). A check that only looks at the first one misses synchronization products and backup tools that were granted the other two and never reviewed again.
None of this holds if the rest of the identity plane sits at a lower trust tier than the DCs you just hardened. Microsoft's AD DS Tier Model and the hardening series' NTLM guidance both make the same point: AD CS, Entra Connect, the hypervisor hosting your virtual DCs, and your backup console are Tier 0 by definition. A hardened DC sitting on a hypervisor administered by help-desk credentials leaves the front door reinforced and the window around the side wide open.
Start with the restore test, not the GPO
If you take one thing from this into Monday, make it the restore test, not the enforcement policy. Run a nonproduction System State recovery, confirm DSRM credentials retrieve, and check that Security and Directory Service events are actually landing in your collector. Only then start the protocol phase, in the order above, one control family per change window. Enforcement without a proven rollback path is how a correct setting turns into an outage, and an outage is what gets a hardening project cancelled before it reaches NTLM.
We audit domain controller environments against this exact sequence, including the parts that never make it into a checklist: which service accounts actually hold DCSync rights, whether your backup path is really Tier 0, and where your LDAP and SMB defaults sit right now versus what Server 2025 assumes they are.
Need help hardening your identity infrastructure?
We assess Active Directory and Entra ID environments for the misconfigurations attackers actually exploit. Book a session to discuss your environment.