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, Im sure wherever you are its 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 youve come across this in your environment, dont fretas its a good security practice to have secure RDP sessions. Theres also a lot of misguiding information out there on the internet Being a PKI guy myself, I thought Id chime in a bit to help the community.
The answer to the question? It depends.
Okay Im done.
HA! If only it was that easy! You people reading this right now wouldnt be here if it were that easy, right?
To get started, Im going to break this topic up into several parts. Im 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 dont 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.
Lets 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 theres a potential risk of a compromise. Sure, it can be perceived as a hassle sometimes, but dog gone itdont just click through it without reading what its 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 credentialswhich 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.
Im 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 cant tell you how many times weve 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:
Im going to begin this by saying that Im only including this scenario because Ive 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 elevatedespecially 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 certificatesso if youre 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 - //gallery.technet.microsoft.com/Windows-Server-2016-Active-165e88d1
RDS Farm - //gallery.technet.microsoft.com/Windows-Server-2016-Remote-ffc383fe
Off my soapbox nowback to the topic at hand:
More than likely, youve decided to RDP to a machine via IP address. I dont know how many users are out there that believe that this method is correct. Sure, it worksbut 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 dont 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 forwardgo on, Ill wait. :smiling_face_with_smiling_eyes: If by simply changing HOW you connect via RDP to machines [names vs IP address] fixes your problemcongrats! You can stop reading now. And in case youre wondering, yesthats a supported solution. *stifles laughter*
However, if RDP using names still produces warning messages then lets continue. Youve launched the RDP client [mstsc.exe] and typed in the name of a machinehit connectand 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 isnt 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 youre trying to establish the RDP session from doesnt have the remote machines self-signed certificate in the local Trusted Root CA certificate store. So how do we remedy that?
Solution for this scenario Export the remote machines 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 machines certificate into a new GPO at Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies -> Trusted Root Certification Authorities.
This will install the machines certificate accordingly on the local machine, so the next time you RDP using the remote machines 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 youre trying to connect to must exist on the certificate! Otherwise youll get warnings despite the fact the cert is deployed in the local Trusted Root CA store. Just because its trusted doesnt guarantee warnings are forever gone. You still must connect using the correct machine names.
Notice I didnt say to make any registry changes or click the little Dont ask me again for connections to this computer option? The idea is to get rid of the warning message the right wayheh.
Okay this scenario is a little like the previous one, except for a few things. Devils in the details!
First, your domain-joined client should already have a valid chain of trust if ADCS is deployedso that cant be the root cause. But perhaps its not a domain-joined clientin 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 youre connecting to a machine that has a certificate that contains the name youre trying to establish an RDP session into. I dont 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 templates 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, doesnt mean RDS will use it automatically. Remember, by default the local Remote Desktop Protocol will use the self-signed certificatenot one issued by an internal CAeven 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 certificatejust installing the cert isnt 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 utilizeand 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 computers 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, youll want to create a custom certificate template with the above EKU settings [or nonebut Ive always used Server Auth or RDA]. Its always best to use a custom certificate template, and not the default ones. But, Im not going to completely go off on a PKI best practices rant herethats for another day. [Theres several articles that walk you through this process if you havent done so already - here and here].
Once the templates created and scoped appropriately via permissions [autoenrollment or whatever] then its 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 arent deployed, then the subject name will typically be the machines nameconfigure 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 dont 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 machinenot the self-signed certificate.
Create a new GPO at the domain level [or OU...and dont use the Default Domain Policybad 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.
Heres 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
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 RDPis 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 machines 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 efficientand unless you script it out to hit all machines involved, youll only impact one at a time instead of using a scoped GPO.
Now we get to the meaty part [as if I havent written enough already]. Unlike the above 2 scenarios, you dont really need special GPO settings to deploy certificates, force RDS to use specific certs, etc. The roles themselves handle all that.
Lets say Remote Desktop Services has been fully deployed in your environment. It can be 2008 R2 RDS, or 2012 / 2012 R2 RDS. Doesnt matteror 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. [//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 its 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 dont 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 Gatewaysince in those scenarios the client is coming in externally anyways.
To recapDONT 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.
- DONT 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 didnt miss any. If I did, please feel free to ask! Happy RDPing everyone!
Tim Beasley, Microsoft PFE Platforms.