Yeah, that error is a pain — you're trying to connect to a server, a database, or maybe Outlook, and Windows just slams the door with 0X8009035F. Let's get it fixed.
The Fix: Adjust the LAN Manager Authentication Level
The most common cause is a security policy that tells Windows to refuse NTLM responses. The fix is to loosen that setting just enough to allow NTLM while still blocking older, weaker protocols.
- Press Windows + R, type
secpol.msc, and hit Enter. If you get a UAC prompt, click Yes. - In the left pane, expand Local Policies, then click Security Options.
- Scroll down and double-click Network security: LAN Manager authentication level.
- Change the setting to Send NTLMv2 response only. Refuse LM & NTLM. That's the default on modern Windows, but sometimes a group policy overrides it to something stricter like Send NTLMv2 response only. Refuse LM & NTLMv2 (which is the one that causes 0X8009035F).
- Click Apply, then OK.
- Close the Local Security Policy window.
After you click Apply, you won't see any immediate change — the setting just saves. You need to either restart the app that gave the error, or log off and back on to be safe. If you're on a domain, the local policy might be overwritten by a domain policy, so check that too (see below).
Now try your connection again. If it works, great. If not, move on to the next section because there's a registry tweak that does the same thing, and it can override the policy.
Registry Method (If the Policy Doesn't Stick)
Sometimes the policy is greyed out or gets reverted by a domain group policy. In that case, do this:
- Press Windows + R, type
regedit, and hit Enter. - Navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. - Find the value
LmCompatibilityLevelin the right pane. If it's not there, right-click on the empty space, select New > DWORD (32-bit) Value, and name itLmCompatibilityLevel. - Double-click it and set the value to 2. That means “Send NTLMv2 response only.”
- Click OK, close the registry editor, and restart your computer for the change to take effect.
After the restart, the error should be gone. The registry value is what the policy actually writes to — if you set it manually, it's hard for a policy to override it unless a domain policy is explicitly set to enforce the stricter value.
Why This Works
The 0X8009035F error means the server and the client can't agree on how to authenticate. The server is saying “I'll only accept NTLMv2” and the client is replying “I'm only sending NTLMv2, so we're good.” But then the client actually sends an LM or NTLM response because the security policy is set to refuse those, and the server rejects it. Setting LmCompatibilityLevel to 2 tells Windows to send NTLMv2 only — which is exactly what the server wants. The stricter setting (value 5) refuses LM and NTLM entirely, which is too strict for most mixed environments.
I've seen this happen on Windows 10 22H2 and Windows Server 2019 when a security admin tightened the policy “just in case.” It's a good instinct, but it breaks connections to older servers that haven't updated their NTLM handling.
Less Common Variations
If the above doesn't fix it, here are two other things to check.
1. The “Send NTLMv2 Response Only. Refuse LM & NTLMv2” Policy
That's the exact policy name that's usually the culprit. But sometimes it's set at the Default Domain Policy level, and your local change gets overwritten. To check, run gpresult /h gp.html in an elevated command prompt, open the resulting file, and look under “Security Settings” for that LAN Manager setting. If it says “Not Defined” or “Disabled”, you're fine. If it's set to a value other than 2, you need your domain admin to change it in the Group Policy Management Console.
gpresult /h C:\Temp\gp.html2. The “Allow NTLM” Authentication Level
There's a separate policy called Network security: Restrict NTLM: Incoming NTLM traffic. If that's set to “Deny all accounts”, it will cause a similar error. Set it to “Allow all” or at least “Allow for domain accounts” depending on your security needs. That one is also in the same Security Options section.
Prevention
The real fix is to modernize your authentication. NTLM is old and weak — that's why it's being locked down. But if you can't switch to Kerberos or a certificate-based method right now, at least set the policy to a consistent level across all machines.
Make sure your server-side NTLM settings match the client. If the server is set to refuse NTLMv2, no client tweak will help — you'd have to change the server policy instead. Also, check for any third-party software that might be forcing its own NTLM policy, like some VPN clients or database drivers.
One more thing: if you're using Outlook and getting this error, check that your mail server supports OAuth2. That's a much better authentication method and avoids this whole mess. But for quick, immediate relief, the LmCompatibilityLevel setting is your friend.
Now go restart that app and get back to work.