Here is my issue. Our internal AD domain name is not the same as what we own in the outside world.
Lets say our internal AD is called internal.com and the one we own is called external.com
Naturally our internal computers are named desktop1.internal.com, desktop2.internal.com, etc.
our outside services are called webmail.external.com, client.external.com, etc.
for our outside services we just add the SSL to the IIS (or apache) site and we are good, even though internally it might be named e2k10.internal.com.
the problem i am coming across is this:
we've pointed login.external.com to an internal RDP server using port 3389 (NAT). when connecting to it via RDC program we get a cert error saying pretty much "you tried to get to login.external.com but the computer that responded was rdpserver1.internal.com. do you want to continue?"
we have to say yes and then we get access. We would like to secure this so that we dont get the error and use a valid SSL Cert and I'm not sure of the best way. I can't buy internal.com because someone else owns it in the outside world.
instead of making a direct connection to the internal RDP Server, we were thinking of putting the RD Gateway on a DMZ and see if this would act as a passthrough. But I'm not sure if it will do what we need. We can't change our internal AD domain name and i cant buy the internal.com domain name.
I saw this:http://blogs.msdn.com/b/rds/archive/2009/07/31/rd-gateway-deployment-in-a-perimeter-network-firewall-rules.aspx
but it looks like it needs a lot of servers and firewalls in the DMZ and im not sure if i want an AD DC in a DMZ.
Is it possible to put the RD Gateway on a DMZ (or NAT), when the user puts in login.external.com in the RDP program, it will hit the RD Gateway and then send it to an internal RDP server that doesnt have any type of SSL cert?