If you missed the other parts of the series, check out:

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

Configure the LDAP Servers in the ISA Firewall Console

In order to use LDAP authentication, you need to configure the ISA Firewall with the names of the LDAP servers you want to use to pre-authenticate the incoming connections. There are two procedures involved in setting up LDAP Servers for the ISA Firewall to use for pre-authentication:

• Define sets of LDAP servers that the ISA Firewall can query to authenticate user credentials
• Define login expressions that the ISA Firewall can use to determine how to route the LDAP query. The login expressions determine what LDAP server is responsible for a particular authentication request.

To setup the LDAP servers, open the ISA Firewall console and expand the Arrays node and then expand the array name. Expand the Configuration node and click the General node. In the middle pane, click the Specify RADIUS and LDAP Servers link.

Figure 1

Click the LDAP Servers tab in the Authentication Servers dialog box. Click the Add button next to the list of LDAP Server Sets.

In the Add LDAP Server Set dialog box, enter a name for the LDAP Server set. In this example we’ll create a LDAP Server Set for the msfirewall.org domain, so we’ll put MSFIREWALL in the LDAP server set name text box.

Click the Add button in the Add LDAP Server Set dialog box. In the Add LDAP Server dialog box, enter the FQDN of the msfirewall.org domain controller. In this example, the name of the DC for the msfirewall.org domain controller is exchange2003be.msfirewall.org, so we enter that into the Server name text box. The Server description field is optional, and you can leave the Time-out (seconds) value as it is, unless you have networking issues that might require that you increase this value.

Figure 2

Click OK in the Add LDAP Server dialog box.

Notice that we entered an FQDN for the server name. We need to do this because we will use LDAPS certificate authentication when the ISA Firewall communicates with the domain controller. If you had entered an IP address in the Server name text box, the LDAPS authentication would fail because the value in the Server name text box must match the common/subject name on the server certificate installed on the DC. Since we installed an enterprise CA on the DCs, a self-signed machine certificate was automatically generated on each of the domain controllers in our scenario. If we had not installed an enterprise CA on the DCs, we would need to create the machine certificates manually.

NOTE:
Pay very close attention to the last sentence in the last paragraph and it’s important that it not to be taken lightly. The assignment of a server certificate for the DCs in our current scenario was very easy because we installed an enterprise CA on the DCs. If you have not installed a enterprise CA on your DCs, then you must install a machine certificate on the DCs. The best way to do this is to install an enterprise CA somewhere in your environment and then configure Group Policy for machine certificate autoenrollment. This article is already very long, and detailed instructions on autoenrollment are beyond the scope of this article. For excellent coverage of how to configure autoenrollment (and all other certificate deployment scenarios) please see the ISA Server 2000 VPN Deployment Kit here on the ISAserver.org Web site.

In the Type the Active Directory domain name (use the fully-qualified domain name) text box, enter the FQDN of the Active Directory domain name used by the LDAP Server set. In this example, we’re creating a set for the msfirewall.org domain, so we enter that value into the text box.

Figure 3

In order to support user password changes using LDAP pre-authentication at the ISA Firewall, we must enable LDAPS support. In order for LDAPS to work, you must install a machine certificate on the Domain controllers with the correct common/subject name on the certificates. The easiest way to do this is to use an enterprise CA and enable autoenrollment via Group Policy.

The ISA Firewall needs the CA certificates of the issuing CAs installed in it’s own Trusted Root Certification Authorities machine certificate store (not the user or service store), so that it will trust the certificates installed on the DCs. We have already installed the CA certificates on the ISA Firewall when we installed the Web site certificates into the ISA Firewall’s machine certificate store.

When LDAPS authentication is enabled in order to support user password changes, the Use Global Catalog option must be disabled, and you must enter the FQDN of the Active Directory domain name in the Type the Active Directory domain name (use the fully-qualified domain name) text box. If you didn’t want to enable password management, then you could check the Use Global Catalog (GC) option and leave the Active Directory domain name blank.

