Configuring ISA Firewalls (ISA 2006 RC) to Support User Certificate Authentication using Kerberos Constrained Delegation (Part 1) – Front-end/Back-end Exchange Server Publishing Scenario

Discuss this article on the Web Boards at http://tinyurl.com/zlcw6

If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our ISAserver.org Real-Time Article Update newsletter.

NOTE: This article builds on the principles and configuration discussed in the article series starting at Publishing Outlook Web Access and Outlook RPC/HTTP with ISA Server 2006 Enterprise Edition Firewalls using Forms-based Authentication (Single Member Array without NLB). I highly recommend that you read all four parts of that series before you try out the configuration discussed in this article. There are a number of critical networking and ISA firewall concepts discussed in that series which are pivotal to making the configuration discussed in this article work correctly.

One of the major improvements included in the new ISA firewall is the ability to support delegation of Kerberos credentials for users that authenticate with the ISA firewall using User Certificates. ISA Server 2006 support for Kerberos Constrained Delegation (KCD) allows users to present a User Certificate to the ISA firewall and have that user’s credentials automatically forwarded to the destination Web server. This prevents users from having to provide credentials a second time.

With ISA 2004, when a user pre-authenticated at the ISA firewall using a User Certificate, the credentials were not forwarded to the destination Web server. If the destination Web server also required authentication, the user would be presented with a second authentication prompt. While this represented a mild inconvenience for users logging in with PC based Web browsers, it was an even bigger problem for Windows Mobile devices configured for User Certificate authentication. In addition, the fact that the users were challenged to manually enter user credentials represents a security issue, as “shoulder surfers” could potential gain information about that users credentials.

Another significant problem the new ISA firewall’s KCD support solves is related to User Certificate provisioning and Active Directory configuration. In order to fully leverage User Certificate authentication with ISA 2004, you had to deploy the User Certificate and then go through a fairly complex process of binding that certificate to the user account in the Active Directory. With KCD, you don’t have to bind that certificate to the user account. This leads to an enormous reduction in administrator overhead.

NOTE:
Throughout this series and in all future articles I write about User Certificate authentication, I will use the term user certificate and not client certificate. The term “client certificate” is confusing and non-specific. What type of client? A machine client? A user client? A service client? What’s the difference between machine authentication and user authentication? Isn’t the calling computer that presents its machine certificate to the destination server in some scenarios a “client” of the destination server? Is this type of authentication “client certificate” authentication? By using the term User Certificate I make very clear the type of certificate required and how that User Certificate is used in practice.

Why Deploy User Certificate Authentication?

Why would you want to use User Certificate authentication?

• User certificate authentication prevents users from logging into their mailbox using OWA from an unmanaged device. The nightmare of every Microsoft network security professional is the thought of some hapless user at an airport dropping a dime into the public Internet kiosk and having the key logger installed on the device steal an executive user’s user name and password
• You can configure your Windows Mobile clients with User Certificates so that only managed Windows mobile devices are allowed to authenticate with the ISA firewall. This is easy to do as you can deploy your own enterprise CA and then configure the ISA firewall to only trust certificates issued to a small group of certificate authorities (such as Microsoft) that users would not be able to obtain User Certificates from. The ISA firewall then only accepts User Certificate issued by your CA. We’ll examine how to use some new features in ISA Server 2006 firewall to control what User Certificates are valid for connections to the ISA firewall
• Smart cards contain User Certificates. The KCD feature enables you to use Smart cards for user log on to Web sites published by the ISA firewall, include all Exchange Server Web services and SharePoint Portal Server Web services.

KCD is one of the two killer features and must haves that you should check out before even considering an inferior solution, such as Blue Coat. The other must have feature included with the new ISA firewall is the Web Farm Load Balancing feature that I discussed in my last article. The only drawback at the time I wrote this article is that there is almost no documentation available on how to actually get the KCD mechanism to work with ISA firewall Web Publishing. The current publicly available information indicates that you have to configure the Active Directory to allow delegation. Now I don’t know about you, but as a network security and infrastructure guy, I don’t spend a heck of a lot of time with the Active Directory and it’s inner workings, so I had no idea what to do with this information.

I spent about 12 hours trying to figure this out for myself but finally threw in the towel because I was running out of “wheel spinning” time. I enlisted the help of two fine Microsoft employees, Avi Yaar and Tomer Shiran. They helped me put the pieces together so that I can show you how publish your FE Exchange Servers in a front-end/back-end Exchange Server deployment scenario.

At this time I do need to note that the Microsoft Exchange team does not officially support this deployment scenario. The reason for this is that in order to make this work, we must enable Integrated authentication on the /Exchange directory on the FE and BE Exchange Servers. However, I’m hopeful that some time in the future this becomes a fully supported scenario. Regardless of the level of support from the Exchange team, it does work so if you want to try it out now in your labs to show that there is no adverse impact on your production environment, then get right to it.

Assumptions and Requirements

In this article I will build on the same network environment I set forth in the article series Publishing Outlook Web Access and Outlook RPC/HTTP with ISA Server 2006 Enterprise Edition Firewalls using Forms-based Authentication (Single Member Array without NLB). There are several key elements to this network configuration that are required to make this work:

