Add an RDP Server With Certificate Auth

Last modified on February 23, 2024


A Remote Desktop Protocol (RDP) server in StrongDM is used to control a Microsoft Windows resource, such as a server running Windows Server 2019 or Windows 10 Professional. This guide describes how to set up an RDP server with a certificate in the Admin UI.

Using certificate authentication eliminates the need to manage unique key pairs for each of your servers. By using a certificate authority managed by StrongDM, every connection is secured with a short-lived private/public key pair, thus eliminating the risk of lost keys being compromised.


Before you begin, ensure that the server you are attempting to add is accessible from your StrongDM gateways or relays. You must have a properly functioning gateway or relay up and running, and it must be able to reach the target server before you can proceed.

To verify, go to the gateway or relay server and from a command prompt, type ping <YOUR_HOSTNAME>. If your gateway or relay can connect to this hostname, you can continue.

For more information see nodes.

Review and Download RDP Certificate

Every organization in StrongDM is automatically assigned a unique root Certificate Authority (CA) for RDP, known as a Strong CA. The Strong CA issues certificates that are added to your environment in order to allow RDP servers to authenticate with trusted certificates.

As an alternative to the Strong CA, organizations that have the Enterprise bundle enabled may use an RDP CA issued by a third party (for example, HashiCorp). Third-party CAs are managed in the same way as the Strong CA.

All RDP CAs available to your organization are listed on the Admin UI’s Network > Certificate Authorities page. Selecting a CA opens that CA’s settings, which shows all certificates issued by the CA. Each certificate is identified by a unique fingerprint and the time and date when it was created.

Multiple certificates can exist, but only one can be active at a time. An active certificate is the one configured to authenticate to the resource. The active certificate is highlighted and shown in blue, whereas inactive certificates are shown in gray.

To download a root certificate from the Admin UI, follow these steps.

  1. Log in to the StrongDM Admin UI.
  2. Go to Network > Certificate Authorities and select either StrongDM RDP Certificate Authority or another RDP CA.
  3. From the RDP CA’s Settings tab, select one of the certificates shown, or create a new certificate.
  4. Click the download button for the selected certificate to download the file rdp.cer. The certificate is added to your environment in the next step.
Network > Certificate Authorities > StrongDM RDP Certificate Authority
Network > Certificate Authorities > StrongDM RDP Certificate Authority

Add the RDP CA to Your Host

Set up your host to trust certificates issued by your organization’s RDP CA. The following steps are for configuring RDP certificate authentication in Microsoft Entra ID (formerly Azure AD) and on-premises AD. Follow the instructions for your host.

Microsoft Entra ID setup

  1. Log in to the Azure portal or Microsoft Entra admin center.
  2. From Azure Services, select Microsoft Entra ID.
  3. Go to Security > Manage > Certificate authorities and upload the root certificate file you downloaded from StrongDM. Specify that it is a root CA certificate and click Add.
  4. Go to Security > Manage > Authentication methods > Policies to allow users from Azure to use smart cards to authenticate with this mechanism. Select Certificate-based authentication from the list of methods.
  5. On the Enable and Target tab, enable it. Then under Include and Exclude, set the appropriate user and/or group targets for your organization.
  6. On the Configure tab, under Authentication binding, set Protection Level to single-factor authentication.
  7. Still on the Configure tab, add a rule. On the Edit rule screen, select Certificate issuer. Make sure the certificate issuer identifier is correct and that the protection level is still set to single-factor authentication, and save.
  8. Review all the certificate-based authentication settings. The certificate fields may be left as the defaults. When done, acknowledge and save.

Configuration is now complete.

On-premises AD setup

The following steps describe how to set up RDP authentication using Remote Identities in an on-premises AD deployment.

Before you begin, ensure that the following requirements are met:

  • Have an AD instance deployed, have an AD domain set up, and have a Windows server joined to the AD domain.
  • Have an Active Directory Certificate Service (AD CS) set up. This ensures that AD CS generates additional domain controller certificates (which are not the same as the RDP root certificate downloaded from StrongDM).

AD CS setup

If AD CS is not already set up, follow these steps. If already done, skip to Upload Trusted Root Certificate to AD.

  1. First consult Microsoft documentation to install the certification authority.
  2. Check that the certificates are populated in the correct certificate stores. The names of these certificates are typically in the format <DOMAIN_CONTROLLER_NAME>-auth, <DOMAIN_CONTROLLER_NAME>-email, and <DOMAIN_CONTROLLER_NAME>-kerberos. Use the Group Policy Manager to see if these certificates are present. To view the domain controller certificates, use the shortcut Windows+R and run mmc. With MMC open, under File, select Add/Remove Snap-in > Certificates > Add > Computer Account. Then go to Local computer > Finish > Certificates (Local Computer) > Personal.
  3. Ensure there is a root certificate in the format <DOMAIN_NAME>-<DOMAIN_CONTROLLER_NAME>-CA in the proper certificate stores. It should be present in all of the certificate stores viewable via the Microsoft Management Console (MMC) snap-in, specifically NTAuthCertificates, AIA Container, Certification Authorities Container, and Enrollment Services Container. In the same windows, under the CDP Container, you should also see a certificate revocation list (CRL) with the same name as this root certificate. See Verify CA Certificates Are Imported to learn how to view the certificate stores using MMC.
  4. Check that the root domain controller certificate is present in the Trusted Root Certification Authorities tab under the group policy object settings. See Upload Trusted Root Certificate to AD to learn how to view it.

Upload trusted root certificate to AD

