How do I troubleshoot authentication errors when I use RDP to connect to an EC2 Windows instance?

Key Takeaways

Hello, I'm Special, a cloud support engineer at the AWS office in Auckland, New Zealand. Today, I'm going to show you how to troubleshoot network level authentication errors when you try to use Remote Desktop Protocol or RDP to connect to an EC2 Windows instance. Let's get started. When you try to use RDP to connect to your EC2 Windows instance, you might receive network level authentication or NLA errors such as an authentication error has occurred. The local security authority cannot be contacted. Or 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. This errors can occur because you turn on NLA for the server, which causes an instance to lose connectivity to a domain controller because the domain credentials aren't authenticated. The error can also occur because the trust relationship between your domain and the instance fails when you log in to RDP. First, I will show you how to turn off NLA for the server. Before you begin, make sure that you have the correct permissions to perform these actions. Also, please make sure you have taken an AMI or snapshot backup of the instance. This precaution is necessary in case we need to roll back to the previous stage. To turn off NLA on an unreachable instance that has Systems Manager managed, you can run the AWS Support Troubleshoot RDP Automation document, deactivate NLA with Session Manager capability of Systems Manager, run the AWS Run PowerShell script command document, or manually change the registry offline. To use the AWS Systems Manager AWS Support Troubleshoot RDP Automation document to deactivate NLA on the instance, first, open the Systems Manager console. In the navigation pane, choose documents. Search for the runbook name AWS Support Troubleshoot RDP. Choose AWS Support Troubleshoot RDP. And then, choose execute automation. In the input parameters, choose your managed instance. In the NLA setting action, select disable. Then, choose execute. Wait for the automation to successfully complete, and then RDP into the instance. Another way to turn off NLA is to use Session Manager to add registry keys. First, open the AWS Systems Manager console. In the navigation pane, choose Fleet Manager. Choose the managed instance that you want to connect to. In the node actions menu, choose start terminal section. This connects you to the instance using Session Manager. In the terminal, run these commands to turn off NLA. You can also use the AWS Run PowerShell script command document to turn off NLA. On the Systems Manager console, navigate to run command. Choose run command. Search for the command document name AWS Run PowerShell script. Select AWS Run PowerShell script. Next, in the command parameters, I will enter the same registry commands that I entered when I used Session Manager. Then, choose instance manually and select your instance. Choose run. Wait for the process to successfully complete, and then RDP into the instance. And finally, if you can't connect to your instance, then you can manually change the registry offline to turn off NLA. First, create an Amazon machine image or a snapshot as a backup. Then, stop the unreachable instance and detach the root volume. Launch a new instance in the same availability zone as the unreachable instance that you stopped. The new instance becomes your rescue instance. It's a best practice to launch a Windows instance that's different from the unreachable instance to avoid disk signature issues. Next, attach the detached volume to the rescue instance as dev xvdf. Use RDP to connect to the rescue instance, and then bring the attached volume online in Disk Manager. In the command prompt, enter regedit.exe, and then press enter to open the Registry Editor. Choose HKEY_LOCAL_MACHINE, and then choose file, load hive. Navigate to the Windows folder on the attached volume, and then select the system file. The default path is D Windows System32 config. Name the system file. For example, basis. The basis system file now appears under HKEY_LOCAL_MACHINE. Under basis, navigate to ControlSet001, then Control, then Terminal Server, WinStations, and finally, RDP-TCP. Double-click Security Layer and set the value data to zero. Choose User Authentication and set the value data to zero. Then, choose fAllowSecProtocolNegotiation and set the value data to zero. Choose basis, file, unload hive. After the hive unloads, open Disk Manager and take the disk offline. Detach the volume from the rescue instance, and attach the volume to the unreachable instance as the root volume. Finally, start the instance and test your RDP connection. If NLA is set by group policy, then these steps might not work. You will also need to turn off NLA in group policy. Now, let me show you how to resolve the failure that happens in the trust relationship between your domain and the instance when you log in to RDP. To resolve this issue, use cached user credentials to try to log in to the unreachable instance. Before you begin, make sure that you have a local account that can successfully authenticate to the instance. Also, when the domain controller isn't available, make sure to set the number of previous logins to cache to at least one. You must set this value to use interactive logins. You can set the policy to the default value of 10. By default, the policy isn't defined, and you can use the server's local policy. To use cached user credentials, first, open the EC2 console. Create a new security group with RDP inbound access, but no outbound access. Assign the new security group to your instance. Use a regular domain account to RDP into the instance. Because there's no outbound access, RDP uses cached credentials on the server to authenticate. After you connect, you can change the security group back to its original settings. So, now you know how to troubleshoot NLA errors when you try to use RDP to connect to a Windows instance. Thanks for watching and happy cloud computing from all of us here at AWS.