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

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

If you missed part 1 of this two part series, please read Configuring ISA Firewalls (ISA 2006 RC) to Support User Certificate Authentication using Constrained Delegation (Part 1) – Front-end/Eack-end Exchange Server Publishing Scenario.

In part 1 of this two part series on how to publish a pair of front-end Exchange Servers in a front-end/back-end Exchange configuration using an ISA firewall to provide User Certificate authentication, I discussed the advantages of User Certificate authentication, the improvements the new ISA firewall brings to User Certificate authentication scenarios, and the base requirements for getting the solution to work.

In this article we’ll finish up by discussing the following topics:

• Configuring the Exchange Directories and Creating the Web Publishing Rules
• Fixing the Web Publishing Rules
• Testing the Configuration
• Advanced User Certificate Authentication Options

Configure the Exchange Directories and Create the Web Publishing Rules

In order to support Kerberos Constrained Delegation, the FE and BE Exchange Servers need to be configured to support Integrated authentication on the /Exchange directory. If you check the configuration on your FE and BE Exchange Servers, you’ll see that this isn’t the default configuration, and if you call PSS with a problem, they’ll probably tell you that this configuration is not supported and you should not enable Integrated authentication on these directories. This is the chance you take when you deploy a high security configuration, but I expect that the Exchange team will come up with updated guidance and configuration information that will make this a support configuration in the future.

The only problem I’ve seen with this configuration (so far) is that when you click on the Log Off link in the OWA interface, you’ll see a Page not found error in the browser. I haven’t done any troubleshooting yet on this issue, but I’m planning on doing an OWA publishing article next week where we publish a single OWA Server using KCD, so by then I should have this problem worked out, or I’ll at least be able to explain my findings and see if the community can come up with a solution.

You need to change the authentication methods allowed on the /Exchange directory on all the FE and BE Exchange Servers. Perform the following steps on each Exchange Server to set the authentication option:

1. Click Start and point to Administrative Tools. Click Internet Information Services (IIS) Manager.
2. In the Internet Information Services (IIS) Manager console, expand the server name, then expand the Web Sites node. Expand the Default Web Site and then click the Exchange node. Right click the Exchange node and click Properties.
3. In the Exchange Properties dialog box, click the Directory Security tab. Click the Edit button in the Authentication and access control frame.
4. In the Authentication Methods dialog box, put a checkmark in the Integrated Windows Authentication checkbox and click OK.

Figure 1

5. Repeat this procedure on each Exchange Server.

Now we’re ready to create the Web Publishing Rule. As we did in the previous article series, we’ll use the Exchange Web Client Wizard to publish the OWA and RPC/HTTP sites. Note that I’ve already created the Web Farm in the previous article series referred to earlier in this paper. If you want to see how to create the Web Farm used in the Web Publishing Rule we’re about to create, check out this article.

Perform the following steps to create the Web Publishing Rules:

1. In the ISA Firewall console, expand the Arrays node and then expand the array name. Click on the Firewall Policy node and then click the Tasks tab in the Task Pane. On the Tasks tab, click the Publish Exchange Web Client Access link.
2. On the Welcome to the New Exchange Publishing Rule Wizard page, enter a name for the rules in the Exchange Publishing rule name text box. In this example we’ll name the rule Exchange Farm. You’ll see later that some changes to the rule names will be required in order to determine exactly what the specific rules are for. Click Next.
3. On the Select Services page, select the Exchange Server 2003 option from the Exchange version drop down list box. Select the Outlook Web Access and Outlook RPC/HTTP(s) checkboxes from the Web client mail services options. Click Next.

Figure 2

4. On the Publishing Type page, select the Publish a server farm of load balanced Web servers option and click Next.

Figure 3

5. On the Server Connection Security page, select the Use SSL to connect to the published Web server or server farm. This option tells the ISA firewall to forward the connection request over a secure SSL channel, and this is an ISA firewall best practice. If you did not select this option, the connection would be forwarded over an unsecure channel.

   While the user credentials are not at risk in this scenario because we’re using KCD, the data moving over the link is easily accessible by another with a network sniffer (protocol analyzer). For this reason, unless there are compelling security reasons to enable the low security option (think about the implications of that statement), you should always use SSL from the ISA firewall to the published Web server.

   Click Next.
   
   
   
   

Figure 4

6. On the Internal Publishing Details page, enter the common/subject name on the Web site certificate bound to the FE Exchange Server’s Web sites. In this example, the Web site certificate bound to the FE Exchange Server’s Web sites has the common/subject name of owa.msfirewall.org. You must enter the common/subject name correctly on this page or else you will receive a 500 Internal Server Error when connecting to the site.

   Click Next.
   
   

Figure 5

7. On the Specify Server Farm page, select the server farm you created previously in the Select the Exchange server farm you want to publish drop down list. Click the Edit button. If you previously entered IP addresses for the members of the Server Farm, then you will need to change the entries from IP addresses to either NetBIOS or FQDNs for the members of the Server Farm.

   The reason for this is that these names must match the SPNs registered for these servers. The NetBIOS and FQDNs for the FE Exchange Servers are automatically registered http/ SPNs, so there’s no need to run the setspn utility on these machines.

   After making the necessary changes, click OK in the FE Exch Farm Properties dialog box and then click Next on the Specify Server Farm page.
   
   
   
   

Figure 6

8. On the Public Name Details page, enter the common/subject name of the certificate that will be bound to the Web listener. In this scenario, the common/subject name on the certificate bound to the Web listener is owa.msfirewall.org, so we enter that name in the Public name text box. This is the name that users will use to access the OWA and RPC/HTTP sites, both internally and externally, as described in this article series. Make sure you external and internal DNS zones have the appropriate DNS entries for this name. Details on the DNS configuration can be found here.

   Click Next.
   
   

Figure 7

9. On the Web Listener page, select the listener we created over here. In this example, the name of the Web listener is Exch Farm SSL Listener. After the Wizard is complete, we’ll need to make some changes to the Web listener so that both the OWA and RPC/HTTP Web Publishing Rules work when using a single IP address on the external interface of the ISA firewall.

   Click Next on the Select Web Listener page.
   
   

Figure 8

