locked
Remote Desktop Services 2012 (certificates and DNS requirements) RRS feed

  • Question

  • 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

    Monday, December 17, 2012 11:14 PM

Answers

  • 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_Cao Thursday, December 27, 2012 1:37 PM
    • Marked as answer by Aiden_Cao Monday, December 31, 2012 2:28 AM
    Wednesday, December 19, 2012 8:46 PM

All replies

  • 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.
    • Proposed as answer by Janne T.1 Thursday, November 14, 2013 2:34 PM
    Tuesday, December 18, 2012 2:47 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 3:51 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:43 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:46 PM
  • 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

    Tuesday, December 18, 2012 9:56 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 9:58 PM
  • Please see this thread (you're the poster on this one too) :)

    http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/e80f9284-48d2-4085-bc62-eba8cae72d93

    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

    Tuesday, December 18, 2012 10:06 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

    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

    Wednesday, December 19, 2012 7:39 AM
  • 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


    Wednesday, December 19, 2012 5:40 PM
  • Yes 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:09 PM
  • Okay 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:11 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

    Wednesday, December 19, 2012 7:34 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_Cao Thursday, December 27, 2012 1:37 PM
    • Marked as answer by Aiden_Cao Monday, December 31, 2012 2:28 AM
    Wednesday, December 19, 2012 8:46 PM
  • 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!

    Wednesday, May 8, 2013 10:01 AM
  • Its true that 2012 does not allow you to configure a certificate on the listener on RDSH which is why you get a certificate mismatch error and there is no UI present to do that in 2012 even when using a wildcard certificate.

    But one easy way to prevent that error is you can always use a 2008R2 server to connect to your 2012 server using the RDSH config snap-in and then you can bind the wildcard certificate.

    For .local address, you can still get a certificate from some CA's like digicert but

    After November 1, 2015 Certificates for Internal Names Will No Longer Be Trusted.

    Best option is to use 2008R2 for now until you can migrate your domain name to a publically registrable name.

    • Proposed as answer by Manish Jeenwal Monday, September 23, 2013 3:52 PM
    Thursday, May 23, 2013 12:26 PM
  • Thank you Manish!! so simple yet genius!!
    • Edited by Jack2423 Thursday, September 5, 2013 5:59 PM
    Thursday, September 5, 2013 5:58 PM
  • This worked perfectly! Thank you!

    Luke

    Tuesday, May 13, 2014 3:08 PM
  • "Best option is to use 2008R2 for now until you can migrate your domain name to a publically registrable name."

    Do you really think this is an option?  If I told my customers they would need to migrate 5000+ users and loads of complex server infrastructure to a new Active Directory forest (as you cannot change the forest root domain) when running Exchange 2007 or higher as Rendom.exe is no longer supported... just to make "Remote Desktop Services" work without a certificate warning for public connecting users, then start going into the costs involved in performing such a task, they would tell me to get out of their office!

    Ridiculous - absolutely ridiculous!

    We need a better way of dealing with this.


    Clint Boessen MVP - Exchange Server, MCSE, MCITPx6, Dip Network Engineering
    Perth, Western Australia

    Blog: http://clintboessen.blogspot.com
    Employer: http://www.avantgardetechnologies.com.au

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Thursday, July 17, 2014 6:36 AM
  • Hi Clint,

    I created a cmdlet that allows you to change the published FQDN.  That way you can use a single wildcard certificate with external domain for all RDS purposes.  Please see below:

    Change published FQDN for Server 2012 or 2012 R2 RDS Deployment

    http://gallery.technet.microsoft.com/Change-published-FQDN-for-2a029b80

    Thanks.

    -TP

    Thursday, July 17, 2014 1:42 PM
  • Hi TP,

    Thanks for sharing that link.  From the description you are saying to run it on the connection broker, what about the built in RDP certificates which are created as part of the Windows installation process?  Can I replace those with my public wildcard certificate then create split DNS internally to ensure private IP addresses are associated with the new host names?

    Syntax

    Set-RDPublishedName [-ClientAccessName] <String> [[-ConnectionBroker] <String> ]

    Example

    In this example the cmdlet is run directly on the RD Connection Broker and we would like to change the published name to remote.contoso.com. We are making this change in order to match our installed wildcard certificate which has a subject of *.contoso.com:

    Set-RDPublishedName "remote.contoso.com"

    Regards,


    Clint Boessen MVP - Exchange Server, MCSE, MCITPx6, Dip Network Engineering
    Perth, Western Australia

    Blog: http://clintboessen.blogspot.com
    Employer: http://www.avantgardetechnologies.com.au

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    Thursday, July 17, 2014 2:58 PM
  • Hi Clint,

    It may be helpful to split it out to two cases. 

    First case is for RDSH servers that are part of a RDS deployment.  Here you would assign the wildcard in the deployment properties for all purposes, configure split DNS, and make sure that client device is using at least RDP 8.0 capable client (RDP 8.1 client preferred).  When configured properly there are no certificate errors, even though technically each RDSH server has a self-signed certificate.

    Please note that with 2012/2012 R2 you should configure things so that users make their initial connection to the RD Connection Broker server.  This is different from previous versions where you would have users make their initial connection directly to the RDSH servers.  So in the internal DNS you would have the published FQDN point to the RDCB server.

    As an admin you could see a cert error if you try to connect from external (via RDG) directly to a specific RDSH using /admin, but in that case you can click past the error (you already authenticated the RDG, so at that point you are only trusting that there is no MITM between RDG and internal RDSH).  Internally if you connect as an admin directly to a specific RDSH you should not see a certificate error because Kerberos will be used to authenticate the server's identity.

    Now, an exception to the above is when you are forced to use older clients, for example, thin clients that are not RDP 8.0 or later capable.  To handle these you need to import the wildcard certificate into each RDSH server's local computer Personal store, then use wmi or powershell to assign the certificate to the RDP-Tcp listener.  Please keep in mind that with older clients you are not getting any of the RDP 8.0/8.1 improvements which is a big downside by itself.

    Second case is for servers that are not part of a RDS deployment, like Exchange, SQL, etc.  These will behave like the admin case I described above.  If you are internal you should be fine because it can use Kerberos to authenticate the server's identity (you need to use the server's actual FQDN when connecting), but if you are external you will see a certificate error.  You can solve this by assigning the wildcard certificate to the RDP-Tcp listener via wmi as I mentioned above.

    If the above is not clear I can answer your questions/explain in more depth via Skype or perhaps over a beer at the Summit in November.

    -TP

    Thursday, July 17, 2014 3:29 PM
  • Hi TP,

    Thanks for the information, there are still a couple of grey areas with Remote Desktop Services 2012.  I read on a blog that if you enable RemoteApps on a 2012 Session Host, users can no longer remote desktop the server.  Is this the case?

    In Windows 2008 R2 you could allow RemoteApps and full Remote Desktop sessions to the same host... and some companies require this!

    Ping us your Skype ID to clint.boessen@avantgardetechnologies.com.au, I would love if you had a few minutes for a quick chat to clarify a couple more things.  I have a long history working with Terminal Services / Remote Desktop Services however this is my first project on Server 2012 :).

    Beer at the summit sounds great, I will give you my details over Skype.

    Thanks in advance...

    Regards,


    Clint Boessen MVP - Exchange Server, MCSE, MCITPx6, Dip Network Engineering
    Perth, Western Australia

    Blog: http://clintboessen.blogspot.com
    Employer: http://www.avantgardetechnologies.com.au

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.



    Friday, July 18, 2014 4:06 AM