Archive for the ‘SP2’ Category

New in SP2: Improved Error Pages

October 13th, 2011 No comments

In TMG 2010 Service Pack 2, we put our focus on bug fixing, in order to improve the overall experience with TMG 2010. However next to pure bug fixing, we also introduced some new features.

In this article we’ll provide a quick introduction to the new error pages and will provide a brief overview of how to modify them.

For more information please visit the Technet documentation about Customizing HTML error messages, which has been updated to reflect the changes in SP2.

In TMG SP2 you can now configure TMG to use an improved version of Error Pages. With these new error pages you now have the option to include pictures, e.g. including your company logo on the error page.

In order to configure TMG to use the new version of error pages, you have to open the TMG MMC, right-click the Array and select Properties:


There’s a new tab called “Error Pages”:


As described in the UI, the new version of error pages can be found in the TMG installation directory \Templates\WebObjectsTemplates\ISA. After applying the changes the TMG Firewall service has to be restarted.

The new error pages will look like this when they are not modified:


If you want to modify the pages, there are two default HTLM error files in the \Forefront Threat Management Gateway\Templates\WebObjectsTemplates\ISA folder that can be used as templates for creating additional HTML error message pages, Default.htm for internal clients and DefaultR.htm for external clients.

In the new error pages directory you can find a subdirectory HTML, containing the following files:


These image files will be used in the error pages. If you want to modify things like the Logo, you can do this by simply replacing the image files with your corporate identity logos, without having to modify the template html files.

Another option is to copy the objects/pictures you want to embed into the error pages into the HTML directory and add the reference into the error pages, like this: <img src="HTML/MyImage.gif"> </img>.For detailed information have a look at this Technet article.

Note: Before modifying the error pages or the image files, we strongly recommend to create a backup of the original files! Please be aware that you have to restart the Firewall service to use the modified images.

In my example I just performed some simple modifications to the logo.png file. Here’s how the modification might look like:


I’m sure you can do much nicer modifications though Smiley

Philipp Sand
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
James Kilner
Technical Writer

Categories: customize, SP2, TMG Tags:

New in SP2: Site Activity Report

October 12th, 2011 No comments

Have you ever been interested in which users visit specific sites on the Internet very often? E.g. which users did browse most on last week? In SP2 we added a new report, which allows analyzing the usage of specific sites connected to users in your organization, with a few mouse clicks.

In order to create the report you have to open the TMG MMC / Logs & Reports:


On the right hand side you can select “Create Site Activity Report”.

In the Wizard you can configure how many sites will be reported per user and how many users will be included in the report:


Be aware that in the default setting the Site Name parameter is OVERWRITE. You have to enter the parameter of your choice here. In this example I used, you can also use parameters like .com to see all requests to “.com sites” or narrow down to if you like to see only request to

Here’s how a report can look like:


Be aware that you’ll only see the user name, if you’re using proxy authentication in your environment and if you’re logging the user name. If no proxy authentication is enabled, or specific rules don’t require proxy authentication, you will also see the “anonymous” user in the report.

Philipp Sand
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Roman Golubchyck
Senior SDET TMG Product Group

Categories: report, SP2, TMG Tags:

New in SP2: Kerberos Authentication in Load Balanced Scenarios

October 12th, 2011 No comments

In TMG 2010 Service Pack 2, we did put our focus on bug fixing, in order to improve the overall experience with TMG 2010. However next to pure bug fixing, we also introduced some new features.

One of these new features introduces the possibility to allow Kerberos Authentication when connecting to TMG in a “High Availability” (HA) scenario.

Consider the scenario, where you have a TMG array of two or more nodes. Let’s call them and in this scenario. Both nodes are member of a Domain, and you require Proxy Authentication to authenticate your user for Forward Proxy Access. You enabled Load Balancing on the internal network, e.g. by enabling TMG Integrated NLB, the NLB VIP in your internal network resolves to in this example setup.

Why didn’t Kerberos authentication work in a HA scenario before?

In the given scenario your user could already use Kerberos to authenticate the proxy requests. They could only do this though, when using the FQDN of either one of the nodes, e.g. when using a WPAD file with both proxy FQDN included (see this article to find out how to configure FQDN in the WPAD file), or when connecting to only one node’s FQDN. It wasn’t possible to use Kerberos when connecting to the NLB virtual IP address or when installing a load balancer between the client and the TMG array to balance the requests. As Tom Shinder summarizes in the article CARP and High Availability – Not So Much, the setup using WPAD with multiple FQDNs included, provides some load balancing mechanisms like Client CARP, but it shouldn’t be considered as a HA scenario.

The reason for this limitation is directly connected to the Service Principal Names (SPN), which uniquely identifies an instance of a service. A web client (such as a browser) that uses Kerberos to authenticate against the proxy uses the proxy name as it knows it to construct the SPN for the client-to-proxy authentication. For Domain’s computer accounts, a respective SPN with the computer’s FQDN is created automatically when the computer is joined to the domain. This SPN is associated with the computer account so processes running as NETWORK SERVICE principal, such as TMG’s Firewall Service, can authenticate clients through Kerberos tickets referring to this SPN. In HA scenario all array members need to be able to authenticate such tickets because the client may connect to any array member. However, SPNs have to be registered on only one account. If you register the SPN on multiple accounts in your active directory, you will end up with duplicate SPNs, which can lead to quite unpredictable behavior in your AD. For further details here’s the MSDN description for SPNs:

A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. For more information about SPN format and composing a unique SPN, see Name Formats for Unique SPNs.

Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account object that the service instance uses to log on. A given SPN can be registered on only one account. For Win32 services, a service installer specifies the logon account when an instance of the service is installed. The installer then composes the SPNs and writes them as a property of the account object in Active Directory Domain Services. If the logon account of a service instance changes, the SPNs must be re-registered under the new account. For more information, see How a Service Registers its SPNs.

When a client wants to connect to a service, it locates an instance of the service, composes an SPN for that instance, connects to the service, and presents the SPN for the service to authenticate. For more information, see How Clients Compose a Service’s SPN.

Before TMG SP2, the Firewall Service (the process hosting the Web Proxy and hence the one authenticating proxy clients) could only run under the NETWORK SERVICE account. Therefore it could authenticate only tickets that refer to SPNs associated with the respective computer account. If you considered to register the SPN for in this setup, you would need to register the SPN on each one of the array nodes computer accounts, which leads to duplicate SPNs in your AD and isn’t a valid configuration.

What did change in SP2 to allow Kerberos Authentication in HA scenarios?

In SP2 we introduced the possibility to configure the TMG Firewall Service to run in a context of a user account. With this new possibility it’s now possible to use Kerberos for HA scenarios, as you can register the SPN for the “HA-IP address” FQDN on the user account that is configured for Firewall Service.

How to configure Kerberos Authentication in TMG HA scenarios?

1. You need to configure a domain user account, which will be used as “TMG Firewall service account” in the future. In this example the Account name I use is TMGSP2KRB in Domain

Recommendations for creating the user account to help protect your domain:

· The domain account that you use for the TMG Firewall service is not a member of any local or domain groups. However, since an account must be a member of at least one primary group, define a new placeholder group and use that as the primary group. Make sure that the placeholder group does not have any permission or user right on any domain resource.

· The domain account has no permissions or user rights on any domain resource.

· The domain account is used only for the TMG Firewall service and not for any other purpose within the domain.

Forefront TMG grants the domain account the minimal permissions required on the TMG array nodes when you configure it for the Firewall service and removes the permissions when you configure a different account. Hence, do not manually grant any permission for that user on the TMG array nodes.

2. You need to register at least the SPN for on this user account. You can register the SPN, using the setspn command line tool.

Here’s how to register the SPN for on the account TMGSP2KRB:

setspn –A http/ TMGSP2KRB

In order to be able to use Kerberos when connecting to the FQDN of each individual node, we recommend to register the additional SPNs for each FQDN on the service account as well.

In the end you can use setspn –L TMGSP2KRB to list the SPNs which had been added to the user account. In this example scenario this will look similar to this:


3. With the account all setup, we can now open the TMG MMC of the array to complete the TMG configuration of this scenario.

Right-click the Array name and select properties:


Select the Credentials Tab to configure the service account:


Apply the settings. Please be aware, that the TMG Firewall Services needs to be restarted for this change to take effect. A proper prompt will be displayed when applying the configuration changes. It is also recommended to restart the TMG Admin console (MMC) in this case.

After successfully applying the change, you can open the Services.MSC to verify if the changes were applied successfully.

If applied successfully, you’ll notice, that the Microsoft Forefront TMG Firewall Service will Log On As contoso\TMGSP2KRB now:


When you configure Proxy Authentication now, and collect a network trace on one of your clients, the trace will look similar to this when you connect to your favorite technet blog Smiley


Notice that the client is using GSS-API Authorization which is the equivalent to Kerberos Authentication in Netmon 3.4.

If your client still tries to use NTLM, and the trace looks like this:


make sure that you Enabled Windows Integrated Authentication in the Advanced Internet Explorer Settings:


Without Integrated Windows Authentication the client will try to use NTLM instead of Kerberos. (Please don’t ask me why this setting had been named like this, as Kerberos and NTLM are both Integrated Windows Authentication types as far as I know J)

Philipp Sand
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Oved Itzhak
Senior SDE TMG Product Group

Categories: authentication, Load Balancing, NLB, SP2, TMG Tags:

Forefront TMG Service Pack 2 Now Available

October 12th, 2011 No comments

We are happy to announce the availability of Forefront Threat Management Gateway (TMG) 2010 Service Pack 2 (SP2). The service pack is available for download from the Microsoft Download Center.

Here are some of the improvements we are introducing in Forefront TMG SP2:

  • Site activity report – Forefront TMG SP2 includes a new site activity report that enables you to generate a report showing the data transfer between users and specific websites. This report displays the amount of data transferred to and from different websites, for any
    period that you specify, per user. In addition, you can also display the total data transfer to and from a specific website, per user. 
  • Improved error pages – Forefront TMG SP2 improves the look and feel of web browser error pages and makes it easier to customize the pages.
  • Kerberos authentication for NLB arrays – Forefront TMG SP2 enables you to allow users to authenticate to a Forefront TMG array with Network Load Balancing (NLB) enabled using the Kerberos version 5 protocol.

Visit our TechNet Library for more information.

– The Forefront TMG Team

Categories: Forefront, Forefront TMG, SP2, update Tags: