Archive

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 Florence.contoso.com and Firenze.contso.com 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 SP2Array1.contoso.com 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 SP2Array1.contoso.com 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 contoso.com

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 SP2Array1.contoso.com on this user account. You can register the SPN, using the setspn command line tool.

Here’s how to register the SPN for SP2Array1.contoso.com on the account TMGSP2KRB:

setspn –A http/SP2Array1.contoso.com 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

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)

With the upcoming release of Unified Access Gateway 2010 (UAG) Service Pack 1, we decided it was important to discuss some important scenarios that many of our customers have asked us about. These scenarios are:

Business Continuity

Disaster Recovery

Multi-Geo (Multi-site) deployment

We believe that support for each of these scenarios is important for an enterprise ready solution. Business continuity and disaster recovery needs to be part of any solution designed to provide your users seamless and transparent connectivity to resources that give your firm a competitive advantage. In addition, support for multiple, geographically dispersed sites is also considered important in an era of international business can travel and we consider support for this scenario to be central in our near term goals for UAG.

While UAG Service Pack 1 (UAG SP1) can provide you basic support for business continuity, disaster recovery and multi-geo scenarios, we want you to know that we plan to address each of these scenarios with a post-UAG SP1 update and that work is already underway.

However, until we are able to deliver this update to you, we want to provide you some guidance for supported workarounds for these scenarios.

Business Continuity and Disaster Recovery

In the area of business continuity and disaster recovery we recommend that you create a “mirrored” installation of your UAG DirectAccess server or array. This can be a hot or cold standby that is configured with the same IP addresses as the production server or array. If the production array should fail, you can bring up the standby server or array and take advantage of ISP subnet redundancy so that traffic is routed to the backup deployment. When the primary UAG DirectAccess server or array comes back up, you take down the backup and route the traffic back through the original route.

There are two primary scenarios to consider when deploying UAG SP1 DirectAccess servers or arrays in multiple locations:

Your intranet resources are all IPv4

Your intranet resources are a mix of IPv4 and IPv6

Intranet Resources are all IPv4

If all your intranet resources are accessible only through IPv4 addresses (IPv4-only network), then you will take advantage of the UAG SP1 NAT64/DNS64 IPv6 to IPv4 protocol translator. In this scenario the source IP address of the incoming connections from DirectAccess clients is always an internal IP address on the UAG DirectAccess server or array. Your existing IPv4 routing infrastructure will be able to route these connections from the UAG DirectAccess server or array to the destination resource and responses back to the UAG DirectAccess server or array that the DirectAccess client is connected to. In this scenario you do not need to worry about IPv6 routing on the intranet.

You would install multiple UAG DirectAccess servers or arrays and apply the DirectAccess client and server settings by using different GPOs (which are specific to the particular UAG DirectAccess server or array)and assigning those GPOs to different OUs or security groups. If you are using a pre-SP1 deployment of UAG, you can use the methods discussed in the blog post http://blogs.technet.com/b/edgeaccessblog/archive/2010/02/18/deep-dive-into-uag-directaccess-tweaking-the-gpos.aspx to deploy the settings to different OUs. If you plan to deploy this scenario with UAG SP1, you can take advantage of the new GPO deployment features included in UAG SP1 which make custom deployment of GPOs to OUs or security groups available in the UAG DirectAccess wizard.

This method enables you to assign a fixed number of clients (based on the fixed number of computer accounts that belong to an OU or security group that you configure) to each UAG DirectAccess server or array. While this method allows for a static level of load balancing (DirectAccess clients can be split relatively evenly between servers or arrays), this approach does not allow users to change which array they connect to. This change requires that an administrator move the computer account to a different security group or OU.

Intranet Resources are IPv4 and IPv6

In this scenario, you would take advantage of the same distribution of DirectAccess clients are you would with an IPv4-only intranet – by assigning clients to a specific UAG DirectAccess server or array through the use of different GPOs or security groups. What changes in this scenario is how you handle the IPv6 routing requirements in a geographically distributed environment.

In this scenario you can configure a single ISATAP cloud and deploy multiple ISATAP routers that are on-link with the UAG DirectAccess server or array at each location. To make this work, you need to do the following:

Prevent DirectAccess clients from connecting to the UAG DirectAccess server or array using the 6to4 protocol. You can accomplish this by blocking IP Protocol 41 inbound through your edge firewalls.

Install an ISATAP router on the same link as the internal interface of the UAG DirectAccess server or array (that is to say, on the same physical or virtual segment).

Allocate a /64 ISATAP prefix for your entire intranet and use the same prefix for all your ISATAP routers.

On each of the ISATAP routers, add a specific /64 Teredo route, based on the Teredo address space that is generated by the UAG for that server’s or array’s clients.

On each of the ISATAP routers, add a specific /64 IP-HTTPS route based on the IP-HTTPS address space that is generated by UAG for that server’s or array’s clients.

Add a resource record for ISATAP for each ISATAP router. ISATAP hosts will receive all ISATAP resource records from the DNS server and will send router solicitation requests to each ISATAP server so that the ISATAP hosts are aware of all routes back to DirectAccess clients.

One other thing worth highlighting is the fact that the ISATAP Router needs to be configured with two IPv6 addresses:

The ISATAP address is used by the entire organization to reach the ISATAP router

The native IPv6 address is used on the ISATAP router to communicate with the UAG server

Figure 1 provides a high level overview of what this configuration looks like.

Figure 1 Workaround for an intranet with IPv6 ISATAP resources

Figure 1 shows that the ISATAP router in Asia is configured with routes for the Asia UAG Teredo and IP-HTTPS address space to the Asia UAG DirectAccess server. It also shows that the ISATAP router in the USA is configured with routes for the USA UAG Teredo and IP-HTTPS address space to the USA UAG DirectAccess server.

If you have some experience with IPv6 and ISATAP, the configuration should not be too difficult to accomplish. However, if you would like to see how this configuration works in a Test Lab, we plan to publish a Test Lab Guide – Test Lab Guide: Demonstrate UAG SP1 DirectAccess in a Multi-Site Configuration soon after the release of UAG SP1, which should help speed you understanding of the overall solution. For a list of current UAG Test Lab Guides, be sure to check out UAG DirectAccess Test Lab Guide Portal page at http://social.technet.microsoft.com/wiki/contents/articles/uag-directaccess-test-lab-guide-portal-page.aspx