ISA Firewall Publishing OWA and RPC/HTTP with a Single IP Address: Part 5 – Single Exchange Server with Separate DC Scenario/LDAP Authentication

By /

If you missed the other articles, check them out at:

This is the last part of our article series on how to publish the OWA and RPC/HTTP sites in a single Exchange Server environment where the Exchange Server is not installed on a DC. In the first four parts of this series we went over the requirements and procedures that enabled us to successfully publish both the OWA and RPC/HTTP sites, and do so using a single IP address on the external interface of the ISA Firewall.

Discuss this article

In this, the last article in the series, we’ll take a look at how we can control authorization for access to the OWA and RPC/HTTP sites, and then check into how you can easily redirect user requests so that they don’t have to remember to add https:// or the /exchange path in the URL. Finally, we’ll see how you can enable user password changes and password notification when using LDAP authentication.

Create an LDAP Group and Limit OWA and RPC/HTTP to LDAP Group and Test the Configuration

In the Web Publishing Rule we created, we used the default setting for the authentication option, which was to allow all authenticated users access to the published Web sites. In a production environment, you might want to limit access to selected groups, instead of allowing unfettered access to any user who has an account in the domain in question.

For example, suppose we created a global group in the msfirewall.org domain named OWA Users and populated that group with users we want to allow remote access to the msfirewall.org OWA and RPC/HTTP sites. We can easily do this by creating an LDAP group. Remember, LDAP has the advantage over RADIUS in that LDAP can leverage existing Active Directory groups while RADIUS cannot.

Prior to performing the following procedure, perform the following actions in the Active Directory Users and Computers console:

  • Create a security group named OWA Users
  • Create a user named User1
  • Place User1 into the OWA Users security group

The following procedure illustrates how to create an LDAP group on the ISA Firewall based on the OWA Users Active Directory global group:

  1. In the ISA Firewall console, click the Firewall Policy node in the left pane of the console and double click the OWA and RPC/HTTP Web Publishing Rule.
  2. In the OWA and RPC/HTTP Properties dialog box, click the Users tab. On the Users tab, click the All Authenticated Users entry in the This rule applies to requests from the following user sets list and then click the Remove button.


Figure 1

  1. On the Users tab, click the Add button.
  2. In the Add Users dialog box, click the New command.


Figure 2

  1. On the Welcome to the New User Set Wizard page, enter a name for the LDAP user set in the User set name text box. In this example, we’ll use the name MSFIREWALL OWA Users and click Next.


Figure 3

  1. On the Users page, click the Add button. In the fly-out menu, click the LDAP… entry.


Figure 4

  1. In the Add LDAP User dialog box, click the LDAP server set down arrow and select the MSFIREWALL entry. Select the Specified group or user option and then enter OWA Users (the name of the group that is populated with users we want to allow access to the msfirewall.org OWA site). Click OK.


Figure 5

  1. An authentication dialog box appears. Enter a valid user name and password. This does not need to be a domain admin. Click OK.


Figure 6

  1. The ISA Firewall contacts the domain controller and after finding the group the log on dialog box will disappear and then you’ll see the LDAP server group listed on the Users page. Click Next on the Users page.


Figure 7

  1. Click Finish on the Completing the New User Set Wizard page.


Figure 8

  1. In the Add Users dialog box, double click the MSFIREWALL OWA Users entry and then click Close.


Figure 9

  1. On the Users tab you’ll now see the LDAP user set in the This rule applies to requests from the following user sets list. Click OK.


Figure 10

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

    Now let’s test the effectiveness of this rule by logging onto the OWA Web site as user1. You will find that User1 is authenticated and authorized by the ISA Firewall and the connection is forwarded to the OWA Web site.

    Next, try to log onto the OWA Web site as Administrator in the msfirewall.org domain. You’ll find that the connection attempt is denied. This is because we didn’t include the Administrator in the OWA Users security group. Try using the AdminTest profile you created earlier in Outlook 2003. You’ll find that the Outlook client is blocked from the RPC/HTTP site, again because the Administrator wasn’t include in the OWA Users global security group.

    The figures below show what the Administrator account sees when trying to connect to the OWA site, and also what you see in the Outlook Connection Status window when the connections are denied.






Figure 11


Figure 12

Before moving forward, go to the domain controller and add the Administrator account to the OWA Users global security group.

Create an HTTPS redirect for HTTP Connections and Test the Configuration

A common problem ISA Firewall administrators have to deal with are users who can’t remember the correct protocol to enter in the Internet Explorer address bar. While I’ve been somewhat critical of these users, much of that criticism is probably unfair. The reason for this is that users don’t normally enter any protocol into the Internet Explorer address bar. When a user wants to go to www.microsoft.com, he doesn’t enter the protocol, which is http://, because Internet Explorer will insert that automatically for the user. It would be natural for the user to balk at all of sudden having to enter a protocol when he’s never had to do so before.

A new feature included in the ISA 2006 Firewall is the ability to configure the Web listener to automatically redirect users who try to connect using the address owa.msfirewall.org/exchange to https://owa.msfirewall.org/exchange.

To create this protocol redirect, double click on the OWA and RPC/HTTP Web Publishing Rule and click the Listener tab in the OWA and RPC/HTTP Properties dialog box. On the Listener tab, click the Properties button.


Figure 13

In the SSL Listener Properties dialog box, click the Connections tab. On the Connections tab, notice that the listener is only configured to allow SSL connections. Since we want to redirect users who connect via non-SSL connections, we need to put a checkmark in the Enable HTTP connections on port checkbox and leave the default value as 80.

In addition, we need to enforce the redirect. We do that by going into the HTTP to HTTPS Redirection frame and selecting the Redirect all traffic from HTTP to HTTPS. This causes all HTTP connections to this Web listener and any rule that uses this Web Listener to be redirected as HTTP connections.

Click OK after making the changes.


Figure 14

Click OK in the OWA and RPC/HTTP Properties dialog box.


Figure 15

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

Now open Internet Explorer on the client machine and enter the URL owa.msfirewall.org/exchange Because we haven’t enter the protocol, Internet Explorer will automatically add the http:// and the connection will be sent as a plain HTTP request to the ISA Firewall.


Figure 16

When the connection completes, you’ll see that the connection was automatically redirected to an HTTPS connection and the log on form appears.


Figure 17

Discuss this article

Create a Redirect to Forward Root Directory Connections to the /Exchange Path

Users have more problems than just remembering the correct protocol. They also often forget or are irritated by having to include the /Exchange path in the URL. Instead of entering owa.msfirewall.org/exchange, users want to enter owa.msfirewall.org and automatically be redirected to the https://owa.msfirewall.org/exchange site.

The new ISA Firewall includes a new feature that allows you to configure a redirect when you create a Deny Web Publishing Rule. This is very useful as it makes it easy to forward connections to denied URLs to another site. In fact, the site can be an internal or external site.

In order to make this work, we need to do the following:

  • Create a Deny Web Publishing Rule that Redirects the / path to the /Exchange Path This rule will deny requests to owa.msfirewall.org and forward them to owa.msfirewall.org/exchange 
  • Put the RPC/HTTP Above the Deny Rule and Put the Deny Rule Above the OWA and RPC/HTTP Web Publishing Rule The Deny rule must be placed above the OWA and RPC/HTTP allow rule because we need to have the deny rule processed first; this forces the redirect

You might wonder why this doesn’t break the RPC/HTTP connection. The reason is that the redirect is only for owa.msfirewall.org/ and not for owa.msfirewall.org/rpc  This means that the connection from the Outlook RPC/HTTP client is ignored by the first rule and the OWA and RPC/HTTP Web Publishing Rule is the first one to match the connection request.

Create a Deny Web Publishing Rule that Redirects the / path to the /Exchange Path

The first step is to create the Deny Web Publishing Rule. Perform the following steps to create that 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. In the Task Pane, click the Publish Web Sites link.
  2. On the Welcome to the New Web Publishing Rule Wizard page, enter a name for the rule. In this example, we’ll name the rule OWA Redirect and click Next.


Figure 18

  1. On the Select Rule Action page, select the Deny option. All connections matching the parameters we set in this rule will be denied. It would be nice if the ISA Firewall dev team had included a text box on this page that would enable us to create the redirect here, but we’ll have to wait until the rule is created and then go into the Properties of the rule. Click Next.


Figure 19

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


Figure 20

  1. On the Server Connection Security page, select the Use SSL to connect to the published Web server or server farm option. This option actually has no meaning in this scenario, since no connections will be forwarded by this Deny rule. Click Next.


Figure 21

  1. On the Internal Publishing Details page, enter an internal site name in the Internal site name text box. Put a checkmark in the Use a computer name or IP address to connect to the published server checkbox and enter the IP address of the OWA server. Note that again, these values have no actual meaning, as the connection will not be forwarded to the server by this deny rule. Click Next.


Figure 22

  1. On the Internal Publishing Details page, put a / (without a wildcard after the /) in the Path (optional) text box. Click Next.


Figure 23

  1. On the Public Name Details page, enter the public name, owa.msfirewall.org in the public name text box. Enter a / (without a wildcard after the /) in the Path (optional) text box. This is a key setting, as we want any connections requests for owa.msfirewall.org/ to be denied and redirected. Note that the user doesn’t need to enter the trailing /, Internet Explorer will enter it for the user. Click Next.


