You can use Remote Desktop to connect to and control your PC from a remote device by using a Microsoft Remote Desktop client (available for Windows, iOS, macOS and Android). Network Level Authentication (NLA) refers to the usage of CredSSP to authenticate the user before the initiation of the RDP connection. This allows the server to dedicate resources only to authenticated users. In case of a critical vulnerability in the RDP protocol, NLA can limit the exploitation of this vulnerability to authenticated users only. In the protocol specification for CredSSP, there is no reference to the ability to change the user's password while NLA is running. Therefore, the observed behavior can be considered 'by design.' CredSSP is the underlying technology that enables NLA, and it does not support password changes. NLA is implemented as a generic Windows Sockets 2 Name Resolution service provider. You can use Remote Desktop to connect to and control your PC from a remote device by using a Microsoft Remote Desktop client (available for Windows, iOS, macOS and Android).
-->Personal computers running Microsoft Windows often have numerous network connections, such as multiple network interface cards (NIC) connected to different networks, or a physical network connection and a dial-up connection. Windows Sockets has been capable of enumerating available network interfaces for some time, but certain critical information about network connections was previously unavailable. This includes information such as the logical network to which a Windows computer is attached or whether multiple interfaces are connected to the same network.
The Network Location Awareness service provider, commonly referred to as NLA, enables Windows Sockets 2 applications to identify the logical network to which a Windows computer is attached. In addition, NLA enables Windows Sockets applications to identify to which physical network interface a given application has saved specific information. NLA is implemented as a generic Windows Sockets 2 Name Resolution service provider.
-->This article can help you troubleshoot authentication errors that occur when you use Remote Desktop Protocol (RDP) connection to connect to an Azure virtual machine (VM).
Symptoms
You capture a screenshot of an Azure VM that shows the Welcome screen and indicates that the operating system is running. However, when you try to connect to the VM by using Remote Desktop Connection, you receive one of the following error messages:
- An authentication error has occurred. The Local Security Authority cannot be contacted.
- The remote computer that you are trying to connect to requires Network Level Authentication (NLA), 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.
- This computer can't connect to the remote computer. Try connecting again, if the problem continues, contact the owner of the remote computer or your network administrator.
Cause
There are multiple reasons why NLA might block the RDP access to a VM:
- The VM cannot communicate with the domain controller (DC). This problem could prevent an RDP session from accessing a VM by using domain credentials. However, you would still be able to log on by using the Local Administrator credentials. This problem may occur in the following situations:
- The Active Directory Security Channel between this VM and the DC is broken.
- The VM has an old copy of the account password and the DC has a newer copy.
- The DC that this VM is connecting to is unhealthy.
- The encryption level of the VM is higher than the one that’s used by the client computer.
- The TLS 1.0, 1.1, or 1.2 (server) protocols are disabled on the VM.The VM was set up to disable logging on by using domain credentials, and the Local Security Authority (LSA) is set up incorrectly.
- The VM was set up to accept only Federal Information Processing Standard (FIPS)-compliant algorithm connections. This is usually done by using Active Directory policy. This is a rare configuration, but FIPS can be enforced for Remote Desktop connections only.
Before you troubleshoot
Create a backup snapshot
To create a backup snapshot, follow the steps in Snapshot a disk.
Connect to the VM remotely
To connect to the VM remotely , use one of the methods in How to use remote tools to troubleshoot Azure VM issues.
Group policy client service
If this is a domain-joined VM, first stop the Group Policy Client service to prevent any Active Directory Policy from overwriting the changes. To do this, run the following command:
After the problem is fixed, restore the ability of this VM to contact the domain to retrieve the latest GPO from the domain. To do this, run the following commands:
If the change is reverted, it means that an Active Directory policy is causing the problem.
Workaround
As a work around to connect to the VM and resolve the cause, you can temporarily disable NLA. To disable NLA please use the below commands, or use the DisableNLA script in Run Command.
Then, restart the VM, and proceed to the troubleshooting section.
Once you have resolved the issue re-enable NLA, by runing the following commands, and then restarting the VM:
Troubleshooting
Troubleshoot Domain-joined VMs
To troubleshoot this problem:
- Check whether the VM can connect to a DC.
- Check the health of the DC.
Note
To test the DC health, you can use another VM that is in the same VNET, subnet, and uses the same logon server.
Connect to the VM that has the problem by using Serial console, remote CMD, or remote PowerShell, according to the steps in the Connect to the VM remotely section.
Determine the DC that the VM is attempting to connect to. run the following command in the console:
Test the health of the secure channel between the VM and the DC. To do this, run the
Test-ComputerSecureChannelcommand in an elevated PowerShell instance. This command returns True or False indicating whether the secure channel is alive:If the channel is broken, run the following command to repair it:
Make sure that the computer account password in Active Directory is updated on the VM and the DC:
If the communication between the DC and the VM is good, but the DC is not healthy enough to open an RDP session, you can try to restart the DC.
If the preceding commands did not fix the communication problem to the domain, you can rejoin this VM to the domain. To do this, follow these steps: Roda mildef laptops & desktops driver download for windows 10.
Create a script that’s named Unjoin.ps1 by using the following content, and then deploy the script as a Custom Script Extension on the Azure portal:
This script forcibly removes the VM from the domain and restarts the VM 10 seconds later. Then, you need to clean up the Computer object on the domain side.
After the cleanup is done, rejoin this VM to the domain. To do this, create a script that is named JoinDomain.ps1 by using the following content, and then deploy the script as a Custom Script Extension on the Azure portal:
Note
This joins the VM on the domain by using the specified credentials.
If the Active Directory channel is healthy, the computer password is updated, and the domain controller is working as expected, try the following steps.
If the problem persists, check whether the domain credential is disabled. To do this, open an elevated Command Prompt window, and then run the following command to determine whether the VM is set up to disable domain accounts for logging on to the VM:
If the key is set to 1, this means that the server was set up not to allow domain credentials. Change this key to 0.
Troubleshoot standalone VMs
Check MinEncryptionLevel
In an CMD instance, run the following command to query the MinEncryptionLevel registry value:
Based on the registry value, follow these steps:
4 (FIPS): Go to Check FIPs compliant algorithms connections.
3 (128-bit encryption): Set the severity to 2 by running the following command:
2 (Highest encryption possible, as dictated by the client): You can try to set the encryption to the minimum value of 1 by running the following command:
Restart the VM so that the changes to the registry take effect.
TLS version
Depending on the system, RDP uses the TLS 1.0, 1.1, or 1.2 (server) protocol. To query how these protocols are set up on the VM, open a CMD instance, and then run the following commands:
If the returned values are not all 1, this means that the protocol is disabled. To enable these protocols, run the following commands:
For other protocol versions, you can run the following commands:
Note
Silicon portals driver. Get the SSH/TLS version x.x from the Guest OS Logs on the SCHANNEL errors.
Check FIPs compliant algorithms connections
Remote desktop can be enforced to use only FIPs-compliant algorithm connections. This can be set by using a registry key. To do this, open an elevated Command Prompt window, and then query the following keys:
If the command returns 1, change the registry value to 0.
Check which is the current MinEncryptionLevel on the VM:
Nla Microsoft Word
If the command returns 4, change the registry value to 2
Microsoft Nla Authentication
Restart the VM so that the changes to the registry take effect.
Nla Microsoft
Next steps