locked
Deploying RemoteApp and Desktop Connections certificate... RRS feed

  • Question

  •  

         Hello,

       I am currently trying to deploy a certificate for remoteapp and desktop connections and continue to receive a certificate error.  We are running a 2012r2 developement RDS Farm.  We have one Connection Broker, 2 session hosts, gateway, web access etc...we have about 15 applications published and the user's can access them via web access, however, when we try and setup (RADC-RemoteApp and Desktop Connections) it errors out due to security issue with the certificate.  If we manually install the cert in the client's Trusted Root Certificate Authority for the local machine, it works flawlessly....however, we do not want to have to install this cert for 500 users +....we would rather deploy through GP.

        We have it narrowed down to the point of the certificate is not being deployed to all of the clients.  We have attempted many GPO policy edits that we have found from other technet articles and other websites online...but I cant seem to find any solid GPO instructions that seem to work for this environment to properly deploy the certificate to all of the clients.

      These clients are running windows 7 and windows 8 & 8.1.  All the clients that are running windows 7 have RDP 8.0....

    Any help would be greatful....thanks in advance.     JCT

    Tuesday, August 12, 2014 1:59 PM

Answers

  • Hi,

    You need to request the necessary certificates from your CA, export each certificate and its private key to a .pfx file, then use these files for the RDS in Server Manager -- RDS -- Overview -- Tasks -- Deployment Properties -- Certificates.

    To do this you can use certlm.msc. For example, start on the broker, open certlm.msc, request a new cert using Computer template, before clicking enroll go into the details and edit the properties of the request so that the private key will be marked as exportable, then enroll.  Once it is done the certificate will be in the Personal store, right-click on it and export it as well as the private key to a .pfx file.

    In Server Manager -- RDS -- Overview -- Tasks -- Edit Deployment Properties -- Certificates tab, select RDCB SSO, select existing certificate, choose the .pfx, etc., then click Apply.  Select RDCB Publishing, select existing certificate, choose .pfx, OK, click Apply.

    At this point you should be finished with 2 out of the 4 RDS purposes.  Log on to the RDWeb server, request the certificate and export it (and its private key) to .pfx file as described above, and copy the file over to the broker.  Repeat the process I described above to assign this certificate to the RDWeb and RDG purposes in deployment properties.

    Now you should have all 4 purposes set and showing as trusted in deployment properties.  The client PCs should not get any certificate errors since they should trust the certificates issued by your enterprise CA.  Additionally the client PCs need to be able to reach the path defined in CRL Distribution points and AIA on the certificates so that they can do revocation checking.

    -TP

    Tuesday, August 12, 2014 9:49 PM

