Michael Kleef ::: MSFT

http://twitter.com/mkleef

Setting Up Terminal Server Gateway with ISA Server

Setting Up Terminal Server Gateway with ISA Server

  • Comments 4
  • Likes

I was talking with a friend on mine, Ian, a few weeks ago - he was talking to me about security and approaches he was looking at. Without telling all the details, I talked to him about Terminal Services Gateway and how you can reverse proxy it with ISA Server.

Personally I do this all the time on my test server environment as ISA server is the main gateway into my test LAN. So to help everyone understand how this is done I've done a screencast on how to configure it to get it to work. I also briefly touch on SoftGrid 4.5 at the end and show you how to publish Softgrid apps in the Remote Programs and TS Web access views.

Any questions on it please just ask!

Comments
  • In my last post I talked about Softgrid 4.5 on Terminal Servers as part of the screencast I did on configuring

  • Michael:

    Thanks for the great webcast on this topic.  We've been using TS Gateway with ISA 2006 for about a year now and love it.  I have a couple questions if you have time:

    One difference between our configuration and yours is in the Paths tab.  I just left it at the default /* instead of specifying it as you did in your presentation.  Do you know what the ramifications of this might be?

    Also, another issue we have is that our user's are required to prefix their usernames with our domain and a backslash.  RDC 6.1 made this a non-issue, thankfully, but I still get questioned about this.

    Thanks again!

  • So the implications here are that it can allow a default path to a backend server. Good security is able being explicit on what constitutes expected behaviour.

    For example:

    www.myserver.com/tsweb is a valid path and the only one we want to allow. ISA will block anything else and not both the server its proxying needlessly.

    www.myserver.com/randomurl may not be a valid path though because you have specified /* it means that it will try the server you have reverse proxied because it now successfully that meets that rule.

    It also affects future reverse proxying to resources such as OWA or other web services that could be on other servers (assuming you're using the one URL) but the /* rule means that, assuming that rule is higher in the list, it will meet that request and send through to the wrong server and you'll wonder why its not working properly.

    Explicit is good - and its easier to predict!

  • Makes sense to me.  Thanks for clearing that up; I'm going to change it to be more restrictive.

    I certainly appreciate the advice.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment