Microsoft Forefront Unified Access Gateway Product Team Blog : Application Publishing

Publishing Windows 2008 Terminal Services Farm (session broker) behind IAG 2007

edgeaccessblog — Tue, 22 Jul 2008 17:08:00 GMT

The Terminal Server Session Broker Load Balancing feature allows to evenly distribute the session load between servers in a load-balanced terminal server farm. With TS Session Broker Load Balancing, new user sessions are redirected to the terminal server with the fewest sessions.

Using TS Session Broker to load balance sessions involves two phases:

1. In the first phase, initial connections are distributed by a preliminary load-balancing mechanism, such as Domain Name System (DNS) round robin. After a user authenticates, the terminal server that accepted the initial connection queries the TS Session Broker server to determine where to redirect the user.

2. In the second phase, the terminal server where the initial connection was made redirects the user to the terminal server that was specified by TS Session Broker. The redirection behaviour is as follows:

•	A user with an existing session will connect to the terminal server where their session exists.
•	A user without an existing session will connect to the terminal server that has the fewest sessions.

For more details on Session broker please refer to the following TechNet article:

http://technet2.microsoft.com/windowsserver2008/en/library/902a6081-9ecd-45ec-96ee-f51097d71c8c1033.mspx?mfr=true

Publishing Terminal Server farm using Windows 2008 Session Broker server behind IAG 2007 appears to be a challenge. You would be essentially publishing it as one of the Terminal Services application over an HTTP/S Trunk. The problem is when you publish the session broker server via IAG assuming that DNS Round Robin configured for load balancing will enable session broker to distribute the terminal session to the backend farm effectively it will not work for end user connecting through IAG to this farm.

IAG is aware of only one published Terminal Server – the Session Broker – and will therefore route terminal service requests from end users only to this server. What Session Broker does for load balancing at the backend is that it redirects sessions to another terminal server in the farm, and this is essentially a new session request from IAG perspective each time.

When, after being load balanced, this traffic is sent from the client back through IAG towards another terminal server in the farm, IAG will not treat this as a valid request since in the IAG configuration the Terminal Services application exposes only the Session Broker server. With this configuration when a client connects via IAG server to a Session Broker managed farm, the client gets an error message saying “the client cannot connect to the remote computer”, as no handling is performed by the IAG SSL VPN components on the client side in order to intercept RDP traffic to this other terminal server.

To solve this problem we have to consider using Socket Forwarder and publishing the entire Terminal Server farm and not only the Session Broker server.

Here is the step by step configuration:

1. Publish the Terminal Server application for the entire farm by specifying all the terminal servers IP addresses (single/ranges/subnets) and hostnames (all listed manually or by using wildcards).

2. Set one Terminal Server as the jump-start and set it as a lead server.

3. The MSTSC.exe client will connect initially to that server, but if the TS session broker will "redirect" to another terminal server in the farm (either by its name or its IP address) the Socket Forwarding component will intercept and route that RDP traffic to the appropriate server seamlessly.

4. Without Socket Forwarder installed, only the first server on the list is supported.

Author: Faisal Hussain

Developer Support - Security

UK GTSC Developer Internet Team

Publishing Forefront Security Management Console through IAG 2007

edgeaccessblog — Sun, 20 Jul 2008 21:38:00 GMT

1. Motivation

Recently I received a question from a customer about how to securely access the Forefront Security Management Console from the Internet. His specific request was:

“We have a 24x7 Security Team and they often travel to visit our remote branch offices. While they are traveling they stay in Hotels and connect to the VPN when it is necessary. There were already situations that those guys were unable to connect to the VPN using L2TP/IPSec because of restrictions in the Hotel’s Firewall. We are looking for a central solution where the remote engineer can quickly manage the security state of the servers by connecting to Forefront Security Management Console from outside without using VPN and allowing access only for the administrators. The solution needs to verify if the computer where the remote engineer is connected from is compliance with our security policy. We currently have IAG 2007 and some applications are already published in the Company’s Portal.”

Reading this request it was clear that the customer was looking into the right place to accomplish that. Since he already has an IAG 2007 Portal what we need to do is address the following point: “…manage the security state of the servers by connecting to Forefront Security Management Console from outside without using VPN for the administrators only”.

2. Reviewing Forefront Security Management Console Configuration

This article assumes that you already have the FSSMC installed and working fine internally. For more information on how to deploy FSSMC in your environment review the Forefront Server Security Management Console – Deployment Guide at Microsoft TechNet. With this assumption, review the IIS configuration for the FSSMC to see how it is configured the authentication and the ports that are listening to.

Figure 1 – IIS Console in the Server that has the FSSMC installed.

3. Creating the Application in the IAG Portal

Open the HTTPS Portal and under the Applications follow the steps below:

1) Click in Add and the window below will appear:

Figure 2 – Choosing the application that you want to publish.

2) Select the option Web Application, choose Generic Web App and click in Next.

3) In the step 2 fill the options according to the window below. Notice that the option All Users Are Authorized is unchecked. This is due the requirement to allow only the administrators to access this application. After finish this window, click in Next.

Figure 3 – Application Setup.

4) The step 3 will be to add the FSSMC Server’s name, path and port(s). Before type the address in this window, make sure that you can browse this path from the IAG box itself. After that click in Next.

Figure 4 – FSSMC name (FQDN) and ports.

5) In the step 4 you will select the authentication method that IAG will use to reply the web server’s request. Click in Add and choose your Active Directory Repository.

Note: we are assuming that you already have your authentication repository created. In this particular case we are using the name AD, but you can use any other name.

Figure 5 – Authentication.

6) The final step in this wizard is to type the portal name and review the link (application URL). Click in Finish.

Figure 6 – Portal Link.

Now the application is already created the next step is to review the authorization.

4. Authorization

Following the request from the customer, the next step is to configure which group of users has authorization to launch this application. Open the properties of the application and follow the steps below:

1) Click in the Authorization tab and the following window will appear:

Figure 7 – Authorization window.

2) Click in the Add button.

3) In the Look in option, choose AD (which is the repository name that I’m using for this application). Double click in the Users container and choose Domain Admins. Click in Add and click OK.

Figure 8 – Users and groups.

4) Notice that the Authorization window will appears like the one below:

Figure 9 – Authorization window.

5) Click OK.

Now that you have the application and the authorization configured, click in the Activate button to commit the changes.

5. Testing

Now when the administrator connects from outside and access the application, the Forefront Security Management Console appears in the IAG window like this:

Figure 10 – Accessing FSSMC from IAG.

6. Why not use ISA Server for this solution?

This sound like a MCSE Exam question: choose the most appropriate answer according to the scenario. In this case it is simple to identify the points that makes IAG the correct solution. Let’s review the customer’s requirements:

Requirement	Why Not ISA?	IAG, why?
“..a central solution”	Customer doesn’t want to access multiple URLs. He wants to connect to a single place where he can launch the applications from there.	Customer already has an IAG portal implemented. Only one single location and single portal is already in place.
“The solution needs to verify if the computer where the remote engineer is connected from is compliance with our security policy.”	It doesn’t do endpoint security policy compliance.	It allows you to configure endpoint security policy detection very granular.

What option you will choose for the final deployment will really vary according to your customer’s need. It is important to look at all aspects of the solution so you can address all their needs. There will be situations where the ISA will cover aspects that IAG will not cover. For more information about considerations when to use one or the other (better together) review the following articles:

http://www.microsoft.com/Forefront/edgesecurity/iag/en/us/faq.aspx

http://www.microsoft.com/forefront/edgesecurity/iag/en/us/secure-remote-access.aspx

Author

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – TX

Technical Reviewer

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – WA