First published on TechNet on Dec 18, 2017

Hello everyone! Tim Beasley, Platforms PFE here again from the gorgeous state of Missouri. Here in the fall, in the Ozark Mountains area the colors of the trees are just amazing! But hey, I'm sure wherever you are it's nice there too. Quick shout out to my buds SR PFE Don Geddes (RDGURU), and PFE Jacob Lavender who provided some additional insight on this article! I am writing this blog post to shed some light on the question of \"How come we keep getting prompted warning messages about certificates when we connect to machines via RDP?\"

First published on TechNet on Dec 18, 2017

Hello everyone!  Tim Beasley, Platforms PFE here again from the gorgeous state of Missouri.  Here in the fall, in the Ozark Mountains area the colors of the trees are just amazing!  But hey, I’m sure wherever you are it’s nice there too.   Quick shout out to my buds SR PFE Don Geddes (RDGURU), and PFE Jacob Lavender who provided some additional insight on this article!

I am writing this blog post to shed some light on the question of “How come we keep getting prompted warning messages about certificates when we connect to machines via RDP?”  A couple of examples you might see when running the Remote Desktop Connection Client (mstsc.exe)…

If you’ve come across this in your environment, don’t fret…as it’s a good security practice to have secure RDP sessions.  There’s also a lot of misguiding information out there on the internet…  Being a PKI guy myself, I thought I’d chime in a bit to help the community. 

The answer to the question?  It depends.

Okay I’m done. 

HA!  If only it was that easy!  You people reading this right now wouldn’t be here if it were that easy, right?

To get started, I’m going to break this topic up into several parts.  I’m also going to assume that whoever is reading this knows a bit of PKI terminology.    

Unless there are security requirements that they must meet, most organizations don’t deploy certificates for systems where they are simply enabling RDP to allow remote connections for administration, or to a client OS like Windows 10.  Kerberos plays a huge role in server authentication so feel free to take advantage of it.  The Kerberos authentication protocol provides a mechanism for authentication — and mutual authentication — between a client and a server, or between one server and another server.  This is the underlying authentication that takes place on a domain without the requirement of certificates.

However, to enable a solution where the user can connect to the apps or desktops that you have published for them from ANY device and from ANYWHERE, then you eventually need to deploy certificates. 

Let’s be clear on one thing:  The warning messages / pop-ups that end users see connecting via RDP are a GOOD THING.  Microsoft wants you to be warned if there’s a potential risk of a compromise.  Sure, it can be perceived as a hassle sometimes, but dog gone it…don’t just click through it without reading what it’s trying to tell you in the first place!  Why not you ask?   Well for one thing, using sniffing tools attackers can successfully extrapolate every single key stroke you type in to an RDP session, including login credentials.  And given that, often customers are typing in domain admin credentials…which means you could have just given an attacker using a Man-in-the-Middle (MTM) attack the keys to the kingdom.  Granted, current versions of the Remote Desktop Client combined with TLS makes those types of attacks much more difficult, but there are still risks to be wary of.

I’m going to go through a few scenarios where the warning messages can be displayed, and then how you can remediate them THE SUPPORTED WAY.   I can’t tell you how many times we’ve seen customers manually change registry settings or other hacks to avoid the warning prompts.  However, what should be done is making sure the remote computers are properly authorized in the first place. 

DO NOT JUST HACK THE REGISTRY TO PREVENT WARNING PROMPTS FROM OCCURRING.  

Read the following sections, or pick which one applies for your situation:

\n
• Scenario 1: Regardless if RDS Role has been deployed, no internal PKI (no ADCS), and you’re experiencing certificate warning prompts when establishing RDP connections.
\n
• Scenario 2: Remote Desktop Services ROLE has NOT been deployed yet, you have an internal MS PKI (ADCS), and you’re experiencing certificate warning prompts when establishing RDP connections.
\n
• Scenario 3: Remote Desktop Services Roles have been deployed, you have ADCS PKI, and you’re experiencing certificate warning prompts when establishing RDP connections.
\n

Scenario 1:  Regardless if RDS Role has been deployed, no internal PKI (no ADCS), and you’re experiencing certificate warning prompts when establishing RDP connections.

I’m going to begin this by saying that I’m only including this scenario because I’ve come across it in the past.  We HIGHLY recommend you have an internal PKI/ADCS deployed in your environment.  Although technically achievable, using self-signed certificates is normally NOT a good thing as it can lead to a never-ending scenario of having to deploy self-signed certs throughout a domain.  Talk about a management overhead nightmare!  Additionally, security risk to your environment is elevated…especially in public sector or government environments.  Needless to say, any security professional would have a field day with this practice an ANY environment.  IT life is much better when you have ADCS or some other PKI solution deployed in an organization.  

A fellow colleague of mine, Jacob Lavender(PFE), wrote a great article on how to remove self-signed RDP certificates…so if you’re wanting the details on how you can accomplish this, check out this link!

Jacob has also written a couple of awesome guides that will come in handy when avoiding this scenario.  The first one is a guide on how to build out an Active Directory Certificate Services (ADCS) lab, and the second link is for building out an RDS Farm in a lab.  Both of course feature the amazing new Windows Server 2016, and they are spot on to help you avoid this first scenario.  Just remember they are guides for LAB environments.

                ADCS - https://gallery.technet.microsoft.com/Windows-Server-2016-Active-165e88d1

                RDS Farm - https://gallery.technet.microsoft.com/Windows-Server-2016-Remote-ffc383fe