• All machines must be members of the same Active Directory domain. You can’t get funny and create the dreaded “one way trust” hork that creates an illusion of security. If you have some hesitation joining your ISA firewalls to the domain because of some promulgated misinformation, then head on over and read the White Paper Debunking the Myth that the ISA Firewall Should Not be a Domain Member. After you read that White Paper, you’ll never again worry about joining the ISA firewall arrays to the domain
• The domain must set at the Windows Server 2003 Functional Level
• You have deployed a PKI so that you assign the machine and User Certificates

These are the core requirements, but make sure to check out this article for a detailed account of the lab configuration. In this article I build on network environment configured in that series of articles, so I will assume that you have your entire network infrastructure in place, have your machine certificates deployed, the ISA firewall software installed, and that you’re ready to make the Active Directory changes required and create the Web Publishing Rule.

As a refresher, the lab environment looks like this:

Figure 1

Table 1 provides key information about the configuration of each of the machines in the lab.

Table 1: Configuration Information for Lab Machines

In order to get User Certificate authentication with Kerberos Constrained Delegation to work, you’ll need to do the following:

• Configure the Computer Accounts to be trusted for delegation
• Configure the /Exchange Directories and Create the Web Publishing Rules
• Test the Configuration

In this article we’ll configure the computer accounts to be trusted for delegation and then in part two we’ll create the Web Publishing Rules and test the configuration.

Discuss this article on the Web Boards at http://tinyurl.com/zlcw6

Configure the Computer Accounts to be trusted for Delegation

The FE Exchange Servers must be configured to trust the Kerberos ticket obtained on the behalf of the user who authenticated via User Certificate authentication at the ISA firewall. In addition, the BE Exchange Server must be configured to trust the Kerberos ticket obtained from the FE Exchange Servers.

The process seems simple in concept, but when you actually try to configure these trusts, you feel like you’re in the middle of a pinwheel and you’re spinning as fast as it can.

The reason for this is that the Active Directory guys have it all backwards. Why backwards? Backwards because when I configure the FE Exchange Servers to trust the ISA firewall’s tickets, I do the configuration on the ISA firewall’s machine account in the Active Directory. This is like saying in order to get Alice to trust Bob, I’ll go to Bob to create that trust. Wouldn’t it make more sense to go to Alice to create that trust?

Regardless if it makes any sense or not, that’s how we have to do things. To create the FE Exchange Servers trust of the ISA firewall’s tickets, perform the following steps:

1. At the domain controller (DC in our scenario) click Start, and then point to Administrative Tools. Click the Active Directory Users and Computers link.
2. In the Active Directory Users and Computers console, expand the domain name and click the Computers node. In the right pane of the console, double click the name of the ISA firewall. In this example, the ISA firewall is named ISA2006SE.

Figure 2

3. In the ISA2006SE dialog box, click the Delegation tab. On the Delegation tab, select the Trust this computer for delegation to specified services only option. Then select the Use any authentication protocol option. After selecting these two options, click the Add button.

Figure 3

4. In the Add Services dialog box, click the Users or Computers button.

Figure 4

5. In the Select Users or Computers dialog box, enter the NetBIOS names of the front-end Exchange Servers. In this example, the NetBIOS names of the front-end Exchange Servers are FE1EXCHANGE and FE2EXCHANGE2003. If you don’t remember the names of your own FE Exchange Servers, you can use the Advanced button to find them. Click OK.

Figure 5

6. In the Add Services dialog box, scroll down the list of available services and find the http service. Hold down the CTRL key and select all of the Exchange FE servers. Click OK.

Figure 6

7. On the Delegation tab of the ISA firewall’s computer account, you should now see the names of both the FE Exchange Servers and the Service Type should be listed as http. Click OK.

Figure 7

You have now successfully configured the ISA firewall’s machine account to tell the FE Exchange Servers machines to trust the ISA firewall’s tickets it obtains on behalf of the user who authenticated with the ISA firewall using User Certificate authentication.

The next step is to configure the BE Exchange Server to trust the tickets provided by the FE Exchange Servers. Perform the following steps to achieve this goal:

1. In the Active Directory Users and Computers console, double click on the one of the FE Exchange Servers. In this example, we’ll double click on the FE1EXCHANGE computer account.
2. In the FE1EXCHANGE Properties dialog box, click on the Delegation tab. On the Delegation tab, select the Trust this computer for delegation to specified service only option and then select the Use any authentication protocol option. Click the Add button.
3. In the Add Services dialog box, click the Users or Computers button.
4. In the Select Users or Computers dialog box, enter the name of the BE Exchange computer. If you don’t remember the name, use the Browse button to find the machine.
5. In the Add Services dialog box, select the http service for the BE Exchange computer and click OK.
6. Click OK in the FE1EXCHANGE Properties dialog box.

Figure 8

7. Repeat the procedure for all other FE Exchange Servers.

Discuss this article on the Web Boards at http://tinyurl.com/zlcw6

Summary

In this, part 1 of a two part series on how to configure the ISA Server 2006 firewall to support Kerberos Constrained Delegation, I went over some key principles and requirements to make the Kerberos Constrained Delegation publishing solution work. Then we went over the details of configuring the required trust relationships so that constrained Kerberos delegation was properly setup between the ISA firewall and the FE Exchange Servers and the FE Exchange Servers and the BE Exchange Server. In the next (and I promise) last part of this series, we’ll create the Web Publishing Rules and test the configuration. See you then! –Tom.

If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our ISAserver.org Real-Time Article Update newsletter.