Remote Desktop Services 2012 (certificates and DNS requirements)
-
Monday, December 17, 2012 11:14 PM
Hi,
I hope you can advise me. I am familiar with RDS (based on Windows Server 2008 R2). I just started with RDS (based on Windows Server 2012). I find the certificate requirements and DNS requirements somewhat confusing. I can't find any clear information about this on the internet and I also noticed more people are having the same questions. Allow me to explain my scenario. I have the following setup:
RDS01 = RD Licensing Server + RD Connection Broker + RD Web Access
RDSH01 = RD Session Host
RDSH02 = RD Session Host (currently not available yet. Only RDSH01 at this time!)
RDSH03 = RD Session Host (currently not available yet. Only RDSH01 at this time!)I can easily install and configure all server roles. But here it comes. In Windows Server 2008 R2 you are able to configure a farm DNS name. In Windows Server 2012 you can’t as far as I can see. With Windows Server 2008 R2 you would then need to create several A-records (round-robin) that point to each RD Session Host. For this to work you would also need to have a Computer Certificate on each RD Session Host where the subject name matches the farm DNS name. But how does this work with Windows Server 2012? Do you still need to configure a separate farm DNS name and import certificates on every RD Session Host which matches the subject name?
I can only import a certificate (.pfx). Which by the way I find very unhandy you can’t select an already existing certificate from the certificate store. I notice when I import a certificate it is only imported on the RD Connection Broker. I understand the certificate for signing the RDP files and Web Access. But what about the RD Connection Broker? Also… the certificate configuration is globally? What if you have multiple collections, no certificate requirements per collection? Maybe I am missing something because the currently de RDSH01 is the only RD Session Host operational.
Can someone shine a light on this.
Boudewijn Plomp, BPMi Infrastructure & Security
All Replies
-
Tuesday, December 18, 2012 2:47 PMI'm having a similar problem in that when I connect to the farm, it presents the self signed cert for the session host box itself. I can't find the equivalent settings in 2012 where you set the farm name and pick the correct certificate.
-
Tuesday, December 18, 2012 3:51 PM
I'm having a similar problem in that when I connect to the farm, it presents the self signed cert for the session host box itself. I can't find the equivalent settings in 2012 where you set the farm name and pick the correct certificate.
At least I am not alone ;)Boudewijn Plomp, BPMi Infrastructure & Security
-
Tuesday, December 18, 2012 9:43 PM
You don't define farm names in DNS and connect to a farm name in a 2012 deployment. You connect to the Connection Broker and it routes you to the collection by using the collection name. This is as you have noticed a fundamental difference between 2012 and everything prior.
The certificates you deploy need to have a subject name or subject alternate name that matches the name of the server that the user is connecting to. So for example, for Publishing, the certificate needs to contain the names of all of the RDSH servers in the collection. The certificate for RDWeb needs to contain the FQDN of the URL, based on the name the users connect to. If you have users connecting externally, this needs to be an external name (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, again the subject name needs to match the servers in the collection.
The easiest way to do this if you control the client machines that will be connecting is to use Active Directory Certificate Services. You can request and deploy your own certificates and they will be trusted by every machine in the domain. If you're going to allow users to connect externally and they will not be part of your domain, you would need to deploy certificates from a public CA.
The reason why the Certificates are a global setting is because it was designed as a centralized management solution, allowing you to deploy certificates to every RDS server in your deployment from one place, using one UI. You no longer need to install the certificate on each server and then repeat the same process in each UI on each server to configure the certificates. In Windows Server 2012, you need only export the certificate with the private key and then use the RDMS UI on the Connection Broker to deploy it to ALL servers.
Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging
-
Tuesday, December 18, 2012 9:46 PM
All public cert providers are stopping issuing certs with .LOCAL in them, so how are we supposed to get a publicly trusted cert that has our private names on it (which itself is not good security practice).
Why couldn't this have been done properly like Citrix where you simply have an external cert that you connect to (web interface, citrix, secure gateway) that then proxies the internal remote desktop connections invisibly to the client?
-
Tuesday, December 18, 2012 9:56 PMExternal clients would only connect to RDWeb and RD Gateway using an external name. Those two roles need to have a certificate that matches the external name. A certificate for Single Sign On that matches the internal names should work just fine provided you are using RDP 8 to connect.
Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging
-
Tuesday, December 18, 2012 9:58 PM
Thanks Don - but Vista and XP users can't use RDP 8...
I am really wanting to stop paying extra money to Citrix - and all I need is basic RDP access via the web without lots of cert squawks and extra authentication steps...
-
Tuesday, December 18, 2012 10:06 PM
Please see this thread (you're the poster on this one too) :)
I wish I had a better answer, but at this time there is no RDP 8 for anything other than Windows 7.
Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging
-
Wednesday, December 19, 2012 7:39 AM
You don't define farm names in DNS and connect to a farm name in a 2012 deployment. You connect to the Connection Broker and it routes you to the collection by using the collection name. This is as you have noticed a fundamental difference between 2012 and everything prior.
The certificates you deploy need to have a subject name or subject alternate name that matches the name of the server that the user is connecting to. So for example, for Publishing, the certificate needs to contain the names of all of the RDSH servers in the collection. The certificate for RDWeb needs to contain the FQDN of the URL, based on the name the users connect to. If you have users connecting externally, this needs to be an external name (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, again the subject name needs to match the servers in the collection.
The easiest way to do this if you control the client machines that will be connecting is to use Active Directory Certificate Services. You can request and deploy your own certificates and they will be trusted by every machine in the domain. If you're going to allow users to connect externally and they will not be part of your domain, you would need to deploy certificates from a public CA.
The reason why the Certificates are a global setting is because it was designed as a centralized management solution, allowing you to deploy certificates to every RDS server in your deployment from one place, using one UI. You no longer need to install the certificate on each server and then repeat the same process in each UI on each server to configure the certificates. In Windows Server 2012, you need only export the certificate with the private key and then use the RDMS UI on the Connection Broker to deploy it to ALL servers.
Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging
Hi Don, thank you for your answer. This is what I somewhat expected. Your explenation makes sense. I do have some question though.
For my confirmation. For internal use you connect to the RDCH with some special properties in the initial connection that tells the RDCH you need to connect to a certain collection. Those properties are provided when you use RD Web Access or the RD Web Feed. Correct me if I'm wrong.
You say you need to create and import a certificate that includes alle hostnames of each RDSH. But I have noticed that the certificate is not imported on every RDSH. When you import a certificate (through .pfx) it is only imported and linked on the RDSH. So why having a SAN certificate? That would be very unhandy when you expand or add session collections. So that doesn't make sense to me. Could you be wrong or is there an explanation for that?
One other thing. Whatever you import each RDSH keeps its own self-singed certificate that came with the OS. In our case all servers have a computer certificate issued from an internal Enterprise Root CA. With WS 2008 R2 you are able to use an RDSH console to link that certificate. For WS 2012 I know you can still use a GPO though. I have read about WMI a command. Is there a PowerShell command to link an existing certificate to the RDP protocol?
Boudewijn Plomp, BPMi Infrastructure & Security
- Edited by Boudewijn Plomp Wednesday, December 19, 2012 7:43 AM
-
Wednesday, December 19, 2012 5:40 PM
Did you use the RDMS UI? For an RDSH farm, deploy a certificate for "Publishing" and "Single Sign On". I typically use a wildcard cert as I control my own ADCS server.
Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging
- Edited by dgeddes [MSFT]Microsoft Employee Wednesday, December 19, 2012 5:41 PM
-
Wednesday, December 19, 2012 7:09 PMYes I did. Our session collection will only be used internally and by trusted partners inside our network. Every client/server in our domain already has Computer (Version 2) certificate issued by an internal Enterprise Root CA. But since you can't select an existing certificate I have requested a Computer (Version 2) with the same common name on another server. Exported it and imported with the RDMS UI. Unhandy, but everything works fine now. But, each RDSH still uses its self-signed certificate. All because the RDMS UI doesn't configure it for you and because there is no UI anymore (as with WS 2008 R2) to configure it. The only option I have is using a GPO or use a script to link the valid certificate on each RDSH. Again, unhandy!
Boudewijn Plomp, BPMi Infrastructure & Security
-
Wednesday, December 19, 2012 7:11 PMOkay so I guess I'm not clear on the behavior that you are seeing that is undesired. When you say each RDSH server still uses it's self-signed certificate, where are you seeing that?
Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging
-
Wednesday, December 19, 2012 7:34 PM
First of all your information is very appreciated. At first I had some struggle getting thing right. But now that I know that RDS in WS2012 works different then WS2008R2 I am getting there.
As you know every server OS deployment has its auto generated certificate bound to the RDP service in Windows. When you configured autoenrollment for computer certificates on every server; with WS2008R2 you have the option to configure that computer certificate for RDP connectivity manually (RDSH UI). WS2012 does not offer that UI anymore. Or you can use a GPO setting (OU wide). The RDMS UI you mention does allow you to configure certificates. But it only imports the certificate on the RDCB, RDWA and/or RDG. It does not configure a RDSH. So each RDSH is still left with a self-signed certificate. User notice it, when they open a RemoteApp through the RD Web Access, the RDCB certificate is ok and trusted. But they are then redirected to one RDSH and are prompted with an untrusted (self-signed) certificate. If you examin the certificate store on the RDSH there is no certificate present. The RDMS UI does not configure it.
The RDMS UI works great but it does not do the full job. At least not in my case. And you say you need a SAN certificate which include every hostname of each RDSH. I got the feeling that isn't required because it is not imported in any way to the RDSH. Unless you need a public certificate, only want to request one public certificate that you manually configure on every RDSH with a GPO or the command below.
Someone at another forum posted this syntax: (I just tried it and it works)
wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="e2f034c171b92ablbablaafc96b23b7f4da15728c1e461a9"Do you understand what I mean? I just want to know how it works. And I wish you could select an existing certificate from the certificate store, which would make life much easier.
Boudewijn Plomp, BPMi Infrastructure & Security
- Edited by Boudewijn Plomp Wednesday, December 19, 2012 7:59 PM
-
Wednesday, December 19, 2012 8:46 PM
In Windows Server 2012, there is no equivalent to the setting in Windows Server 2008 R2 RD Session Host Configuration as it is not needed anymore. Which is why I wanted to make sure that you weren't seeing something unexpected based on how you have your certificates configured. Are you seeing any prompts that you don't think you should be seeing? Is SSO not working? Please let me know.
You don't have to use a SAN certificate, that is just one of the ways to do it. If you don't use a wildcard, then you have to use SAN in the certificate. What Remote Desktop cares about is that it's a Server Authentication certificate, the FQDN is either in the Subject Name, or SAN, and that the certificate is trusted.
As for the inability to install a certificate that is already in the store on the Broker, I have heard that feedback several times before and I agree it would be nice if it allowed you to do that. The reason it doesn't is simply one of design.
Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging
- Proposed As Answer by Aiden_CaoMicrosoft Contingent Staff, Moderator Thursday, December 27, 2012 1:37 PM
- Marked As Answer by Aiden_CaoMicrosoft Contingent Staff, Moderator Monday, December 31, 2012 2:28 AM
-
Wednesday, May 08, 2013 10:01 AM
External clients would only connect to RDWeb and RD Gateway using an external name. Those two roles need to have a certificate that matches the external name. A certificate for Single Sign On that matches the internal names should work just fine provided you are using RDP 8 to connect.
Don Geddes - SR Support Escalation Engineer - Remote Desktop Services - Printing and Imaging
Sorry for digging up an old topic.
What happens if you have a 2-certificate solution (1 with public CA for the External access, and 1 with your internal CA for Single Sign On), and you connect from a non-RDP8 client such as XP?
Does it work, but with more password prompts, or doesn't it work at all?
Very valuable information in this thread! Much appreciated!

