In a previous blog on Object
Identifiers (OID) in PKI
, I mentioned creating a certificate template for Remote
Desktop Connection (RDP).  In this blog,
I will show how to create the template, why the OID and extensions are
important, and how to implement it and remove self-signed certificate warnings
from RDP connections. 

Important Note

Prior to Windows Server 2012, a bug existed where using the template Display Name in the GPO (below), would trigger an enrollment, however the policy would not honor it. At each subsequent GPO refresh the process was repeated resulting in huge numbers of RDP certificates being issued. Pay close attention to this if there are server OS(s) below Windows Server 2012 in your environment and use template name or OID when specifying the RDP template.  A best practice I always follow is no spaces in template names and setting template name and template display name to match when possible.

Why Issue RDP Certificates?

There are multiple reasons to issue RDP certificates from a PKI. The most noticeable is the warning displayed when making an RDP connection to a server or client. Upon the first RDP connection, servers and clients generate a self-signed certificate, which are not trusted so the warning is displayed.

The identity of the remote computer cannot be verified. Do you want to connect anyway?

Clicking Yes, to connect sets a bad precedent, especially when checking the box to not be notified again. In servers and clients prior to Windows 8.1 and Server 2012R2, the self-signed certificates were issued based on a SHA1, until an update when they started issuing SHA2 based self-signed.

After following these steps, clients and servers the GPO is
applied to will no longer generate the self-signed certificates and will use
the trusted certificate issued from your PKI to secure the connection.

Current Policies & Corresponding OIDs

To view the policies and OID list, open the certificate templates console (certtmpl.msc), then right click on the console root at the top left and select “View Object Identifiers...

OID(s) that start with 1.3.6.1.4.1.311 are Microsoft based policies

The highlighted policy above is Microsoft’s OID designation
for Remote Desktop Authentication (1.3.6.1.4.1.311.54.1.2) but isn’t present by
default and must be created.

Creating Remote
Desktop Authentication Policy

To create the policy, open certificate templates console (certtmpl.msc)
then right click on the default Computer template and duplicate template. Highlight
the Extensions tab and select Application Polices and click Edit.
 Select Client and Server Authentication
polices and Remove. Now click Add and the Add Application Policy
box opens; select New and in the New Application Policy dialog box enter
“Remote Desktop Authentication” in the Name field and 1.3.6.1.4.1.311.54.1.2
in the Object Identifier field (delete the default value in the box) then OK
out. On the Security tab set Read and Enroll for targeted servers or
groups. On the General tab, set the Template
display name
and Template name to
match exactly with no spaces. (Example: NewRDPTemplate)

Utilizing the New Certificate Template

Publish the new RDP template to a certificate authority.  For servers to automatically enroll and stop generating and using self-signed certificates a GPO must be configured. The GPO settings are located under:  Computer Configuration, Policies, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Security, Server Authentication certificate template. Update the policy with the template name or OID of the RDP certificate template and select the enable radio button then OK. When the GPO refresh applies to targeted servers they will enroll for the new certificate and use it for RDP connections.

Configuration of GPO using Template Name
Template Name Example
Configuration of GPO using OID
OID Example

When setting the Certificate Template Name for RDP template in the GPO, rather than using the template name, the templates OID may also be used. The OID is shown under the Extension tab in the Certificate Template Information or via Certutil: Certutil -adtemplate -v “<template name>”.

Jake Grandlienard

About Jake Grandlienard

Jacob Grandlienard brings more than 19 years of industry experience as a senior level engineer. He has spent the past 10 years designing, leading, and training clients in Public Key Infrastructure (PKI) implementations for medium to enterprise-scale Fortune 500 companies. He specializes in PKI implementations of Microsoft-based identity solutions, including Microsoft Active Directory Certificate Services (ADCS) as well as integration with other security and identity management technologies. Jacob is a subject matter expert in PKI, mobile device management software, smart card management software, and Hardware Security Module (HSM) integration.

5 Comments

  1. Avatar Michael Keane on March 27, 2020 at 10:56 am

    Very good article. I have my environment configured in the same way, however, we encounter a small problem with this setup.

    For some of our servers that reside deeper in our data centers, they have two NIC’s configured. One for the Public side of the Network and one for the Private (Admin) side of the Network. Since these servers technically have two DNS entries for the differing Networks, we find an issue in where the RDP Cert which is issued on the Public side of the network does not include the Private (Admin) DNS entry in the RDP Cert, so we end up getting the RDP Cert Warning when accessing the server on the Private (Admin) Network. Is there a way to include an additional SAN entry for the Private (Admin) Network DNS entry upon RDP Cert Issuance so that the RDP Cert gets both DNS entries for the server which include the Public and Private (Admin) DNS entries?

    • Jake Grandlienard Jake Grandlienard on April 27, 2020 at 1:05 pm

      Hi Michael,
      Thank you for your question and apologies for the delay in my response. The problem you mention you are seeing with your servers RDP certificates is like those I see with other clients custom Domain controller or Webserver certificates. The option of building the subject from AD is not able to get everything needed into the certificate. In these cases, the only option is to have a separate template that allows a subject supplied in request. The custom names and SAN(s) from both private and public NIC(s) can be added. We would also want to make sure the template is configured to Use subject information from existing certificates for auto-enrollment renewal request. (Available after compatibility for recipients of Windows 7 / Server 2008R2 or later) Lastly, we need to make sure the designated servers have both enroll and auto-enroll configured, so the renewals are automated.
      Thank you again from the question, and I will do a better job of responding quicker in the future.
      Jake

  2. Avatar Nick D. on June 8, 2020 at 6:17 pm

    Hi Jake, excellent article. I’ve bumped up against the issue with multiple RDP certs being issued on every gpupdate. All servers are 2012R2, 2016, 2019, with all Windows 10 1809/1909 clients. The ADCA is running on Server 2019. DFL/FFL is at 2012R2 level. I’ve attempted several iterations of creating new templates, naming template name and template displayname the same, no spaces. Also tried using the template name in my gpo as well as the oid. Any ideas on where else this repeat gpupdate enrollment is triggering from?

    thanks

    • Jake Grandlienard Jake Grandlienard on June 9, 2020 at 8:30 am

      Hi Nick,

      Sorry to hear you are having problems. The multiple certificates bug was present in older version of Windows Server, but I have not seen or heard of it in anything later like you have in your environment. Can you verify the permission on the template you have configured in the GPO? The certificate listed (by template name or OID) only needs Read and Enroll permissions for the intended systems, not auto enroll. If auto enroll is granted it may be causing the duplication issues. If that isn’t the case, please reply back and let me know.

      Thank you,
      Jake

      • Avatar Nick D. on June 9, 2020 at 6:08 pm

        Thanks for the quick response! I resolved the issue. Sadly I made multiple changes in one shot so I’m not sure which was of my goofs were causing this behavior. First thing, my original template did have autoenroll enabled. Then during testing I set validity time to 6 hrs with 2 hr renewal window to test autorenewal and cleanup of expired/revoked certs. I then had issues so I simply deleted the template, re-sync’ed AD, then created a new template but used the *same* template name as the deleted template and set autorenew off with the same expiry/renewal time as the deleted template. Even though I followed your instructions on that second template I continued to have the multiple enrollments. Finally, after seeing your post and a bit more digging and failures, I followed your original instructions again, this time with a new template name, no autoenroll, and much higher expiry/renewal periods. I also set compatibility to cert server 2016, clients Win8/2012R2, and crypto ECDH_P256. That worked! no more multiple enrollments. Thanks for the major assist!

Leave a Comment





This site uses Akismet to reduce spam. Learn how your comment data is processed.