Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 6)

If you would like to read the other parts in this article series please go to

If you would like to be notified when Thomas Shinder releases the next part in this article series please sign up to the ISAServer.org Real Time Article Update newsletter.

Last week we left off by creating the SSL Web Listener that we will use for our OWA, RPC/HTTP and ActiveSync publishing rules. With that Web Listener in place, we are ready to create the OWA, RPC/HTTP and Exchange ActiveSync Web Publishing Rules.

In this article we will do the following:

  • Create the Basic Authentication OWA Web Publishing Rules
  • Create the Integrated Authentication OWA Web Publishing Rules
  • Create the RPC/HTTP Web Publishing Rules
  • Create the Exchange ActiveSync Web Publishing Rules

Discuss this article

Create the OWA Web Publishing Rules

With the Web Listener ready, we can now move our attention to the OWA Web Publishing Rules. We will need to create two OWA Web Publishing Rules: one that uses Basic authentication delegation and one that uses NTLM authentication delegation. I am not sure why we need to do this, but from what I have read, the new /OWA directory requires that you use integrated authentication in order to get all the “new features” to work. I do not know what those new features are, but I am not going to argue with this advice. All the other OWA related directories will need to use Basic authentication.

The first OWA Web Publishing Rule we will create will be the one that uses basic delegation. When we enable Basic delegation for a Web Publishing Rule that uses a Web Listener that is configured for forms-based authentication, the ISA Firewall will collect free text credentials from the client. The ISA Firewall will authenticate the client. After the ISA Firewall authenticates the client, it will check to see if that client is authorized to use the OWA Web Publishing Rule. If the user is authorized to use the rule, then it will forward the user’s credentials using Basic authentication to the Exchange Client Access Server. This is an example of authentication protocol transition – where the ISA Firewall accepts credentials using one protocol and then forwarding them to the published server using another authentication protocol.

Click the Firewall Policy node in the left pane of the ISA Firewall console. In the Tasks tab in the Task Pane, click the Publish Exchange Web Clients link.


Figure 1

On the Welcome to the New Exchange Publishing Rule Wizard page, enter a name for the Web Publishing Rule. In this example, we will enter OWA (Basic) in the Exchange Publishing rule name text box and click Next.


Figure 2

On the Select Services page, select Exchange Server 2007 from the Exchange version drop down list. In the Web client mail services section, put a checkmark in the Outlook Web Access checkbox. Notice that you can only publish one Web service at a time when publishing Exchange 2007, in contrast to how things worked with Exchange 2003. Click Next.


Figure 3

On the Publishing Type page, select the Publish a single Web site or load balancer option. If you had multiple Exchange Client Access Servers you would want to use the Publish a server farm of load balanced Web servers. In that case, you would create a Web Farm and allow the ISA Firewall to provide transparent load balancing and fail over for your Exchange Client Access Servers. Click Next.


Figure 4

On the Server Connection Security page, choose the type of connection the ISA Firewall will establish to the actual Web server. That is to say, the type of connection from the ISA Firewall’s internal interface to the published server itself. In this example we are using SSL to SSL bridging for the highest level of security. Select Use SSL to connect to the published Web server or server farm option to enable SSL to SSL bridging. Click Next.


Figure 5

On the Internal Publishing Details page you specify the name of the published server. Well, that is not exactly true. In the Internal site name text box, you do not actually enter the name of the published Client Access Server. What you do enter is the common/subject name on the certificate bound to the OWA Web site on the Client Access Server. In our current example, the name on the Web site certificate bound to the OWA Web site on the Client Access Server is owa.msfirewall.org, so we enter owa.msfirewall.org.

One of the nice improvements in ISA 2006 is that you do not need a split DNS or HOSTS file entry on the ISA Firewall to allow the ISA Firewall to resolve the common/subject name on the certificate to the IP address of the published Client Access Server. In ISA 2006, all you need to do is put a checkmark in the Use a computer name or IP address to connect to the published server checkbox and then use the Browse button to find the server, as seen in the figure below.


Figure 6

Click Next after entering the common/subject name on the Web site certificate on the Client Access Server in the Internal site name text box and the actual computer name or IP address in the Computer name or IP address text box.


Figure 7

On the Public Name Details page, select the This domain name (type below) option from the Accept request for drop down list. Enter the common/subject name on the certificate bound to the Web listener in the Public name text box. This is the name that external clients will use to connect to the ISA Firewall to reach the Client Access Server. In this example, both internal and external clients will use owa.msfirewall.org to reach the ISA Firewall, so we enter that into the Public name text box. Click Next.


Figure 8

On the Select Web Listener page, select the SSL Listener that we created earlier and click Next.


Figure 9

On the Authentication Delegation page, select the Basic authentication option from the Select the method used by ISA Server to authenticate to the published Web server drop down list. This will allow the user to use free text authentication via the log on form. After the ISA Firewall authenticates and authorizes the user, the ISA Firewall will convert the free text credentials into Basic Authentication credentials. Click Next.


Figure 10