Off my soapbox now…back to the topic at hand:

More than likely, you’ve decided to RDP to a machine via IP address.  I don’t know how many users are out there that believe that this method is correct.  Sure, it works…but guess what?  You will always get the warning because you are trying to connect using IP address instead of a name, and a certificate can't be used to authenticate an IP address.  Neither can Kerberos for that matter.  So, RDP asks you to make sure you want to connect since it can't verify that this is really the machine you want to connect to.  Main security reason: Someone could have hijacked it. (This is very easily done with environments that don’t use secure DNS btw…)  

Take a quick second to smack yourself for doing this, and make a mental note to establish RDP sessions using machine names going forward…go on, I’ll wait.  😊  If by simply changing HOW you connect via RDP to machines (names vs IP address) fixes your problem…congrats!  You can stop reading now.  And in case you’re wondering, yes…that’s a supported solution.  *stifles laughter*

However, if RDP using names still produces warning messages then let’s continue.  You’ve launched the RDP client (mstsc.exe) and typed in the name of a machine…hit connect…and pops up a warning regarding a certificate problem.  At this point, typically this is due to the self-signed certificate each server generates for secure RDP connections isn’t trusted by the clients.   Think of a Root CA Certificate and the chain of trust.  Your clients want to use/trust certificates that a CA issues, but they must trust the certificate authority that the certificates come from, right?   RDP is doing the same thing.  The client machine you’re trying to establish the RDP session from doesn’t have the remote machine’s self-signed certificate in the local Trusted Root CA certificate store.  So how do we remedy that? 

Solution for this scenario – Export the remote machine’s certificate (no private key needed) and create a GPO that disperses the self-signed certificate from the remote machine to the local machine.   Import remote machine’s certificate into a new GPO at Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies -> Trusted Root Certification Authorities. 

This will install the machine’s certificate accordingly on the local machine, so the next time you RDP using the remote machine’s name, the warning vanishes.  One little caveat though:  Certificate SAN names for CNAME DNS entries.  If you use CNAME (alias) DNS records in your environment, DO NOT try and connect to a machine using the CNAME entry unless that CNAME exists on the certificate.  The name you’re trying to connect to must exist on the certificate!  Otherwise you’ll get warnings despite the fact the cert is deployed in the local Trusted Root CA store.  Just because it’s trusted doesn’t guarantee warnings are forever gone.  You still must connect using the correct machine names.  

Notice I didn’t say to make any registry changes or click the little “Don’t ask me again for connections to this computer” option?  The idea is to get rid of the warning message the right way…heh.

Scenario 2:  Remote Desktop Services ROLE has NOT been deployed yet, you have an internal MS PKI (ADCS), and you’re experiencing certificate warning prompts when establishing RDP connections.

Okay this scenario is a little like the previous one, except for a few things.  Devil’s in the details! 

First, your domain-joined client should already have a valid chain of trust if ADCS is deployed…so that can’t be the root cause.  But perhaps it’s not a domain-joined client…in that case get the appropriate certificate(s) installed on your local machine to have a valid chain of trust to eliminate that possibility.  Moving on and re-referencing the info in Part 1, quit trying to RDP to an IP address, and make sure you’re connecting to a machine that has a certificate that contains the name you’re trying to establish an RDP session into.  I don’t believe I need to harp on that one any more...

Normally when deploying ADCS, certificate autoenrollment is configured as a good practice.  In this instance, all users and machines can be configured to automatically enroll for a certificate, barring a published template’s permissions are set correctly.  But RDS is a bit different since it can use certificates that not all machines have.  For instance, just because a machine with autoenrollment enabled acquires a computer certificate from an ADCS issuing CA, doesn’t mean RDS will use it automatically.  Remember, by default the local Remote Desktop Protocol will use the self-signed certificate…not one issued by an internal CA…even if it contains all the right information.  If you want to use a certificate other than the default self-signed certificate that RDP creates, you must configure the RDP listener to use the custom certificate…just installing the cert isn’t enough.  If needed, refer to this article for additional info on configuring the RDP listener for WS2012 /2012R2.  Basically, the right certificate with appropriate corresponding GPO settings for RDS to utilize…and that should solve the warning messages.  How do we do that?

Keep in mind the requirements of certificates that RDS uses:

\n
• The certificate is installed in the local computer’s “Personal” certificate store. (not user)
\n
• The certificate has a corresponding private key.
\n
• The Enhanced Key Usage extension has a value of either “Server Authentication” or “Remote Desktop Authentication” (1.3.6.1.4.1.311.54.1.2). You can also use certificates with no Enhanced Key Usage extension.
\n

Now that you have the certificate requirements, you’ll want to create a custom certificate template with the above EKU settings (or none…but I’ve always used Server Auth or RDA).  It’s always best to use a custom certificate template, and not the default ones.  But, I’m not going to completely go off on a PKI best practices rant here…that’s for another day.  (There’s several articles that walk you through this process if you haven’t done so already - here and here).  

Once the template’s created and scoped appropriately via permissions (autoenrollment or whatever) then it’s time for the machine to request the certificate.  Remember, certificates you deploy need to have a subject name (CN) or subject alternate name (SAN) that matches the name of the server that a user is connecting to!  And in this scenario where the RDS Roles aren’t deployed, then the subject name will typically be the machine’s name…configure the certificate template to pull the subject name from AD.   Manual enrollment is a bit time consuming, so I prefer autoenrollment functionality here.

What about computers that don’t have RDS enabled, will they get those certificates too?  Answer:  If autoenrollment is configured and the template is configured to auto-enroll “domain computers” then, Yes.  To mitigate the CA from handing out a ton of certs from multiple templates, just scope the template permissions to a security group that contains the machine(s) you want enrollment from.  I always recommend configure certificate templates use specific security groups.  Where certificates are deployed is all dependent upon what your environment requires.  Just take the time to plan / lab things out before deploying to production…

Next, we configure Group Policy.  This is to ensure that ONLY certificates created by using your custom template will be considered when a certificate to authenticate the RD Session Host Server (or machine) is automatically selected.  Translation: only the cert that came from your custom template will be used when someone connects via RDP to a machine…not the self-signed certificate. 

Create a new GPO at the domain level (or OU...and don’t use the Default Domain Policy…bad practice), then edit it.  Navigate to Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Session Host -> Security.  The option you want to set is “Server Authentication certificate template.”  Simply type in the name of your custom certificate template, and close the policy to save it.   As soon as this policy is propagated to the respective domain computers (or forced via gpupdate.exe), every machine the GPO is scoped to that allows Remote Desktop Connections will use it to authenticate RDP connections. 

Here’s an example:  In my lab, a custom certificate with the Remote Desktop Authentication EKU was installed via autoenrollment.  I then created a GPO called “RDP Certificate” and linked it at the domain level.  I updated group policy on a member server, and tested it.

Proof:  In my lab, I got a warning message since I tried to RDP to an IP .   Image2 shows the OID for the custom EKU of Remote Desktop Authentication.  

Of course, as soon as I try to connect using the correct machine name, it connected right up as expected.  Warning went POOF!

Another way of achieving this result, and forcing machines to use a specific certificate for RDP…is via a simple WMIC command from an elevated prompt, or you can use PowerShell.  The catch is that you must do it from the individual machine.  You will need the thumbprint of the certificate you wish RDP to use, and the cert itself must exist in the machine’s personal store with the appropriate EKU.

CMD:

wmic /namespace:\\\\root\\cimv2\\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=\"THUMBPRINT\"

PowerShell:

$path = (Get-WmiObject -class \"Win32_TSGeneralSetting\" -Namespace root\\cimv2\\terminalservices -Filter \"TerminalName='RDP-tcp'\").__path

Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash=\"THUMBPRINT\"}

Quick, easy, and efficient…and unless you script it out to hit all machines involved, you’ll only impact one at a time instead of using a scoped GPO.

Scenario 3:  Remote Desktop Services Roles have been deployed, you have ADCS PKI, and you’re experiencing certificate warning prompts when establishing RDP connections.

Now we get to the meaty part (as if I haven’t written enough already).  Unlike the above 2 scenarios, you don’t really need special GPO settings to deploy certificates, force RDS to use specific certs, etc.  The roles themselves handle all that.

Let’s say Remote Desktop Services has been fully deployed in your environment.  It can be 2008 R2 RDS, or 2012 / 2012 R2 RDS.  Doesn’t matter…or does it?  Kristin Griffin wrote an excellent TechNet Article detailing how to use certificates and more importantly, why for every RDS role service.  Her article details RDS certificates for Server 2008 R2, GPO settings, etc.  When it comes to WS2012 and WS2012R2 however, it gets easier and a bit less complicated.  Just remember the principals are the same.  Again, we use certificates to maximize security pertaining to Remote Desktop Connections and RDS. 

By default, RD Session Host sessions use native RDP encryption. However, RDP does not provide authentication to verify the identity of an RD Session Host server. You can enhance the security of RD Session Host sessions by using Secure Sockets Layer (SSL) Transport Layer Security (TLS 1.0) for server authentication and to encrypt RD Session Host communications. The RD Session Host server and the client computer must be correctly configured for TLS to provide enhanced security.  (https://technet.microsoft.com/en-us/library/ff458357.aspx)

First thing to check if warnings are occurring, is (yep, you guessed it) …are users connecting to the right name? 

Next, check the certificate(s) that are being used to ensure they contain the proper and accurate information.  Referring to the methods mentioned in the following information is from this TechNet Article:

“In Windows 2008 and Windows 2008 R2, you connect to the farm name, which as per DNS round robin, gets first directed to the redirector, then to the connection broker, and finally to the server that hosts your session.  

In Windows 2012 / 2012R2, you connect to the connection broker, and it then routes you to the collection by using the collection name.

The certificates you deploy need to have a subject name (CN) or subject alternate name (SAN) that matches the name of the server that the user is connecting to.  For example, for Publishing, the certificate needs to contain the names of all the RDSH servers in the collection. The certificate for RDWeb needs to contain the FQDN or the URL, based on the name the users connect to.   If you have users connecting externally, this needs to be an external name (it needs to match what they connect to).  If you have users connecting internally to RDWeb, the name needs to match the internal name.  For Single Sign On, the subject name needs to match the servers in the collection.”

Go and read that article thoroughly.  It talks about proper SAN names to include for external and internal naming for the 2012 / 2012 R2 RDS server roles.  Only the RD Web Access and RD Gateway roles should ever be exposed to the Internet, which means obtaining a certificate for those roles from a Public CA.  

Now that you have created your certificates and understand their contents, you need to configure the Remote Desktop Server roles to use those certificates.  This is the cool part!  For 2012 / 2012R2:

\n
1. On the Connection Broker, open the Server Manager. Click Remote Desktop Services in the left navigation pane.
\n
2. Click Tasks > Edit Deployment Properties.
\n
3. In the Configure the deployment window, click Certificates.
\n
4. Click Select existing certificates, and then browse to the location where you have a saved certificate (generally it’s a .pfx file).
\n
5. Import the certificate.
\n

You can use a single certificate for all the roles if your clients are internal to the domain only, by generating a wildcard certificate (for example: *.CONTOSO.com) and binding it to all roles.  Or you will use multiple certs if you have both internal and external requirements.

Note: even if you have multiple servers in the deployment, Server Manager will import the certificate to all servers, place the certificate in the trusted root for each server, and then bind the certificate to the respective roles.  See!  Told you it was cool!  You don’t have to manually do anything to each individual server in the deployment!  You can of course, but typically not mandatory. 

PRO TIP:  For most scenarios where the client is not domain-joined but connecting via RDP to a machine that IS domain joined you should probably be using an RD Gateway…since in those scenarios the client is coming in externally anyways.

Conclusion:

To recap…DON’T try to establish an RDP connection using an IP address.  DO use the correct naming.   DO use an internal PKI and/or GPOs.  DO use custom templates with proper EKUs.  DO use RDS.  

\n
1. You don't have an internal PKI, then use the self-signed certs...and always connect via server names (assuming the DNS suffix on NIC is good) or FQDN. The other takeaway is just have an internal PKI...
\n
2. If you do have an internal PKI, then replace the self-signed certs using GPO and custom certs for the RDS service to use...and connect using server names or FQDN.
\n
3. DON’T connect via IP (did I mention that before?)
\n

And for all our sanity, do NOT mess with the security level and encryption level settings!  The default settings are the most secure.  Just leave them alone and keep it simple.

Thank you for taking the time to read through all this information.  I tried to think of all the scenarios I personally have come across in my experiences throughout the past 25 years, and I hope I didn’t miss any.  If I did, please feel free to ask!  Happy RDP’ing everyone!

Tim Beasley, Microsoft PFE – Platforms.

First published on TechNet on Dec 18, 2017

Hello everyone!  Tim Beasley, Platforms PFE here again from the gorgeous state of Missouri.  Here in the fall, in the Ozark Mountains area the colors of the trees are just amazing!  But hey, I’m sure wherever you are it’s nice there too.   Quick shout out to my buds SR PFE Don Geddes (RDGURU), and PFE Jacob Lavender who provided some additional insight on this article!

I am writing this blog post to shed some light on the question of “How come we keep getting prompted warning messages about certificates when we connect to machines via RDP?”  A couple of examples you might see when running the Remote Desktop Connection Client (mstsc.exe)…

If you’ve come across this in your environment, don’t fret…as it’s a good security practice to have secure RDP sessions.  There’s also a lot of misguiding information out there on the internet…  Being a PKI guy myself, I thought I’d chime in a bit to help the community. 

The answer to the question?  It depends.

Okay I’m done. 

HA!  If only it was that easy!  You people reading this right now wouldn’t be here if it were that easy, right?

To get started, I’m going to break this topic up into several parts.  I’m also going to assume that whoever is reading this knows a bit of PKI terminology.    

Unless there are security requirements that they must meet, most organizations don’t deploy certificates for systems where they are simply enabling RDP to allow remote connections for administration, or to a client OS like Windows 10.  Kerberos plays a huge role in server authentication so feel free to take advantage of it.  The Kerberos authentication protocol provides a mechanism for authentication — and mutual authentication — between a client and a server, or between one server and another server.  This is the underlying authentication that takes place on a domain without the requirement of certificates.

However, to enable a solution where the user can connect to the apps or desktops that you have published for them from ANY device and from ANYWHERE, then you eventually need to deploy certificates. 

Let’s be clear on one thing:  The warning messages / pop-ups that end users see connecting via RDP are a GOOD THING.  Microsoft wants you to be warned if there’s a potential risk of a compromise.  Sure, it can be perceived as a hassle sometimes, but dog gone it…don’t just click through it without reading what it’s trying to tell you in the first place!  Why not you ask?   Well for one thing, using sniffing tools attackers can successfully extrapolate every single key stroke you type in to an RDP session, including login credentials.  And given that, often customers are typing in domain admin credentials…which means you could have just given an attacker using a Man-in-the-Middle (MTM) attack the keys to the kingdom.  Granted, current versions of the Remote Desktop Client combined with TLS makes those types of attacks much more difficult, but there are still risks to be wary of.

I’m going to go through a few scenarios where the warning messages can be displayed, and then how you can remediate them THE SUPPORTED WAY.   I can’t tell you how many times we’ve seen customers manually change registry settings or other hacks to avoid the warning prompts.  However, what should be done is making sure the remote computers are properly authorized in the first place. 

DO NOT JUST HACK THE REGISTRY TO PREVENT WARNING PROMPTS FROM OCCURRING.  

Read the following sections, or pick which one applies for your situation:

\n
• Scenario 1: Regardless if RDS Role has been deployed, no internal PKI (no ADCS), and you’re experiencing certificate warning prompts when establishing RDP connections.
\n
• Scenario 2: Remote Desktop Services ROLE has NOT been deployed yet, you have an internal MS PKI (ADCS), and you’re experiencing certificate warning prompts when establishing RDP connections.
\n
• Scenario 3: Remote Desktop Services Roles have been deployed, you have ADCS PKI, and you’re experiencing certificate warning prompts when establishing RDP connections.
\n

Scenario 1:  Regardless if RDS Role has been deployed, no internal PKI (no ADCS), and you’re experiencing certificate warning prompts when establishing RDP connections.

I’m going to begin this by saying that I’m only including this scenario because I’ve come across it in the past.  We HIGHLY recommend you have an internal PKI/ADCS deployed in your environment.  Although technically achievable, using self-signed certificates is normally NOT a good thing as it can lead to a never-ending scenario of having to deploy self-signed certs throughout a domain.  Talk about a management overhead nightmare!  Additionally, security risk to your environment is elevated…especially in public sector or government environments.  Needless to say, any security professional would have a field day with this practice an ANY environment.  IT life is much better when you have ADCS or some other PKI solution deployed in an organization.  

A fellow colleague of mine, Jacob Lavender(PFE), wrote a great article on how to remove self-signed RDP certificates…so if you’re wanting the details on how you can accomplish this, check out this link!

Jacob has also written a couple of awesome guides that will come in handy when avoiding this scenario.  The first one is a guide on how to build out an Active Directory Certificate Services (ADCS) lab, and the second link is for building out an RDS Farm in a lab.  Both of course feature the amazing new Windows Server 2016, and they are spot on to help you avoid this first scenario.  Just remember they are guides for LAB environments.

                ADCS - https://gallery.technet.microsoft.com/Windows-Server-2016-Active-165e88d1

                RDS Farm - https://gallery.technet.microsoft.com/Windows-Server-2016-Remote-ffc383fe

Off my soapbox now…back to the topic at hand:

More than likely, you’ve decided to RDP to a machine via IP address.  I don’t know how many users are out there that believe that this method is correct.  Sure, it works…but guess what?  You will always get the warning because you are trying to connect using IP address instead of a name, and a certificate can't be used to authenticate an IP address.  Neither can Kerberos for that matter.  So, RDP asks you to make sure you want to connect since it can't verify that this is really the machine you want to connect to.  Main security reason: Someone could have hijacked it. (This is very easily done with environments that don’t use secure DNS btw…)  

Take a quick second to smack yourself for doing this, and make a mental note to establish RDP sessions using machine names going forward…go on, I’ll wait.  😊  If by simply changing HOW you connect via RDP to machines (names vs IP address) fixes your problem…congrats!  You can stop reading now.  And in case you’re wondering, yes…that’s a supported solution.  *stifles laughter*

However, if RDP using names still produces warning messages then let’s continue.  You’ve launched the RDP client (mstsc.exe) and typed in the name of a machine…hit connect…and pops up a warning regarding a certificate problem.  At this point, typically this is due to the self-signed certificate each server generates for secure RDP connections isn’t trusted by the clients.   Think of a Root CA Certificate and the chain of trust.  Your clients want to use/trust certificates that a CA issues, but they must trust the certificate authority that the certificates come from, right?   RDP is doing the same thing.  The client machine you’re trying to establish the RDP session from doesn’t have the remote machine’s self-signed certificate in the local Trusted Root CA certificate store.  So how do we remedy that? 

Solution for this scenario – Export the remote machine’s certificate (no private key needed) and create a GPO that disperses the self-signed certificate from the remote machine to the local machine.   Import remote machine’s certificate into a new GPO at Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies -> Trusted Root Certification Authorities. 

This will install the machine’s certificate accordingly on the local machine, so the next time you RDP using the remote machine’s name, the warning vanishes.  One little caveat though:  Certificate SAN names for CNAME DNS entries.  If you use CNAME (alias) DNS records in your environment, DO NOT try and connect to a machine using the CNAME entry unless that CNAME exists on the certificate.  The name you’re trying to connect to must exist on the certificate!  Otherwise you’ll get warnings despite the fact the cert is deployed in the local Trusted Root CA store.  Just because it’s trusted doesn’t guarantee warnings are forever gone.  You still must connect using the correct machine names.  

Notice I didn’t say to make any registry changes or click the little “Don’t ask me again for connections to this computer” option?  The idea is to get rid of the warning message the right way…heh.

Scenario 2:  Remote Desktop Services ROLE has NOT been deployed yet, you have an internal MS PKI (ADCS), and you’re experiencing certificate warning prompts when establishing RDP connections.

Okay this scenario is a little like the previous one, except for a few things.  Devil’s in the details! 

First, your domain-joined client should already have a valid chain of trust if ADCS is deployed…so that can’t be the root cause.  But perhaps it’s not a domain-joined client…in that case get the appropriate certificate(s) installed on your local machine to have a valid chain of trust to eliminate that possibility.  Moving on and re-referencing the info in Part 1, quit trying to RDP to an IP address, and make sure you’re connecting to a machine that has a certificate that contains the name you’re trying to establish an RDP session into.  I don’t believe I need to harp on that one any more...

Normally when deploying ADCS, certificate autoenrollment is configured as a good practice.  In this instance, all users and machines can be configured to automatically enroll for a certificate, barring a published template’s permissions are set correctly.  But RDS is a bit different since it can use certificates that not all machines have.  For instance, just because a machine with autoenrollment enabled acquires a computer certificate from an ADCS issuing CA, doesn’t mean RDS will use it automatically.  Remember, by default the local Remote Desktop Protocol will use the self-signed certificate…not one issued by an internal CA…even if it contains all the right information.  If you want to use a certificate other than the default self-signed certificate that RDP creates, you must configure the RDP listener to use the custom certificate…just installing the cert isn’t enough.  If needed, refer to this article for additional info on configuring the RDP listener for WS2012 /2012R2.  Basically, the right certificate with appropriate corresponding GPO settings for RDS to utilize…and that should solve the warning messages.  How do we do that?

Keep in mind the requirements of certificates that RDS uses:

\n
• The certificate is installed in the local computer’s “Personal” certificate store. (not user)
\n
• The certificate has a corresponding private key.
\n
• The Enhanced Key Usage extension has a value of either “Server Authentication” or “Remote Desktop Authentication” (1.3.6.1.4.1.311.54.1.2). You can also use certificates with no Enhanced Key Usage extension.
\n

Now that you have the certificate requirements, you’ll want to create a custom certificate template with the above EKU settings (or none…but I’ve always used Server Auth or RDA).  It’s always best to use a custom certificate template, and not the default ones.  But, I’m not going to completely go off on a PKI best practices rant here…that’s for another day.  (There’s several articles that walk you through this process if you haven’t done so already - here and here).  

Once the template’s created and scoped appropriately via permissions (autoenrollment or whatever) then it’s time for the machine to request the certificate.  Remember, certificates you deploy need to have a subject name (CN) or subject alternate name (SAN) that matches the name of the server that a user is connecting to!  And in this scenario where the RDS Roles aren’t deployed, then the subject name will typically be the machine’s name…configure the certificate template to pull the subject name from AD.   Manual enrollment is a bit time consuming, so I prefer autoenrollment functionality here.

What about computers that don’t have RDS enabled, will they get those certificates too?  Answer:  If autoenrollment is configured and the template is configured to auto-enroll “domain computers” then, Yes.  To mitigate the CA from handing out a ton of certs from multiple templates, just scope the template permissions to a security group that contains the machine(s) you want enrollment from.  I always recommend configure certificate templates use specific security groups.  Where certificates are deployed is all dependent upon what your environment requires.  Just take the time to plan / lab things out before deploying to production…

Next, we configure Group Policy.  This is to ensure that ONLY certificates created by using your custom template will be considered when a certificate to authenticate the RD Session Host Server (or machine) is automatically selected.  Translation: only the cert that came from your custom template will be used when someone connects via RDP to a machine…not the self-signed certificate. 

Create a new GPO at the domain level (or OU...and don’t use the Default Domain Policy…bad practice), then edit it.  Navigate to Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Session Host -> Security.  The option you want to set is “Server Authentication certificate template.”  Simply type in the name of your custom certificate template, and close the policy to save it.   As soon as this policy is propagated to the respective domain computers (or forced via gpupdate.exe), every machine the GPO is scoped to that allows Remote Desktop Connections will use it to authenticate RDP connections. 

Here’s an example:  In my lab, a custom certificate with the Remote Desktop Authentication EKU was installed via autoenrollment.  I then created a GPO called “RDP Certificate” and linked it at the domain level.  I updated group policy on a member server, and tested it.

Proof:  In my lab, I got a warning message since I tried to RDP to an IP .   Image2 shows the OID for the custom EKU of Remote Desktop Authentication.  

Of course, as soon as I try to connect using the correct machine name, it connected right up as expected.  Warning went POOF!

Another way of achieving this result, and forcing machines to use a specific certificate for RDP…is via a simple WMIC command from an elevated prompt, or you can use PowerShell.  The catch is that you must do it from the individual machine.  You will need the thumbprint of the certificate you wish RDP to use, and the cert itself must exist in the machine’s personal store with the appropriate EKU.

CMD:

wmic /namespace:\\\\root\\cimv2\\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=\"THUMBPRINT\"

PowerShell:

$path = (Get-WmiObject -class \"Win32_TSGeneralSetting\" -Namespace root\\cimv2\\terminalservices -Filter \"TerminalName='RDP-tcp'\").__path

Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash=\"THUMBPRINT\"}

Quick, easy, and efficient…and unless you script it out to hit all machines involved, you’ll only impact one at a time instead of using a scoped GPO.

Scenario 3:  Remote Desktop Services Roles have been deployed, you have ADCS PKI, and you’re experiencing certificate warning prompts when establishing RDP connections.

Now we get to the meaty part (as if I haven’t written enough already).  Unlike the above 2 scenarios, you don’t really need special GPO settings to deploy certificates, force RDS to use specific certs, etc.  The roles themselves handle all that.

Let’s say Remote Desktop Services has been fully deployed in your environment.  It can be 2008 R2 RDS, or 2012 / 2012 R2 RDS.  Doesn’t matter…or does it?  Kristin Griffin wrote an excellent TechNet Article detailing how to use certificates and more importantly, why for every RDS role service.  Her article details RDS certificates for Server 2008 R2, GPO settings, etc.  When it comes to WS2012 and WS2012R2 however, it gets easier and a bit less complicated.  Just remember the principals are the same.  Again, we use certificates to maximize security pertaining to Remote Desktop Connections and RDS. 

By default, RD Session Host sessions use native RDP encryption. However, RDP does not provide authentication to verify the identity of an RD Session Host server. You can enhance the security of RD Session Host sessions by using Secure Sockets Layer (SSL) Transport Layer Security (TLS 1.0) for server authentication and to encrypt RD Session Host communications. The RD Session Host server and the client computer must be correctly configured for TLS to provide enhanced security.  (https://technet.microsoft.com/en-us/library/ff458357.aspx)

First thing to check if warnings are occurring, is (yep, you guessed it) …are users connecting to the right name? 

Next, check the certificate(s) that are being used to ensure they contain the proper and accurate information.  Referring to the methods mentioned in the following information is from this TechNet Article:

“In Windows 2008 and Windows 2008 R2, you connect to the farm name, which as per DNS round robin, gets first directed to the redirector, then to the connection broker, and finally to the server that hosts your session.  

In Windows 2012 / 2012R2, you connect to the connection broker, and it then routes you to the collection by using the collection name.

The certificates you deploy need to have a subject name (CN) or subject alternate name (SAN) that matches the name of the server that the user is connecting to.  For example, for Publishing, the certificate needs to contain the names of all the RDSH servers in the collection. The certificate for RDWeb needs to contain the FQDN or the URL, based on the name the users connect to.   If you have users connecting externally, this needs to be an external name (it needs to match what they connect to).  If you have users connecting internally to RDWeb, the name needs to match the internal name.  For Single Sign On, the subject name needs to match the servers in the collection.”

Go and read that article thoroughly.  It talks about proper SAN names to include for external and internal naming for the 2012 / 2012 R2 RDS server roles.  Only the RD Web Access and RD Gateway roles should ever be exposed to the Internet, which means obtaining a certificate for those roles from a Public CA.  

Now that you have created your certificates and understand their contents, you need to configure the Remote Desktop Server roles to use those certificates.  This is the cool part!  For 2012 / 2012R2:

\n
1. On the Connection Broker, open the Server Manager. Click Remote Desktop Services in the left navigation pane.
\n
2. Click Tasks > Edit Deployment Properties.
\n
3. In the Configure the deployment window, click Certificates.
\n
4. Click Select existing certificates, and then browse to the location where you have a saved certificate (generally it’s a .pfx file).
\n
5. Import the certificate.
\n

You can use a single certificate for all the roles if your clients are internal to the domain only, by generating a wildcard certificate (for example: *.CONTOSO.com) and binding it to all roles.  Or you will use multiple certs if you have both internal and external requirements.

Note: even if you have multiple servers in the deployment, Server Manager will import the certificate to all servers, place the certificate in the trusted root for each server, and then bind the certificate to the respective roles.  See!  Told you it was cool!  You don’t have to manually do anything to each individual server in the deployment!  You can of course, but typically not mandatory. 

PRO TIP:  For most scenarios where the client is not domain-joined but connecting via RDP to a machine that IS domain joined you should probably be using an RD Gateway…since in those scenarios the client is coming in externally anyways.

Conclusion:

To recap…DON’T try to establish an RDP connection using an IP address.  DO use the correct naming.   DO use an internal PKI and/or GPOs.  DO use custom templates with proper EKUs.  DO use RDS.  

\n
1. You don't have an internal PKI, then use the self-signed certs...and always connect via server names (assuming the DNS suffix on NIC is good) or FQDN. The other takeaway is just have an internal PKI...
\n
2. If you do have an internal PKI, then replace the self-signed certs using GPO and custom certs for the RDS service to use...and connect using server names or FQDN.
\n
3. DON’T connect via IP (did I mention that before?)
\n

And for all our sanity, do NOT mess with the security level and encryption level settings!  The default settings are the most secure.  Just leave them alone and keep it simple.

Thank you for taking the time to read through all this information.  I tried to think of all the scenarios I personally have come across in my experiences throughout the past 25 years, and I hope I didn’t miss any.  If I did, please feel free to ask!  Happy RDP’ing everyone!

Tim Beasley, Microsoft PFE – Platforms.

First published on TechNet on Dec 18, 2017

Hello everyone! Tim Beasley, Platforms PFE here again from the gorgeous state of Missouri. Here in the fall, in the Ozark Mountains area the colors of the trees are just amazing! But hey, I'm sure wherever you are it's nice there too. Quick shout out to my buds SR PFE Don Geddes (RDGURU), and PFE Jacob Lavender who provided some additional insight on this article! I am writing this blog post to shed some light on the question of \"How come we keep getting prompted warning messages about certificates when we connect to machines via RDP?\"

Sorry for grabbing up this old thread.

Am I right, that the remote desktop service will still create a self signed certificate even though a correct cert (from a third party CA) is available and also is used without eventlog entries in TerminalServices-RemoteConnectionManager IDs 105* and no cert warnings (prooft locally and tested from a client pc)?

Regards, Stefan

Windows should create it by default regardless, in case it has to use it.

Tim_Beasley Thanks. I don't even know how to go about doing that. 

And being DoD, I wouldn't even have the info to create a proper account to be able to open a case. 

RichardHauer - unless you have a certificate authority that's being leveraged by Intune either through SCEP or another method / cert profile, from what I understand you can't customize the certificates that Intune hands out dynamically.  Plus with only a day of expiration, you'd continually have to configure things every time the thumbprint changed. Talk about a royal pain in the butt.  You'd be much better off leveraging Microsoft Cloud PKI.  Microsoft Cloud PKI launches as a new addition to the Microsoft Intune Suite | Microsoft Intune Blog

jgarcia2193 - Honestly this is the first time I'm hearing about this sort of thing. I hate doing this but you're better off opening a CSS case to see if this is expected behavior or if you possibly found a bug.

Tim_Beasley -Thanks for responding. I hope you may be able to provide some insight or at lest point me in a direction.

Whenever I have run the Powershell to set the SSL...Hash i refresh and verify in the registry that it has set. Hash is verified there and correct to the Certificate. 

I run: Restart-service termservice -force

Refresh the registry and the hash has been removed. I get the same results when I try using cmd prompt. This is on Server 2019. 

Thanks for the reply Tim_Beasley  - I completely agree.

Not sure what you mean by \"Try a cert that has the hostname in the CN as well as a SAN entry along with the IPs.\"

The certificate is being issued by Entra as far as I can tell. The expiry is only 1 day. We don't have any PKI infrastructure at all, so it seems that it's Entra itself that is getting the certificate wrong.

Is there some way I can influence the certificates that Entra is creating?

This is the problem.

Thanks again!

RichardHauer - Sorry for the delay.  What it sounds like is that because the hostname of the device is missing from the SAN entries, it's flipping the switch for the cert warning. Try a cert that has the hostname in the CN as well as a SAN entry along with the IPs.

jgarcia2193 - what do you mean it gets deleted every time the service is restarted?  

What do you do if the SSLCertificateSHA1Hash gets deleted Everytime the termservice is restarted? 

Tim_Beasley you seem to be all over this topic, so hoping you can help as I've not found anything anywhere that seems to meet our scenario, that I would have assumed was actually the most common case. Here goes.

1. No on-prem hybrid, just regular Entra Domain with Intune delivering some policies incl firewall

2. User devices (Win11 23H2) are on a local network with IP range 10.0.0.0/24

3. Users all log into their machines using AD UPN - account profiles are established on their devices as admins

4. If a user tries to RDP into their machine from another machine on the network we get a certificate error:

   - MSTSC is set to 'use a web account to sign in on the remote computer'

   - MSTSC server auth is set to 'Warn me' if server authentication fails

   - MSTSC connect to is 'DESKTOP-12345' (we cannot use IP address as this does not work with 'use a web account...' according to connect-to-remote-aadj-pc 

   - MSTSC username can be either the user [upn] (their email) or AzureAD\\[upn] with the same result

   - client appears to connect with a series of screens that are only shown the first time through:

       - login to Entra

       - Entra MFC

       - Warning that \"you are going to connect Remote computer called 'DESKTOP-12345'

   - Certificate warning is shown stating:

       - The remote computer could not be authenticated due to problems with its security certificate. It may be unsafe to proceed.

       - Name mismatch. Requested computer name DESKTOP-12345. Name in the certificate from teh remote computer 172.XX.XX.1

       - The server name on the certificate is incorrect

The statement _may be unsafe to proceed_ gives the impression clicking OK on the warning will let us through, but it does not complete the connection.

Looking at the certificate I can see that the `Subject` is the device's ObjectID in Entra.
I can also see in `Subject Alternate Names` that there are **only** IP addresses listed including the 10... address of the machine on the local network and the 172... address mentioned in the error message which is a HyperV Virtual Ethernet Adapter. The hostname of the computer is not included in the certificate.

This makes me think:

1. the login was granted by Entra which issued the certificate to the machine

2. the RDP system seems to be expecting connection using the IP address, which conflicts with the rules of using a web account

3. if the cert is in fact issued by Entra there must be somewhere in Entra or Intune where I can tell it to include the hostname of the machine in the certificate that it issues

Has anyone got any insights into what is going wrong here? I feel like I'm a tick-box away from solving this issue.

I've recently started encountering this issue with an org that recently transitioned to be Entra/Intune native. There is/was no PKI, and several devices are behaving perfectly fine, where a chunk of others match the exact behavior you described here. There is no hostname in the Subject Alternate Names, only IPs. The machines that are working do have hostnames there. I cannot find any notable differences between the machines other than this behavior. Two examples being freshly deployed after any significant changes related to the transition.

Have you found any resolution for this?

Thread isn't dead, just been extremely busy fighting threat actors.  To use the specified certificate you have to ensure that it's using the correct EKU, then set it in the registry.  By default it uses the self-signed certificate.