Since we do want to support password changes for remote users, we must also provide user credentials that can be used to access the Active Directory to verify user account status and change account passwords. This can be any user in the Active Directory, and it does not require domain admin credentials. Enter the user name in the User name text box and the Password in the password text box. In this example we’ll use the domain name user account, as seen in the figure above.

NOTE:
You do not need to use a domain admin account. You can use a regular user account to connect to the Active Directory. I am using the Active Directory domain admin account in this example because I’m too lazy to create a new user.

Click OK in the Add LDAP Server Set dialog box to complete the configuration of the msfirewall.org LDAP Server set.

We now must create a second LDAP Server Set for the pixkiller.net domain. Create the second server set using the information provided in the figure below

Figure 4

We have completed the first step, which was to create the LDAP Server Sets. The second step is to create the rules that the ISA Firewall will use to forward the authentication requests to the correct authentication server. These rules are based on elements of the users’ log on strings.

For example, users could log into the two OWA sites using log on strings such as:

[email protected]

MSFIREWALL\user

[email protected]

PIXKILLER\user

Based on this information, we can create rules based on wildcards and elements of these authentication strings so that the ISA Firewall forwards the authentication attempt to the correct domain controller. For example:

*@msfirewall.org

MSFIREWALL\*

Authentication attempts containing these strings would be forwarded to the MSFIREWALL LDAP Server Set. Another example:

*@pixkiller.net

PIXKILLTER\*

Authentication attempts containing these strings would be forwarded to the PIXKILLER LDAP Server Set.

To create these rules, click the New button that sits to the right of the Define the login expressions ISA Server will use to match the user login strings list. In the New LDAP Server Mapping dialog box, enter the log on expression MSFIREWALL\* in the Login expression text box. In the LDAP server set drop down list box, select the MSFIREWALL entry. Click OK.

Figure 5

Click New again and create a second LDAP Server mapping. This time, make the Login expression as *@msfirewall.org and select the MSFIREWALL entry from the LDAP server set drop down list.

Figure 6

Click New again to create a third LDAP Server mapping. This time, enter PIXKILLER\* in the Login expression text box and select the PIXKILLER entry from the LDAP server set drop down list box. Click OK.

Figure 7

Click New to create the last LDAP Server mapping. Enter *@pixkiller.net in the Login expression text box. Select PIXKILLER from the LDAP server set drop down list box. Click OK.

Figure 8

The figure below shows the list of login expressions. Notice that you can use the up and down arrows to change the order of the rules (although at the time of this writing, I can’t think of a scenario where placement in the list would be an issue). Click Apply and then click OK. Click Apply to save the changes and update the firewall policy and click OK in the Apply New Configuration dialog box.

Figure 9

Create the first Web Publishing Rule for the first OWA Server

Now we can get to creating the Web Publishing Rules that publish the msfirewall.org and the pixkiller.net OWA sites. We’ll create the msfirewall.org Web Publishing Rule first and then create the pixkiller.net Web Publishing Rule using the msfirewall.org Web Publishing Rule as a template.

Perform the following steps to create the msfirewall.org OWA Web Publishing Rule:

1. In the ISA Firewall console, click the Firewall Policy node in the left pane of the console and click the Tasks tab in the Task Pane. Click the Publish Exchange Web Client Access link in the Task Pane.
2. On the Welcome to the New Exchange Publishing Rule Wizard page, enter a name for the rule in the Exchange Publishing rule name text box. In this example we’ll name the rule MSFIREWALL OWA and click Next.
3. On the Select Services page, select the Exchange Server 2003 option from the Exchange version drop down list box. Put a checkmark in the Outlook Web Access checkbox. Click Next.

Figure 10

4. On the Publishing Type page, select the Publish a single Web site or load balancer option and click Next.

Figure 11

5. On the Server Connection Security page, select the Use SSL to connect to the published Web server or server farm option. This allows the ISA Firewall to create a secure SSL connection from its internal interface to the published OWA server. This insures that we have an end to end secure connection between the OWA client on the Internet and the OWA server on the corporate network. Click Next.

