TS Gateway - a few questions

I've just learnt about TS Gateway feature in 2008, and this is sweet.

However, this also puzzled me - aren't RDP sessions already encrypted? - Isn't than using SSL over HTTP a double encryption?

And what about Smart Cards? That is easily implemented in Terminal Servers, and serves as authentication - so this TS G. is not actually a first preauthentification RDP solution.

Thank you.
Who is Participating?
tigermattConnect With a Mentor Commented:

RDP sessions are encrypted, just like TSG sessions. The emphasis behind deploying a TSG is less on the authentication aspect and more on the server configuration and administration aspects:

- A dedicated TSG can (and in a large network, should) be located in the DMZ. This means the TSG acts as a pre-authentication, and you only need to open the more high-risk port 3389 between the TSG and the internal network.

- Centralised connection point. You no longer need a static IP for every machine on the LAN you need to open Remote Desktop to. Instead, you instruct all users to connect to the internal name of their PC and direct the connection via the TSG; this only requires one port and one static IP to be open for all remote sessions for the entire organization.

- Firewall concerns. Because TSG sessions use 443 between the initiating client and the TSG, for users who may connect into TS from a larger corporate network, it will be more likely they can initiate a connection; unlike port 3389, 443 is unlikely to be blocked as it is used for standard Internet HTTPS traffic.

Smart Card pre-authentication is another form of pre-authentication, but doesn't give any of the other benefits listed above. Without a TSG you'd still need to open ports direct to all the TS Servers, which uses IP addresses and so on.

mrmutAuthor Commented:
ok, does this means that TSG server must be joined to the domain or at least need to access LDAP to Domain Controller ?

Would that be a security problem later on down the track ?
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.


"...does this means that TSG server must be joined to the domain or at least need to access LDAP to Domain Controller..."

If the TS Gateway will be authenticating users via Active Directory, it should ideally be located on the private network with port 443 open directly to it. You should *never* expose an Active Directory Domain Controller to your DMZ - my blog post at http://tigermatt.wordpress.com/2009/08/03/exchange-server-dmz/ explains why.

If the TS Gateway is located in the DMZ, you should perform authentication using local accounts. Port 3389 is then open to the Terminal Servers on the private network.

Either way, TS Gateway servers are predominantly available to act as a central connection point for connection to multiple Terminal Servers or workstations running RDP. The fact they work over port 443, so are considered by some to be more secure, does not necessarily make them secure - and you shouldn't throw standard security out of the window by placing a domain-joined machine into the DMZ.

Hi Matt,

thanks for replying, so to be more precise here it is what I'm doing with multi home router/gateway deployment with no AD DS in the DMZ
 1. from the external world to DMZ: port 80 and 443 only
 2. from DMZ into the local network (both ways): 3389, 389, 88, 53, 135 only.
 so the above ports is the minimum to be open in the firewall/cisco router from my point of view,
 I'm actually thinking to disabling port 53 as it can expose my internal DNS to outside world.

Opening 389 and the various other ports from the DMZ into the private network is precisely what you DON'T want to do. My blog post at http://tigermatt.wordpress.com/2009/08/03/exchange-server-dmz/, albeit written for Exchange in the DMZ, applies to this situation. If you want Active Directory integration on the TS Gateway, the best (and in my opinion, only) place for it is the private network. Put it in the DMZ and you open the ports, which reduces security.

Basically, don't ever put a domain joined machine into the DMZ. AD LDS should be used in the DMZ for security purposes, rather than locating a Domain Controller there or opening ports to the private network. Off hand, I don't think TS Gateway supports the use of AD LDS.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.