Publishing Outlook Web Access and Outlook RPC/HTTP with ISA Server 2006 Enterprise Edition (RC) Firewalls using Forms-based Authentication (Single Member Array without NLB) – Part 4 Creating the Web Publishing Rules and Testing the Configuration

By /

Publishing Outlook Web Access and Outlook RPC/HTTP with ISA Server 2006 Enterprise Edition (RC) Firewalls using Forms-based Authentication (Single Member Array without NLB) – Part 4 Creating the Web Publishing Rules and Testing the Configuration

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

If you missed the other parts in this article series please read:

In the first part of this series on how to publish OWA and RPC/HTTP sites using the ISA firewall, I discussed the network environment on which the series is based, some key networking and ISA firewall concepts and issues involved with using the new ISA firewall, ISA Server 2006. In the second part of the series, I went into great depth about important DNS considerations that you need to take into account before for deploy the solution. In part three we deployed the certificates and created the Web farm.

In this, the last part in the series we’ll finish up the configuration and test the results. We cover the following topics:

  • Creating the OWA and RPC/HTTP Web Publishing Rules
  • Examine the Web Publishing Rules
  • Configure the HTTP Security Filter
  • Test the OWA and RPC/HTTP Web Publishing Rules

Creating the OWA and RPC/HTTP Web Publishing Rules

The ISA Server 2006 firewall greatly simplifies publishing OWA and RPC/HTTP sites via its Exchange Publishing Rule wizard. The wizard will create rules for both the OWA and the RPC/HTTP proxy sites.

A major improvement that the ISA 2006 firewall provides over ISA 2004 is that you can now use a single IP address to publish both Exchange Web services and the RPC/HTTP proxy when forms-based authentication was enabled. The problem in the past was that if FBA was enabled on the Web listener, the Outlook 2003 client didn’t know how to respond to the form and the connections failed without providing any useful diagnostic information on either the client or the server side.

ISA Server 2006 fixes this problem by using its application layer inspection capabilities to check the user-agent header in the request. If the user-agent header indicates that a non-browser based application is connecting through the Web listener, then the ISA firewall will fall-back from FBA authentication to basic authentication. The Basic authentication credentials are secured from end to end because we use ISA firewall best practices by employing SSL to SSL bridging.

Another significant change introduced with the new ISA firewall is a new array of authentication delegation options. I’ll go over those with you when we get to that point in the wizard.

Perform the following steps to publish the OWA and RPC/HTTP sites on the front-end Exchange Server Web farm:

  1. In the ISA firewall console, expand the array name and then click the Firewall Policy node. Click the Tasks tab in the Task Pane. In the Task Pane, 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 rule in the Exchange Publishing Rule text box. The wizard will actually create two rules for us, so we’ll name the rule based on the servers we’re publishing. In this example we’ll name the Exchange FE Web Farm and click Next.
  3. On the Select Services page you can select the version of Exchange you’re publishing and then select the services on that Exchange Server that you want to publish. The service options change depending on the version of Exchange you’re publishing. For example, in this scenario we’re publishing Exchange 2003, so the Publish additional folders on the Exchange Server for Outlook 2007 clients option would not be available and the Outlook Mobile Access also won’t be available since OMA isn’t included in Exchange 2007.


Figure 1

  1. In this scenario we’re publishing Exchange 2003, so select that option and then put a checkmark in the Outlook Web Access and Outlook RPC/HTTP(s) checkboxes and click Next.


Figure 2

  1. On the Publishing Type page you have the option to Publish a single Web site or load balancer or Publish a server farm of load balanced Web servers. The first option is used if you don’t want to use the ISA firewall’s integrated Web farm publishing feature and the second option enables the Web farm publishing feature. Since we have a Web farm of FE Exchange Servers we want to publish, we’ll select the second option as seen in the figure below. Click Next.