Figure 24

  1. On the Select Web Listener page, click the down arrow on the Web listener drop down list and select the SSL Listener entry (which we created earlier). Click Next.


Figure 25

  1. On the Authentication Delegation page, accept the default entry, No delegation, and client cannot authenticate directly. There’s no need for the client to authenticate in this scenario, since we want the connection to be automatically redirected for everyone.


Figure 26

  1. On the User Sets page, select the All Authenticated Users entry in the This rule applies to requests from the following user sets list and click Remove. Click the Add button.


Figure 27

  1. In the Add Users dialog box, double click the All Users entry and click Close.


Figure 28

  1. On the User Sets page, click Next.


Figure 29

  1. Click Finish on the Completing the New Web Publishing Rule Wizard page.


Figure 30

  1. Double click the OWA Redirect rule in the ISA Firewall console. In the OWA Redirect Properties dialog box, click the Action tab. Put a checkmark in the Redirect HTTP requests to this Web page checkbox and then enter https://owa.msfirewall.org/exchange in the text box. Click OK.


Figure 31

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

Change the Rule Order

Make sure that the Deny rule is above the OWA and RPC/HTTP allow rule, as seen in the figure below. If it is not, use the up down arrow buttons in the MMC button bar to get the rules in the correct order.


Figure 32

Testing The Solution

Open Internet Explorer and enter owa.msfirewall.org. Note that this request is sent over HTTP and there is no /exchange path. This will allow us to test both the protocol and path redirects that we’ve implemented.


Figure 33

Bam! The OWA log on page appears and you’ll see that the protocol was redirected to HTTPS. You won’t see the /exchange in the path, but you do see it in the query section (after the question mark).


Figure 34

Enable Password Changes and Notification for LDAP Authentication

We have already created an LDAP Server set that allows the ISA Firewall to authenticate users against the Active Directory user database. However, the way we have things set up right now does not allow users to change their passwords or provide users notification that passwords are about to expire or have expired.

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 machine autoenrollment via Group Policy.

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

When LDAPS authentication is enabled 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 did not 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 make the above changes and 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.

To make these changes, expand the Configuration node in the left pane of the console and click the General node. On the General node, click the Specify RADIUS and LDAP Servers link in the middle pane. In the Authentication Servers dialog box, click the LDAP Servers tab. On the LDAP Servers tab, double click the MSFIREWALL entry in the LDAP Server Set list.

In the Add LDAP Server Set dialog box, remove the checkmark from the Use Global Catalog (GC) checkbox and put a checkmark in the Connect LDAP servers over secure connection checkbox. Enter a user name and password of a domain user in the User name and Password text boxes. Click OK and then click OK in the Authentication Servers dialog box.


Figure 35

In order to support password changes and password notifications, you’ll need to configure the Web listener to provide that information to OWA users (RPC/HTTP users will not receive password notification as the client doesn’t provide that capability). There are several ways to get to the Properties dialog box for the SSL listener we created earlier. One way to do it is to double click on the name of the listener in the list of firewall rules, in the From/Listener column. Go ahead and do that now to open the SSL listener’s Properties dialog box.

In the SSL Properties dialog box, click the Forms tab. On the Forms tab, put a checkmark in the Allow users to change their passwords and Remind users that their password will expire in this number of days checkboxes. Click OK.


Figure 36

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

When you visit the OWA site after making these changes, you will see that the log on dialog box changes. Now you have the option I want to change my password after logging on, as seen in the figure below.


Figure 37

After enter credentials and clicking Log On, you’ll see the password change page, as seen in the figure below. Enter the old password, and then enter the new password and confirm the new password. Click the Change Password button.


Figure 38

After the password is changed, a confirmation page appears informing the user that the password was changed. The user will be automatically redirected to his mailbox.


Figure 39

Discuss this article

Summary

In this, the last part of our article series on how to publish the OWA and RPC/HTTP sites in a single Exchange Server deployment where the Exchange Server is not installed on the DC, we went over the procedures required to create redirects so that users do not need to remember to enter https:// and also so that they don’t have to remember to enter the /exchange path at the end of the URL in order to reach the OWA Web site.

If you missed the other articles, check them out at:

About The Author

Tom Shinder is a Program Manager at Microsoft and has two decades of networking and security experience. He has written dozens of books, thousands of articles, and spoken at large industry conferences on the topics of IT infrastructure, Cloud computing, and cybersecurity. In his free time, Tom enjoys participating in equine prediction markets.

Read Next

Static vs Dynamic IP Address

Static vs Dynamic IP Address

Most people are familiar with Internet Protocol (IP) Addresses, but many people don’t know you have 2 types. In this article, you’ll learn about static…

Read More »

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top