Nowadays, IT security it’s a serious deal, and Remote Desktop Services is no exception especially if there are external clients connecting to the infrastructure. In order to make it easier for those clients to connect, we as administrators have to configure these services as smooth and transparent as possible, and to secure them, we will use as you might guessed…certificates. Here we have three options: we either use self-signed certificates, an internal enterprise Certification Authority or a public Certification Authority. I don’t recommend the first option not even in labs, but the other two, work well in production. If you have clients that are not part of the organization, I will go and buy a certificate form a public Certification Authority. Also, by using a public certificate, you will also be able to see the problems that arise from using a .local domain with Remote Desktop Services.
Now as a certificate requirement we only need a web certificate type and I will recommend you go for a SAN certificate or a wildcard one just so you don’t get lost in a bunch of certificates; easier management. There are multiple ways to install certificates in Remote Desktop Services, but in this article we are going to use the wizard that comes with this role since it’s a central console for all the servers in the RDS Infrastructure. Off course, you will not use this wizard for troubleshooting because it’s useless in this matter, but is perfect for what we need now because we don’t have to log in on every server to install the certificates.
Before we move forward, I trust you already have the certificate(s) purchased from a public authority or issued from an internal CA. I will use the term certificate from now on since I’m going to use a SAN certificate for my RDS infrastructure.
One thing to keep in mind are the FQDNs you put in the certificate. For those clients that are not part of the company you will need to put at their disposal a public FQDN to connect in order to launch their applications. In this case it is recommended to use a certificate issued from a public Certification Authority and the FQDNs be part of the certificate. If you don’t have external clients, then using an internal CA will work just great since these certificates are automatically trusted by all the clients in the company.
To start deploying certificates launch Server Manager, click on Remote Desktop Services and from the Deployment Overview section choose Tasks > Edit Deployment Properties.
Once the Deployment Properties window opens, click on Certificates. By default everything shows as not configured and as you can see we also have quite a few certificates to install. I hope you now understand why I recommended you to buy a SAN or a wildcard certificate. Down bellow there are two buttons, one that we are not going to use at all since it creates self-signed certificates and the other one that we are going to use extensively to install our trusted certificate.
In order to be as detailed as possible, I decided to break down every role service in the list into sections for this article. And the first one is:
RD Connection Broker – Enable Single Sign-On
Remote Desktop Services (RDS) uses single sign-on so users that launch their applications from the web portal or from a RemoteApp and Desktop Connection feed don’t have to type in their credentials every time the service refreshes or when connecting to the back-end servers. The same credentials that were used to log into the web portal will be used for every connection until the user disconnects. If no certificate is installed for this service, or the certificate is not trusted, we will get a warning when making the connection like the one in the bellow image:
To install our trusted certificate for the single sign-on role service, just select it then click the Select Existing Certificate button. What the service is looking in the certificate to make this connection “trusted”, is the FQDN that was typed in the browser address (discussed later on, in the RD Web Access section). So if that FQDN is in the certificate, we should be good-to-go here.
In the window that pops-up click on Choose a different certificate radio button then hit Browse and select the certificate. The certificate needs to be in a .pfx format in order to have its private key. Once is selected we can’t click OK until the Allow the certificate to be added to the Trusted Root Certification Authorities certificates store on destination computers box is checked.You might think this is annoying, but it’s actually a great thing. By checking this box, the wizard copies the certificate on the remote computer and also installs it in the computer Certificates Store. Click OK to save the changes.
Back in the Deployment Properties window you might be tempted to install a certificate for another role service, but let me tell you that it’s not going to work. As the warning says, only a single certificate a time can be installed for a role service. We have to click Apply and after the operation is finished we can go and install another certificate for another role service.
Once the wizard is done installing the certificate, we get a Success message in the State column and we can also see the certificate shows as Trusted. If we click the View Details link we get some basic information about the certificate.
RD Connection Broker – Publishing
This role service is used by the RDS infrastructure to sign RDP files in order for the users to know if it’s a safe application they are opening or not. If RDP files are not signed, users get an annoying warning message:
A website is trying to run a RemoteApp program. The publisher of this RemoteApp program can’t be identified.
To get rid of this warning we need to install a certificate that this role service will use to sign those RDP files. We can use the same SAN certificate we used before, so again, click the Select existing certificate button from the Deployment Properties window and provide the certificate .pfx file.
This service does not necessarily needs a FQDN to sign RDP files, but it needs the certificate to be trusted. The Common Name in the certificate is displayed as the publisher who signed the RDP file.
Once we hit Apply we should have a Success message in the Status column and the certificate should be trusted.
RD Web Access
This role service is the most visible one to users and the most annoying since is their first contact with the RDS infrastructure. Once they open the RDS web portal and no trusted certificated is installed and configured, they will get the well known browser certificate error message:
To fix this, all we have to do is install a trusted certificate for the web portal. We do it by selecting the RD Web Access role service in the Deployment Properties window list then click the Select existing certificate button. In the new window, browse for the certificate which again, must be in a .pfx format then check the Allow the certificate to be added to the Trusted Root Certification Authorities certificates store on destination computers box and click OK.
To install the certificate on the RD Web Access server, hit Apply. Again, we should have a Success message and also the certificate must be showing as Trusted.
Now if we open the web portal, the certificate error is not displayed anymore, and the connection is trusted. Off course, in the browser address you need to type the FQDN that exist in the certificate.
I haven’t talked about RD Gateway on server 2012 in any of my articles yet, but for sort, this is the role service that secures the data transmission for users that are connecting from outside the corporate network. Usually this service is deployment in a DMZ zone, but more details will come in a future article.
If we don’t have a trusted certificated installed for this role service the connection will fail with the bellow message. This is the only role service in the RDS infrastructure that closes the connection if is not trusted, so no self-signed certificates here!
This computer can’t verify the identity of the RD Gateway <RD Gateway FQDN>. It’s not safe to connect to servers that can’t be identified. Contact your network administrator for assistance.
The FQDN you typed in the RD Gateway settings, needs to mach one of the subject alternative names (FQDN) in the certificate, if it’s a SAN certificate. If is just a simple certificate, then it need to match the Common Name in the certificate.
Like before, to install the certificate all we have to do is select the role service from the list, click the Select existing certificate button then browse for the certificate. If everything was done right we should have a Success message in the Deployment Properties window.
Testing the connection
And we got to the final section of the article where we can test our work.
Open the web portal and see if you get any certificate errors in the web browser. I already showed this in the RD Web Access section of the article, but it doesn’t hurt to show it again. The connection is secured and trusted, so this one passed the test.
Clicking on any of the published applications should start up the connection until we get an information screen. This is normal, and it is always displayed for users that logged in with the option This is a public or shared computer. If the user chooses on the login screen of the web portal This is a private computer option, they get a check box in the information window to not display it anymore. Looking at the information here, we can see the publisher name that was used to sign the RDP file, the RD Gateway server (if used) and the RD Connection Broker server. Hit the Connect button to open the application.
This is the problem that I was briefly talking about in the beginning of the article. If your internal domain has the suffix with .local, or any other suffix for that matter that can’t be put in a public/commercial certificate, you will get the bellow warning. If the user clicks Yes, the connection will succeed and the application will open, but as we know, this will get a lot of tickets in our queue. If you are using an internal Certification Authority this message will not be displayed since the certificate is trusted.
There are some solutions to this problem, but they are not easy to implement in some organizations or you might consider them too much for what you need to do in the end. If you have any other ideas or an actual proof of concept (POC), please leave a comment.
The first one, and the ugliest one is to rename your domain. Off course, I don’t recommend you go with this one since renaming the domain might end up with problems, especially for beginners.
The second one is to build another Active Directory forest, create a trust between the two, then deploy the RDS infrastructure in the new forest. This one is almost acceptable but for those medium to big organizations since it brings some complications into the environment.
The third one is to build a new tree in the existing forest and deploy the RDS infrastructure in this new tree. I guess this is acceptable for most environment because you can deploy a single domain controller in the new tree and go from there.
Now off course, if you don’t have to many external clients you can always tell them to ignore the warning and continue, but that’s a little dangerous because you are actually training them to ignore warnings messages.
Installing certificates in 2012 Remote Desktop Services is not a hard job to do, but as you saw, these certificates are necessary for security, trust and least but not last, happy users.You might be tempted to go with self-signed certificates since all you have to do is push a button, but don’t do it, because these will create more problems than they fix and that’s why I did not talked about them in the article. Usually the certificates installation is a smooth process, but I can’t promise that is always going to be this way. Sometimes they work great, sometimes errors or installation problems might arise and when they happen, make sure you are the hero that saves the day.
Want content like this delivered right to your