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

Short description

You might receive the following authentication errors when you use RDP to log in to an EC2 Windows instance:

"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."

These errors occur for the following reasons:

• The trust relationship between your domain and the instance that's joined to the domain failed during the RDP login.
• The instance is domain-joined, but can't reach the domain controller.
• The Secure Channel or Netlogon service on the domain-joined instance is broken.
• You activated Network Layer Authentication (NLA) for the server.

Resolution

Run the AWSSupport-Troubleshoot runbook

Prerequisites:

• Make sure that the instance has an AWS Identity and Access Management (IAM) instance profile role with the AmazonSSMManagedInstanceCore Amazon managed policy attached.
• Verify that your current IAM user or role has the required permissions. For more information, see Required IAM permissions on AWSSupport-TroubleshootRDP.
  Note: If you choose the AllowOffline option, then the runbook uses the AWSSupport-ExecuteEC2Rescue runbook to fix issues offline. To start the AWSSupport-ExecuteEC2REscue runbook, your IAM role or user must have the AmazonSSMAutomationRole IAM managed policy.

To automatically resolve configuration issues at the operating system (OS) level, run the AWSSupport-TroubleshootRDP runbook.

Troubleshoot trust relationship failure during RDP login

If the trust relationship fails, then use the cached user credentials to log in to the unreachable instance. When you use cached credentials, you avoid domain controller authentication and can gain access to the instance. If you can't use cached credentials, then proceed to Troubleshoot domain-joined instances.

Prerequisites:

• At least one domain AWS account must have been logged in when the instance communicated with the domain controller.
  Note: It's a best practice to use a local account.
• You must have a local account that can successfully authenticate to the instance.
• If the domain controller isn't available, then make sure that Interactive logon: Number of previous logons to cache (in case domain controller is not available) is set to at least 1. For more information, see Interactive logon: Number of previous logons to cache (in case domain controller is not available) on the Microsoft website.
  Note: 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 to log in, complete the following steps:

1. Open the Amazon EC2 console.
2. In the navigation pane, choose Security groups.
3. Choose Create security group.
4. Add a security group name and description.
5. Under Inbound rules, choose Add rule.
6. For Type, select RDP. Then, enter information for the source that you connect from.
7. Under Outbound rules, remove all outbound access.
8. Choose Create security group.
9. In the navigation pane, choose Instances, and then choose the unreachable instance.
10. Choose Actions, and then select Security.
11. Choose Change security groups.
12. Remove the existing security groups, and then add the security group that you created.
13. Use RDP to connect to the instance with the domain account.
    Note: Because you removed outbound access from Amazon EC2, RDP uses the cached credentials that are stored on the server. After you log in, you can change the security group settings back to the original state.
14. Troubleshoot issues with the Windows instance.

Troubleshoot domain-joined instances

Verify that the instance can reach the domain controller

Complete the following steps to use Fleet Manager, a capability of AWS Systems Manager, to check your instance:

1. Open the AWS Systems Manager console.
2. In the navigation pane, choose Fleet Manager.
3. Choose your managed instance.
4. In the Node actions menu, select Start terminal session.
5. Run the following command to test connectivity to the domain controller:

   nltest /dsgetdc:your-domain-name

   If the command fails or returns errors, then the instance can't reach the domain controller. To resolve this issue, check the instance's security group and network access control list (network ACL). Make sure that they allow outbound traffic on ports 88 (Kerberos), 389 (LDAP), 445 (SMB), and 49152–65535 (RPC dynamic ports) to the domain controller.
6. Run the following command to confirm that the domain controller is running and reachable from the instance's virtual private cloud (VPC) subnet:

   Test-NetConnection IP address-computer-name -Port port-example -InformationLevel "Detailed"

   Note: Replace IP-address-computer-name with the domain controller's IP address or computer name and port-example with the instance's port.
7. Run the following command in the terminal session to verify that the instance's DNS settings point to the domain controller's IP address:

   ipconfig /all 

If the DNS settings don't point to the domain controller's IP address or DNS server, then complete the following steps to update the settings:

1. Choose the Start menu, and then open Control Panel.
2. Choose Network and Internet, and then choose Network and Sharing Center.
3. Choose Change adapter settings.
4. Open the context (right-click) menu for your network adaptor, and then select Properties.
5. Choose Internet Protocol Version 4 (TCP/IPv4), and then choose Properties.
6. Select Use the following DNS server addresses, and then enter your domain controller's IP address.
7. Choose Ok.

Repair the Secure Channel for domain-joined instances

Complete the following steps:

1. Open the Systems Manager console.

2. In the navigation pane, choose Fleet Manager.

3. Choose your managed instance.

4. In the Node actions menu, select Start terminal session.

5. Run the following Windows PowerShell command to test the Secure Channel:

   Test-ComputerSecureChannel -Verbose

6. If the Secure Channel is broken, then run the following command to repair it:

   Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

   Note: When prompted, enter the credentials of a domain administrator account.

7. Wait for the repair to complete.

8. Stop and start the instance.

If you still encounter Secure Channel issues, then see Secure channel problems detected on the Microsoft website.

Troubleshoot Netlogon service issues

To troubleshoot Netlogon service issues, see The Netlogon service doesn't start and event IDs 2114 and 7024 are logged on the Microsoft website.

Reset the computer's account password for domain-joined instances

