none
Certificate error when connecting to RemoteApp outside of private network RRS feed

  • Question

  • I have a server running Windows Server 2012 R2. It is configured as an all-in-one RDS server - all roles are installed on it. We've configured it primarily to use an application as a RemoteApp - the application is hosted at a different site, and this RDS server is at that site. We have a site to site VPN set up, so that it is all a part of our domain. The issue I'm having seems related to the fact that our internal network is .local, but the certificate only has a single .com name, so that we can access it from the Internet.

    Everything works, though what I'm trying to clear up is a certificate error. When connecting to the RemoteApp from outside of our private network, we get the error "The server name on the certificate is incorrect." This occurs after entering credentials.  The public name of the server (rds.contoso.com) is different from the private name (server.contoso.local).  We can proceed through the error and connect (though we'd like to fix it).

    I implemented a fix that I found elsewhere to try to fix this.  This was to add a custom RDP setting like so:

    Set-RDSessionCollectionConfiguration –CollectionName QuickSessionCollection -CustomRdpProperty "use redirection server name:i:1`nalternate full address:s:rds.contoso.com"

    That seemed to make some progress, then we got another error.  I made a change to the RD RAP in RD Gateway Manager - by default, it allowed access to Domain Computers (which rds.contoso.com did not exist as a domain computer). I modified it to allow access to the rds.contoso.com name.

    I now receive a different error message and that's where I'm stuck.  The heading on the message is RemoteApp Disconnected.  The text of the error is 'Remote Desktop can't find the computer "rds.contoso.com".  This might mean that "rds.contoso.com" does not belong to the specified network.  Verify the computer name and domain that you are trying to connect to.'

    Any thoughts on what I can do next?  When I roll back the changes I've made, I'm again able to connect fine, I just have the certificate error again.

    Wednesday, February 4, 2015 8:44 PM

Answers

  • Hi,

    1. For changing the published FQDN I recommend you use Set-RDPublishedName cmdlet instead setting a custom rdp property on the collection:

    Change published FQDN for Server 2012 or 2012 R2 RDS Deployment

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

    2. As you mentioned before you need to edit the RD RAP so that the FQDN that you are using is permitted, or set it to Allow users to connect to any network resource.

    3. On your internal network (internal to the RDG), you need to create a DNS A record for the published FQDN (rds.contoso.com) that points to your server's private ip address. 

    I'm not sure how you have things configured right now in terms of network and DNS so it is tough to give you instructions on how to fix.  Let me explain a bit.  Normally with a VPN you would not need RD Gateway, although it is okay if you want to use it.  If you have things configured properly an external client will normally connect to the RDG using the FQDN specified for RDG, then the RDG will connect to the published FQDN for the RDS deployment.

    In your case these two FQDNs would be the same, only when the client does a DNS lookup it should get the ip address that you want users to connect to for the RDG whereas when the RDG does a DNS lookup it should get the private ip address of the server.  Exactly how you need to configure your DNS entries will depend on your VPN and networking configuration.

    Please give it a try using the information provided above and reply back here with your results and any further questions you may have.

    Thanks.

    -TP

    Thursday, February 5, 2015 1:19 AM
    Moderator

All replies

  • Hi,

    1. For changing the published FQDN I recommend you use Set-RDPublishedName cmdlet instead setting a custom rdp property on the collection:

    Change published FQDN for Server 2012 or 2012 R2 RDS Deployment

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

    2. As you mentioned before you need to edit the RD RAP so that the FQDN that you are using is permitted, or set it to Allow users to connect to any network resource.

    3. On your internal network (internal to the RDG), you need to create a DNS A record for the published FQDN (rds.contoso.com) that points to your server's private ip address. 

    I'm not sure how you have things configured right now in terms of network and DNS so it is tough to give you instructions on how to fix.  Let me explain a bit.  Normally with a VPN you would not need RD Gateway, although it is okay if you want to use it.  If you have things configured properly an external client will normally connect to the RDG using the FQDN specified for RDG, then the RDG will connect to the published FQDN for the RDS deployment.

    In your case these two FQDNs would be the same, only when the client does a DNS lookup it should get the ip address that you want users to connect to for the RDG whereas when the RDG does a DNS lookup it should get the private ip address of the server.  Exactly how you need to configure your DNS entries will depend on your VPN and networking configuration.

    Please give it a try using the information provided above and reply back here with your results and any further questions you may have.

    Thanks.

    -TP

    Thursday, February 5, 2015 1:19 AM
    Moderator
  • Thanks Amy. Let me investigate these changes and I'll get back to you.
    Monday, February 9, 2015 2:23 PM
  • Hi Amy, you were able to identify a fix for us. In our environment, the issue was that the DNS A record was configured with the public IP address of the server - this was causing us to not be able to complete the connection when connecting remotely (and thus going through the RDP Gateway). 

    It was originally configured this way since this RDS server is at a different site, and the thinking was that if the VPN tunnel was to fail, we'd still be able to connect without issue.  We'll figure out a different way to make that work.  Thank you very much for the input!

    Monday, February 23, 2015 3:00 PM