Figure 3

  1. On the Server Connection Security page you select whether or not you want the ISA firewall to establish an SSL connection between itself and the published servers in the Web farm. I strongly recommend that you always select the Use SSL to connect to the published Web server or server farm. The reason for this is that you can no longer trust any network, including your corporate network. Anyone with a network sniffer (protocol analyzer) can capture packets that are not encrypted and attack your FE Exchange Servers using the information gathered in the packet trace.

    The only scenario in which I would deviate from this recommendation is when there is a dedicated connection between the ISA firewall and the FE Exchange Server farm. This could take the form of a dedicated network on which the farm sits. In a single Exchange Server scenario (not the one we’re discussing in this article series), you could also use a crossover cable. In all other circumstance, you should always use SSL from the ISA firewall array to the published Web servers.

    In our current scenario, we’re going to use security best practices and enforce SSL to SSL bridging, so we’ll select the Use SSL to connect to the published Web server or server farm and click Next.




Figure 4

  1. On the Internal Publishing Details page you enter the common/subject name on the certificate bound to the FE Exchange Web farm Web sites. You do not enter the actual machine name, you must enter the name included on the Web site certificate bound to the FE Exchange Servers Web sites. Failure to do so will generate a 500 Server Error.

    The explanation of what name to enter into the text box on this page is interesting. It says The internal site name is the name of the Web site you are publishing as it appears internally. Typically, this is the name internal users type into their browsers to reach the Web site. I think this is good general information, but can be a bit misleading. For example, if you do not require SSL for the connections made by the internal user, you might have internal users connect to the actual machine name. However, if you require SSL from the ISA firewall to the FE Exchange Servers, and don’t require SSL for internal users, two different names are used and the name isn’t the one used by the internal users.

    We solve this problem in our scenario by requiring both internal and external users to go through the ISA firewall to access the FE Exchange Server Web farm. In this way we make it easy for users, regardless of their location, to use the same name when connecting to the Exchange Server’s Web resources. We also have simplified things significantly by using our split DNS infrastructure to support using the same name from end to end.

    If you missed the discussion on configuring a split DNS infrastructure to support this solution, you should go back to part 2 of the article series now. A split DNS infrastructure, while not an absolute requirement, will make your ISA firewall OWA and RPC/HTTP solution much more popular among your users (and bosses) and will be much easier to manage. Check out part 2 at http://www.isaserver.org/tutorials/Publishing-Outlook-Web-Access-Outlook-RPCHTTP-ISA-Server-2006-Firewalls-Forms-based-Authentication-Part2.html

    In our current example the common/subject name on the Web site certificate is owa.msfirewall.org, so we will enter than name in the Internal site name text box. Click Next.








Figure 5

  1. On the Specify Server Farm page you select or create a new server farm. You can create a new server farm by clicking the New button or edit an existing server farm by clicking the Edit button. We already created a server farm in the last article so we can select that from the Select the Exchange server farm you want to publish drop down list. Select the server farm you created in the last article and click Next.


Figure 6

  1. On the Public Name Details page you enter the common/subject name on the Web site certificate that you will bind to the Web listener. Users will access the published sites using the common/subject name on the Web site certificate that you will bind to the Web listener. If the name you enter on this page does not match the common/subject name on the certificate used by the Web listener, the connection attempt will fail.

    Note that you actually have two options in the Accept request for drop down box: This domain name (type below) and any domain name. I highly recommend that you never select the Any domain name option because this will open your ISA firewall and published Web sites for a number of attacks. While this isn’t an issue for SSL publishing scenarios (since users can only connect when they use the FQDN included in the subject/common name on the certificate), it is a significant problem when publishing HTTP sites or when you use wildcard certificates on the ISA firewall’s Web listener.

    In this example the common/subject name on the Web site certificate that we’ll bind to the Web listener for this rule is owa.msfirewall.org so we enter that in the Public name text box. Click Next.




