RDP Certificate Authentication

This section describes the procedures for enabling certificate authentication for RDP connections.

Prerequisites

Before enabling certificate authentication for RDP, check and execute the following:

  • Target hosts must belong to a Windows domain. The domain must include:

    • A domain controller with the server role Active Directory Domain Services, for handling authentication requests.

    • A Certificate Authority Server (CA server), with the server role Active Directory Certificate Services, including the Role Service Certification authority.

      The CA server must also have a service for certificate-revocation-status checks, for example, HTTP CRL with Certificate Enrollment Web Service or Web Server IIS role, or alternatively OCSP with the Online Responder role service.

    • Ensure that users' group policy allows RDP login. When enabling login with personal accounts, also ensure target-host local policy allows users to log on locally.

  • Both the domain controller and the CA server must run on one of the platforms where RDP certificate authentication is supported, described in Preparing for Deployment.

  • The domain policy must enable server certificate auto-enrollment. For instructions about enabling this, please refer to Microsoft documentation at https://docs.microsoft.com (search title: configure server certificate auto-enrollment).

  • Firewalls for the domain must allow HTTP access to PrivX server port 80, for obtaining the Certificate Revocation List.

  • PrivX server's IPs and FQDNs should be recorded in the shared-config.toml file. All listed IPs and FQDNs will be used as Certificate Revocation List Distribution Points.

  • Hosts in the target domain must be able to resolve PrivX server FQDNs.

  • Ensure NLA is not required for target hosts.

  • Ensure that target-servers' time settings are correct. Even a clock skew of just few minutes may break certificate-based authentication.

    By default certificates for SSH connections are valid for 8 hours, starting from 2 minutes prior to the current time in PrivX.

  • We recommend disabling smartcard-certificate propagation, which prevents users from using the certificate for further RDP/SSH connections.

Even with smartcard-certificate propagation disabled, users can still install the ephemeral certificate by running certutil on the target host. After that the user can use the certificate for further connections as long as the certificate is valid.

Ephemeral RDP certificates are typically valid for the user's entire domain.

RDP Certificate-Authentication-Setup

After ensuring the prerequisites, enable certificate authentication for RDP by performing the following:

  1. For target hosts to trust PrivX certificates, you must publish the PrivX CA certificate in the Windows domain.
    To obtain the PrivX CA certificate, go to the PrivX GUI. On the Settings→Deployment→Configure a Windows Domain for RDP Access page, click Download Certificate.

  2. Add the PrivX CA certificate to the Trusted Root Certification Authorities for the domain.

    Start by opening the Group Policy Manager and navigating to Forest→Domains→[your domain]→Group Policy Objects. Right click Default Domain Controllers Policy and select Edit.
    In the new window, navigate to Computer Configuration→Policies→Windows Settings→Security Settings→Public Key Policies→Trusted Root Certificate Authorities. Right click and select Import. Import the downloaded certificate.

    For improved security, also restrict the purposes of the PrivX CA: In the general properties of the PrivX CA certificate, select Enable only the following purposes, then select the following purposes:

    • Smart Card Logon
    • Client Authentication

    Save your changes to the certificate.

  3. Publish the PrivX CA certificate to the domain (replace privx_ca.crt with the path of the PrivX CA-certificate file):

    certutil -dspublish -f privx_ca.crt NTAuthCA

    Also ensure that the registry is updated by running:

    certutil -addstore -enterprise NTAuth privx_ca.crt

  4. On all target hosts, ensure that the host allows remote connections without Network Level Authentication.

  5. Define which roles are allowed to access the target hosts, and as which target accounts. For more information about mapping roles to target accounts, see Setting up Hosts.

  6. Certificates issued by PrivX are very time-sensitive. Even a clock skew of few minutes may prevent certificates from working correctly.

    Verify that the system times on the target hosts, Domain Controller and PrivX instances is correct. Adjust as necessary.

You will still need to enter the target password when you connect to it for the first time. After that, RDP connections to target are authenticated by just-in-time certificates provided by PrivX, without needing to provide passwords.

Certificate-Authentication Events in Windows Logs

Upon successful login from PrivX with certificate to target Windows host, the target host logs an event similar to the following:

Note certificate serial number and thumbprints in the windows logs, which should match the corresponding entries in PrivX event logs. This is useful to link PrivX user to windows login if the target account is a shared account.

Was this page helpful?

On this page