Figure 12

6. On the Internal Publishing Details page, enter the common/subject name on the Web site certificate bound to the OWA site that you’re publishing. Since this is the OWA Web Publishing Rule for the msfirewall.org OWA site, the common/subject name on the Web site certificate bound to the OWA site is owa.msfirewall.org. Therefore, we enter owa.msfirewall.org in the Internal site name text box.

   This is a critical setting, and it’s importance is not made clear in the text on the Internal Publishing Details page. The name you enter in the Internal site name text box must be the common/subject name on the Web site certificate bound to the OWA site. Many ISA Firewall admins will mistake the meaning of this text box and enter the actual computer name or the actual FQDN of the OWA site’s computer. For example, in our current example, the actual name of the computer hosting the msfirewall.org OWA Web site is exchange2003be or exchange2003be.msfirewall.org. You must not enter the actual computer name in the Internal site name text box.

   With previous versions of the ISA Firewall, you had to enter a HOSTS file entry (or deploy a split DNS infrastructure) for the common/subject name on the OWA Web site certificate so that name would resolve to the IP address of the OWA site on the internal network. This was because the same name was used to resolve the IP address of the OWA site and the name that would be sent in the SSL CONNECT. With ISA 2006 Firewalls, you no longer need to do that. The name entered in the Internal site name will be used for the CONNECT and the entry you put into the Computer name or IP address will be used to forward the connection to the correct location. You can enter the actual computer name or an IP address in the Computer name or IP address text box. In our current example, the IP address of the msfirewall.org OWA server is 10.0.0.2, so we’ll enter that value into the Computer name or IP address text box.

   Click Next.
   
   
   
   
   
   

Figure 13

7. On the Public Name Details page, select the This domain name (type below) option from the Accept request for drop down list. In the Public name text box, enter the common/subject name on the Web site certificate that will be bound to the Web listener that you’ll use in this Web Publishing Rule. The Web site certificate that we’ll use has the common/subject name owa.msfirewall.org, so we’ll enter owa.msfirewall.org in the Public name text box.

   This is a critical setting, because this is the name that external users will use to access the OWA site. You will need to configure your external DNS servers to resolve this name to the IP address on the external interface of the ISA Firewall that the Web listener will be configured to listen on (I’m assuming that the ISA Firewall is a edge security device since that’s what it was designed to be, and has a public address; the situation is different if you put a NAT device in front of the ISA Firewall).
   Click Next.
   
   
   

Figure 14

8. On the Select Web Listener page, click the New button.
9. On the Welcome to the New Web Listener Wizard page, enter a name for the Web Listener in the Web listener name text box. In this example, we will use this Web listener for the msfirewall.org and pixkiller.net OWA Web Publishing Rules, so we’ll enter OWA SSL into the text box and click Next.
10. On the Client Connection Security page, select the Require SSL secured connections with client option. This will force external OWA Web clients to use SSL when connecting to the ISA Firewall’s external interface. Click Next.

Figure 15

11. On the Web Listener IP Addresses page, put a checkmark in the External checkbox. Leave the checkmark in the ISA Server will compress content sent to clients through the Web Listener if the clients requesting the content support compression enabled.

    Although the ISA Firewall allows you to bind multiple certificates to a single Web listener, it does not fix the problem related to a having a separate IP address for each Web site certificate. There must be a different IP address for each Web site certificate. A single IP address cannot be used for multiple certificates because of current limitations in the SSL protocol and client/server implementations, not because of any inherent limitations in the ISA Firewall. This means that we can’t use this listener to listen on all IP addresses for all certificates. We need to assign each certificate to an IP addresses. In order to solve this problem, we need to click the Select IP Addresses button.
    
    

Figure 16