If you still encounter issues after you repaired the Secure Channel, then complete the following steps to reset your computer's account password:

1. Log in to a domain controller, or to another domain-joined machine with domain administrator credentials.
2. Run the following Windows PowerShell command:

   Reset-ComputerMachinePassword -Server DomainControllerName -Credential (Get-Credential)

   Note: Replace InstanceComputerName with the name of the instance.
   -or-
   Run the following Netdom command:

   netdom resetpwd /server:DomainControllerName /userd:DOMAIN\AdminUser /passwordd:*

   Note: Replace DomainControllerName with your domain controller name and DOMAIN\AdminUser with your user account.
3. When prompted, update the instance password.
4. Stop and start the instance.

Deactivate NLA for the server

NLA errors occur if an instance loses connectivity to a domain controller because the domain or network credentials aren't authenticated. If you completed the troubleshooting steps and still encounter NLA issues, then use one of the following methods to deactivate NLA on the unreachable instance.

Note: You must change the registry when you change the NLA. Before you start, create an Amazon Machine Image (AMI) of your instance to use as a backup. If you receive an "Internal error" error message after you deactivate NLA, then see Resolve the "Internal errors" issue

Use Session Manager to connect to your instance and deactivate NLA

Prerequisites:

• Make sure that your configuration adheres to the prerequisites for Session Manager, a capability of AWS Systems Manager.
• Make sure that the instance has an IAM role with the required Session Manager permissions.

Complete the following steps:

1. Open the Systems Manager console.
2. In the navigation pane, choose Fleet Manager.
3. Choose your managed instance.
4. In the Node actions menu, select Start terminal session.
5. Run the following commands in the terminal session to deactivate NLA:

   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
    

Or, to deactivate NLA with the aws:runPowerShellscript in Run Command, a capability of AWS Systems Manager, complete the following steps:

1. Open the Systems Manager console.

2. In the navigation pane, choose Run Command, and then choose Run a Command.

3. For Command document, search for and select AWS-RunPowerShellScript.

4. 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 
   

5. For Target selection, select Choose instances manually, and then select your instance.

6. Choose Run.

7. Wait until the Overall status is Success. Then, stop and start the instance.

Manually change the registry offline

Complete the following steps:

1. Stop the unreachable instance.

2. Detach the instance's root volume.

3. Launch a rescue instance in the same Availability Zone as the unreachable instance.
   Important: To avoid disk signature issues, it's a best practice to launch a Windows instance that uses a different OS version than the unreachable instance.

4. Attach the root volume to the rescue instance as /dev/xvdf.

5. Use RDP to connect to the rescue instance.

6. Choose the Start menu, and then open Disk Manager.

7. Open the context (right-click) menu for the root volume, and then select Online.

8. In a command prompt, run the following command to open the Registry Editor:

   regedit.exe

9. Choose HKEY_LOCAL_MACHINE, and then choose File.

10. Choose Load Hive, and then navigate to the Windows folder for the volume. The default path is D:\Windows\System32\config.

11. Choose the SYSTEM file, and then name it. For example, name the file badsys.

12. The badsys system file now appears under HKEY_LOCAL_MACHINE. Under badsys, choose ControlSet001.

13. Navigate to Control\Terminal Server\WinStations\RDP-Tcp, and then choose the key.

14. Double-click SecurityLayer, and then set the value to 0.

15. Choose UserAuthentication, and then set the value to 0.

16. Choose AllowSecProtocolNegotiation, and then set the value data to 0.

17. Repeat steps 11-16 for ControlSet002, Terminal Server, WinStations, and RDP-Tcp.

18. Choose badsys, and then choose File.

19. Choose Unload Hive.

20. After the hive unloads, unmount and detach the volume from the rescue instance.

21. Attach the volume to the original instance as the /dev/sda1 root volume.

22. Start the original instance.

Resolve the "Internal errors" issue

If you receive an "Internal error" error message after you deactivate NLA, then you must fix the RSA MachineKeys permissions. Use Session Manager or RDP with local credentials to connect to the instance. Then, run the following Windows PowerShell commands as an administrator:

Get-ChildItem C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys | ForEach-Object {icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\$_ /grant system:F}
Get-ChildItem C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys | ForEach-Object {icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\$_ /grant NetworkService:R}
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name fAllowSecProtocolNegotiation -Value 1 -Force
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name UserAuthentication -Value 1 -Force
Restart-Service TermService -Force

Unjoin and rejoin the domain

If you still encounter issues, then complete the following steps to unjoin and rejoin the domain:

1. Use Session Manager or a local administrator account to log in to the instance.

2. Run the following Windows PowerShell command to remove the instance from the domain:

   Remove-Computer -UnjoinDomainCredential (Get-Credential) -PassThru -Verbose -Restart

3. After the instance restarts, log in with a local administrator account.

4. Run the following Windows PowerShell command to rejoin the domain:

   Add-Computer -DomainName your-domain-name -Credential (Get-Credential) -Restart

5. After the instance restarts, use RDP to log in to the instance with domain credentials.
   Note: When you unjoin and rejoin the domain, the instance gets a new machine account in Active Directory. Make sure to apply Group Policy Objects (GPOs) or domain-based configurations to the rejoined instance.

Troubleshoot further

If you still can't connect to the instance, then see How do I troubleshoot RDP connection issues with my EC2 Windows instance?