RDP (Certificate Auth)

Overview

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.

If you do not intend to use certificate authentication, you should see the section for the RDP resource type.

Limitations

For Windows users, StrongDM supports the Microsoft Terminal Services Client (MSTSC) that comes bundled with Windows, but does not fully support the Remote Desktop app on the Windows Store. It is recommended if you are using MSTSC that you use StrongDM CLI 45.88.0 or higher, as a change introduced by the Windows 11 2024 Update caused a temporary incompatibility prior to this CLI version.

Due to a Microsoft update that went into effect in February 2025, a registry setting must be altered for domain controller servers in order for StrongDM users to access RDP resources via certificate authentication. The Key Distribution Center (KDC) REG_DWORD type key StrongCertificateBindingEnforcement must be set to 1. A restart is not required for the registry change to take effect.

A separate Microsoft Windows update for September 10, 2025, however, removes the need to make that registry change. Instead, any StrongDM customer who has an on-premises AD deployment and is on a certain version of the StrongDM CLI will have to configure a Security Identifier (SID) for every user who will authenticate to the RDP server, or risk losing connectivity to the RDP certificate-based resource. SID configuration information is provided in the On-premises AD Setup section of this article.

What this means for you:

If you are on a StrongDM CLI version that does not support the SID configuration (below version 50.4.0), you should continue to use the StrongCertificateBindingEnforcement registry setting as a workaround and should avoid applying the Windows update for September 10, 2025.
If you are on a StrongDM CLI version that supports the SID configuration (version 50.4.0 or higher), and have configured the SIDs, you no longer need the StrongCertificateBindingEnforcement registry setting (and may remove it from existing Windows servers), and are prepared for the Windows update for September 10, 2025.

Prerequisites

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.
The RDP server must be configured to require TLS encryption from connecting clients, rather than RDP native encryption.
The RDP server must have smart card service enabled.
The RDP server must be joined to Active Directory (AD).
The "Always Prompt for Password Upon Connection" option should not be enabled on AD or RDP servers.
Your Active Directory Domain Controller must be allowed to reach the StrongDM control plane on port 443 in order to acquire the Certificate Revocation List.
Smart card sharing must be disabled on the RDP client to allow StrongDM to negotiate the proper authentication.

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 plan 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 Settings > Secrets Management page within the Certificate Authorities tab. 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.

Certificate authorities are managed in the Admin UI only. For more information, please see Certificate Authorities.

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

Log in to the StrongDM Admin UI.
Go to Settings > Secrets Management and to the Certificate Authorities tab and select either StrongDM RDP Certificate Authority or another RDP CA.
From the RDP CA's Settings tab, select one of the certificates shown, or create a new certificate.
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.

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

Log in to the Azure portal or Microsoft Entra admin center.
From Azure Services, select Microsoft Entra ID.
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.
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.
On the Enable and Target tab, enable it. Then under Include and Exclude, set the appropriate user and/or group targets for your organization.
On the Configure tab, under Authentication binding, set Protection Level to single-factor authentication.
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.
Review all the certificate-based authentication settings. The certificate fields may be left as the defaults. When done, acknowledge and save.

See the Microsoft documentation for information on how to configure and test Microsoft Entra CBA.

Configuration is now complete.

On-premises AD setup

The following steps describe how to set up RDP authentication using Identity Aliases 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 Publish Trusted Root Certificate to AD.

First consult Microsoft documentation to install the certification authority.
Check that the Domain Controller 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.

These certificates must not be expired.

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.

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

Launch the command prompt as administrator, and publish the trusted root certificate (the certificate file downloaded from the StrongDM; in this example "rdp.cer") for the AD domain:
```
certutil -dspublish -f rdp.cer RootCA
```
Publish the CA to the NTAuth store:
```
certutil -dspublish -f rdp.cer NTAuthCA
```
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

To verify that the certificate was uploaded correctly, launch the MMC tool using the shortcut windows key+R. Type mmc, and then hit enter.
Go to File > Add/Remove snap-in…. Add the Enterprise PKI snap-in and click OK.
Right-click on the Enterprise PKI snap-in and select Manage AD Containers.
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

Open the Group Policy Management Console.
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 Identity Aliases.

It is optional to create a new domain policy, onto which you can apply StrongDM-specific settings, such as Identity Aliases. If you do create a new one, be sure to apply the policy to the proper scope, including the organizational units or groups that include the users who will use Identity Aliases to log in.

Click Computer Configuration > Policies > Windows Settings > Security Settings > System Services.
From System Services, click Smart Card > Define This Policy > Automatic.

SID configuration

{{< alert context="tip" >}} The information in this section is applicable only for on-premises AD deployments. If you are using Microsoft Entra, this section does not apply to you. {{< /alert >}}