12. On the External Network Listener IP Selection page, select the Specified IP addresses on the ISA Server computer in the selected network option. Double click each IP address in the Available IP Addresses list. This will move the IP addresses to the Selected IP Addresses list on the right side of the dialog box. Notice the Add IP button, which is new with the 2006 ISA Firewall. Click OK.

Figure 17

13. Click Next on the Web Listener IP addresses page.
14. On the Listener SSL Certificates page, select the Assign a certificate for each IP address option. Then select the IP address that will listen for incoming connections for the msfirewall.org OWA site. In this example, the IP address 192.168.1.71 will be configured in DNS to accept incoming connections for the msfirewall.org OWA site. Select that IP address and then click Select Certificate.

Figure 18

15. On the Select Certificate page you will see a list of certificates installed on the ISA Firewall that can be used by the Web listener. This is one of the big improvements included in the new ISA Firewall. In ISA 2004, trying to figure out why a specific certificate didn’t work was a bit of a challenge, but with the new ISA Firewall, you get complete diagnostics right in the ISA Firewall console. I bet your ASA or Blue Coat doesn’t do that!

    In this example, select the owa.msfirewall.org certificate from the list of certificates. In the Certificate Installation Details section you can see information about the certificate. Notice that the Show only valid certificates checkbox is enabled by default. If you don’t see your certificate in the list of available certificates, remove the checkmark from that checkbox. The certificate will appear and you’ll get useful diagnostic information on why the certificate was invalid.

    Select the owa.msfirewall.org certificate and then click the Select button.
    
    
    
    

Figure 19

16. In the Listener SSL Certificates dialog box, you’ll see that the owa.msfirewall.org certificate is now bound to 192.168.1.71. Now select the 192.168.1.72 entry from the list and click the Select Certificate button.

Figure 20

17. In the Select Certificate dialog box, select the owa.pixkiller.net Web site certificate and click Select.

Figure 21

18. In the Listener SSL Certificates dialog box you should see that both IP addresses have separate certificates assigned to them. Click Next.

Figure 22

19. On the Authentication Settings page, select the HTML Form Authentication option from the Select how clients will provide credentials to ISA Server drop down list. This will allow the ISA Firewall to generate the log on form for the OWA clients. In the Select how ISA Server will validate client credentials list of options, select the LDAP (Active Directory) option. Click Next.

Figure 23

20. On the Single Sign On Settings page, remove the checkmark from the Enable SSO for Web sites published with this Web listener checkbox. SSO is not an option in this scenario because the destination servers belong to different domains and there is no trust between the domains. Click Next.

Figure 24

21. Click Finish on the Completing the New Web Listener Wizard page.
22. On the Select Web Listener page, click the Edit button so that you can make some changes to the Web listener.
23. In the Properties dialog box, click the Forms tab. On the Forms tab, put a checkmark in the Allow users to change their passwords and the Remind users that their password will expire in this number of days checkboxes. Click Apply and then click OK.

Figure 25

24. A spurious dialog box will appear indicating that the LDAP Servers are not configured to use LDAPS. We know that this dialog box is incorrect, as we were very explicit about configuring the LDAP Server sets to us LDAPS. Click OK to dismiss the spurious dialog box.
25. Click OK in the Web listener’s Properties dialog box.
26. On the Authentication Delegation page, select the Basic authentication option from the Select the method used by ISA Server to authenticated to the published Web server drop down list. This is the best option in a secure SSL to SSL bridging Web Publishing scenario. Click Next.

Figure 26

27. On the User Sets page, you can keep the default option, which is All Authenticated Users. Click Next.
28. Click Finish on the Completing the New Exchange Publishing Rule Wizard page.

Summary

In this article we continued our series on how to publish multiple OWA sites belonging to multiple domains using the new ISA Firewall’s LDAP authentication feature. We configured the LDAP server sets, the LDAP server matching strings, and then created the Web listener and Web Publishing Rule for the owa.msfirewall.org Web site. In the next and probably last installment in this series, we’ll create the owa.pixkiller.net Web Publishing Rule and then test the configuration to provide that everything works as it should. See you next week! –Tom.