Active Directory Certificate Services CA Integration for RDP
Last modified on July 3, 2025
- Prerequisites
- AD CS Configuration Considerations
- NDES Configuration Considerations
- Add Active Directory Certificate Services CA in the Admin UI
- Configure the StrongDM Node
- Add the Active Directory Certificate Services CA to a Certificate-Based RDP Server
- Manage the CA
- Additional Information
- Add Active Directory Certificate Services CA in the CLI
On this page
- Prerequisites
- AD CS Configuration Considerations
- NDES Configuration Considerations
- Add Active Directory Certificate Services CA in the Admin UI
- Configure the StrongDM Node
- Add the Active Directory Certificate Services CA to a Certificate-Based RDP Server
- Manage the CA
- Additional Information
- Add Active Directory Certificate Services CA in the CLI
This feature is part of the Enterprise plan. If it is not enabled for your organization, please contact StrongDM at the StrongDM Help Center.
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
andSDM_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:
- Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\MSCEP.
- Set the values for all the keys to the name of the template that has been created in the CA.
- 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.
- From the Settings > Secrets Management page in the Certificate Authorities tab, click Add certificate authority.
- Enter the Name for the CA (any name).
- For Type, select Active Directory Certificate Services.
- For Server, enter the address where the CA is stored (for example,
https://ad.example.com:1234
). - 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
- If you have not already done so, follow the instructions to add an RDP server with certificate authentication.
- On the resource form, pay particular attention to Certificate Authority. For this field, select the newly added AD CS CA.
- Complete all required fields and save.
- 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.
API Account example-terraform-key (cc1e23eb-e456-7891-23c4-edf5678c9123) created a secret store named example-tf-rdp-ca
.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: