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:
- Scenario 1: Regardless if RDS Role has been deployed, no internal PKI (no ADCS), and you’re experien...
- Scenario 2: Remote Desktop Services ROLE has NOT been deployed yet, you have an internal MS PKI (ADC...
- Scenario 3: Remote Desktop Services Roles have been deployed, you have ADCS PKI, and you’re experien...
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. :smiling_face_with_smiling_eyes: 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:
- The certificate is installed in the local computer’s “Personal” certificate store. (not user)
- The certificate has a corresponding private key.
- 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.
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:
- On the Connection Broker, open the Server Manager. Click Remote Desktop Services in the left navigation pane.
- Click Tasks > Edit Deployment Properties.
- In the Configure the deployment window, click Certificates.
- Click Select existing certificates, and then browse to the location where you have a saved certificate (generally it’s a .pfx file).
- Import the certificate.
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.
- 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...
- 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.
- DON’T connect via IP (did I mention that before?)
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.