All replies

  • what's the domain functional level?

    is the certificate from an internal enterprise CA or a 3rd party?

    do you have certificate auto enrollment GPO configured?

    how are you publishing the certificate through GPO?

    how are you identifying that the GPO is not having the desired effect, as in, are not seeing in the certificate store or you do see it and it just doesn't have the effect on RDS?

    Tuesday, August 12, 2014 2:57 PM
  • Domain Functional level  :  Windows Server 2012r2

    Forest Functional level  :  Windows Server 2012r2

    Not sure about cert auto enrollment GPO.

    I'm currently trying to figure the publishing through GPO part out.  It is published to the servers in the RDS farm through RDMS, however, our concern is getting it deployed to client machines.

    After a few different attempts, we have run GPupdate.exe on the client machines and then checked the local cert stores and the cert is not located there....

    thank you

    Tuesday, August 12, 2014 3:17 PM
  • Hi,

    I recommend you purchase a wildcard certificate from a trusted public authority (GoDaddy, GeoTrust, Thawte, Digicert, etc.) and use it for all RDS purposes.  This requires the least amount of work and time to set up and will provide the best experience.  An alternative to purchasing a wildcard would be to use multiple single-name certificates.  How many single-name certificates you need depends on how you have placed the RDS Role Services (in terms of whether or not some RDS Role Services are on the same server as other RDS Role Services).

    -TP

    Tuesday, August 12, 2014 3:48 PM
  • auto enrollment is mentioned near the end of this article

    http://msdn.microsoft.com/en-us/library/cc770857.aspx

    as for the certificate itself, it can be confusing, simplest method is here

    http://technet.microsoft.com/en-us/library/cc772491.aspx

    but you need to check to see if the user has to be member of a certain group to receive the published cert, it all depends on how you setup the cert initially and what kind of template was used, I'm assuming you generated the cert yourself

    Tuesday, August 12, 2014 3:53 PM
  • The Dev environment we are working on is completely isolated from the web.  We have a virtual machine as a connection broker, 2 virtual machines as session hosts, a virtual machine that is the gateway.  The gateway is connected via VLAN and port rules and is hosted on another Hyper-visor.  We are using a Certificate Template with the intended purpose of Server Authentication & Client Authentication for RDS.

    Gateway and web access roles are on the same server.

    Connection Broker and licensing server are on the same server.

    SH1 has session host role, SH2 has session host role installed.


    Tuesday, August 12, 2014 4:14 PM
  • sorry, it is also an internal Enterprise CA

    Tuesday, August 12, 2014 4:35 PM
  • I'm trying to ultimately find the client certificate requirements for RDS 2012 R2...please advise to any documentation...

    the only documentation regarding certificates for RDS is for the CB SSO, CB Provisioning, Gateway, and Web Access pieces which are all server components...

    thanks in advance...

    JT

    Tuesday, August 12, 2014 4:45 PM
  • Hi,

    1. Are the client PCs joined to the domain?  If yes then by default they should trust the certificate(s) issued by your internal CA and there is no need to have the RDS certificate(s) deployed to each client.  The other thing that needs to be configured properly is the revocation checking.

    2. Are you saying that the client PCs are not able to contact the public Internet at all?

    The reason I (almost) always recommend for people to use certificates from a public authority is because it is less complex, takes less time to configure, allows non-domain clients to work, allows external (devices not on the LAN) to work, etc.  If you have a RDS environment that is all domain-joined devices and all internal devices then yes, you can use an internal CA and things can work fine.  You will still need to get your internal PKI configured properly in order for everything to work, and many people do not have enough experience (with AD CS).  As a result they will spend a significant amount of hours troubleshooting/researching AD CS/GPO settings in addition to RDS certificate requirements before they get it right.

    Now, if your client PCs are prohibited from contacting the public Internet my recommendation of using public certificates will have issues as well because the client PCs need to perform a revocation check and will fail because this requires access to the Internet.  So perhaps in your case you will be forced to use your internal CA or configure things in a non-standard way to get it working.

    -TP

    Tuesday, August 12, 2014 4:59 PM
  • "...  If you have a RDS environment that is all domain-joined devices and all internal devices then yes, you can use an internal CA and things can work fine.  You will still need to get your internal PKI configured properly in order for everything to work, and many people do not have enough experience (with AD CS).  As a result they will spend a significant amount of hours troubleshooting/researching AD CS/GPO settings in addition to RDS certificate requirements before they get it right...."
           This is how we have it setup, however, we cant seem to find anything on RDS CERTIFICATE REQUIREMENTS...any help would be greatful.
    Tuesday, August 12, 2014 7:23 PM
  • Hi,

    You need to request the necessary certificates from your CA, export each certificate and its private key to a .pfx file, then use these files for the RDS in Server Manager -- RDS -- Overview -- Tasks -- Deployment Properties -- Certificates.

    To do this you can use certlm.msc. For example, start on the broker, open certlm.msc, request a new cert using Computer template, before clicking enroll go into the details and edit the properties of the request so that the private key will be marked as exportable, then enroll.  Once it is done the certificate will be in the Personal store, right-click on it and export it as well as the private key to a .pfx file.

    In Server Manager -- RDS -- Overview -- Tasks -- Edit Deployment Properties -- Certificates tab, select RDCB SSO, select existing certificate, choose the .pfx, etc., then click Apply.  Select RDCB Publishing, select existing certificate, choose .pfx, OK, click Apply.

    At this point you should be finished with 2 out of the 4 RDS purposes.  Log on to the RDWeb server, request the certificate and export it (and its private key) to .pfx file as described above, and copy the file over to the broker.  Repeat the process I described above to assign this certificate to the RDWeb and RDG purposes in deployment properties.

    Now you should have all 4 purposes set and showing as trusted in deployment properties.  The client PCs should not get any certificate errors since they should trust the certificates issued by your enterprise CA.  Additionally the client PCs need to be able to reach the path defined in CRL Distribution points and AIA on the certificates so that they can do revocation checking.

    -TP

    Tuesday, August 12, 2014 9:49 PM