Figure 7

  1. On the Select Web Listener page, click the New button to create a new SSL Web listener.
  2. On the Welcome to the New Web Listener Wizard page, enter a name for the Web listener in the Web listener name text box and click Next. In this example I’ll name the Web listener Exch Farm SSL Listener and click Next.


Figure 8

  1. On the Web Listener IP Addresses page you select what ISA firewall Networks you want to allow the Web listener to accept incoming connections. In this example we want to allow connections from the ISA firewall’s default External Network and also from the ISA firewall’s default Internal Network. If I had multiple IP addresses bound to any of the interfaces connected to either of these ISA firewall Networks, I could click the Select IP Addresses button and select specific IP addresses on these Networks to accept the incoming connections. In our current scenario each interface on the ISA firewall has only a single IP address bound to it.

    Notice that the ISA Server will compress content sent to clients through this Web Listener if the clients requesting the content support compression checkbox is checked by default. This is a good thing and do not uncheck the checkbox. The ISA firewall supports HTTP compression and this will significantly improve performance for your OWA clients.

    Click Next.




Figure 9

  1. On the Listener SSL Certificates page you select the certificate or certificates you want to bind to the Web listener. In this example we have only a single certificate that we want to bind to the Web listener. This certificate enables the ISA firewall to impersonate the SSL Web site on the FE Exchange Server Web farm. You would bind multiple certificates to the Web listener if you want to use this Web listener to listen for connections to multiple SSL Web sites that have different names.

    Click the Select Certificate button.


Figure 10

  1. You select the certificate you want to bind to the Web listener on the Select Certificate page. The new ISA firewall makes certificate management much easier by providing useful information about the status of the certificate. In the figure below you can see that there is a single Web site certificate installed on the ISA firewall that can be bound to the Web listener. The interface provides you information about the validity of the certificate and if the private key is included with the certificate.

    Click on the owa.msfirewall.org certificate and click the Select button.


Figure 11

  1. Click Next on the Listener SSL Certificates page.


Figure 12

  1. On the Authentication Settings page you select how you want the ISA firewall to authenticate the users connecting to the Web farm. In the Select how clients will provide credentials to ISA Server drop down list box. You have the following options:

    HTML Form Authentication (forms-based authentication)
    HTTP Authentication (which means either Basic or Digest)
    SSL Client Certificate Authentication (which means user certificate authentication)
    No Authentication (which means anonymous connections are allowed)


    Depending on your selection, different options regarding collection of additional delegation credentials are available and how the ISA firewall will validate the client credentials. You’ll have to wait for the book to come out (or read the Help File) to get a complete list of which options are available for the different authentication types. In this example we’ll select the HTML Form Authentication option.

    Select the HTML Form Authentication option.




Figure 13

  1. After selecting the HTML Form Authentication option, you’ll have the available authentication methods enabled, as well as the ability to select additional credentials in the form. If you select the Collect additional delegation credentials in the form option, your authentication methods are limited to RADIUS OTP and SecureID. If you don’t select this option, then all of the authentication methods are available to you.

    Since the ISA firewall is a domain member (an ISA firewall best practice, as confirmed by the ISAserver.org white paper at http://www.isaserver.org/tutorials/Debunking-Myth-that-ISA-Firewall-Should-Not-Domain-Member.html we should select the Windows (Active Directory) option. If the ISA firewall wasn’t a member of the domain, then you could choose the LDAP (Active Directory) or RADIUS options.

    Select the Windows (Active Directory) option and click Next.




Figure 14

  1. On the Single Sign On Settings page you configure the single sign on domain for the Web listener. This is a very useful feature included with the new ISA firewall, ISA Server 2006. For example, you might want to publish your SharePoint Portal Server site using this same listener. This would then allow OWA users to click SPS links contained within the e-mail messages and open the SPS content (note that you need to publish the SPS site before users can access it).

    In ISA 2004, users would need to reauthenticate before connecting to the SPS site, even if the site is in the same domain in which the user has already authenticated to the OWA site. With ISA Server 2006, if the SPS site is in the same domain as the OWA site and the ISA firewall has already authenticated the user (this requires that you allow the ISA firewall to pre-authenticate the user), then the user will not need to authenticate again.

    The default setting is to enable the Enable SSO for Web sites published with this Web listener option. You then enter the domain for which you want to allow single sign on. This is the domain the ISA firewall forwards the connections to. In order to make this simple and flawless as possible, I highly recommend that you deploy a split DNS infrastructure. For details on creating a well designed split DNS infrastructure, check out: http://www.isaserver.org/tutorials/Publishing-Outlook-Web-Access-Outlook-RPCHTTP-ISA-Server-2006-Firewalls-Forms-based-Authentication-Part2.html

    In this example we’ll enter .msfirewall.org into the SSO domain name text box, since all the published servers will belong to this domain and this domain has the split DNS infrastructure setup to allow connections that are user location transparent.

    Click Next.








Figure 15

  1. Click Finish on the Completing the New Web Listener Wizard page.
  2. Click Next on the Select Web Listener page.


Figure 16

  1. On the Authentication Delegation page you configure if and how you want the ISA firewall to delegate user credentials. You have the following options:

    No delegation, and the client cannot authentication directly
    No delegation, but the client may authentication directly
    Basic authentication
    NTLM authentication
    Negotiate (Kerberos/NTLM)
    Kerberos constrained delegation


    The best option for delegation of authentication is definitely scenario based. In our current scenario, the preferred option is to delegate basic authentication, since we’re using SSL to SSL bridging. Other authentication delegation options are preferred if you use SSL to HTTP bridging, because the back end communications are in the clear and it would be a simple affair to steal the username and password off the unencrypted channel between the ISA firewall and the FE Exchange Servers if Basic authentication delegation were used.

    NOTE:
    I’ll go into detail on the various authentication delegation options in a future article on ISAserver.org. Until then, you can benefit from reading the Microsoft article on ISA Server 2006 authentication at http://www.microsoft.com/technet/prodtechnol/isa/2006/authentication.mspx

    Since we are using ISA firewall best practices in this article series, we have enabled SSL to SSL bridging and so the best option is Basic authentication. This option enables the ISA firewall to authenticate the user and then confirm that the user is authorized to access the published OWA or RPC/HTTP sites. If the user successfully completes authentication and authorization, then the ISA firewall forwards the user’s credentials on behalf of the user, so that the user doesn’t encounter a second authentication prompt. This is especially important for Outlook RPC/HTTP, because there is no mechanism available for the Outlook client to respond to the second authentication prompt.

    Select the Basic authentication option and click Next.








Figure 17

  1. On the User Sets page you configure what users or groups you want to be able to access the published Web sites. The default setting is All Authenticated Users. This is a somewhat liberal setting and you might want to be a bit more conservative and create your own groups for those who have access to the OWA and RPC/HTTP sites. Note that the settings you apply here would apply to both the OWA and RPC/HTTP rules. You can customize each rule when you’re finished..


Figure 18

  1. Click Finish on the Completing the New Exchange Publishing Rule Wizard page.
  2. Click Apply to save the changes and update the firewall policy
  3. Click OK in the Apply New Configuration dialog box.

Examining the Web Publishing Rules

You’ll see that the wizard has created two rules, as seen in the figure below. The Exchange FE Web Farm RPC/HTTP(S) Web Publishing Rule is easily identifiable, but the other rule, Exchange FE Web Farm isn’t so easy to identify. I would recommend that you rename the rule to Exchange FE Web Farm OWA to make it clear that this rule applies to your OWA Web Publishing Rule.


Figure 19

If you’re an experienced ISA 2004 firewall admin, you’ll be impressed with the new features included with Web Publishing Rules. While you’ll be able to leverage a lot of what you knew with ISA 2004 firewalls, with the new ISA firewall’s approach to Web Publishing Rules, there is still a lot of new things that you should know about so that you can get the most out of your Web Publishing experience.

Let’s drill down on the two Web Publishing Rules created by the wizard.

Drill Down on the RPC/HTTP Web Publishing Rule

Double click the Exchange FE Web Farm RPC/HTTP(s) Web Publishing Rule and click on the Web Farm tab. You’ll see something like what appears in the figure below. Notice that the Source-IP based option is selected in the Load Balance Mechanism frame in the dialog box. This means that the ISA firewall will load balance the connections from RPC/HTTP clients based on the source IP address of the incoming client connection. The reasons for this is that the Outlook client is unable to process cookies and therefore IP address based load balancing must be used.


Figure 20

Click on the Traffic tab. Notice that only HTTPS can be used to connect to RPC/HTTP site. Any HTTP requests are automatically blocked, which increases security since most automated exploits are going to use HTTP connections only. Put a checkmark in the Require 128-bit encryption for HTTPS traffic checkbox to enforce high encryption connections. For RPC/HTTP publishing, never enable the Require SSL Certificate option because at this time the Outlook client does not support user certificate authentication.


Figure 21

Click on the Listener tab. Here you see some of the details of the Web listener you created for the Web Publishing Rule. Click the Properties button.


Figure 22

In the Exch Farm SSL Listener Properties dialog box, click on the Forms tab. Forms are assigned on a per Web listener basis. In the case of the RPC/HTTP, the form isn’t an issue because the Outlook RPC/HTTP client cannot process the form. In addition, the options in the Password Management frame do not apply to RPC/HTTP clients, again because these clients do not process the form and fall back on basic authentication.


Figure 23

Click the Advanced button on the Forms tab. In the Advanced Form Options dialog box you have the options to set persistent cookies and to ignore the browser’s IP address for cookie validation. Again, these cookie options do not apply to the RPC/HTTP client because Outlook cannot process the cookies.

In the Client Security Settings frame you can configure time out intervals for both browser and non-browser based clients. The default is to treat the maximum idle time for the Web listener as the maximum time a client connection can be idle. You can customize the timeout interval so that it differs from the Web listeners timeout period by selecting the Treat as maximum session duration option and setting limits for both public and private computers.

Note that there is an option to Apply session timeout to non-browser clients. However, at this time I’m using the release candidate of the new ISA firewall and the Help File has not been updated to reflect the precise meaning of this option. What is unclear at this time is what timeout value is applied to the non-browser clients. Is it the default value for the Web listener, or is it the custom value you create when you select the Treat as maximum session duration option? I would guess the former, since there is no mechanism for the Outlook client to set itself as either a public or private computer.


Figure 24

Click Cancel in the Advanced Form Options dialog box and then click Cancel in the Exch Farm SSL Listener Properties dialog box. Click OK in the Exchange FE Web Farm RPC/HTTP(s) Properties dialog box.

Drill Down on the OWA Web Publishing Rule

Double click on the Exchange FE Web Farm Web Publishing Rule. In the Exchange FE Web Farm Properties dialog box, click on the Web Farm tab. Notice that in this case, the Load Balance Mechanism is set for Cookie based. Cookie based load balancing enables session affinity, which provides a bit more robust failover and load balancing scheme than IP address based affinity in that if one of the servers in the farm goes down and then comes back up again, the cookie based client is not automatically redirected back the previously downed server.


Figure 25

Click the Application Settings tab. Here you’ll see that we have options that weren’t available in the RPC/HTTP Web Publishing Rule. This points out the importance of using the Exchange Web Client Publishing Wizard when publishing Exchange sites, because there is a lot going on behind that scenes when using the Wizard that isn’t exposed anywhere else in the user interface. Here you’ll see in the Exchange Publishing Attachment Blocking frame options to block e-mail attachments for either or both Public computers and Private computers.


Figure 26

Click on the Listener tab and then click the Properties button. In the Exch Farm SSL Listener Properties dialog box, click the Forms tab. A common request among ISA 2004 firewall admins was to provide a an easier way to enable users to change their passwords over the OWA connection. Microsoft heard their pleas and enabled this functionality right into the user interface in the new ISA firewall.

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

In the Password Management frame, put checkmarks in the Allow users to change their passwords and Remind users that their password will expire in this number of day checkboxes. Notice that you can customize the number of days lead time you give your users to change their passwords. This is a very nice feature and something that Microsoft IT had already deployed as a custom feature in their ISA 2004 firewall deployments.


Figure 27

Click the Advanced button. Here you can configure the browser session timeouts. Note that the option to close the session is not included in the Release Candidate of the ISA Server 2006 firewall,  but I expect that option to be available in the RTM version. Note the default values in the Client Security Settings dialog box. You might want to change these based on your own company’s preferences.


Figure 28

Click OK in the Advanced Form Options dialog box and then click OK in the Exch Farm SSL Listener Properties dialog box. Click OK in the Exchange FE Web Farm Properties dialog box. Click Apply to save the changes and update the firewall policy and click OK in the Apply New Configuration dialog box.

Configuring the HTTP Security Filter

As good as the Wizards are, one thing they unfortunately don’t do is configure the HTTP Security Filter for you. While this would be a very nice feature, I understand why Microsoft decided not to do so. The reason is most likely due to the risk of increasing PSS support calls because the HTTP Security Filter really needs to be customized based on your specific requirements and the level of security and restriction the company is willing to endure.

Steven Hope, formerly with Microsoft Consulting Services, put together a fantastic document on how to configure the HTTP security filter for a number of Exchange Publishing Scenarios. You can find that document at http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/firewall-exchange2003.mspx

I won’t go into details on how to configure the HTTP Security Filter in this article, as the Microsoft article provides excellent information on this subject, but as an example, the following figures show how to correctly configure the HTTP Security Filter for the RPC/HTTP Web Publishing Rule.


Figure 29


Figure 30


Figure 31


Figure 32


Figure 33

Testing the OWA and RPC/HTTP Web Publishing Rules

Now let’s get to the big fun and test the configuration. There are a lot of moving parts in setting up Exchange Server and ISA to work for secure OWA and RPC/HTTP, so in this section we’ll look at what you’re see when things are working right and discuss some troubleshooting tips along the way as well.

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

One thing that gets forgotten too many times is the Outlook RPC/HTTP client configuration. The ISA firewall admin may have done everything right, the Exchange Server admin might have done everything right, but if the Office admins don’t get things right, then the entire house of cards will fall. If you have problems with your RPC/HTTP Web Publishing Rules, make sure to check the clients first.

If you want to configure the Outlook RPC/HTTP client manually, perform the following steps:

  1. At the Windows XP client machine, click the Start menu and right click the Outlook icon and click Properties.
  2. In the Mail Setup dialog box, click the Show Profiles button.
  3. In the Mail dialog box, click the Add button.
  4. In the New Profile dialog box, enter a name for the profile in the Profile Name text box. In this example we’ll name the profile based on the user name, which is isahero and click OK.
  5. In the E-mail Accounts dialog box, select the Add a new e-mail account option and click Next.


Figure 34

  1. In the Server Type dialog box, select the Microsoft Exchange Server option and click Next.


Figure 35

  1. In the Exchange Server Settings dialog box, enter the name of the user’s mailbox server in the Microsoft Exchange Server text box. Note that this is the actual FQDN of the mailbox server and may or may not be the same as the proxy settings that you’ll configure the account to use for the RPC/HTTP proxy server. This is a very common mistake and you can avoid it by confirming that the actual FQDN of the mailbox server is used in the Microsoft Exchange Server text box.

    Enter the user name in the User Name text box. Then click More Settings.


Figure 36

  1. After clicking the More Settings dialog box you will see an error if the client isn’t on the network or doesn’t have RPC connectivity to the Exchange Server. Click OK  in the Microsoft Office Outlook dialog box.


Figure 37

  1. In the Microsoft Exchange Server dialog box that appears, click Cancel.


Figure 38

  1. In the Microsoft Exchange Server dialog box, click the Connection tab. On the Connection tab, put a checkmark in the Connect to my Exchange Mailbox using HTTP checkbox. Then click the Exchange Proxy Settings button.


Figure 39

  1. In the Exchange Proxy Settings dialog box you enter a number of key values required to connect to the RPC/HTTP proxy server located behind the ISA firewall. In the Use this URL to connect to my proxy server for Exchange text box, you enter the common/subject name of the Web site certificate bound to the Web listener used to publish the RPC/HTTP proxy behind the ISA firewall. In our current scenario, the name on the listener’s Web site certificate is owa.msfirewall.org, so we enter that value into the text box.

    If you want to mutually authenticate the SSL session, put a checkmark in the Mutually authenticate the session when connecting with SSL and then enter the name on the Web site certificate bound to the Web listener and precede that name with msstd:, as seen in the figure below.

    The default selection for RPC/HTTP connectivity is On slow networks, connect using HTTP first, then connect using TCP/IP. This is very much a misnomer, and I have no idea why the Office team tried to obfuscate the actual protocols used. This option indicates to Outlook that it should use RPC/HTTP over slow connections, and if that doesn’t work, it should try to use Outlook MAPI RPC connections. It’s sort of ridiculous to state “use TCP/IP” since both MAPI and RPC/HTTP are part of the TCP/IP protocol suite.

    In the Use this authentication when connecting to my proxy server for Exchange drop down list box, select the Basic Authentication option. You need to select this option because the Web listener is configured to provide forms-based authentication for Web clients and fall back to Basic authentication for non-Web clients. The Web listener will NOT fail back to Integrated authentication. If you want to use Integrated authentication, then you will need to create a second Web listener dedicated to the RPC/HTTP Web Publishing Rule and enable Integrated authentication on that listener and delegate Integrated authentication. I won’t cover that option in this article but may do so in the future if anyone is interested in it.

    Click OK.








Figure 40

  1. Click OK in the Microsoft Exchange Server dialog box.
  2. Click Next on the Exchange Server Settings dialog box.
  3. Click Finish on the Congratulations page.

Now let’s fire up the connection. Open Outlook and select the profile for which you configured RPC/HTTP connectivity and click OK. Enter the user name and password in the Connect to dialog box, as seen in the figure below.


Figure 41

You’ll see Outlook giving you the message that the mailbox is being prepared for first use, and then see a balloon in the system tray indicating that a local copy of the mailbox is now being set up. Hold down the control key on the keyboard and then right click the Outlook icon in the system tray. You’ll see something like the figure below if the RPC/HTTPS connection is successful.

It’s worthy of note here that even though the server name that appears in this Exchange Server Connection Status dialog box is the actual mailbox server on which the user’s mailbox is located, this name does not need to be resolvable from the Internet in an RPC/HTTP connection scenario. This name only needs to be resolvable from the Internet in a secure Exchange RPC publishing scenario, not in a RPC/HTTP publishing scenario.


Figure 42

The figure below shows the ISA firewall’s log entries for these connection attempts. The lines are probably too small for you to see, but that’s OK, since you’ll find the ISA firewall logs of relatively little use in troubleshooting RPC/HTTP connectivity issues. Even when the connections are successful, you’ll find a number of Failed Connection Attempt entries in the log files which would give the false impression that the there is something wrong, even when things are working correctly.


Figure 43

If you look on the Sessions tab in the ISA firewall console, you’ll see that the RPC/HTTP user has both active Web Proxy and SecureNET sessions with the ISA firewall. The reason why you see a SecureNET session in addition to a Web proxy client session is that the external host isn’t explicitly configured as a Web proxy client, which makes the machine a SecureNET client. However, the machine is magically transformed into a Web proxy client when the Web listener for the Web Publishing rule intercepts the connection request.


Figure 44

Next we’ll test the OWA configuration. Open a Web browser and go to https://owa.msfirewall.org/exchange You’ll see a very nice looking log on page like that in the figure below. Notice that you now have the option of changing your password when you log in.


Figure 45

You’ll see the following dialog box when you choose to change your password. However, don’t try this in the Release Candidate of ISA Server 2006 yet, as I found it made everything go haywire and killed all connections through the ISA firewall. I’m confident this problem will be solved in the RTM version of the new ISA firewall.


Figure 46

Tips from the Lab Book

There are a lot of things that can go wrong with the configuration. Don’t loose heart if things don’t work the first time. As always, test the configuration in your VM lab FIRST. Never try complex new configurations such as the one we’ve done in this article series on a production network. Once you are confident that you can get things working in your lab, and that you understand why things are working, then you can move to the production network and roll out the solution.

Here are some tips from my lab book, many of which are based on errors I made when configuring the solution for this article series:

  • Make sure that your public DNS contains the correct entries to enable clients to connect to the external interface of the ISA firewall
  • Make sure the internal DNS contains entries that map the common/subject name on the Web site certificate bound to the ISA firewall’s Web listener to the internal IP address of the ISA firewall
  • Confirm that SSL to SSL bridging is enabled on the RPC/HTTP Web Publishing Rule
  • Confirm that source IP load balancing is enabled on the RPC/HTTP Web Publishing Rule (when using Web farm load balancing)
  • Confirm that the original host header is sent by the ISA firewall to the front-end Exchange Servers
  • On the Outlook RPC/HTTP clients, confirm that you enter the users actual mailbox server in the correct text box and not the RPC/HTTP proxy server name (which is the name of the Web site certificate bound to the ISA firewall’s Web listener)
  • Make sure that that the FE Exchange Servers are actually configured to be FE Exchange Servers
  • Make sure that you have confirmed RPC/HTTP functionality on all the FE Exchange Servers
  • A HOSTS file entry is not required on the ISA firewall when using Web farm load balancing
  • The HTTP filter does not need to be configured to enable RPC/HTTP publishing to work correctly
  • You not need to make any changes in the OWA or RPC/HTTP Web Publishing Rules after the wizard is complete
  • You can use either the machine names or the IP addresses of the servers included in the Web Farm when configuring the server farm in the ISA firewall console
  • The external clients do not need to resolve the name of the mailbox server. External clients only need to be able to resolve the name on the Web site certificate bound to the Web listener

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

Conclusion

In this series of articles I demonstrated the procedures and methodologies you can use to publish a Web farm of front-end Exchange Servers using the ISA firewall’s new Web farm Web Publishing capabilities. The Web Publishing Rule published both the OWA and RPC/HTTP sites. We were able to demonstrate that the new ISA firewall enables you to publish OWA sites using FBA and RPC/HTTP using a single IP address on the external interface of the ISA firewall. We finished up by going over the Outlook configuration and then testing the configuration.

I hope you enjoyed this article series as much as I enjoyed writing it. I’ve been thinking for a long time that I need to get something up on how to publish RPC/HTTP sites, since the other articles on this subject were based on beta versions of Office 2003 and were well before the significant ease of use improvements that Exchange Service Packs introduced to RPC/HTTP connectivity.

When you configure your own publishing scenarios, please consider first, before embarking on the actual deployment and configuration, your DNS infrastructure. I strongly recommend that you deploy a split DNS infrastructure. Even if you can’t deploy a pure split DNS infrastructure, you can still use a parallel split DNS infrastructure, as I described in part 2 of the series. Even if split DNS is something new to you, I can honestly say that from long experience is in this business that a split DNS is the only way to go and leads to happy customers ever time, without fail.

If you missed the other parts in this article series please read:

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

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