Need help?

Our experts have had an average response time of 13.52 minutes in October 2021 to fix urgent issues.

We will keep your servers stable, secure, and fast at all times for one fixed price.

Authentication error while using RDP on EC2

by | Jul 15, 2021

Stuck with authentication error while using RDP on EC2? We can help you.

Here at Bobcares, we handle requests from our customers to fix similar issues as a part of our Server Management Services.

Today let’s see how our Support Engineers fix this for our customers.


What causes authentication error while using RDP on EC2?

Typical error might look as one of the following errors:

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.

Error might cause due to below reasons:

  • Network Layer Authentication (NLA) is enabled on the server.
  • The trust relationship between your domain and EC2 instance joined to this domain fails during RDP login.


How to resolve it?

Today, let us see the steps followed by our Support Techs to resolve it.

NLA is enabled on the server

NLA errors often occur when the instance has lost connectivity to a domain controller because domain credentials aren’t authenticated.

To fix this issue, you can use the AWS Systems Manager AWSSupport-TroubleshootRDP automation document. Or, you can disable NLA on the instance.

The AWSSupport-TroubleshootRDP automation document allows you to modify common settings on an Amazon EC2 Windows instance that can impact RDP connections.

You can disable NLA on the unreachable instance using one of the following methods:

  • Disable NLA using Systems Manager AWS-RunPowerShellScript document.
  • Manually make registry changes offline.
Disable NLA using Systems Manager AWS-RunPowerShellScript document

To use AWS Systems Manager AWS-RunPowerShellScript Run Command to add registry keys, follow these steps:

  • Firstly, open theAWS Systems Manager console.
  • From the Instances & Nodes section of the navigation pane, choose Run Command.
  • For Command document, select AWS-RunPowerShellScript.
  • For Command parameters, enter the following commands:
reg add “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” /v SecurityLayer /t REG_DWORD /d 0 /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” /v UserAuthentication /t REG_DWORD /d 0 /f
reg add “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” /v fAllowSecProtocolNegotiation /t REG_DWORD /d 0 /f
  •  Then for Targets, select Choose instances manually.
  • Select your instance.
  • Choose Run.
  • Wait until the Overall status changes to Success. Refresh the page after 2 minutes.
  • Restart the instance.
  • Log in to the instance using RDP.


Manually make registry changes offline
  • Firstly, stop the unreachable instance and detach the root volume.
  • Launch a new instance in the same Availability Zone as the original instance you just stopped.

This becomes your rescue instance. It’s a best practice to launch a Windows version that is different from the unreachable instance.

This avoids disk signature issues.

  • Attach the detached volume to the rescue instance as /dev/xvdf.
  • Connect to the rescue instance using RDP, and then bring the volume you just attached online in Disk Manager.
  • Then, run regedit.exe to open the Registry editor.
  • Select HKEY_LOCAL_MACHINE and then select 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 badsys.
  • badsys now appears under HKEY_LOCAL_MACHINE. Under badsys, navigate to ControlSet001, Control, Terminal Server, WinStations, RDP-Tcp.
  • Double-click SecurityLayer and set its value data to 0. Then select UserAuthentication and set its value data to 0.
  • Scroll up and select badsys, File, Unload Hive.
  • After the hive unloads, open Disk Manager and take the disk offline.
  • Detach the volume from the rescue instance and attach it to the unreachable instance as the root volume (/dev/sda1).
  • Start the instance and test RDP.


The trust relationship between your domain and EC2 instance joined to this domain fails during RDP login.

To log in using cached user credentials, use the following steps:

  • Open the Amazon EC2 console and select Security groups.
  • Select Create Security Group and then add a name and description.
  • Under Security group rules, select Inbound – Add Rule.
  • Enter RDP.
  • In the Source field, enter the IP address where you want to RDP from.
  • For Outbound rule, remove all outbound access and then select Create.
  • Choose the unreachable instance, and then select Actions, Networking, Change Security Groups. Remove all existing security groups and
  • assign only the security group that you just created.
  • RDP to the EC2 instance using the regular domain account.
  • Since all outbound access is removed from EC2, RDP uses the cached credentials stored inside the server.


[Need assistance with EC2? We can help you]



Today, we saw how our Support Techs resolved authentication error while using RDP on EC2.



Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.


var google_conversion_label = "owonCMyG5nEQ0aD71QM";


Submit a Comment

Your email address will not be published. Required fields are marked *


Privacy Preference Center


Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]


Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid


Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie


These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.