Infohub‎ > ‎Articles‎ > ‎

Remote Desktop Gateway publishing with TMG: the certificate setup


The easy part

As often happens, the easy part is to understand your needs: you are out of office and you need to access your brand new Virtual Desktop that is setup in a Microsoft VDI infrastructure. Of course you don't want to set-up a VPN, instead you want to use the easy-firewall-bypassing RD Web Gateway, to tunnel your traffic into an SSL pipe.
The good news is that it is possible, the bad one is that the setup is not so easy (how could have been?...).

The certificates problem

I assume that you set up your VDI infrastructure, and in your Microsoft-centric network you want to use Forefront Threat Management Gateway (TMG) to access it from anywhere. This is a big assumption, but googling around will give you access to several docs on the way to build it all.
The problem I found is that is easy and clear documentation on the crucial part about digital certificates needed to run all the thing.
These are somewhat-quick and not-so-dirty hints to help you.

What we have

We have a TMG facing the internet with a public IP address (this is not absolutely required, but it is pretty common). We can create a record in out public DNS that points to that IP: we choose public.name.dns.
We have our connection broker and RD Web access in the inside network. We can call it broker.internal.lan. Note that I'm using the FQDN: forget using short names if you want the things working *all the time*.
You probably have clients inside your network that are bound to the Active Directory domain. We assume to have a single integrated Root CA, so our domain clients trust its certificate. You can use private or commercial PKIs and CAs, the important thing here is to trust their certificate on the clients and servers involved.

What we are going to do

We need two distinct certificates. I know you probably found guides that tell you need one certificate. If you're reading this, you probably realized that some kind of setup are not working, or simply require lot more effort that described. Also, they probably are patch-style solutions, not elegant nor affordable.
Back to us, you need:
- a certificate with a common name that is the one of the public DNS record for the TMG public IP: public.name.dns in our example
- a certificate for the internal connection broker broker.internal.lan.
These can be Computer or Web Server type certificate if you're using the Microsoft CA.

Now you should have the public named certificate installed in the computer store on the TMG and the private named certificate on the connection broker.
Use the RD Gateway snap-in on broker to "install" the certificate. I don't know why the snap-in uses that verb, but you simply have to choose that certificate in the properties of the gateway. This will restart the service dropping active connections.
Now, if you browse to https://broker.internal.lan/RDWeb from inside your network you should see the RD Web access page without any red-little-shield indicating that the certificate is not ok.

Now let's fire TMG config snap-in. This is not a step-by-step guide (as you probably supposed at this point) so I'll point out the activities to accomplish:
- create a Web listener, bound to the external IP that is resolved by public.name.dns. It must be HTTPS only, and must use the certificate with common name that is public.name.dns.
- create a web publishing rule. Follow the wizard and set:
-- broker.internal.lan as the internal host name. Use /RPC/* as the path to publish.
-- public.name.dns as the public name to respond to.
-- kerberos as the credential delegation method. Modify http to host in the SPN.
- complete the wizard and apply, then re-open the rule you just created and:
-- add /RDWEB/* to the published paths.
- apply the changes
- test the rule. This will not succeed. You need to open the AD snap-in and configure a delegation for the TMG host. If you click on the red cross in the test-rule page, read the error. It contains the link to a Microsoft howto on the way to configure delegation in AD. Follow it (2 minutes needed) and the re-test the rule. It should succeed.

We are almost done, what we left out?

We (and others) have not described the right way to connect from outside!
Go to your preferred internet cafè, startup your laptop and fire MSTSC.
As the host to connect to type broker.internal.lan (yes, the INTERNAL host name), thengo to Advanced->Settings->Use these RD Gateway settings and type public.name.dns as the Server Name. Choose Ask for password (NTLM) for logon.
Click ok and then connect. You should read the client stepping various phases and then, finally, your remote desktop will come up. If you were assigned a VDI machine that was set to sleep, you may have to wait some moments.

And now?
You can work, for me it's time to sleep. Hope this helped. Let me know using the Contact form.
Bye