Authentication Failed Because NTLM Authentication Has Been Disabled | Fast Fix Steps

Authentication Failed Because NTLM Authentication Has Been Disabled Error Overview

The message authentication failed because NTLM authentication has been disabled appears when a Windows device refuses NTLM logons from a client, even though the username and password are correct. Windows treats the attempt as unsafe because current security baselines push administrators toward Kerberos and away from NTLM, which is easier to intercept and crack.

Newer builds of Windows 10 and Windows 11 tighten NTLM rules by default, especially in Remote Desktop, file sharing, and old tools that still rely on NTLMv1. When those rules change, older servers, NAS boxes, or applications keep sending NTLM, so the sign in fails with this specific error text instead of a password prompt.

From an end user point of view, this looks like a random glitch. In reality, the system is doing exactly what security policy tells it to do. Either NTLM is blocked outright through the Network Security Restrict NTLM settings, or the account falls under a policy that forbids NTLM, such as a protected users group or hardened domain controller rules.

Why Authentication Failed Because NTLM Authentication Has Been Disabled On Windows 10 And 11

Under the hood, Windows checks several layers of configuration before it allows an NTLM handshake. Domain level Group Policy can restrict NTLM across the whole forest. Local security policy on a member server or workstation can deny incoming NTLM traffic. Individual account types, such as protected users, can also be barred from NTLM, even when other accounts still use it without trouble.

Microsoft guidance now recommends restricting NTLM wherever possible and using Kerberos instead. That guidance shows up as security templates, hardening tools, and new default values in recent releases. After an upgrade, a device that once accepted NTLM might suddenly reject it because Restrict NTLM policies changed from allow all to deny all domain accounts or deny all accounts.

Remote Desktop, SMB file shares, SQL connections, and migration tools such as ADMT can all trigger this message when they fall back to NTLM and the target host refuses it. In many homes and small offices the device sending NTLM is not joined to the same domain, or not joined at all, so the only available protocol is blocked, and the user receives the error immediately.

Fixing NTLM Authentication Disabled Errors In Windows Settings

Before you change policy, confirm that the failure is actually tied to NTLM and not a typo or reachability issue. Event Viewer on the target system records NTLM blocked events with codes that match the error, and tools such as network traces reveal NTLM negotiation packets followed by a reset instead of a normal response.

Check Local And Domain Restrict NTLM Policies

On a domain joined host, Group Policy often controls whether NTLM is allowed. The core setting appears as Network security Restrict NTLM Incoming NTLM traffic or Restrict NTLM authentication in this domain. When those settings are set to deny all accounts, every NTLM request returns an NTLM blocked error even when the credentials would pass.

• Open Local Security Policy — Press Win+R, type secpol.msc, and press Enter on the target machine.
• Review Restrict NTLM Settings — Under Local Policies > Security Options, look for entries that begin with Network security: Restrict NTLM and note any deny values.
• Test With Relaxed Policy — As a short term test, switch Incoming NTLM traffic from deny all accounts to allow all, apply the change, and repeat the sign in from the client.

If loosening the setting resolves the problem, you have confirmed that Restrict NTLM is the direct cause. You can then add specific server exceptions or account based rules instead of leaving NTLM wide open everywhere, which would undo the security gain from the earlier hardening work.

Adjust Group Policy For Domain Wide NTLM Rules

In a domain, a central policy might be pushing stricter NTLM behavior than any single server owner expects. Domain controllers expose settings under Network security Restrict NTLM NTLM authentication in this domain. When that policy denies NTLM, authentication failed because NTLM authentication has been disabled shows up for many services at once.

• Open Group Policy Management — On a management workstation, run gpmc.msc and open the policy linked to the domain or the affected organizational unit.
• Locate NTLM Domain Policies — Browse to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options and edit the Network security: Restrict NTLM entries.
• Switch To Audit First — Change deny settings to audit only where possible so that blocked NTLM traffic is logged but still allowed while you map which servers and apps still depend on it.

This audit first pattern follows Microsoft hardening guidance and keeps the network usable while you plan a cleaner Kerberos rollout. Once logs show that only legacy devices or specific applications still use NTLM, you can move them to an exception policy and turn full denial back on for everything else.

Server Side Changes When NTLM Authentication Is Disabled

Many NTLM failures come from servers or devices that never moved to Kerberos or another modern protocol. Older NAS appliances, Linux Samba servers, printers, and third party Windows services still rely on NTLM, and sometimes even NTLMv1. When the client or the domain blocks that older protocol, the connection breaks with the same error text.