On the User Sets page, set which users you want to be authorized to connect to the published Web site. The default setting is All Authenticated Users. However, if you do not want all authenticated users to access the published Web site, you can create Active Directory groups and allow just those groups access. In this example we will use the default setting, All Authenticated Users, and click Next.


Figure 11

Review the settings on the Completing the New Exchange Publishing Rule Wizard page and click Next.


Figure 12

Double click on the OWA (Basic) Web Publishing Rule that you just created. Click on the Paths tab in the OWA (Basic) Properties dialog box. Notice that the wizard created four paths for us:

/public/*

/OWA/*

/Exchweb/*

/Exchange/*

Since we want to benefit from the “new” features included with OWA for Exchange 2007, we want to use integrated authentication when connecting to the /OWA/ directory. Because of this, we need to remove the /OWA/* entry from this list. Click the <same as internal> /OWA/* entry on the list and click Remove.


Figure 13

Now you will see that there are only three paths in the list and the /OWA/ directory is removed. Click OK to close the OWA (Basic) Properties dialog box.


Figure 14

Now we need to create the second OWA Web Publishing Rule that supports integrated authentication with the /OWA/ directory. The easiest way to do this is to copy the OWA Web Publishing Rule that we already created and use that as the template for our new Web Publishing Rule. In the ISA Firewall console, right click the OWA (Basic) Web Publishing Rule and click the Copy command.


Figure 15

Right click the OWA (Basic) Web Publishing Rule again and then click the Paste command.


Figure 16

We will now see the new rule named OWA (Basic)(1). Double click on the OWA (Basic)(1) Web Publishing Rule.


Figure 17

In the OWA (Basic)(1) Properties dialog box, click the General tab. On the General tab, enter a new name for the Web Publishing Rule in the Name text box. In this example we will name the rule OWA (NTLM), as seen in the figure below.


Figure 18

Click on the Paths tab. On the Paths tab you see the paths that were valid for the basic authentication OWA Web Publishing Rule. In this rule we need to remove all of the paths and then enter the /OWA/ directory. Click on each of the rules and then click on the Remove button to remove each of the paths from the list.


Figure 19

After removing all the paths from the list, click the Add button. In the Path mapping dialog box, enter the path /OWA/* as seen in the figure below. Make sure that the Same as published folder option is selected, then click OK.


Figure 20

Click OK in the OWA (Basic)(1) Properties dialog box. The name of the path will change to OWA (NTLM) after you click OK.


Figure 21

Create the RPC/HTTP Web Publishing Rule

Now that we have the two OWA Web Publishing Rules in place we can move along to our next task: creating the Web Publishing Rule for the RPC/HTTP site on the Client Access Server. Remember, our goal here is to use the same Web Listener for all of our rules, so we do not need to worry about creating a new Web Listener, something that would not have worked in previous version of the ISA Firewall.

Click on the Firewall Policy node in the left pane for the ISA Firewall console and then click the Tasks tab on the Task Pane. On the Tasks tab, click the Publish Exchange Web Client Access link.


Figure 22

On the Welcome to the New Exchange Publishing Rule Wizard page, enter a name for the Web Publishing Rule. In this example, we will name the rule Outlook Anywhere and then click Next.

Discuss this article


Figure 23

On the Select Services page, select the Exchange Server 2007 option from the Exchange version drop down list box. Put a checkmark in the Outlook Anywhere (RPC/HTTP) checkbox and also put a checkmark in the Publish additional folders on the Exchange Server for Outlook 2007 clients checkbox. I do not know what those folders are, but it cannot hurt to put a checkmark in that checkbox and then find out which paths will be published. Click Next.


Figure 24

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


Figure 25

On the Server Connection Security page, select the Use SSL to connect to the published Web server or server farm and then click Next.


Figure 26

On the Internal Publishing Details page, put the common/subject name on Web site certificate bound to the OWA Web site on the Client Access Server. In our current example, the common name on the Web site certificate bound to the OWA Web site on the Client Access Server is owa.msfirewall.org, so we will enter owa.msfirewall.org in the Internal site name text box. Remember, the Internal site name bears no relation at all to the actual name of the Client Access Server, the name you put there is the common/subject name on the Web site certificate.

Put a checkmark in the Use a computer name or IP address to connect to the published server. Then use the Browse button to find the name of the Client Access Server, as seen in the figure below.


Figure 27

As you can see in the figure below, the Internal site name is not the same as the computer name of the Client Access Server. Click Next.


Figure 28

On the Public Name Details page, select the This domain name (type below) option from the Accept requests for drop down list. In the Public name text box, enter the name that external users will use to connect to the ISA Firewall in order to reach the RPC/HTTP site.


Figure 29

On the Select Web Listener page, select the SSL listener you created earlier from the Web listener drop down list and click Next.


Figure 30

On the Authentication Delegation page, select NTLM authentication from the Select the method used by the ISA Firewall to authenticate to the published Web server drop down list. Because the Outlook RPC/HTTP client does not know what to do with the forms-based authentication page, the ISA Firewall will detect that a non-browser client is connecting to the Web Listener and will fail back to basic authentication. The Outlook RPC/HTTP client will then use Basic authentication to authenticate to the ISA Firewall. The ISA Firewall will then authenticate and authorize the user. If the user is authenticated and authorized, the ISA Firewall will forward the user’s credentials as NTLM credentials. I know this sounds like magic and that it should not work, but by the time we are done, I think you will find that it does work.

By the way, this does not solve the problem related to users having to authenticate each time they open Outlook to connect to the RPC/HTTP proxy through the ISA Firewall. The reason for this is that in order to bypass by entering credentials, you would have to bypass pre-authentication at the ISA Firewall and allow NTLM credentials directly to the Client Access Server. That would be a foolhardy move and obviates the security provided by the ISA Firewall, as it allows every hacker on the Internet free access to anonymous connections to your RPC/HTTP proxy, and when the zero-day comes that someone exploits the RPC/HTTP proxy, you will be sorry that you did not take my advice.

Click Next.


Figure 31

On the User Sets page, accept the default All Authenticated Users and click Next.


Figure 32

Review the settings on the Completing the New Exchange Published Rule Wizard page and click Next.


Figure 33

Double click on the Outlook Anywhere Web Publishing Rule and click the Paths tab. Notice that a number of paths other than the /rpc/* directory have been added. As you can see in the figure below the following paths have been added:

/unifiedmessaging/*

/rpc/*

/OAB/*

/ews/*

/AutoDiscover/*

What are they all used for? I cannot tell you definitively, but maybe someone over at www.msexchange.org can. What I do know is that the /rpc/* path allows connections to the RPC/HTTP proxy, which is what we are mostly interested in at this time.


Figure 34

Create the ActiveSync Web Publishing Rule

While we will not actually test a ActiveSync client in this article series, there is a way to check whether or not the publishing rule is working, so we will go ahead and create an ActiveSync Web Publishing Rule.

Click on the Firewall Policy node in the left pane for the ISA Firewall console and then click the Tasks tab on the Task Pane. On the Tasks tab, click the Publish Exchange Web Client Access link.

On the Welcome to the New Exchange Publishing Rule Wizard page, enter a name for the new rule. In this example we will name the rule ActiveSync and click Next.


Figure 35

On the Select Services page, select Exchange Server 2007 from the Exchange version drop down list. Put a checkmark in the Exchange ActiveSync checkbox. Click Next.


Figure 36

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


Figure 37

On the Server Connection Security page, select the Use SSL to connect to the published Web server or server farm option and click Next.


Figure 38

On the Internal Publishing Details page, put the common/subject name on Web site certificate bound to the OWA Web site on the Client Access Server. In our current example, the common name on the Web site certificate bound to the OWA Web site on the Client Access Server is owa.msfirewall.org, so we will enter owa.msfirewall.org in the Internal site name text box. Remember, the Internal site name bears no relation at all to the actual name of the Client Access Server, the name you put there is the common/subject name on the Web site certificate.

Put a checkmark in the Use a computer name or IP address to connect to the published server. Then use the Browse button to find the name of the Client Access Server, as seen in the figure below.


Figure 39

As you can see in the figure below, the Internal site name is not the same as the computer name of the Client Access Server. Click Next.


Figure 40

On the Public Name Details page, select the This domain name (type below) option from the Accept requests for drop down list. In the Public name text box, enter the name that external users will use to connect to the ISA Firewall in order to reach the RPC/HTTP site.


Figure 41

On the Select Web Listener page, select the SSL listener you created earlier from the
Web listener
drop down list and click Next.


Figure 42

Notice on the Select Web Listener page a new piece of information:

“The session timeout function of the Web listener will not be applied to non-browser clients. This will allow the continued use of stored credentials for ActiveSync users”

This is very good! Now ActiveSync users (whose user-agent string indicates that it is not a browser client) will not have to be restricted by timeouts, which could be problematic if you have lot of ActiveSync clients. Click Next.


Figure 43

On the Authentication Delegation page, select the Basic authentication option from the Select the method used by ISA Server to authenticate to the published Web server drop down list box. We need to do this because we must use basic authentication to the ActiveSync directory. Click Next.


Figure 44

Accept the default setting, All Authenticated Users on the User Sets page and click Next.


Figure 45

On the Completing the New Exchange Publishing Rule Wizard page, review your settings and click Finish.


Figure 46

Double click on the ActiveSync Web Publishing Rule. In the ActiveSync Properties dialog box, click the Paths tab. Here you can see the path that is published to access the ActiveSync Web site, which is /Microsoft-Server-ActiveSync/*.


Figure 47

After making all these changes, click the apply button to apply the changes and then click OK to save the changes. At this point we are done with configuration of the ISA Firewall.

Discuss this article

Summary

In this article we created two Web Publishing Rules for publishing the OWA directories, one Web Publishing Rule for publishing the RPC/HTTP directory and one Web Publishing Rule for publishing the ActiveSync directory. We are done configuring the ISA Firewall. Next week we will move our attention to configuring the clients and testing the solution.

See you then! –Tom.

If you would like to read the other parts in this article series please go to

If you would like to be notified when Thomas Shinder releases the next part in this article series please sign up to the ISAServer.org Real Time Article Update newsletter.

Leave a Comment

Your email address will not be published.

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

Scroll to Top