LDAP Pre-authentication with ISA 2006 Firewalls: Using LDAP to Pre-authenticate OWA Access (Part 1)

There are times when you might not want to make the ISA firewall a domain member. For example, the ISA firewall might be the front-end firewall in a back to back firewall configuration, with the back-end firewall being another ISA firewall, or perhaps a less secure or lower performance firewall like a Cisco ASA or Sonicwall.

Another situation where I prefer not to make the ISA firewall a domain member is when you don’t trust the Active Directory admins and you’re not sure they understand group policy. If you make the ISA firewall a domain member, and the guys controlling group policy aren’t sure which end eats, you could end up with some potential troubleshooting nightmares with your ISA firewall.

Regardless of the reason why the ISA Firewall isn’t a domain member, you end up with some challenges when the ISA Firewall isn’t a domain member. The biggest challenge is that of pre-authentication. Pre-authentication allows you to configure the ISA Firewall to authenticate and authorize access to network resources before forwarding the connections to the network resource server.

For example, when using the ISA Firewall to publish Outlook Web Access (OWA), the ISA Firewall can be configured to require users to first authenticate with the ISA Firewall. When the user successfully authenticates with the ISA Firewall, the ISA Firewall then sends the user credentials to the OWA site. The OWA site authenticates the user, informs the ISA Firewall of successful authentication attempt, and then the ISA Firewall forwards the connection to the OWA server.

In order to authenticate the user, the ISA Firewall must have a mechanism to use for authentication. When the ISA Firewall is a domain member, it can use Windows integrated authentication to accomplish this task. When the ISA Firewall is not a domain member, other methods must be used to authenticate the incoming connections. With the ISA 2004 Firewall, you could use RADIUS or SecurID.

The problem with RADIUS is that you can’t leverage Active Directory groups and you had to create custom ISA Firewall Groups in order to have per-group based access control at the ISA Firewall. While on one hand ISA Firewall Groups can be seen as an advantage (the ISA Firewall admin doesn’t need to be a Domain Admin or interact with domain admins to create group based ISA Firewall access controls), on the other hand if there are already well defined user groups on which to based access control, why not use them? RADIUS can not use them and thus can potentially increase the administrative overhead in managing the ISA Firewall.

ISA 2006 Firewalls solve this problem by introducing LDAP authentication. With the new ISA Firewall you can use LDAP authentication to pre-authenticate users at the ISA Firewall and leverage existing Active Directory security groups. This provides a great advantage over RADIUS, where you could not use the Active Directory security groups in your ISA Firewalls access controls.

In addition to allowing you to use existing Active Directory security groups, ISA 2006 LDAP authentication makes it much easier to have a single ISA Firewall pre-authenticate users from multiple domains. In order to provide pre-authentication for multiple domains using RADIUS, you had to set up a complex RADIUS server configuration that included RADIUS servers and RADIUS proxies. Then you had to figure out how to correctly route requests through the RADIUS proxy to the appropriate RADIUS servers. In contrast, authentication request routing requires using the ISA 2006 Firewall’s integrated support for LDAP authentication is a no-brainer.

In this article we’ll take a look at how you can use the ISA 2006 Firewall’s LDAP authentication feature to publish multiple Exchange Servers belonging to different domains. This scenario is common in many organizations after a merger, or in a hosted environment where the ISA Firewall is in front of many customers’ Exchange Servers.

In this article series we’ll do the following to highlight the new LDAP authentication feature set included in the ISA 2006 Firewall:

• Describe the lab network
• Obtain Web site certificates for the OWA Sites
• Export the Web site certificates (with their private keys) and the CA certificates to a file
• Copy the Web site certificates and the CA certificates to the ISA Firewall and install these certificates in the ISA Firewall’s machine Certificate Store
• Configure HOSTS file entries on the ISA Firewall
• Configure the LDAP Servers in the ISA Firewall console
• Create the first Web Publishing Rule for the first OWA Server
• Create the second Web Publishing Rule for the second OWA Server
• Test the Configuration

Describe the Lab Network

Our first step is to describe the lab network I used to test the configuration. I always test out new configurations on a lab network before deploying them on my own, or any of my customer’s networks. One of the worst mistakes you can make is to turn your network, or your customer’s network, into a lab network. Make your mistakes in the lab, not on a live network.

Figure A

In the lab network there are four computers:

• A Windows XP client machine. This machine will be used to test connectivity to the OWA sites through the ISA Firewall
• A dual homed ISA Firewall. Remember that ISA Firewalls, in order to provide comprehensive protection, need two or more NICs. You do yourself, and your customer, a disservice by “going on the cheap” by using a unihomed configuration. The ISA Firewall is not a domain member. The ISA Firewall has two IP addresses bound to its external interface, in order to support publishing two SSL sites using two different Web site certificates
• An Exchange Server that is also an Active Directory DC for the msfirewall.org domain. Notice that I do not use .local for the top level domain name. Illegal top level domain names can cause you no end of trouble in the long run. Let the benighted SBS consultants and customers deal with the limitations of illegal TLDs – you want to use legal TLDs for your production networks. This machine also has an enterprise CA installed on it, so that we can request a Web site certificate from an online CA using the IIS Web site certificate request wizard.
• An Exchange Server that is also an Active Directory DC for the pixkiller.net domain. Like the other Exchange Server, an enterprise CA is installed on this machine

Obtain Web site Certificates for the OWA Sites

We will use SSL to SSL bridging in this example because we want a secure connection from end to end. I see many people who want to do so-called “SSL offloading” and do SSL to HTTP bridging. This is unfortunate, since these ISA Firewall admins assume that the network between the ISA Firewall and the published Exchange Server is perfectly safe. This is a false assumption in 99%+ of cases I’ve seen. No network should be trusted, and SSL to SSL bridging secures the connection from end to end, which is what we want as part of a responsible security infrastructure.

In order to perform SSL to SSL bridging, the ISA Firewall must establish two SSL connections: the first between the OWA client and the ISA Firewall and the second between the ISA Firewall and the OWA Web site on the corporate network. In order to support the second SSL connection between the ISA Server 2004 firewall and the OWA Web site, we must request a Web site certificate and binds that certificate to the OWA Web site. Later we will bind the same certificate to the ISA Firewall’s Web Listener, so as to support the first SSL link between the OWA client and the external interface of the ISA Firewall.

We will need to request Web site certificates for both the msfirewall.org OWA server and the pixkiller.net OWA Server. Perform the following steps to request a Web site certificate for the msfirewall.org OWA Web Site:

1. At the EXCHANGE2003BE.msfirewall.org machine, click Start and point to Administrative Tools. Click Internet Information Services (IIS) Manager.
2. In the left pane of the Internet Information Services (IIS) Manager console, expand the Web Sites node and click the Default Web Site. Right click Default Web Site and click Properties.
3. On the Default Web Site Properties dialog box, click the Directory Security tab.
4. On the Directory Security tab, click the Server Certificate button in the Secure communications frame.

Figure 1

5. On the Welcome to the Web Server Certificate Wizard page, click Next.
6. On the Server Certificate page, select the Create a new certificate option and click Next.

Figure 2

Discuss this article

7. On the Delayed or Immediate Request page, select the Send the request immediately to an online certificate authority option and click Next.

Figure 3

8. On the Name and Security Settings page, accept the default settings and click Next.
9. On the Organization Information page, enter your organization’s name in the Organization text box and your Organizational Unit’s name in the Organizational Unit text box. Click Next.

Figure 4

10. On the Your Site’s Common Name page, enter the common name of the site. The common name is the name that external and internal users will use to access the site. For example, if users enter https://owa.msfirewall.org into the browser to access the OWA site, you would make the common name owa.msfirewall.org. In our current example, we will enter owa.msfirewall.org into the Common name text box. This is a critical setting. If you do not enter the correct common name, you will see errors when attempting to connect to the secure OWA site. Click Next.

Figure 5

11. On the Geographical Information page, enter your Country/Region, State/province and City/locality in the text boxes. Click Next.
12. On the SSL Port page, accept the default value, 443, in the SSL port this web site should use text box. Click Next.
13. On the Choose a Certification Authority page, accept the default selection in the Certification authorities list and click Next.

Figure 6

14. Review the settings on the Certificate Request Submission page and click Next.
15. Click Finish on the Completing the Web Server Certificate Wizard page.
16. Notice that the View Certificate button is now available. This indicates that the Web site certificate has been bound to the OWA Web site and can be used to enforce secure SSL connections to the Web site.

Figure 7

17. Click OK in the Default Web Site Properties dialog box.

Summary

In this article I introduced the concept of the ISA 2006 Firewall’s LDAP authentication feature set. First introduced with the ISA 2006 Firewall, LDAP authentication can be used when it’s not possible to make the ISA Firewall a domain member, or when domain membership is not required or is otherwise deemed inappropriate. ISA 2006 Firewall LDAP authentication enables the ISA Firewall to send authentication queries to specific Active Directory domain controllers based on the log on strings presented by the user. Depending on the log on string rules you create, authentication queries can be directed to domain controllers in different domains. LDAP authentication enables you to leverage Active Directory security groups, so that you don’t need to create ISA Firewall Groups if you don’t want to.

In the next article in this series we’ll continue creating the certificate infrastructure that supports the solution and if we have time, create the relevant HOSTS file entries on the ISA Firewall. Thanks! –Tom.