10. On the Authentication Delegation page, select the Kerberos constrained delegation option from the Select the method used by ISA Server to authenticate to the published Web server drop down list. In the Type the Service Principle Name (SPN) used by ISA Server for Kerberos constrained delegation text box, accept the default entry http/*  This is required because we are publishing an Exchange FE Server Web farm where the Exchange Web services are running in the context of the local system account.

    Click Next on the Authentication Delegation page.
    
    

Figure 9

11. On the User Sets page, accept the default entry, All Authenticated Users, and click Next.
12. Click Finish on the Completing the New Exchange Publishing Rule Wizard page.
13. Click OK in the dialog box indicating that you must configure Active Directory SPNs to make this work.
14. Click OK again in the dialog box indicating that you must configure Active Directory SPNs to make this work.
15. Click Apply to save the changes and update the firewall policy.
16. Click OK in the Apply New Configuration dialog box.

Fixing the Web Publishing Rules

There are still a few things we need to do in order to get the solution working. At the point the OWA Web Publishing Rule using KCD works right out of the box and you can test it now to confirm if you like. However, you’ll find that the RPC/HTTP Web Publishing Rule will not work. There are two problems:

• The default settings on the Web Listener require all users to authenticate
• The authentication delegation option on the RPC/HTTP Web Publishing Rule is set to Kerberos Constrained delegation
• The condition on the rule is set to All authenticated users

We have to make changes to the Web listener and RPC/HTTP Web Publishing Rule configuration because the Outlook RPC/HTTP client does not support User Certificate authentication. Because of this, we have potentially two options:

• Disable pre-authentication on the ISA firewall for RPC/HTTP connections
• Configure a fallback authentication method for the RPC/HTTP connections

We can disable pre-authentication at the ISA firewall for RPC/HTTP connections. This would be unfortunate, as one of the major advantages of bringing an ISA firewall onto the network is to prevent attacks from anonymous users who wish to compromise out FE Exchange Servers.

A possible solution to this problem would be to provide a fallback mechanism so that clients that are unable to authenticate via Kerberos Constrained Delegation could use another form of authentication, such as Basic Authentication. In ISA Server 2006 firewall interface there is a suggestion that this is possible in the configuration of the Web listener.

To view this possible option, double-click the Exchange Farm RPC/HTTP(s) Web Publishing Rule and click the Listener tab. On the Listener tab, click the Properties button. In the Exch Farm SSL Listener Properties dialog box, click the Authentication tab.

Notice on the Authentication tab you have the option to Use a fallback authentication method. Enable that checkbox and click the Configure button.

Figure 10

This brings up the SSL Fallback Authentication Method dialog box. Here you can select HTTP authentication methods: Basic, Digest and Integrated. Since the Outlook RPC/HTTP client supports basic authentication, let’s enable the Basic checkbox, as seen in the figure below.

Figure 11

Click OK in the SSL Fallback Authentication Method dialog box and then click OK in the Exch Farm SSL Listener Properties dialog box.

Whoo hoo! It looks like things just might work. The only thing we need to do now so that we can pre-authenticate the RPC/HTTP connections at the ISA firewall is to change the authentication delegation option to delegation of basic authentication. In the Exchange Farm RPC/HTTP(S) Properties dialog box, click the Authentication Delegation tab.

Oh no! If you click the down arrow for the Method used by ISA Server to authenticate to the published Web server drop down list box, you’ll find that you have three options:

• No delegation, but client may authenticate directly This won’t help because we want to pre-authenticate the user at the ISA firewall and have that RPC/HTTP user’s basic credentials delegated to the FE Exchange Server
• No delegation, and client cannot authenticate directly This definitely won’t help, because we need the Outlook RPC/HTTP client to authenticate somewhere, if not at the ISA firewall, then with the FE Exchange Server itself.
• Kerberos constrained delegation This can’t work because the Outlook RPC/HTTP client doesn’t support User Certificate authentication

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

What’s missing here is an option to delegate Basic authentication credentials. This might be a RC bug which will be fixed in the final version of the ISA Server 2006 firewall. But at this time, it’s not possible to pre-authenticate RPC/HTTP connections at the ISA firewall when KCD is enabled on the Web listener. Of course, you could always create a second listener, but that requires a second IP address and second certificate.

Figure 12

It’s important to note here that the limitation is only when there is a single IP address bound to the external interface of the ISA firewall. If you have more than one IP address, you can create a second Web listener. However, this requires that the common/subject name on the certificate bound to the second Web listener be different than the one on the first Web listener, and you’ll need to make the requisite DNS changes to complete a working solution.

In order to get things working in our current scenario, we need to make three changes:

• Change the configuration of the Web listener so that all users are not required to authenticate. This won’t hurt security for the OWA Web Publishing Rule, because the rule will require all users to authenticate
• Change the RPC/HTTP Web Publishing Rule so that RPC/HTTP clients can authenticate directly with the FE Exchange Server
• Change the RPC/HTTP Web Publishing Rule so that no authentication is required for the rule

Perform the following steps to make these changes:

1. Double click on the Exchange Farm RPC/HTTP(S) rule in the ISA firewall console.
2. In the Exchange Farm RPC/HTTP(S) Properties dialog box, click the Listener tab.
3. On the Listener tab, click the Properties button.
4. On the Exch Farm SSL Listener Properties dialog box, click the Authentication tab.
5. On the Authentication tab, click the Advanced button.
6. On the Advanced Authentication Options dialog box, remove the checkmark from the Require all users to authenticate checkbox. Click OK.

Figure 13

7. Click OK in the Exch Farm SSL Listener Properties dialog box.
8. Click the Authentication Delegation tab.
9. On the Authentication Delegation tab, select the No delegation, but client may authenticate directly option from the Method used by ISA Server to authenticate to the published Web server drop down list box.

Figure 14

10. Click on the Users tab.
11. On the Users tab, click the All Authenticated Users entry in the list of users and click the Remove button. Click the Add button.
12. In the Add Users dialog box, double click the All Users entry and click Close.

Figure 15

13. Click OK in the Exchange Farm RPC/HTTP(S) Properties dialog box.
14. A dialog box will appear indicating that the Web listener is still requiring authentication. The reason for this is that the changes we made to the Web listener haven’t been registered yet. Click OK to continue.

Figure 16

15. Click Apply to save the changes and update the firewall policy.
16. Click OK in the Apply New Configuration dialog box.

Test the Configuration

To test the configuration, start the Outlook RPC/HTTP client application. After the connection completely, use the ISA firewall’s built-in log filter to see the traffic that took place in the last 5-10 minutes. You’ll see something like what appears in the figure below.

Figure 17 (Click image to enlarge)

While there is little of use here to troubleshoot RPC/HTTP connections, you should note that even though the connection attempt succeeds, all you see here are failed connection attempts for the Exchange Farm RPC/HTTP(S) Web Publishing Rule. I include this information here to warn you that if something is wrong with your RPC/HTTP Web Publishing Rule, do not take the ISA firewall’s log entries at face value, since in both working and not working scenarios, the log files will indicate that connections related to the Web Publishing Rule have failed.

You can check the Exchange Server Connection Status window on the client machine to confirm that the connection is using RPC/HTTP, as seen in the figure below.

Figure 18

Now start up an OWA connection from the Windows XP client. In contrast to what we see with the RPC/HTTP connections, the log files on the ISA firewall show successful connections for the authenticated user, as seen in the figure below.

Figure 19 (Click image to enlarge)

Advanced Certificate Authentication Options

I left this section for last since it wasn’t really tied into what I wanted to talk about in this article. However, I did want to include some interesting information on a major improvement in the ISA Server 2006 firewall’s advanced handling of User Certificates in a User Certificate authentication scenario.

To view these options, click the Firewall Policy node in the left pane of the console and click the Toolbox tab. In the Toolbox tab, click the Network Objects section and then click the Web Listeners folder. Double click on the Exch Farm SSL Listener entry.

In the Exch Farm SSL Listener Properties dialog box, click the Authentication tab. On the Authentication tab, click the Advanced button. In the Advanced Authentication Options dialog box, click the Client Certificate Trust List tab. You’ll see what appears in the figure below.

Figure 20

Notice the two options you have on this page:

• Accept any client certificate trusted by the ISA Server computer
• Only accept client certificates trusted by the Root Certification Authorities selected below

This is a powerful option and ties into something I said at the beginning of the first part of this two part article series regarding how User Certificate authentication can be used to insure that only corporate managed devices are allowed to connect to the published Web site through the ISA firewall.

For example, suppose I only want managed machines to connect to my OWA site (or OMA or ActiveSync). One way to do this would be to remove all the entries in the machine’s Trusted Root Certification Store except for the CA certificate for our corporate enterprise CA. This could present a problem if we wanted to reach other secure sites from our ISA firewall. While this shouldn’t pose too much of a problem since you shouldn’t be browsing from the ISA firewall at all, the auto-update feature included in Windows requires at least the root CA that issues the certificate to the Microsoft Update site. There may be other circumstances where you might need other root CAs in the ISA firewall’s root trust list.

A better way to handle this problem is to select the Only accept client certificates trusted by the Root Certification Authorities selected below option and then select the corporate CA. Since this applies only to the Web listener, it has no effect on the machine’s certificate store. In the example discussed in this article series, I would select the dc.msfirewall.org CA certificate. Any machine that presents a User Certificate issued by another root CA, even if that CA is included in the Trusted Root Certificate Authorities machine certificate store, will not be trusted and the authentication attempt would fail.

Figure 21

Click on the Client Certificate Restrictions tab. On this tab you have the option to Accept the client certificate only if it matches at least one of the defined restrictions. When you click the Add button you can add restrictions based on:

• Issuer
• Subject
• Enhanced Key Usage
• Extensions

In the figure below you see that I have configured a restriction so that only User Certificates are accepted based on the OID of the User Certificate. User certificate restrictions can work with or instead of the settings you configure in the Client Certificate Trust List tab.

Figure 22

Before leaving the subject of advanced User Certificate authentication options, there is one more configuration I’d like to discuss. In this scenario, you enable HTML forms based authentication and also configure the rule to require a User Certificate. Consider this “one and a half factor” authentication. The user must have a User Certificate on his computer and must be able to enter valid user credentials.

I refer to this as “one and a half factor” authentication because it doesn’t quite have the security of two-factor authentication because if someone steals the computer, they’ll possess the certificate and thus only need to guess the user name and password. In contrast, with full two-factor authentication, if someone steals the computer, he is unlikely to obtain the smart card along with the computer and thus is without smart card and password.

The advantage of requiring a User Certificate when using forms-based authentication is that you can leverage the utility of forms based authentication while at the same time insuring that only corporate managed machines are able to connect. In order to do this, you go into the Properties of the Web listener and click on the Authentication tab. On the Authentication tab, you configure the Method clients use to authenticate to ISA Server as HTML Form Authentication, as seen in the figure below.

Figure 23

This method works with Kerberos Constrained Delegation. Click on the Authentication Delegation tab and select the Kerberos constrained delegation option from the Method used by ISA Server to authenticate to the published Web server drop down list.

Figure 24

The last step is to click on the Traffic tab and then put a checkmark in the Request SSL Client Certificate checkbox, as seen in the figure below. When both forms-based and User Certificate authentication is configured on the ISA firewall, the user will first select his certificate and then the form will appear. The name on the User Certificate must match the name used by the use to authenticate with the ISA firewall.

Figure 25

I know that I’ve only provided a skeleton outline of how to work with the ISA firewall’s new advanced certificate authentication options, but I wanted to give you a taste of what’s coming. In the future I’ll do a series of step by step articles on how to use these advanced certificate options in a number of different publishing scenarios.

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

Summary

In this article series I went over the principles and procedures involved with configuring the ISA firewall to support User Certificate authentication when connecting to Exchange Web services. In this article we went over the details of the Web Publishing Rules and how to tweak those rules so that both OWA and RPC/HTTP would work when User Certificate authentication was enabled on the OWA Web Publishing Rule. We finished up with a discussion about some of the cool new User Certificate authentication advanced options. In the future I’ll follow up with some step by step guidance on how to use these advanced User Certificate authentication capabilities included with the new ISA firewall. Thanks! –Tom.

If you missed part 1 of this two part series, please read Configuring ISA Firewalls (ISA 2006 RC) to Support User Certificate Authentication using Constrained Delegation (Part 1) – Front-end/Eack-end Exchange Server Publishing Scenario.