The Remote Computer Requires Network Level Authentication (NLA)

8.3K

This tutorial shows how to fix Network Level Authentication issues in RDP.

What is Network Level Authentication (NLA)?

Network Level Authentication (NLA) is a Remote Desktop Service security feature that requires the client to be authenticated before an RDP session is established. NLA is enabled by default in all supported versions of Windows. When performing NLA authentication in an Active Directory domain environment, domain controllers are used to validate user credentials.

How NLA Authentication Works (simplified)

The user must be authenticated before an RDP session is established when NLA is enabled. In a domain environment, this scenario usually requires contacting a DC to validate credentials using Kerberos/NTLM.

As a result, any problems related to connectivity, name resolution, trust relationship, or authentication can cause NLA authentication to fail.

Common Causes of NLA Authentication Errors

NLA authentication may fail if the Remote Desktop host is unable to contact a DC (however, this is only one of several possible causes):

The remote computer that you are trying to connect to requires Network Level Authentication but your Windows domain controller cannot be contacted to perform NLA. If you are an administrator on the remote computer, you can disable NLA by using the options on the Remote tab of the System Properties dialog box.

Note that this error message is generic (it does not always mean that the DC is unavailable). The message indicates that NLA authentication failed.

Common Root Causes of NLA Authentication Failures

Connectivity issues

• Remote Desktop host cannot reach a DC
• Network routing problems

DNS configuration issues

• DNS server settings misconfigured
• Domain name cannot be resolved

Secure channel / trust issues

• Broken trust relationship between the computer and the domain
• Machine account password mismatch

Authentication issues

• Kerberos failures (e.g., SPN or ticket issues)
• Time sync problems (clock skew)

Client-side limitations

Note that using an IP address instead of an FQDN may prevent Kerberos authentication. This will force NTLM fallback, and in such scenario you can face NLA issues in domain environments.

Checking Domain Controller connectivity and troubleshoot problem

To check DC connectivity and troubleshoot the underlying problem, you should log in locally to the RD host. Use one of the following methods:

• Log on to the RDP host remotely using the local administrator account (instead of the domain account).
• Login to RD host from a local console (e.g. VM console, HPE iLO, Dell iDRAC, etc.).

If neither of these methods work, you can temporarily disable the NLA requirement on the Remote Desktop host as a workaround.

Note. For security reasons, it is not recommended to completely disable NLA in most cases. But if you are using an alternative RDP client (for example, on Linux or macOS) that doesn’t support NLA, these are the only ways to fix the connection problem.

How to Disable Network Level Authentication (NLA) on Windows

Disabling NLA in Windows depends on whether you can logon RD host locally or remotely.

Method 1. Disable NLA via System Properties

If you can logon to the RD host locally, you can disable NLA in the system settings.

1. Run the sysdm.cpl command and go to the Remote tab;
2. Disable the option Allow connections only from computer running Remote Desktop with Network Level Authentication (recommended).

On Windows 11, you can disable NLA from Settings > System > Remote Desktop. Disable the option Require devices to use Network Level Authentication to connect.

Method 2. Disable NLA using Group Policy

Network Level Authentication can be disabled in Windows via Group Policy.

1. Open the Local Group Policy Editor console (gpedit.msc);
2. Go to Computer configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security;
3. Open the option Require user authentication for remote connections by using Network Level Authentication and set it to Disabled;

   

4. Run the gpupdate /force command to update the local Group Policy settings.

Method 3. Disabling RDP Network Level Authentication (NLA) remotely

In case you cannot sign in to the Remote Desktop host, you can disable NLA remotely via the Registry Editor or with PowerShell:

1. Open the Registry Editor (regedit.exe) on a domain-joined computer and select File > Connect Network Registry.
   

   

2. Enter the RD hostname where you want to disable NLA.
   

   

3. Navigate to the registry key HKLM\ SYSTEM\ CurrentControlSet\ Control\ Terminal Server\ WinStations\ RDP-Tcp
4. Change the value of the UserAuthenticationRequired parameter from 1 to 0.
5. This will disable NLA on the remote host.

   

Also, you can check the NLA status on the remote computer using PowerShell:

$Computer = 'wks12lk22'

(Get-CimInstance `
-ClassName Win32_TSGeneralSetting `
-Namespace root\cimv2\terminalservices `
-ComputerName $Computer `
-Filter "TerminalName='RDP-tcp'").UserAuthenticationRequired

NLA is enabled if the return value is 1.

To remotely disable Network Level Auth on the host, run the command:

$Session = Get-CimInstance `
-ClassName Win32_TSGeneralSetting `
-Namespace root\cimv2\terminalservices `
-ComputerName $Computer `
-Filter "TerminalName='RDP-tcp'"

Invoke-CimMethod `
-InputObject $Session `
-MethodName SetUserAuthenticationRequired `
-Arguments @{UserAuthenticationRequired = 0}

If you are using Azure VM, you can disable NLA using the built-in script in Azure Portal.

1. Sign in to Azure Portal;
2. Select your VM > go to Run command;
3. Find the DisableNLA script and click Run. This method is useful when RDP access is completely unavailable and you don’t have a local console access.

Once NLA has been disabled, you can log in to the target host with RDP and troubleshoot the underlying problem.

Fix Underlying Issues That Prevent NLA Authentication

After you get access to the host, follow these steps to identify and fix the root cause:

Step 1. Check DC Availability and Verify DNS

Check whether the RD host can connect to a DC. Ping the DC by its name and check that the client can discover the DC in a domain:

ping dc1.theitbros.loc

nltest /dsgetdc:theitbros.loc

If the DC is not reachable, check the network configuration and the DC health (also check How to fix Active Directory Domain Controller could not be contacted problem).

Step 2. Check and Repair the Domain Secure Channel

Make sure that the client is able to establish a security channel with a domain controller. Check the trust relationship between a workstation and a domain using the PowerShell command

Test-ComputerSecureChannel -verbose

If this command returns False, you can repair the security channel with the command:

Test-ComputerSecureChannel -Repair -Credential corp\domain_adm

Note that large time differences between the RD host and the DC may prevent Kerberos authentication and cause NLA failures. To check clock skew, run the command:

w32tm /query /status

Step 3. Check network profile

Check the assigned network connection profile both on a DC and a client:

Get-NetConnectionProfile

If it returns Public or Private instead of DomainAuthenticated, try disabling and enabling the NIC.

Be sure to enable NLA on the RD host after resolving the DC connectivity issue. Leaving it disabled is a security breach.

Note. A domain unjoin and rejoin operation is required in some cases to resolve this issue.

Wrapping up

In most cases, this NLA error is caused by DNS issues, DC connectivity problems, broken trust relationships, or Kerberos authentication failures. Note that disabling NLA can provide temporary access to the server, but we recommend you to identify and fix the underlying domain authentication issue and then re-enable NLA.