As of a planned Microsoft Windows update for September 10, 2025, StrongDM customers with an on-premises AD deployment must configure their RDP certificate-based resources with a valid Security Identifier (SID) corresponding to the user account(s) used to authenticate with the RDP server, or risk losing connectivity to the resource.

A SID is a unique, immutable identifier for a user in Windows (for example, S-1-5-21-1234567890-1234567890-1234567890-1000).

This section summarizes the important changes and considerations to be aware of for this Microsoft Windows update, including configuration changes that must be made in AD and StrongDM, how to obtain a user's SID in AD, limitations, and troubleshooting help.

Limitations

SID extension support currently only works with the following CAs:

StrongDM version 50.4.0 or higher must be installed on all nodes (gateways, relays, or proxy cluster workers) serving the affected RDP resources. Earlier versions do not support SIDs in the resource configuration.

SID Configuration

This section describes how to explicitly configure each user’s SID in StrongDM’s RDP certificate settings, whether using leased credentials or Identity Aliases.

Before you begin, please ensure that StrongDM version 50.4.0 or higher is installed on all nodes (gateways, relays, or proxy cluster workers) serving the affected RDP resources.

If using EJBCA CA, to enable the use of SIDs in the certificate, a specific configuration action must be taken. When creating your Certificate Profile, under Permissions, you must enable the Allow Extension Override option, and in the Overridable Extension OID list box enter 1.3.6.1.4.1.311.25.2.

Leased credentials

If your RDP certificate-based resources are configured to use leased credentials, you need to get the SID for the specific user that you used to configure the resource. Use the following steps to configure SIDs.

Obtain SIDs from Active Directory. The SID is needed for the leased accounts used in resource configuration. You can manually retrieve these from your AD Domain Controller using the Windows GUI, CLI, or programmatically.
One way to retrieve a user's SID from your AD environment is to run the following in your command line:
```
Get-ADUser -Filter {UserPrincipalName -eq "[email protected]"} | Select-Object Name, SID
```
To get it from the Windows GUI, right-click on the user, click on the Attribute Editor tab, and scroll to objectSid. Copy the SID value.
Then in StrongDM (Admin UI, CLI, SDKs, or Terraform), either edit an existing RDP certificate-based resource or add a new one. In the resource configuration properties, for SID, enter the SID value. It should be in a format similar to S-1-5-21-1234567890-1234567890-1234567890-1000.

Identity Aliases

If your RDP certificate-based resources are configured to use Identity Aliases, you must set the SID explicitly in the Identity Alias of each user, either manually or programmatically through the CLI or API.

When configuring the SID explicitly in the Identity Aliases of each user, you will have to make the following adjustment to each Identity Alias. Instead of specifying only a user principal name (UPN), the Identity Alias also must specify the SID via any of the following formats, where <DOMAIN> is a placeholder for the actual domain and <SID> is a placeholder for the actual SID:

[email protected]:<SID>
user:SID
<DOMAIN>\user:<SID>

SID Troubleshooting

When full enforcement mode is active, and a user's SID is either misconfigured or missing, the user will be met with the login screen error: "Your credentials could not be verified."

To correct this, ensure that the SID is configured for the associated username or Identity Alias, and that the SID matches the current SID of the associated user account in Active Directory (if a user account is deleted and recreated, it will be assigned a new SID).

If the error persists and you still need help, please contact StrongDM at the StrongDM Help Center.

Disable NLA

In order for RDP to work via StrongDM, Network Level Authentication (NLA) must be disabled on the RDP server.

For an on-premises AD deployment, consider using a group policy to disable NLA.

Open Control Panel and go to System and Security > Allow remote access > Remote.
Ensure that the setting Allow remote connections to this computer is selected.
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.

In the Admin UI, go to Resources > Servers.
Click Add server.
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.
Click Create to save the resource.
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.

The healthcheck only checks if the RDP resource is alive. It connects to the server but doesn’t log in. If unable to successfully authenticate, the Admin UI may still show the resource as healthy because it can be reached.

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.

Property

Requirement

Description

Display Name

Required