Update Or Reconfigure File Servers And NAS Devices

Network file shares are a common trigger for this issue. Recent security updates for Windows 11 tighten how SMB negotiates NTLM, especially for guest and anonymous sessions. If a share still expects plain NTLM, but the client now insists on Kerberos or stronger signing, you see authentication failed because NTLM authentication has been disabled when you browse to the share path.

• Enable Modern SMB Protocols — On the NAS or file server, enable SMB versions that work with Kerberos and disable legacy NTLMv1 where a patch or firmware update allows it.
• Join Devices To The Domain — When possible, join the storage device to the same Active Directory domain so clients can use Kerberos instead of falling back to NTLM.
• Apply Vendor Security Updates — Install current firmware and patches from the vendor, since many include fixes for modern Windows clients that no longer accept weak NTLM modes.

Review RDP And Application Settings

Remote Desktop and some middleware products may force NTLM even when other choices exist. RDP sessions that target workgroup machines or devices without proper certificates often fall back to NTLM and trigger the same blocked message in current Windows releases.

• Check Network Level Authentication — In Remote Desktop settings on the host, try clearing the box that restricts connections to clients with Network Level Authentication, then retest from the remote machine.
• Update Connection Profiles — Edit saved RDP or client connection files so they point to the host by fully qualified domain name instead of raw IP, which gives Kerberos a better chance to work.
• Inspect App Auth Options — For SQL clients, web apps, or custom tools, pick integrated authentication modes that prefer Kerberos and disable explicit NTLM only options where present.

These changes move traffic away from NTLM where possible so that restrictive policies can remain in place while real work still flows. In many networks, only a handful of exceptions remain once the most visible RDP and file share issues are handled.

Short Term Workarounds Versus Long Term NTLM Strategy

When a business relies on older software that still needs NTLM, the fastest fix may be to re enable it for a narrow set of hosts while a replacement plan comes together. The trick is to keep that enablement as narrow and temporary as possible so that attackers cannot use NTLM weaknesses to steal hashes or relay sessions.

Scenario	Short Term Action	Safer Long Term Step
Legacy file server only handles NTLM	Add the server to an NTLM exception list and restrict access to a small security group.	Replace or upgrade the server so it can use Kerberos and modern SMB signing.
Migration tool fails with NTLM disabled	Allow NTLM for the tool during the migration window only and log all usage.	Retire the tool or move to a version that uses Kerberos or modern APIs.
Remote access to workgroup machines breaks	Permit NTLM traffic only from a management jump host with strong controls.	Join those machines to the domain or move them behind a more modern access layer.

This table illustrates how to limit the blast radius while still getting daily tasks done. Rather than turning NTLM back on everywhere, you carve out a few specific hosts or apps, surround them with extra monitoring, and keep a clear plan to remove those exceptions later.

Any time you relax NTLM rules, write down who approved the change, which hosts are in scope, and when you plan to review it. Change tickets, spreadsheets, or even a short note in your configuration management system all help you track these exceptions. When you later audit NTLM usage, that record keeps surprises low and makes it easier to remove old carve outs that nobody needs any more. That habit pays off quickly.

Quick Diagnostic Checklist For NTLM Authentication Problems

When you see the error for the first time, it helps to follow a simple repeatable path so you reach the root cause quickly. The same pattern works for Remote Desktop, SMB shares, and many custom applications that depend on Windows integrated sign in.

1. Confirm Basic Connectivity — Ping the server name, test DNS resolution, and make sure no firewall rule blocks the port in question.
2. Check Account Type — Verify that the user is not in a group that forbids NTLM, such as protected users, and that the password is current.
3. Inspect Event Logs — Open Event Viewer on the target host and look for NTLM blocked messages tied to the same timestamp as the failed attempt.
4. Review Restrict NTLM Policies — Compare local security policy and Group Policy settings for Network security Restrict NTLM entries that deny or audit traffic.
5. Test Kerberos Paths — Try authenticating from a domain joined machine using its fully qualified name to see whether Kerberos can succeed where NTLM fails.
6. Decide On Exception Or Upgrade — If only one legacy device fails, weigh the risk of a narrow NTLM exception against the cost of replacement or upgrade.

By walking this checklist, you avoid random trial and error changes and instead build a clear picture of how NTLM is used in your network. That picture guides both the immediate fix and the follow up work needed to keep authentication fast, safe, and reliable long term.