In this step, add your StrongDM root certificate as a trusted root certificate in AD. The trusted root certificate is different than the domain controller certificates.

  1. Launch the command prompt as administrator, and upload the trusted root certificate AD domain:
    certutil -dspublish -f ca.crt RootCA
  2. Publish the CA to the NTAuth store:
    certutil -dspublish -f ca.crt NTAuthCA
  3. To force an update of the group policy and certificate stores, use the following command on command prompt. Otherwise, it may take several hours for the policies to update.
    gpupdate.exe /force

Verify CA certificates are imported

  1. To verify that the certificate was uploaded correctly, launch the MMC tool using the shortcut windows key+R. Type mmc, and then hit enter.
  2. Go to File > Add/Remove snap-in…. Add the Enterprise PKI snap-in and click OK.
  3. Right-click on the Enterprise PKI snap-in and select Manage AD Containers.
  4. In Manage AD Containers, click on the tabs to check that the root CA cert for RDP login now exists in the following three certificate stores: NTAuthCertificates, AIA Container, and Certification Authorities Container.

Enable smart card authentication

  1. Open the Group Policy Management Console.
  2. Double-click on the domain policy group policy object. You can use the default domain policy, or you can create your own to apply the correct StrongDM-specific settings, such as Remote Identities.
  3. Click Computer Configuration > Policies > Windows Settings > Security Settings > System Services.
  4. From System Services, click Smart Card > Define This Policy > Automatic.

Disable NLA

If Remote Identities will be used for this resource, Network Level Authentication (NLA) must be disabled on the RDP server.

  1. Open Control Panel and go to System and Security > Allow remote access > Remote.
  2. Ensure that the setting Allow remote connections to this computer is selected.
  3. Ensure that Allow connections only from remote computers running network level authentication (NLA) is not selected.

For more information about Remote Desktop settings and NLA, please see Microsoft documentation.

Add an RDP Certificate-Based Server in the Admin UI

To add a new RDP certificate-based server as a StrongDM resource, follow these steps.

  1. In the Admin UI, go to Infrastructure > Servers.
  2. Click Add server.
  3. Select RDP (Certificate Based) as the Server Type and set other resource properties to configure how the StrongDM relay connects to the server via RDP.
  4. Click Create to save the resource.
  5. Click the resource name to view status, diagnostic information, and setting details. After the server is created, the Admin UI displays that resource as unhealthy until the health checks run successfully. When the resource is ready, the Health icon indicates a positive, green status.

Resource properties

Configuration properties are visible when you add a Server Type or when you click to view the server’s settings. The following table describes the settings available for your RDP (Certificate Based) server.

Display NameRequiredMeaningful name to display the resource throughout StrongDM; exclude special characters like quotes (") or angle brackets (< or >)
Server TypeRequiredSelect RDP (Certificate Based)
HostnameRequiredHostname or IP address to which you are connecting, such as; relay server should be able to connect to your target server or hostname
PortRequiredPort to connect to the resource; default port value 3389
Port OverrideOptionalAutomatically generated with a value between 1024 to 64999 as long as that port is not used by another resource; preferred port can be modified later under Settings > Port Overrides
Certificate AuthorityRequiredWhere the credentials for the server are stored; defaults to Strong CA; to learn more, see Certificate Authority options
AuthenticationRequiredSelect Leased Credentials (default) or Remote Identities
UsernameRequiredDisplays if Authentication is set to Leased Credentials; enter the username the relay should utilize to connect to the server via RDP (for example, bob.belcher)
Healthcheck UsernameRequiredDisplays if Authentication is set to Remote Identities; enter the username that will be utilized to verify StrongDM’s connection to the server; username must exist on the target server
Resource TagsOptionalResource tags consisting of key-value pairs <KEY>=<VALUE> (for example, env=dev)

Certificate Authority options

By default, server credentials are stored in Strong CA. The Strong CA is configured in the Admin UI’s Certificate Authorities page. For more information, please see Certificate Authorities and Strong CA.

If the Enterprise bundle is enabled for your organization, you may use a third-party CA, instead of the default Strong CA, to issue certificates for authentication to your certificate-based SSH resources. A third-party CA is a CA that is issued by a provider outside of StrongDM. For more information, please see Third-Party CA.

CRL Troubleshooting

This section describes ways to resolve potential errors related to the StrongDM certificate revocation list (CRL).

Error - undetermined revocation status

“The revocation status of the smart card certificate used for authentication could not be determined.”


This error message may appear on the login screen when trying to log in, after you have completed all steps to configure the RDP server and the StrongDM resource.

Try the following command on both your domain controller and the Windows machine you are trying to connect to via RDP. This command attempts to ping the CRL that StrongDM hosts. Replace cert.cer with the file path to the StrongDM trusted root CA certificate that you have downloaded on your machine.

certutil -verify -urlfetch cert.cer

Error - unable to check revocation

ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)


If this error is returned in response to the command certutil -verify -urlfetch cert.cer, your domain controller or the RDP server you are trying to connect to cannot access the StrongDM CRL due to your network’s firewall settings.

To fix the issue, allow the URL that the CRL is hosted at to be accessed via your network firewall settings. The URL of the CRL may be found in the output of the command certutil -verify -urlfetch cert.cer. After updating the network settings, run the same command again to check the CRL status and see if the error persists.

Before reattempting the command again, you may need to clear the CRL cache and the Online Certificate Status Protocol (OCSP) on your local machine using certutil -urlcache * delete.

Note that the CRL’s distribution URL needs to be reachable from the domain controller and the target server.