Fix 0X0000056E: Cross-Encrypted Password Required on Domain
This error means the domain controller won't accept your password change because it's encrypted differently. The fix is usually a registry tweak or a policy change.
Quick Answer
Set HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel to 5 on the client machine, or change the domain's default domain policy to Send NTLMv2 response only. Refuse LM & NTLM.
What’s Going On Here?
This error pops up when you’re trying to change a user’s password on a Windows domain and the client machine is speaking an older encryption language that the domain controller won’t accept. Specifically, the client sent an LM (LAN Manager) or NTLMv1 hash for the old password, and the domain controller has its LMCompatibilityLevel set to refuse anything less than NTLMv2 with cross-encryption.
Had a client last month—a small law firm with a 2012 R2 DC and a mix of Windows 10 and some old XP boxes still hanging around. Their domain policy was set to Send LM & NTLM responses, and a user trying to reset their password from the XP machine got this exact 0X0000056E. The DC was rejecting the hash because the client wasn’t sending a cross-encrypted session key.
The real trigger: your domain controller has the Network security: LAN Manager authentication level policy set to Send NTLMv2 response only. Refuse LM & NTLM or higher, but the client machine is configured to send older LM or NTLM responses.
Fix Steps
Step 1: Check the Client’s LMCompatibilityLevel
On the machine that’s throwing the error, open regedit and go to:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LsaLook for LmCompatibilityLevel. If it’s missing, create a DWORD. The values are:
- 0 or 1 – Send LM & NTLM (weak, causes this error)
- 2 – Send NTLMv2 only
- 3 – Send NTLMv2 only. Refuse LM
- 4 – Send NTLMv2 only. Refuse LM & NTLM
- 5 – Send NTLMv2 only. Refuse LM & NTLM. Use cross-encrypted session key (the fix)
Set it to 5. Reboot or run gpupdate /force.
Step 2: Align the Domain Policy
On the domain controller, open Group Policy Management Console. Edit the Default Domain Policy (or the policy applied to the affected users/computers). Navigate to:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security OptionsFind Network security: LAN Manager authentication level. Set it to Send NTLMv2 response only. Refuse LM & NTLM. This matches the client setting. Run gpupdate /force on the DC and clients.
Step 3: Test the Password Change
Have the user press Ctrl+Alt+Del, choose Change a password. If it still fails, reboot the client machine and try again.
Alternative Fixes
If You Can’t Change the Domain Policy
Sometimes the domain security baseline is locked down by higher-ups or a security audit. In that case, you can only fix the client. Set LmCompatibilityLevel to 5 on every machine that needs to change passwords. Also, make sure the client is using NTLMv2 for all network authentication—check the Network security: Minimum session security for NTLM SSP based (including secure RPC) clients policy. It should require 128-bit encryption.
If the Client Is Really Old (Windows XP or Server 2003)
Those older OSes don’t support LMCompatibilityLevel 5 out of the box. Install the KB968389 update (if you can still find it) or upgrade the machine. I’ve had to tell clients, “Your XP box can’t talk to the new DC securely—time to retire it.”
Check if the User Account Has Reversible Encryption
Rare but possible: if the user’s account in AD is set to Store password using reversible encryption, it can confuse the hash negotiation. Uncheck that under Account options in Active Directory Users and Computers.
Prevention Tip
Standardize your domain’s LMCompatibilityLevel to 5 via group policy. Apply it to all computers—workstations and servers. This forces NTLMv2 with cross-encryption everywhere, killing this error before it starts. Also, retire any machines that can’t support it (looking at you, Windows 7 without KB2536276). One less thing to wake you up at 3 AM.
Was this solution helpful?