Active Directory Certificate Services CA Integration for RDP

Last modified on July 3, 2025

This guide provides general information on how to add an Active Directory Certificate Services (AD CS) certificate authority (CA) as a third-party CA to StrongDM. This CA integration allows certificate-based RDP resources to authenticate with X.509 certificates issued by AD CS, through the Network Device Enrollment Service (NDES) instead of the default Strong CA managed by StrongDM.

Prerequisites

Before you begin, ensure that you have the following.

  • Administrator permission level in StrongDM
  • StrongDM relay or gateway ready to run
  • Configured AD Domain Services
  • Configured AD Certificate Services (AD CS)
  • An NDES Server (can be shared with the CA, though it is strongly recommended to deploy a separate one if NDES is already being used in the organization) with a service account
  • Username and password for the account that will be requesting a challenge password from ADCS/NDES (that is, not the account that the user uses to log in with using RDP), set as environment variables SDM_ADCS_USER and SDM_ADCS_PW on the StrongDM relay or gateway
  • StrongDM gateway or relay must trust the CA; generic examples are in this guide, but consult your distribution documentation for details
  • Domain Controller and KDC must have valid certificates
  • Hostname of the server running ADCS/NDES (server must be accessible by the StrongDM relay or gateway)

AD CS Configuration Considerations

This section briefly describes some limitations of AD CS to consider when integrating with StrongDM.

Certificate lifetime minimum

There is a certificate lifetime minimum of 1 hour for certificates in AD CS. If you need certificates to last minutes, not hours, you must use a different certificate authority service.

Challenge password cache

During the process of requesting a certificate, a challenge password needs to be generated. By default, AD CS allows five unredeemed challenge passwords to be active at any given time and will not issue more challenge passwords until they expire.

There is a setting in AD/registry that lets you increase the password cache limit on the NDES server. Consider increasing it if you have several gateways or relays, multiple users, and/or a high number of resources. Not doing so could cause some initial connections to fail.

Certificate signing requests

How does certificate signing work? StrongDM generates a key pair on the gateway or relay and generates a Certificate Signing Request (CSR) signed by the private key. The CSR is submitted to AD CS for signing. The resulting signed certificate is then used, along with the private key, to authenticate to the target resource. The private key never leaves the gateway or relay where it was created.

The template used for issuing the certificate must support:

  • Supplying the subject name in the request
  • Application policies must include “Smart Card Logon” and “Client Authentication”
  • Key usage must include “Digital signature”, “Allow key exchange only with key encryption”, and “Critical extension”

Generally, making a copy of the existing Smartcard Logon template and modifying it to allow supplying the subject name in the request meets these requirements. They are listed here in case the template was modified from the Windows Server defaults.

Permissions

Within the chosen CA, the service account used by NDES must have permissions to “Request Certificates”, though this might be already allowed as the default Windows Server configuration allows authenticated users to do so.

In the specific template, the service account used by NDES must have “Read” and “Enroll” permissions.

NDES Configuration Considerations

The SCEP implementation in NDES does not allow you to provide a specific certificate template in the request. The default must be set in the registry of the system configured with the NDES role:

  1. Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\MSCEP.
  2. Set the values for all the keys to the name of the template that has been created in the CA.
  3. Restart IIS or issue the iisreset command in a shell.

In some cases, you may experience issues with the default configuration of IIS, particularly when using “Classic” Managed Pipeline mode in the SCEP Application pool. Those issues can sometimes be solved by switching to “Integrated” mode.

Add Active Directory Certificate Services CA in the Admin UI

