Add an RDP Server With 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.

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 be joined to Active Directory (AD).

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

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

1. Log in to the StrongDM Admin UI.
2. Go to Settings > Credentials 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) and on-premises AD. 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.

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.

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 Publish Trusted Root Certificate to AD to learn how to view it.

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:

   certutil -dspublish -f rdp.cer RootCA
   

2. Publish the CA to the NTAuth store:

   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.

   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 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.
3. Click Computer Configuration > Policies > Windows Settings > Security Settings > System Services.
4. From System Services, click Smart Card > Define This Policy > Automatic.

Disable NLA #

In order for RDP to work via StrongDM, 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 Resources > 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.
4. Click Create to save the resource.
5. 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.

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 > Credentials 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 must also be written in a valid AD format (such as <DOMAIN>\alice or alice@<DOMAIN>) and not the username alone (such as alice).

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