STATUS_LM_CROSS_ENCRYPTION_REQUIRED 0XC000017F Fix
This error blocks Windows logon when NTLM v1 is rejected and v2 isn't trusted. It's a security mismatch, not hardware failure. Here's how to fix it.
Quick Answer
Set Network security: LAN Manager authentication level to Send NTLMv2 response only/refuse LM & NTLM (value 5) in Local Security Policy or via registry at HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel = 5.
What's Happening Here?
I've seen this error pop up most often on Windows 10/11 Pro or Server 2019/2022 machines after a security update or domain policy change. It means your computer is trying to authenticate using NTLM but the policy says "no LM" and the client isn't sending the right cross-encryption response. Think of it as a handshake where one side says "I only speak encrypted" and the other side forgot the password. The error code 0XC000017F translates to STATUS_LM_CROSS_ENCRYPTION_REQUIRED — essentially, the domain controller is requiring a stronger form of NTLM authentication that the client isn't offering.
I've debugged this on a client's domain where a Samba 4.13 server was the DC, and a Windows 10 21H2 machine couldn't log on after a policy refresh. The real trigger? A GPO that set LmCompatibilityLevel to 4 (which refuses LM but sends NTLMv2) but the DC was expecting 5 (refuse LM and NTLM). That mismatch is the whole story.
Fix Steps
Step 1: Verify the Current Setting
- Open Local Security Policy (press Win+R, type
secpol.msc). - Go to Local Policies > Security Options.
- Find Network security: LAN Manager authentication level.
- Check the current value. If it's
3(Send LM & NTLMv2 responses only. Refuse LM & NTLM) or4(Send NTLMv2 responses only. Refuse LM), you'll hit this error on strict DCs.
Step 2: Set to Level 5
Double-click that policy, set it to Send NTLMv2 response only. Refuse LM & NTLM (value 5). Click OK.
If you're on Windows Home (which lacks secpol.msc), use the registry:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel /t REG_DWORD /d 5 /fThen restart.
Step 3: Reboot or Run gpupdate
Open Command Prompt as admin and run gpupdate /force. Then try logging in again. If you still get the error, reboot — some policies cache until restart.
Alternative Fixes (If Main Doesn't Work)
Check Domain Controller Policy
Sometimes the DC itself is set to require cross-encryption. On the DC, open Group Policy Management, edit the Default Domain Policy, go to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options and set the same LmCompatibilityLevel to 5 there. Then run gpupdate /force on the DC. Yes, I've had to do this on a client's Samba DC where the default was 4.
Disable NTLM Fallback (Not Recommended)
If you absolutely cannot change the policy (like in a locked-down enterprise), you could enable NTLMv1 temporarily by setting LmCompatibilityLevel to 2 (Send NTLMv2 responses only). But don't do this long-term — it weakens security. I only mention it because I've had a case where a legacy app forced me to do it for 24 hours.
Verify SMB Signing Requirements
On rare occasions, this error appears alongside SMB signing issues. Check Microsoft network server: Digitally sign communications (always) and Microsoft network client: Digitally sign communications (always) are both set to Enabled on the client and DC.
Prevention Tip
Before rolling out security updates that touch NTLM (like KB5008285 or newer), test the LmCompatibilityLevel setting on a pilot machine. I keep a test VM in each domain that I update first, then check for this error with a fake logon. Saves hours of panic. Also, document your DC's policy — know whether you're at level 4 or 5. The difference is one bit, but it'll bite you every time.
Was this solution helpful?