Notifications
Clear all
Topic starter
06/06/2026 11:32 am
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.
NHIMG editorial — based on content published by Semperis: why using authentication level 2 is a bad idea
Questions worth separating out
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.
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.
Q: What breaks when LDAP channel binding is not enforced on directory services?
A: Relay attacks remain viable.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Semperis' full article covers the operational detail this post intentionally leaves for the source:
- The exact Windows policy and registry settings used to move from level 2 to level 3 without breaking legacy clients
- A step-by-step explanation of how coercion and relay work against domain controllers in real environments
- The practical difference between levels 4 and 5 when deprecating LM and NTLMv1 entirely
- The Windows Server 2025 change that blocks outbound LM and NTLMv1 connections
👉 Read Semperis' analysis of LAN Manager authentication levels and domain controller risk →
LAN Manager authentication levels 2 vs 3: are your DCs exposed?
Explore further
06/06/2026 12:24 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: LAN Manager authentication level 2 leaves domain controllers exposed
