Add an RDP Server With Certificate Auth

Last modified on November 8, 2023


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 StrongDM RDP Certificate

Every organization in StrongDM is automatically assigned a unique root Certificate Authority (CA). The root certificate needs to be added to your environment in order to allow RDP servers to authenticate with trusted certificates. To download the root certificate from the Admin UI, follow these steps.

  1. Log in to the StrongDM Admin UI
  2. Go to Settings > Credential Management.
  3. Under RDP Certificate Authority, click Download RDP root certificate to download the file rdp.cer. The certificate is added to your environment in the next step.
Credential Management > RDP Certificate Authority
Credential Management > RDP Certificate Authority

Add the StrongDM 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 Azure AD and on-premises AD. Follow the instructions for your host.

Azure AD setup

  1. Log in to the Azure portal.
  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.

Azure AD 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. Log in as an administrator to the domain controller of your AD deployment.
  2. Go to Group Policy Management > Forest. Then select your domain name and go to Default Domain Policy.
  3. From Default Domain Policy, select the default domain group policy object. Optionally create a new one to select users that you want to be able to log in using Remote Identities.
  4. Right-click on the group policy object. Then click through this path to import your RDP root certificate: Edit > Policies > Window Settings > Security Settings > Public Key Policies > Trusted Root Certificate Authority.
  5. From Trusted Root Certificate Authority, right-click Trusted Root Certificate Authority and select Import.
  6. Use the certificate import wizard to import the RDP root CA certificate file.
  7. Launch the command prompt as administrator, and upload the trusted root certificate AD domain:
    certutil -dspublish -f ca.crt RootCA
  8. Publish the CA to the NTAuth store:
    certutil -dspublish -f ca.crt NTAuthCA
  9. To force an update of the group policy and certificate stores, use the following commands on command prompt. Otherwise, it may take several hours for the policies to update.
    certutil -pulse
    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.
Add RDP Certificate-Based Server Configuration Properties
Add RDP Certificate-Based Server Configuration Properties
  1. Click Create to save the resource.
  2. 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
Secret StoreOptionalCredential store location; defaults to Strong Vault; to learn more, see Secret Store 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)
Username (path)RequiredPath to the secret in your Secret Store location (for example, path/to/credential?key=optionalKeyName where key argument is optional); required when using a non-StrongDM Secret Store type
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)

Secret Store options

By default, server credentials are stored in StrongDM. However, these credentials can also be saved in a secrets management tool.

Non-StrongDM options appear in the Secret Store dropdown if they are created under Network > Secret Stores. When you select another Secret Store type, its unique properties display. For more details, see Configure Secret Store Integrations.

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.