# 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](https://docs.strongdm.com/admin/resources/servers/rdp) resource type. ## Limitations * For Windows users, StrongDM supports the Microsoft Remote Desktop Connection client (MSTSC) that comes bundled with Windows, but may not fully support other RDP clients such as the Remote Desktop app on the Windows Store. Clients on Windows 11 version 24H2 must be on a build version of 26100.3323 (February 25, 2025) or higher, due to a temporary incompatibility between MSTSC and StrongDM in prior build versions that was fixed in a Microsoft update. {% hint style="warning" %} Due to a [Microsoft update](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16) 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 9, 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](#on-premises-a-d-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 9, 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 9, 2025. {% endhint %} ## 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 `. If your gateway or relay can connect to this hostname, you can continue. For more information see [nodes](https://docs.strongdm.com/admin/networking/gateways-and-relays). * 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, if using the Strong CA. If using a third-party CA, the domain controller instead must be able to reach the CRL endpoint of the third-party CA. * To use NLA, you must be working with an on-premises AD environment, not an Entra ID one. Additionally, your StrongDM nodes (gateways, relays, and proxy workers) must be running CLI version 51.85.0 or greater if you are using Strong CA, or 52.16.0 if you are using a third-party CA. See the [NLA section](#id-6.-configure-or-disable-nla) for more details. * For organizations with nodes that are running CLI versions earlier than 52.39.0, smart card sharing must be disabled on RDP clients to allow StrongDM to negotiate the proper authentication. If you are using LDAP to retrieve SIDs for Identity Aliases, the following additional prerequisites are required: * LDAPS must be enabled in the domain controllers. * StrongDM nodes (gateways, relays, or proxy workers) must have network connectivity to the domain controllers on the LDAPS port (636). * A service account must be created. ## 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. {% hint style="info" %} Certificate authorities are managed in the Admin UI only. For more information, please see [Certificate Authorities](https://docs.strongdm.com/admin/access/certificate-authorities). {% endhint %} To download a root certificate from the Admin UI, follow these steps. 1. Log in to the StrongDM Admin UI. 2. Go to **Settings** > **Secrets Management** and to the **Certificate Authorities** tab 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. ## 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)](#microsoft-entra-id-setup) and [on-premises AD](#on-premises-ad-setup). 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. {% hint style="info" %} See the [Microsoft documentation](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-certificate-based-authentication#steps-to-configure-and-test-microsoft-entra-cba) for information on how to configure and test Microsoft Entra CBA. {% endhint %} Configuration is now complete. ## On-premises AD setup The following steps describe how to set up RDP authentication using certificates 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). ### **1. 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](#publish-trusted-root-certificate-to-ad). 1. First consult [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/install-the-certification-authority) to install the certification authority. 2. Check that the Domain Controller certificates are populated in the correct certificate stores. The names of these certificates are typically in the format `-auth`, `-email`, and `-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**. {% hint style="warning" %} These certificates must not be expired. {% endhint %} 3. Ensure there is a root certificate in the format `--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](#verify-ca-certificates-are-imported) to learn how to view the certificate stores using MMC. ### **2. 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. 1. 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: ```powershell certutil -dspublish -f rdp.cer RootCA ``` 2. Publish the CA to the NTAuth store: ```powershell certutil -dspublish -f rdp.cer 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. ```powershell gpupdate.exe /force ``` ### **3. 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**. ### **4. 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 Identity Aliases. {% hint style="info" %} 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. {% endhint %} 3. Click **Computer Configuration** > **Policies** > **Windows Settings** > **Security Settings** > **System Services**. 4. From **System Services**, click **Smart Card** > **Define This Policy** > **Automatic**. ### **5. Configure SIDs** {% hint style="info" %} 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. {% endhint %} As of a planned Microsoft Windows update for September 9, 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: * [Strong CA](https://docs.strongdm.com/admin/access/certificate-authorities/strong-ca) * [ADCS third-party CA integration](https://docs.strongdm.com/admin/access/certificate-authorities/adcs-ca) * [AWS third-party CA integration](https://docs.strongdm.com/admin/access/certificate-authorities/aws-ca-rdp) * [EJBCA third-party CA integration](https://docs.strongdm.com/admin/access/certificate-authorities/ejbca-ca-rdp) * [GCP third party CA integration](https://docs.strongdm.com/admin/access/certificate-authorities/gcp-ca) * [HashiCorp Vault third-party CA integration](https://docs.strongdm.com/admin/access/certificate-authorities/vault-ca-rdp) 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. #### **Explicit 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. Choose the appropriate tab in the following section for explicit SID configuration instructions for either 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. {% tabs %} {% tab title="Leased Credentials" %} **Leased Credentials** If your RDP certificate-based resource is 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. 1. 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. Ensure that you replace the example user with the actual user you used to configure the resource. ```powershell Get-ADUser -Filter {UserPrincipalName -eq "example-user@example.com"} | 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. 2. 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](#resource-properties), for **SID**, enter the SID value. It should be in a format similar to `S-1-5-21-1234567890-1234567890-1234567890-1000`. {% endtab %} {% tab title="Identity Aliases" %} **Identity Aliases** If your RDP certificate-based resources are configured to use Identity Aliases, you can choose one of the following approaches to take: * Set the SID explicitly in the Identity Alias of each user, either manually or programmatically through the CLI, API, or through SCIM. * Omit the SID from the Identity Aliases and instead configure the RDP resource to communicate with one or more of the AD DCs at authentication time to look up each user's SID, using secure LDAP (LDAPS) with a configured service account. {% hint style="info" %} LDAP lookup of SIDs is supported with both the StrongDM RDP Certificate Authority and all supported third-party RDP Certificate Authorities but requires StrongDM CLI version 50.66.0 or higher to be installed on the nodes. {% endhint %} **Configure SIDs explicitly for Identity Aliases** 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 `` is a placeholder for the actual domain and `` is a placeholder for the actual SID: * `user@domain.com:` * `user:SID` * `\user:` **Configure LDAP lookup of SIDs for Identity Aliases** To configure LDAP lookup of user SIDs, the following configuration is required: * The Identity Aliases configuration should not include SIDs (if any alias includes an SID, that SID will be used instead of looking one up). * A service account user must be created in the Active Directory domain. * Security policies in the AD domain must permit that service account the ability to log in from the network, but should not permit interactive login. * Secure LDAP (LDAPS) must be enabled on the AD DCs. * The StrongDM nodes through which the RDP resource will be accessed must be able to reach the configured AD DCs on port 636 (LDAPS). * StrongDM CLI version 50.66.0 or higher must be installed on the nodes. * The StrongDM RDP Certificate resource must be configured with the name of the service account (in any of the supported formats `user@domain`, `DOMAIN\user`, or `user`), the AD SID of that account, and a list of DC hostnames. Please see the [RDP Certificate-Based Server resource properties](#resource-properties) section of this article for resource configuration information. {% endtab %} {% endtabs %} {% hint style="info" %} 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`. {% endhint %} #### **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](https://help.strongdm.com/hc/en-us). ### 6. Configure or Disable NLA In order for RDP to work via StrongDM, Network Level Authentication (NLA) must be configured as described here. Otherwise, it must be disabled on the RDP server. * Your StrongDM nodes (gateways, relays, and proxy workers) must be running CLI version 51.85.0 or greater if you are using Strong CA, or 52.16.0 if you are using a third-party CA. * The RDP (Certificate Auth) resource must be for an on-premises Active Directory environment. NLA is not supported for Entra ID environments. * The StrongDM nodes that access the resource must have outbound network connectivity to the Kerberos port (TCP/IP port 88) on one or more of the Active Directory domain controllers. This may require adjusting network firewall settings. * Both the **Domain Controller Hostnames** field and the **Server FQDN** field must be configured in the resource. The fields are marked as optional in the Admin UI because they should be left blank in situations where NLA is not going to be used or supported, such as with Entra ID environments. * If you use Identity Aliases, the configured **AD Service Account** for the resource that is used to conduct healthchecks must be permitted logon rights to the target server, including being a member of the "Remote Desktop Users" group, in order for those healthchecks to succeed. #### Disable NLA If your deployment does not meet the prerequisites for NLA support described above, you should disable NLA. {% hint style="info" %} For an on-premises AD deployment, consider using a group policy to disable NLA. {% endhint %} 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](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-allow-access). ## Add the Resource in StrongDM After you have set up your RDP certificate-based server, you can add it as a resource in StrongDM. This section provides instructions for adding the resource in either the StrongDM Admin UI, CLI, Terraform provider, or SDKs. {% tabs %} {% tab title="Admin UI" %} **Set up and Manage With the Admin UI** If using the Admin UI to add the resource to StrongDM, use the following steps. 1. In the Admin UI, Go to **Resources** > **Managed Resources**. 2. Click **Add Resource**. 3. For **Resource Type**, select **RDP (Certificate Based)**. 4. For **Connectivity Mode**, select either **Virtual Networking Mode** or **Loopback Mode** and their related properties. 5. For **Authentication** type, choose either **Leased Credentials** or **Identity Aliases**. Different properties display for each type.\ \ If using **Leased Credentials**: 1. For **Username**, enter the username that the relay should utilize to connect to the server via RDP. Note that this must be an AD account and not just a local user account, and it must be written in a valid AD format (such as `\alice` or `alice@`). The username must be 20 characters or less due to pre-2000 Windows constraints. 2. For **SID**, enter the 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.\ \ ![](https://4180056444-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FF7eka9SH5TT8nJm2ZfWj%2Fuploads%2Fgit-blob-79c70e7f1d4a1daf63e5f884475cc6a9d39e4465%2Frdp-cert-server-authentication-properties-leased.png?alt=media) \ If using **Identity Aliases**: 1. For **Identity Set**, select an Identity Set name from the list. 2. For **AD Service Account**, enter the username of a service account to use for health checks and LDAP SID lookup; note that the username must exist on the target server. This value is only needed for on-premises AD environments; for Entra ID environments, this field is not used, so enter any value. 3. For **AD Service Account SID**, if this is an on-prem Azure AD server, enter the SID of the service account. 4. For **Domain Controller Hostnames**, enter a comma-separated list of the AD DC hostnames to use for LDAP SID lookup.\
{% hint style="info" %} If NLA is not configured, the healthcheck only checks if the RDP resource is alive. It connects to the server but doesn’t log in. It might not work as intended if it is unable to authenticate, even if the Admin UI shows it as healthy because it can be reached. If NLA authentication is configured, any authentication failures will show the resource as unhealthy. {% endhint %} 6. To configure the resource to use NLA: 1. For **Domain Controller Hostnames**, enter a comma-separated list of the AD DC hostnames to use for Kerberos NLA. 2. For **Server FQDN**, enter the fully qualified DNS name of the target Windows server, including the AD domain, such as `server.example.com`. 3. See the Configure or Disable NLA and NLA Troubleshooting sections for more details about NLA support. 7. Set all other required [resource properties](#resource-properties) to configure how the StrongDM node connects to the server via RDP. 8. When you are done, click **Create** to save the resource. Then you may 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. {% hint style="info" %} 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. {% endhint %} {% endtab %} {% tab title="CLI" %} **Set up and Manage With the CLI** This section provides general steps on how to configure and manage the resource using the StrongDM CLI. For more information and examples, please see the [CLI Reference](https://docs.strongdm.com/references/cli) documentation. 1. In your terminal or Command Prompt, log in to StrongDM: ``` sdm login ``` 2. Run `sdm admin servers add rdp-cert --help` to view the help text for the command, which shows you how to use the command and what options (properties) are available. Note which [properties](#resource-properties) are required and collect the values for them. ```shell NAME: sdm admin servers add rdp-cert - create RDP (Certificate Based) server USAGE: sdm admin servers add rdp-cert [command options] OPTIONS: --bind-interface value IP address on which to listen for connections to this resource on clients. Specify "default", "loopback", or "vnm" to automatically allocate an available address from the corresponding IP range configured in the organization. (default: "default") --dc-hostnames value Comma-separated list of Active Directory Domain Controller hostnames. Required in on-premises AD environments for Kerberos Network Level Authentication (NLA), and for LDAPS SID resolution for strong certificate mapping in full enforcement mode when the identity alias does not specify a SID. Unused for Entra ID. --egress-filter value apply filter to select egress nodes e.g. 'field:name tag:key=value ...' --hostname value (required) --identity-alias-healthcheck-username value Username of the AD service account for health checks, and LDAPS SID resolution if necessary. Required for on-premises AD environments, unused for Entra ID. (conditional) --identity-set-id value --identity-set-name value set the identity set by name --lock-required Require a resource lock to access the resource to ensure it can only be used by one user at a time. --port value (default: 3389) --port-override value Port on which to listen for connections to this resource on clients. Specify "-1" to automatically allocate an available port. (default: -1) --proxy-cluster-id value proxy cluster id --secret-store-id value secret store id --server-fqdn value Fully-qualified DNS name of the target Windows server, including the AD domain. Must match the Service Principal Name (SPN) of the server in AD. Required in on-premises AD environments for Kerberos Network Level Authentication (NLA), unused for Entra ID. --sid value Windows Security Identifier (SID) of the configured Username, or AD service account if using LDAPS SID resolution. Required in on-premises AD environments for strong certificate mapping in full enforcement mode, unused for Entra ID. (secret) --subdomain value, --bind-subdomain value DNS subdomain through which this resource may be accessed on clients (e.g. "app-prod" allows the resource to be accessed as "app-prod.."). Only applicable to HTTP-based resources or resources using virtual networking mode. --tags value tags e.g. 'key=value,...' --template, -t display a JSON template --timeout value set time limit for command --username value (conditional, secret) ``` 3. Run `sdm admin servers add rdp-cert ` to add the resource in StrongDM. Set all required properties with their values. For example: ``` sdm admin servers add rdp-cert "win-rdp-cert-prod-01" --hostname "rdp01.acme.internal" --port 3389 --bind-interface "default" --port-override -1 --egress-filter 'field:name tag:env=prod tag:region=us-west' --proxy-cluster-id "plc_0123456789abcdef" --secret-store-id "ss_abcdef0123456789" --identity-set-id "is_1234567890abcdef" --identity-set-name "Windows Cert Identity Set" --identity-alias-healthcheck-username "svc_rdp_health" --username "fallback_local_admin" --sid "S-1-5-21-1234567890-123456789-123456789-500" --lock-required --subdomain "rdp-win01" --tags "env=prod,role=windows,team=infra" --timeout 30 --dc-hostnames "dc1.example.com,dc2.example.com" --server-fqdn "server.example.com" ``` 4. Check that the resource has been added. The output of the following command should show the resource's name: ``` sdm admin resources list ``` {% endtab %} {% tab title="Terraform" %} **Set up and Manage With Terraform** This section provides an example of how to configure and manage the resource using the Terraform provider. For more information and examples, please see the [Terraform provider](https://github.com/strongdm/terraform-provider-sdm) documentation. ``` # Install StrongDM provider terraform { required_providers { sdm = { source = "strongdm/sdm" version = "16.5.0" } } } # Configure StrongDM provider provider "sdm" { # Add API access key and secret key from Admin UI api_access_key = "njjSn...5hM" api_secret_key = "ziG...=" } # Create RDP certificate-based auth server resource "sdm_resource" "win_rdp_cert_prod_01" { rdp_cert { name = "win-rdp-cert-prod-01" # hostname = "rdp01.acme.internal" # --hostname port = 3389 # --port (default 3389) bind_interface = "default" # --bind-interface (default: "default") port_override = -1 # --port-override (-1 = auto-allocate) egress_filter = "field:name tag:env=prod tag:region=us-west" # --egress-filter identity_set_id = "is_1234567890abcdef" # --identity-set-id # identity_set_id = data.sdm_identity_set.win_cert.id # (looked up by name) identity_alias_healthcheck_username = "svc_rdp_health" # --identity-alias-healthcheck-username secret_store_id = "ss_abcdef0123456789" # --secret-store-id subdomain = "rdp-win01" # --subdomain lock_required = true # --lock-required tags = { # --tags env = "prod" role = "windows" team = "infra" } dc_hostnames = "dc1.example.com,dc2.example.com" server_fqdn = "server.example.com" } } ``` {% endtab %} {% tab title="SDKs" %} **Set up and Manage With SDKs** In addition to the Admin UI, CLI, and Terraform, you may configure and manage your resource with any of the following SDK options: Go, Java, Python, and Ruby. Please see the following references for more information and examples. | Language | Reference | GitHub | Examples | | ------------- | ------------------------------------------------------------------------ | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | Go | [pkg.go.dev](https://pkg.go.dev/github.com/strongdm/strongdm-sdk-go/v16) | [strongdm-sdk-go](https://github.com/strongdm/strongdm-sdk-go) | [Go SDK Examples](https://github.com/strongdm/strongdm-sdk-go-examples) | | Java | [javadoc](https://strongdm.github.io/strongdm-sdk-java-docs/) | [strongdm-sdk-java](https://github.com/strongdm/strongdm-sdk-java) | [Java SDK Examples](https://github.com/strongdm/strongdm-sdk-java-examples) | | Python | [pdocs](https://strongdm.github.io/strongdm-sdk-python-docs/) | [strongdm-sdk-python](https://github.com/strongdm/strongdm-sdk-python) | [Python SDK Examples](https://github.com/strongdm/strongdm-sdk-python-examples) | | Ruby | [RubyDoc](https://www.rubydoc.info/gems/strongdm) | [strongdm-sdk-ruby](https://github.com/strongdm/strongdm-sdk-ruby) | [Ruby SDK Examples](https://github.com/strongdm/strongdm-sdk-ruby-examples) | | {% endtab %} | | | | | {% endtabs %} | | | | ### Resource properties The following table describes the settings available for the RDP (Certificate Based) server.
PropertyRequirementDescription
Display NameRequiredMeaningful name to display the resource throughout StrongDM; exclude special characters like quotes (") or angle brackets (< or >)
Server TypeRequiredRDP (Certificate Based)
Proxy ClusterRequiredDefaults to "None (use gateways)"; if using proxy clusters, select the appropriate cluster to proxy traffic to this resource
HostnameRequiredHostname 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
PortOptionalPort to connect to the resource; default port value 3389
Connectivity ModeRequiredSelect 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 AddressOptionalIf 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 OverrideOptionalIf 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
DNSOptionalIf 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 AuthorityRequiredWhere the credentials for the server are stored; defaults to Strong CA; to learn more, see Certificate Authority options
AuthenticationRequiredSelect Leased Credentials (default) or Identity Aliases
UsernameRequiredDisplays 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
SIDOptionalWindows 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 SetRequiredDisplays if Authentication is set to Identity Aliases; select an Identity Set name from the list
AD Service AccountRequiredDisplays if Authentication is set to Identity Aliases; for Entra servers, this field is not used, so enter any value; for on-premises AD servers, this field is required, and should be the username of a service account to use for health checks and LDAP SID lookup; the username must exist on the target server
AD Service Account SIDOptionalDisplays if Authentication is set to Identity Aliases; enter the SID of the account
Domain Controller HostnamesOptionalA comma-separated list of the AD DC hostnames to use for LDAP SID lookup when using Identity Aliases, or Kerberos authentication when using NLA
Server FQDNOptionalThe fully-qualified domain name of the on-premises AD server; required if using NLA
Resource Lock RequiredRequiredEnables 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 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** tab of the **Settings** > **Secrets Management** page. For more information, please see [Certificate Authorities](https://docs.strongdm.com/admin/access/certificate-authorities) and [Strong CA](https://docs.strongdm.com/admin/access/certificate-authorities/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](https://docs.strongdm.com/admin/resources/servers/ssh-certificate-auth) 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](https://docs.strongdm.com/admin/access/certificate-authorities). ### 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](#on-premises-ad-setup). The SID can be specified via any of the following formats, where `` is a placeholder for the actual domain and `` is a placeholder for the actual SID: * `user@domain.com:` * `user:` * `\user:` ## 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. ```powershell 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. ## NLA Troubleshooting * If both the **Domain Controller Hostnames** and **Server FQDN** fields are configured, connections to this resource will automatically perform NLA when the connections are made. Part of this authentication involves connections to the Kerberos service on one of the configured domain controllers. Multiple domain controllers can be listed for load balancing or failover purposes. * If either the \***Domain Controller Hostnames** or **Server FQDN** fields are left blank, NLA will not be performed. Target server must be configured to accept connections without NLA, or the connections will fail. * When NLA is correctly configured, it is also performed during healthchecks, so misconfiguration may be one cause of failed healthchecks. * NLA is not supported for Microsoft Entra ID environments, only for on-premises AD. ## 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: ```powershell 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: ```powershell 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 `\alice` or `alice@`) 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. * If your organization's nodes are running StrongDM CLI versions less than 52.39.0, check that the RDP client itself has the smart card setting disabled (if available), as it can redirect the login to a physical smart card and bypass StrongDM. This behavior is not present in CLI version 52.39.0 and above. * 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.strongdm.com/admin/resources/servers/rdp-certificate-auth.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.