Forefront Threat Management Gateway (TMG) 2010 Web Proxy Client Redundancy Deep Dive (Part 3) – Enable Kerberos Authentication in Load Balanced Scenarios

If you would like to read the other parts in this article series please go to:


Forefront TMG 2010 Enterprise edition allows an administrator to configure clustered arrays of TMG firewalls to provide redundancy, high availability, and scalability. In a forward (outbound) web proxy scenario there are several options to configure redundancy for the web proxy array, and choices to make when configuring web proxy clients. In part one and two of this series on web proxy client redundancy we covered the DNS and web proxy client configuration options in detail. Here in the final article of this three-part series I’ll explain how to enable Kerberos authentication in load balanced scenarios.

NTLM vs. Kerberos

The default configuration for TMG is to use Integrated Windows Authentication (IWA) for requests that require authentication, as shown here.

Figure 1

In this configuration, a domain-joined TMG firewall configured for authenticated web proxy access will transparently authenticate users using one of two authentication protocols – NTLM or Kerberos. Either method will successfully authenticate the user. The primary drawback to using the NTLM protocol for authenticating web proxy requests is that the TMG firewall must pass each authentication request to a domain controller for verification. Unfortunately, this is done in serial fashion over the secure channel the TMG firewall has established with a domain controller. Further complicating matters is that fact that the secure channel is established to only a single domain controller. In very busy environments this can become a significant bottleneck that results in users being intermittently prompted for authentication and in some cases failed authentication attempts. Kerberos authentication is more efficient in this respect, as the client is required to contact a domain controller itself in order to obtain a valid Kerberos ticket to access the requested resource, thereby removing this burden from the TMG firewall and reducing resource consumption for authenticated web proxy access. For a thorough explanation of the Kerberos authentication protocol, click here. In part two of this series we reviewed client configuration changes that enabled leveraging Kerberos for authentication. To enable Kerberos authentication for load-balanced scenarios, additional configuration changes must be implemented on the TMG firewall itself.

Kerberos Authentication in Load Balanced Scenarios

To improve scalability and performance for Forefront TMG 2010 Enterprise arrays, a new feature included with Service Pack 2 (SP2) for Forefront TMG 2010 provides the ability to leverage Kerberos authentication for forward (outbound) web proxy requests in load balanced scenarios. This feature was designed to support web proxy clients that have been configured to resolve the proxy array name to the Network Load Balancing (NLB) virtual IP address (VIP). It can also be used in a scenario where web proxy clients resolve the proxy array name to multiple IP addresses via DNS round robin (DNS RR).

Preparing for Kerberos Authentication

To support Kerberos authentication for web proxy requests in load balanced scenarios, the Forefront TMG 2010 firewall service must be configured to run in the context of a domain user account. The account should be configured so that the user cannot change password and that the password never expires. The password should also be very long and complex. Following best practices for creating a domain service account, the account should not have any rights or privileges on the domain and should be removed from the default Domain Users global group. In addition, the account should not be used for any other purposes other than the Forefront TMG 2010 firewall service and should be closely audited. Since the account must be the member of at least one group, create an empty placeholder global group that has no rights or permissions on the domain and specify that as the TMG service account’s primary group.

Figure 2

There is no need to configure any rights or permissions for the service account on the Forefront TMG 2010 firewall itself. TMG will configure the appropriate rights and permissions for the service account automatically, and it will remove those rights and permissions later if the account is removed from the TMG configuration. For these reasons, do not attempt to configure the Forefront TMG 2010 firewall service to run in the context of a domain account using the Services control panel applet. This is not supported and will not work.

Next, a Service Principal Name (SPN) corresponding to the proxy array name must be registered in the Kerberos database for the service account using the setspn.exe tool. From an elevated command prompt, enter the following command:

setspn.exe –u –s http/<array_name> <account_name>

For example, if TMG is configured to use service account called tmgsvc and the web proxy clients are configured to use the array name, the command would look like this:

setspn.exe –u –s http/ tmgsvc

Most documentation I’ve read suggests using the –A switch, but as I’ve demonstrated here I prefer to use –S because it will not register the SPN if a duplicate name exists.

To verify that the SPN was successfully registered, enter the following command:

setspn.exe –q http/

Configure TMG for Kerberos Authentication

To configure the TMG firewall service to run in the context of the domain user account created earlier, open the management console, right-click the array node and choose Properties. Select the Credentials tab, then choose the option to Use this account.

Figure 3

Click the Set Account button and enter the TMG service account credentials.

Figure 4

Be careful when entering the credentials, as TMG does not validate this account before applying the configuration and restarting the services. If the specified account or password is incorrect, TMG will restart the firewall service using the Network Service account and log an alert.

Figure 5

Important Note:
If the array on which you are configuring Kerberos authentication for forward web proxy requests is also used for reverse proxy and there are published web sites leveraging Kerberos Constrained Delegation (KCD), you must enable KCD for the firewall service account, not the computer account.

Verifying Kerberos Authentication

To verify that web proxy clients are using Kerberos authentication you can use the klist.exe tool to view the client’s Kerberos tickets. If configured correctly, the client will have a Kerberos ticket for the SPN that corresponds with the proxy array name, as shown here:

Figure 6

You can also view the communication between the client and the server using a network protocol analyzer. If configured correctly you will see the client request and successfully receive the service ticket for the SPN http/ from the Kerberos Key Distribution Center (KDC).

Figure 7


In this final article of a series on web proxy client redundancy we discussed the different authentication protocols used by the TMG firewall (NTLM and Kerberos) and explained why Kerberos is essential to maintaining the highest levels of performance and throughput for authenticated web proxy requests. We also reviewed the configuration changes required to enable Kerberos authentication in load-balanced scenarios and covered how to confirm that Kerberos authentication is actually taking place. Ensuring that our highly available TMG firewall clustered arrays are optimally configured to make the most efficient use of resources requires careful planning and consideration. Proper DNS, web proxy client, and TMG firewall configuration together can effectively enable TMG enterprise arrays to flexibly scale to meet the availability and throughput demands of even the largest enterprise deployments.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top