Failed to Connect to the Target Machine

RDP Supported Authentication Methods

PRA currently supports Enhanced RDP Security with TLS Encryption and NTLM authentication (CredSSP). The target machine needs to have NLA enabled and NTLM authentication traffic needs to be enabled. Standard RDP Security is not currently supported.

Kerberos authentication is supported. See Kerberos Authentication to learn more.

Connection Fails When Network Level Authentication (NLA) Is Disabled on the Target

If Network Level Authentication (NLA) is disabled on a Windows target, a PRA RDP session to that target fails. The error shown in PRA may indicate an access or authorization problem, for example that the user is not authorized for remote login, even though the user has valid RDP rights on the target.

This happens because PRA only supports Enhanced RDP Security with CredSSP, which requires NLA. The native Windows Remote Desktop client (MSTSC) can still connect to the same target because it falls back to Standard RDP Security and shows a warning that the identity of the remote computer cannot be verified, which the user can acknowledge. PRA does not support Standard RDP Security and does not offer this fallback.

If a user with valid RDP rights receives an access or authorization error from PRA but can connect to the same target with MSTSC, check whether NLA is enabled on the target:

  1. On the target machine, open System Properties and select the Remote tab.
  2. Under Remote Desktop, confirm that Allow remote connections to this computer is selected.
  3. Confirm that Allow connections only from computers running Remote Desktop with Network Level Authentication is selected. If it is not, select it and click OK.

To prevent the setting from being changed on individual machines, enforce NLA through Group Policy: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Require user authentication for remote connections by using Network Level Authentication.

The Verify Privileged Identity Platform Agent disables NLA on the Windows machines it manages, and PRA connections to those machines are supported without NLA. Do not re-enable NLA on a target that has the Platform Agent installed. See Task 6: Set Up PRA in the Platform Agent guide.

Failed to Connect to the Target Machine. Error Showing When Attempting to Launch a Remote Session.

The cause of this problem could be that the user's engine server was not properly configured to use the DNS for their environment. The engine may be unable to resolve the DNS name for the selected target.

To fix this problem:

  • Check that the correct site was selected in the site selection dialog drop-down menu.
  • Check that the target server is up and running
  • Ensure that the target server is routable from the engine server (e.g. 192.168.x.x engine server will need routes correctly set up to connect to a 10.10.x.x target server)
  • Verify the secret data is correct (URL(Machine), Password, Public Key, Private Key, Private Key Passphrase)
  • Check that the proper Secret template was used
  • Check that secret "Approval" was granted if necessary and that all security requirements are satisfied.
  • Do ensure that the engine for the site you selected is "Online" (the engine may have gone offline close to the time the user selected the site to connect to)

Diagnosing Connectivity Issues With Linux Target Machines

This section requires root access to the target server and assumes the target server has a recent version of OpenSSH/OpenSSL installed, configured correctly and running successfully.

  1. OpenSSH information:

    • PRA supports versions OpenSSH_7.4p1, OpenSSL 1.0.2k-fips and up to version OpenSSH_8.x, OpenSSL 1.1.1k.

    • The newest version of OpenSSH is 9.x. This version may function but is not yet fully supported.

    • Older versions may still function but are not supported.

       

2. Verify the configuration on the target server:

  • SSH into the Linux target server.

    Copy 
    ssh user@targetServer [-i /path/to/pubkey]

  • Sudo into root

    • Some Linux distributions require superuser privileges to run the following commands

  • Run the following command to verify SSH is installed and is a supported version:

Copy 
ssh -V

  • Run the following command to verify SSHD is running and listening for incoming connection requests:

    Copy 
    netstat -plnt

  • Look for sshd in the output of the above command in the column titled PID/Program name.

  • Check the Local Address column for SSHD and verify it is listening on port 22 i.e. 0.0.0.0:22

Accessing Logs on the Engine Server (Deprecated)

The following command(s) will display a real time update to the users screen containing "Login" logs for the server. Type control c (^c) (hold down the "control" key then type the letter c) to exit the command on any operating system.

  • Debian/Ubuntu

    Copy 
    tail -f /var/log/auth.log

  • RHEL/Redhat 7 & 8/Amazon

    Copy 
    tail -f /var/log/secure

  1. Check if the users request is getting to the target server.

    • Run the command above

    • From the web UI select the secret for the target server you are logged into.

    • From the SSH shell check the logs:

      • Is the request showing up in the logs? If not then check the "Machine" data in the secret is correct.

  2. Check if the users request is being rejected:

    • Run the command above

    • From the web UI select the secret for the target server you are logged into.

    • From the SSH shell check the logs:

    • Does the log entry contain an error e.g. "Invalid user ", "Incorrect password" or "Invalid public key"? If so check the secret data and confirm the password, private/public key or key passphrase is correct.