To add an AD CS CA in the Admin UI, follow these steps.

  1. From the Settings > Secrets Management page in the Certificate Authorities tab, click Add certificate authority.
  2. Enter the Name for the CA (any name).
  3. For Type, select Active Directory Certificate Services.
  4. For Server, enter the address where the CA is stored (for example, https://ad.example.com:1234).
  5. Click Create certificate authority.

Configure the StrongDM Node

Only nodes (gateways or relays) that have network access to the NDES server and the appropriate credentials will be able to handle authentication workflows. Ensure that the StrongDM Gateway or Relay trusts the CA by importing the full chain certificate:

  • In Ubuntu/Debian systems, copy the certificate to /usr/local/share/ca-certificates and issue the command update-ca-certificates as root.
  • In RedHat/Fedora systems, copy the certificate to /etc/pki/ca-trust/source/whitelist and issue the command update-ca-trust as root.

Then, modify the /etc/sysconfig/sdm-proxy file with the appropriate credentials for your user, using the SDM_ADCS_USER and SDM_ADCS_PW variables.

Add the Active Directory Certificate Services CA to a Certificate-Based RDP Server

  1. If you have not already done so, follow the instructions to add an RDP server with certificate authentication.
  2. On the resource form, pay particular attention to Certificate Authority. For this field, select the newly added AD CS CA.
  3. Complete all required fields and save.
  4. Test the connection to the resource (for example, use Remote Desktop to connect).

Manage the CA

After you have added the CA and set a certificate-based server to use it, you may manage the CA and review its settings on the Certificate Authorities tab of the Settings > Secrets Management page in the Admin UI. You may select the CA from the list or click its Details button to view diagnostics, update its settings, or delete the CA configuration.

The Diagnostics tab shows all the nodes (gateways and relays) that are configured to access the CA, as well as health information for the nodes.

If the CA is unable to be accessed by any gateway or relay, please review the CA’s Settings tab and make sure the CA credentials are correct.

Additional Information

Third-party CAs also may be added and managed in the CLI, SDKs, and Terraform. Note that third-party CAs are treated like secret stores in the CLI, SDKs, and Terraform. As such, they use secret store commands, domain objects, and resources.

Add Active Directory Certificate Services CA in the CLI

To add an AD CS CA in the CLI instead of the Admin UI, use the sdm admin secretstores create CLI command. Choose the activeDirectory secret store type and set the correct options/properties.

The activeDirectory secret store type corresponds to the Active Directory Certificate Services CA type. In the CLI, the options are the same as the Active Directory Certificate Services CA properties set in the Admin UI.

CLI example

# Create AD CS CA
sdm admin secretstores create activeDirectory
--name="Example AD CS CA"
--server-address="https://ad.example.com:1234"

# Create RDP (Certificate Based) server
sdm admin servers create rdp-cert
--name="Example RDP AD"
--hostname="https://ad.example.com:1234"
--secret-store-id="se-e1b2"
--username="username"

# Run secret store healthcheck
sdm admin secretstores healthcheck se-e1b2

# Check that the secret store is reachable
sdm admin secretstores status

# Check the connection to the resource
sdm connect "Example RDP AD CS"

Add AD CS CA in Terraform

In addition to using the Admin UI and CLI, you may use Terraform to add an AD CS CA for use with certificate-based RDP servers. This section includes a Terraform example.

For additional information, see our Terraform provider documentation.

Terraform example

# Install StrongDM provider
terraform {
  required_providers {
    sdm = {
      source  = "strongdm/sdm"
      version = "7.1.1"
    }
  }
}

# Configure StrongDM provider
provider "sdm" {
    # Add API access key and secret key from Admin UI
    api_access_key = "njjSn...5hM"
    api_secret_key = "ziG...="
}

variable "prefix" {
  type = string
  default = "example-tf-"
}

# Create AD CS RDP CA
resource "sdm_secret_store" "example-tf-rdp-ca" {
  ad_token_cert_x509 {
    name = "${var.prefix}rdp-ca"
    server_address = "https://ad.example.com:1234"
  }
}

# Create RDP (Certificate Based) server
resource "sdm_resource" "example-rdp-cert-based" {
  rdp {
    name = "${var.prefix}rdp-adcs-ca"
    hostname = "https://ad.example.com:1234"
    secret_store_id = sdm_secret_store.example-tf-rdp-ca.id
    username = "username"
  }
}

Add AD CS CA with the SDKs

To add an AD CS CA with the StrongDM SDKs, please see the SDKs on GitHub:

Top