TL;DR: LAN Manager authentication level 2 on domain controllers allows NTLMv1 both inbound and outbound, which attackers can coerce and relay to gain DC control, according to Semperis. Level 3 preserves legacy compatibility while removing the outbound attack path, so the minimum safe baseline is usually being missed.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Semperis's blog post: LAN Manager authentication level 2 on domain controllers creates avoidable exposure by allowing NTLMv1 outbound authentication, while level 3 preserves legacy inbound compatibility and removes that attack path.
Why it matters: It matters because IAM teams managing Active Directory and domain controllers often leave legacy compatibility settings in place without realising they widen the path from authentication coercion to domain compromise.
Context
LAN Manager authentication level is a Windows setting that controls whether NTLMv1 is accepted and whether it can be used for outbound authentication when Kerberos is not negotiated. On domain controllers, that distinction matters because inbound compatibility and outbound behaviour create very different security outcomes.
The governance problem is not legacy support by itself, but the assumption that a setting chosen to keep older applications working is harmless on a high-value identity tier. On domain controllers, level 2 preserves compatibility while also allowing the controller to initiate NTLMv1 connections, which expands the attack surface in a way many programmes overlook.
Semperis frames level 3 as the practical minimum because it keeps inbound legacy compatibility while stopping the outbound NTLMv1 path. That makes this a domain controller hardening issue, not a broad Windows preference, and it sits squarely in identity governance for privileged infrastructure.
Key questions
Q: What breaks when domain controllers stay on LAN Manager authentication level 2?
A: Level 2 lets domain controllers accept inbound NTLMv1 and also use NTLMv1 outbound, which creates a relay and coercion path that attackers can exploit. The main failure is not legacy compatibility itself, but allowing a privileged controller to originate weak authentication that can be captured and abused against other systems.
Q: Why do domain controllers with NTLMv1 enabled increase domain compromise risk?
A: Because attackers can coerce a controller into authenticating outward, then relay that weaker authentication into directory actions such as shadow credentials or RBCD. The danger is not only cracking a response, but converting a trusted machine identity into administrative control.
Q: How do security teams know whether their DC authentication baseline is too permissive?
A: If a domain controller can still initiate NTLMv1 outbound, the baseline is too permissive for privileged infrastructure. The practical signal is that compatibility was solved at the wrong boundary, leaving weak authentication origination enabled on the systems that matter most.
Q: Should teams keep level 2 for legacy apps or move to level 3 on domain controllers?
A: Teams should move domain controllers to level 3 when legacy inbound compatibility must remain. Level 3 preserves that compatibility while removing the outbound NTLMv1 path, which is the part that creates the attack surface attackers actually exploit.
Technical breakdown
Why level 2 changes the trust boundary for domain controllers
LAN Manager authentication level 2 is not just a compatibility toggle. It tells a domain controller to accept inbound NTLMv1 and also to send NTLMv1 when it initiates authentication. That outbound behaviour matters because a domain controller is not an ordinary endpoint. Once it can be induced to authenticate outward using a weaker protocol, the response can be captured, relayed, or otherwise abused in ways that level 3 prevents. The architectural issue is that the controller becomes both a verifier and an originator of weak authentication, which enlarges the identity attack surface far beyond legacy client support.
Practical implication: Treat level 2 on domain controllers as an exposure state, not a compatibility compromise.
How coercion and relay turn NTLMv1 into domain compromise
Attackers can coerce a domain controller into authenticating outward using techniques such as PrinterBug, DFSCoerce, or PetitPotam. If that outbound session is NTLMv1, the response is weak enough to be cracked quickly or relayed directly. Semperis notes that the relay path can be even more dangerous than offline cracking because the attacker may use the DC's machine account authentication against another controller where LDAPS channel binding is not enforced. That combination can enable Shadow Credentials or Resource-Based Constrained Delegation and turn a single coerced authentication into domain control.
Practical implication: Hunt for coercion opportunities and remove relay-friendly identity paths before they reach privileged controllers.
Why level 3 is the minimum safe compatibility baseline
Level 3 preserves inbound NTLMv1 for legacy clients but blocks outbound NTLMv1 from the domain controller. That narrow change matters because it keeps older applications functioning while removing the controller as an authentication source that can be coerced and relayed. The article's point is not that level 3 is the end state. It is that level 2 is the wrong compromise when compatibility is the only reason for hesitation. In identity terms, level 3 separates legacy acceptance from privileged outbound trust, which is the control boundary that level 2 collapses.
Practical implication: Use level 3 as the default baseline when legacy inbound compatibility must remain in place.
Threat narrative
Attacker objective: Obtain domain controller control by exploiting weak outbound NTLMv1 authentication and relay paths.
- Entry begins when an attacker coerces a domain controller into making an outbound authentication attempt, often by abusing printer, DFS, or related coercion techniques.
- Credential access follows when the outbound NTLMv1 response is captured, cracked, or relayed instead of protected by stronger outbound controls.
- Escalation occurs if the relayed machine-account authentication is accepted on another controller where LDAPS channel binding is not enforced.
- Impact is full control over the domain controller and, by extension, the domain itself.
Breaches seen in the wild
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Level 2 is a privileged identity exposure problem, not a legacy compatibility setting. The mistake is to treat inbound acceptance and outbound initiation as the same control surface. On a domain controller, those are different trust decisions, and only outbound NTLMv1 creates the coercion and relay path that matters. Practitioners should stop classifying level 2 as an acceptable middle ground for privileged infrastructure.
Outgoing NTLMv1 from a domain controller is the control failure that matters. The article shows that attackers do not need to start with elevated privileges if they can force the controller to authenticate outward. Once the controller becomes the issuer of a weak authentication flow, the environment has already crossed the boundary that many identity programmes assume still protects them. The operational implication is that outbound trust from high-value identities must be governed separately from client compatibility.
LDAP channel binding gaps turn a single coerced authentication into a domain-wide weakness. The relay path exists because the downstream target accepts authentication without enforcing the binding control that should stop reuse. That means the problem is not only NTLMv1, but the assumption that a privileged machine account can be allowed to traverse an unbound LDAP path safely. Practitioners should treat controller-to-controller relay resistance as part of identity boundary design.
Minimum safe baselines fail when programme owners optimise for compatibility first. The article makes clear that level 3 preserves legacy inbound behaviour while eliminating the dangerous outbound path, which means many environments are over-permissive by default rather than technically constrained. That is a governance failure as much as a configuration failure. The practical conclusion is to separate business compatibility requirements from privileged authentication policy on domain controllers.
Domain controller hardening must distinguish authentication acceptance from authentication origination. That distinction is the named concept that this article sharpens. Acceptance keeps older clients alive. Origination creates the attack surface that coercion, relay, and machine-account abuse exploit. Identity teams should audit privileged infrastructure for settings that still allow it to originate weaker protocols, because that is where exposure turns into compromise.
What this signals
Authentication origination is the real control boundary: identity programmes often focus on whether legacy logons are accepted, but the more important question on domain controllers is whether the controller can still initiate weak outbound authentication. Once that happens, coercion and relay become viable paths to privileged compromise.
Level 3 is the practical baseline because it separates legacy client compatibility from privileged outbound trust. That distinction is exactly what many environments blur when they leave controllers at level 2 for convenience.
Controllers that can still speak NTLMv1 outbound should be treated as policy exceptions, not default hardened assets. The identity tier should never inherit the weakest protocol path simply because older applications have not yet been rationalised.
For practitioners
- Set domain controllers to level 3 Retain inbound NTLMv1 compatibility for legacy clients, but stop domain controllers from initiating outbound NTLMv1 connections.
- Audit coercion-prone services Review printers, DFS, and related services that can force a controller into an outbound authentication attempt.
- Enforce LDAP channel binding Block relay paths by requiring LDAP channel binding on systems that would otherwise accept relayed machine-account authentication.
- Separate controller policy from client policy Apply stricter authentication rules to domain controllers than to general endpoints so legacy support does not widen privileged trust.
- Plan the move beyond NTLMv1 Use level 4 and level 5 as deprecation milestones when the environment is ready to reject inbound LM and NTLMv1 entirely.
Key takeaways
- The core risk is not NTLMv1 inbound compatibility on its own, but domain controllers initiating weak outbound authentication that attackers can coerce and relay.
- Semperis highlights a fast path from coercion to domain compromise when channel binding is missing, because relay of the controller's machine account can enable Shadow Credentials or RBCD.
- Level 3 is the minimum practical baseline for environments that still need legacy inbound support, because it removes the outbound attack path without breaking older clients.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Level 2 allows weak NTLMv1 authentication on privileged domain controllers. |
| NHI-05 — Overprivileged NHI | Domain controllers expose disproportionate blast radius when they can originate weak authentication. | |
| Recommendation — Eliminate weak outbound authentication paths on domain controllers by moving to a safer baseline. Reduce privileged identity blast radius by separating controller policy from general endpoint compatibility. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator management governs credential and protocol lifecycle for privileged systems. |
| Recommendation — Apply IA-5 to prevent privileged systems from using obsolete authenticator paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about how authorisation and authentication behaviour on DCs expands exposure. |
| Recommendation — Review controller authorizations to ensure weak authentication origination is not permitted. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path depends on coercing credentials and relaying them laterally to another controller. |
| Recommendation — Map coercion-and-relay exposure to credential access and lateral movement detections. | ||
Key terms
- Lan Manager Authentication Level: A Windows policy that determines how a system handles LM and NTLM challenge-response authentication. On domain controllers, the key security question is not just whether legacy logons are accepted, but whether the controller itself can initiate weaker outbound authentication that attackers can coerce and relay.
- NTLMv1: NTLMv1 is an older Microsoft authentication protocol used in Windows environments. It relies on weak cryptography and limited challenge-response protection, which makes captured traffic easier to crack or reuse. In modern Active Directory estates, it is treated as a legacy risk because it can support replay, relay, and offline credential attacks.
- LDAP Channel Binding: LDAP channel binding ties the NTLM authentication exchange to the underlying TLS session so credentials cannot be replayed cleanly on a different connection. When it is not enforced, attackers may relay NTLM to LDAP or StartTLS-protected LDAP despite encryption being present on the wire.
- Domain Controller Authentication Origination: The ability of a domain controller to initiate its own outbound authentication sessions. This is a distinct governance concern from merely accepting logons, because outbound origination from privileged infrastructure can create exposure windows that legacy compatibility settings often hide.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org