Meaningful name to display the resource throughout StrongDM; exclude special characters like quotes (") or angle brackets (< or >)

Server Type

Required

Select RDP (Certificate Based)

Proxy Cluster

Required

Defaults to "None (use gateways)"; if using proxy clusters, select the appropriate cluster to proxy traffic to this resource

Hostname

Required

Hostname or IP address to which you are connecting, such as testserver-01.example.org; relay server should be able to connect to your target server or hostname

Port

Optional

Port to connect to the resource; default port value 3389

Connectivity Mode

Required

Select either Virtual Networking Mode, which lets users connect to the resource with a software-defined, IP-based network; or Loopback Mode, which allows users to connect to the resource using the local loopback adapter in their operating system; this field is shown if Virtual Networking Mode enabled for your organization

IP Address

Optional

If Virtual Networking Mode is the selected connectivity mode, an IP address value in the configured Virtual Networking Mode subnet in the organization network settings; if Loopback Mode is the selected connectivity mode, an IP address value in the configured Loopback IP range in the organization network settings (by default, 127.0.0.1); if not specified, an available IP address in the configured IP address space for the selected connectivity mode will be automatically assigned; this field is shown if Virtual Networking Mode and/or multi-loopback mode is enabled for your organization

Port Override

Optional

If Virtual Networking Mode is the selected connectivity mode, a port value between 1 and 65535 that is not already in use by another resource with the same IP address; if Loopback Mode is the selected connectivity mode, a port value between 1024 to 64999 that is not already in use by another resource with the same IP address; when left empty with Virtual Networking Mode, the system assigns the default port to this resource; when left empty for Loopback Mode, an available port that is not already in use by another resource is assigned; preferred port also can be modified later from the Port Overrides settings

DNS

Optional

If Virtual Networking Mode is the selected connectivity mode, a unique hostname alias for this resource; when set, causes the desktop app to display this resource's human-readable DNS name (for example, k8s.my-organization-name) instead of the bind address that includes IP address and port (for example, 100.64.100.100:5432)

Certificate Authority

Required

Where the credentials for the server are stored; defaults to Strong CA; to learn more, see Certificate Authority options

Authentication

Required

Select Leased Credentials (default) or Identity Aliases

Username

Required

Displays if Authentication is set to Leased Credentials; enter the username the relay should utilize to connect to the server via RDP; must be an AD account and not just a local user account, and be written in a valid AD format (such as <DOMAIN>\alice or alice@<DOMAIN>); must be 20 characters or less due to pre-2000 Windows constraints

SID

Optional

Windows Security Identifier (SID) of the configured username, a unique, immutable identifier for a user in Windows (for example, S-1-5-21-1234567890-1234567890-1234567890-1000); required for strong certificate mapping in full enforcement mode; this property is shown when Leased Credentials is the selected authentication type

Identity Set

Required

Displays if Authentication is set to Identity Aliases; select an Identity Set name from the list

Healthcheck Username

Required

Displays if Authentication is set to Identity Aliases; enter the username that will be utilized to verify StrongDM's connection to the server; username must exist on the target server

Resource Lock Required

Required

Enables a resource lock which can lock access the resource to ensure it can only be used by one user at a time; defaults to disabled

Resource Tags

Optional

Resource 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 tab of the Settings > Secrets Management page. For more information, please see Certificate Authorities and Strong CA.

If the Enterprise plan 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.

Configure Identity Aliases

When adding an Identity Alias to a user for use with an RDP (Certificate Based) resource, ensure that the Identity Alias used is an AD account and not just a local user account. The Identity Alias also must be written in a valid AD format.

For on-premises AD deployments, the Identity Alias also must specify the SID value.

The SID can be specified via any of the following formats, where <DOMAIN> is a placeholder for the actual domain and <SID> is a placeholder for the actual SID:

[email protected]:<SID>
user:<SID>
<DOMAIN>\user:<SID>

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

Solution

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)

Solution

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.

Additional Troubleshooting

If you experience other errors after the full setup is done, try doing the following.

On the RDP server/resource, run the following two commands. They should have the Domain Controller root certificate in the NTAuth and Root stores to build the trust chain successfully:
```
certutil -viewstore -ent NTAuth
certutil -viewstore -ent Root
```
Check that the Domain Controller has the StrongDM CA certificate in the NTAuth and Root stores by running the same commands on the Domain Controller itself:
```
certutil -viewstore -ent NTAuth  
certutil -viewstore -ent Root  
```
In order to use certificate-based auth, the user has to exist in AD and not be a local user. Check that the Identity Alias name in StrongDM is a valid AD-formatted name (such as <DOMAIN>\alice or alice@<DOMAIN>) and not the username alone (such as alice).
Check that the Domain Controller is allowed to reach the StrongDM control plane on port 443 in order to acquire the Certificate Revocation List.
If there are multiple Domain Controllers, check that they are all in sync, with the same group policies and certificates installed.
Check that the RDP client itself has the smart card setting disabled (if available), as it can redirect the logon to a physical smart card and bypass StrongDM.
Ensure that the user is not part of the "Protected Users" group in AD. Additionally, if the user is not a Domain Admin, they should also be added to the Remote Desktop Users group, or be part of a group that has Remote Desktop Users in its membership.
If the connection is still failing and all of the previous items are configured correctly, open EventViewer on the RDP server and navigate to Applications and Services Logs/Microsoft/Windows/CAPI2. If the CAPI2 log is empty, right-click it and enable the logging. Then retest the connection again. It should capture some more verbose errors on why the authentication is failing.

Last updated 5 days ago

Was this helpful?