LAN Manager authentication level 2 leaves domain controllers exposed

At a glance

What this is: This analysis explains why LAN Manager authentication level 2 on domain controllers is a dangerous misconfiguration and why level 3 is the safer baseline.

Why it matters: It matters because domain controllers sit at the center of IAM trust, and an outbound NTLMv1 path can turn legacy compatibility into domain compromise.

👉 Read Semperis' analysis of LAN Manager authentication levels and domain controller risk

Context

LAN Manager authentication level controls how a domain controller handles NTLM and LM challenge-response logons when Kerberos is not used. The issue is not legacy authentication by itself, but the fact that level 2 allows the controller to both accept and initiate NTLMv1 traffic, which expands the credential exposure path.

In identity governance terms, this is a human IAM control with NHI-like consequences because the domain controller itself becomes the identity that can be coerced, relayed, and abused. The article's core warning is that compatibility-driven configuration choices can preserve older applications while quietly preserving an attack path into the domain.

Key questions

Q: How should security teams harden domain controllers that still need legacy authentication support?

A: Set domain controllers to a level that allows inbound legacy authentication if needed, but blocks outbound NTLMv1. Then pair that change with LDAP channel binding, tier-zero review of machine-account permissions, and validation that no legacy exception reopens a relay path.

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: What breaks when LDAP channel binding is not enforced on directory services?

A: Relay attacks remain viable. A coerced authentication from a domain controller can be forwarded to LDAP or LDAPS endpoints and accepted as if it were legitimate, which allows attackers to modify directory objects, abuse delegation, or establish persistence.

Q: Who is accountable when a legacy authentication exception enables domain compromise?

A: The responsibility sits with the team that owns tier-zero identity policy, because legacy compatibility decisions on domain controllers change the trust model for the entire directory. Security, IAM, and directory operations should jointly approve and review those exceptions.

Technical breakdown

How LAN Manager authentication level changes DC behaviour

LAN Manager authentication level is a Windows setting that governs how LM and NTLM are handled during network logons. Level 2 accepts inbound NTLMv1 and also allows outbound NTLMv1 from the domain controller. Level 3 still accepts inbound NTLMv1 for legacy clients, but blocks the controller from initiating NTLMv1 connections. That distinction matters because the outbound direction is what attackers can coerce and relay. The control is therefore not just about compatibility, but about whether the domain controller can be used as a source of weaker authentication material.

Practical implication: raise domain controllers to at least level 3 so they can still serve legacy clients without sending NTLMv1 outbound.

Why coerced NTLMv1 from a DC is a relay problem

Attackers can force a domain controller to authenticate outward using coercion techniques such as PrinterBug, DFSCoerce, or PetitPotam. If that authentication uses NTLMv1, the resulting response is much weaker than NTLMv2 and can often be cracked or relayed. In a relay scenario, the attacker does not need to recover the password hash first. They can forward the authentication to LDAP or LDAPS targets that lack channel binding enforcement and abuse the DC's machine-account identity. The technical issue is not simple sniffing, but abuse of a trusted outbound authentication flow.

Practical implication: block outbound NTLMv1 from DCs and enforce LDAP channel binding so coerced authentication cannot be relayed into directory control.

How shadow credentials and RBCD turn relay into domain control

Once a relayed machine-account authentication reaches a writable directory path, attackers can abuse either shadow credentials or Resource-Based Constrained Delegation. Shadow credentials let an attacker add key material to a target object and later authenticate as that identity. RBCD lets the attacker control delegation settings so another object can act on behalf of the DC. Both techniques convert a relayed authentication event into durable administrative control. The core architectural weakness is that the DC's machine identity is treated as trustworthy even after it has been coerced into an attacker-chosen path.

Practical implication: restrict directory write paths and delegation settings that let a relayed DC identity become persistent domain control.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Outbound NTLMv1 from a domain controller is the broken assumption, not just a legacy setting. The setting assumes that compatibility risk is confined to inbound authentication from old clients. That assumption fails when the controller itself can be coerced into initiating weaker authentication, because the domain controller becomes the attack source. The implication is that identity programmes must treat outbound authentication rules as part of trust design, not just protocol compatibility.

Level 2 creates identity blast radius by preserving a relayable machine identity. The article shows that an attacker does not need a password cracking win to reach domain control. Coerced NTLMv1 can be relayed directly into directory abuse paths such as shadow credentials or RBCD, which turns a single misconfiguration into full domain compromise. Practitioners should read this as a machine identity governance failure where one trusted system account can be weaponised against the directory itself.

Legacy compatibility arguments often hide a lifecycle failure in authentication governance. The problem is not that older applications exist, but that the environment keeps a weak protocol active on the highest-value identity tier. The control gap is failure to separate inbound accommodation from outbound trust. The practical conclusion is that DC authentication policy must be versioned, reviewed, and hardened as a lifecycle control, not left as an inherited default.

Shadow credentials and RBCD are not separate incidents here, they are the same failure mode expressed two ways. Both depend on a coerced machine identity being accepted as authoritative after it leaves the expected authentication path. That is a named governance failure mode: relayable domain-controller identity. For practitioners, the question is whether the directory can still be abused as soon as the DC is allowed to speak NTLMv1 outward.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly identity blind spots compound when machine identities are left under-governed.
• Use the NHI Lifecycle Management Guide to tighten rotation, offboarding, and visibility controls before weak authentication paths become persistent attack routes.

What this signals

Relayable authentication is now a governance issue, not just a protocol issue. If a domain controller can still send NTLMv1 outward, the directory is preserving an attacker-controlled identity pathway at the tier-zero layer. Teams should expect more scrutiny on outbound authentication behaviour during audits because legacy compatibility increasingly looks like an avoidable control exception.

The practical programme impact is that domain controller policy, LDAP hardening, and delegation review need to be managed together. A weak setting on one controller can defeat otherwise sound identity design, so exception handling must be explicit, time-bound, and verified after every change.

For practitioners

• Set domain controllers to LAN Manager authentication level 3 or higher Keep inbound NTLMv1 compatibility for legacy clients, but stop DCs from initiating NTLMv1 outbound connections. Validate the setting through Group Policy and registry review on every controller, then confirm there are no exceptions left behind for older server roles.
• Enforce LDAP channel binding on directory endpoints Make relayed authentication unusable by requiring channel binding on LDAP and LDAPS services that accept machine-account traffic. Test the setting against coercion paths so a DC authentication attempt cannot be forwarded into directory modification.
• Audit for shadow credentials and RBCD write paths Review which principals can modify msDS-KeyCredentialLink and delegation settings on sensitive objects, especially domain controllers and tier-zero systems. Remove unnecessary write access and verify that machine accounts cannot be turned into persistence points.
• Treat outbound authentication as a tier-zero control Include outbound protocol behaviour in domain controller hardening standards, not just inbound authentication acceptance. Document allowed authentication versions, review them during change control, and test that legacy app exceptions do not reopen NTLMv1 relay risk.

Key takeaways

• The breach pattern here is not NTLMv1 itself, but outbound NTLMv1 from a domain controller that attackers can coerce and relay.
• The scale of the risk is full domain compromise, because relay paths can lead directly to shadow credentials or RBCD without requiring hash cracking first.
• The control that changes the outcome is simple in principle: stop DCs from sending NTLMv1 outward and close LDAP relay paths with channel binding.

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.
• NtLm relay: An attack in which captured NTLM authentication is forwarded to another service instead of being cracked. In directory environments, relay becomes dangerous when a trusted machine identity, such as a domain controller, can be coerced into authenticating outward and the target service accepts that forwarded request.
• Shadow Credentials: A persistence technique where an attacker writes key credential material to a directory object so they can authenticate as that identity later. It is especially dangerous when the attacker reaches the object through relayed machine-account authentication, because the directory then stores trust for the attacker.
• Resource-Based Constrained Delegation: A delegation configuration that lets one account be authorised to act on behalf of another. When abused, it lets attackers turn a coerced or relayed machine identity into broader directory control, which is why delegation permissions on tier-zero objects must be tightly governed.

Deepen your knowledge

Domain controller authentication hardening and legacy protocol governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are managing tier-zero identities with compatibility constraints, it is worth exploring.

This post draws on content published by Semperis: why using authentication level 2 is a bad idea. Read the original.