On Web Listeners and Web Publishing Rules

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.

After working with the same product for almost eight years, you begin to take some things for granted and do not think about how they work and how other people might have difficulties understanding the concepts when these concepts are new to them. Even worse, when you work with the same product for so long, you take it for granted that you understand certain concepts and how to work with them, when in fact you might not really understand them at all. I found myself in that position last week when trying to figure out how to publish the autodiscovery feature that allows the Outlook 2007 client to automatically configure itself to use the ISA Firewall as its reverse Web Proxy.

Discuss this article

I have to give Jim Harrison and Jason Jones credit for working with me in the process of figuring out how to use a single Web listener to publish two secure Web sites. The problem I had was that I was still thinking in terms of how the 2004 ISA Firewall handled secure Web Publishing Rules and Web listeners. Once Jim and Jason shook me hard enough, I realized what they were trying to tell me was possible.

First, let’s review what happens when the Outlook client tries to gain autodiscovery information. When an Outlook 2007 client is not domain joined, the client uses a predefined set of URLs to gain access to the autodiscovery site on the Client Access Server. These are:

  • https://smtpdomain/Autodiscover/Autodiscover.xml
  • https://autodiscover.smtpdomain/Autodiscover/Autodiscover.xml
  • http://autodiscover.smtpdomain/Autodiscover/Autodiscover.xml

As you can see, this might present a problem, since when you are publishing your OWA, ActiveSync and Outlook Anywhere sites, you are going to need two different FQDNs and hence two certificates to publish the Exchange Web services sites and the autodiscover site. For example, suppose the SMTP domain name is msfirewall.org and all of our users belong to the msfirewall.org domain, so that they have addresses such as [email protected]. We would need to listen for:

  • Connections to the OWA, ActiveSync and OutlookAnywhere at https://owa.msfirewall.org
  • Connections to the Autodiscover site at https://autodiscover.msfirewall.org

In my way of thinking, we would need at least two IP addresses on the external interface of the ISA Firewall. The reason for this is that one IP address would be used for the Web listener that binds the owa.msfirewall.org certificate to itself, and the second IP address would be used by the Web listener that binds the autodiscover.msfirewall.org certificate to itself. In addition to the two Web listeners, we would then need to create two Web Publishing Rules, one that uses the owa.msfirewall.org Web listener and one that uses the autodiscover.msfirewall.org Web listener.

While all that is well and good for ISA 2004 Firewalls, it is not required with the 2006 ISA Firewall. Why? Because a new feature in the 2006 ISA Firewall enables us to bind multiple certificates to the same Web listener, just as long as each certificate is associated to a different IP address that the Web listener is listening on.

Let’s take a look at the ISA 2006 Web listener and see how this works. I think it will make more sense after we do so.

ISA 2006 Web Listeners

A Web Listener is a software component that accepts connections from non-Web Proxy clients and forwards the connections to the ISA Firewall’s Web Proxy filter. A Web listener is similar to the Web proxy listener that is associated with each ISA Firewall Network (if you choose to enable the Web Proxy listener on a particular ISA Firewall Network). However, Web Listeners have additional features over those provided by Web Proxy listeners, which make them ideal for accepting connections to published servers. Web Listeners are called into play only when you associate them with a Web Publishing Rule.

A Web Listener is responsible for:

  • Defining what networks (or IP addresses) the Web Publishing Rule associated with the Web listener will accept incoming connections
  • Defining what protocols will be allowed for the connection (HTTP or HTTPS)
  • Defining what certificates are bound to which IP addresses that the Web Listener is listening on
  • Defining the single sign on domain
  • Defining what forms might be used for authentication for the Web Listener
  • What type of authentication methods or protocols are accepted for connections to the Web Listener

In the figure below you see General tab in the Web Listener’s Properties dialog box. Here you can give the Web Listener a name and provide a description for the purpose of the Web Listener.


Figure 1

In the figure below you see the Connections tab of the Web Listener. Here you define what protocols the Web Listener will support. In this example we want the Web Listener to listen only for SSL connections, so the checkbox for the Enable HTTP connections on port checkbox is cleared. This Web Listener is going to be used to accept connections to the OWA, ActiveSync and Outlook Anywhere connections, all of which need to be done over a secure SSL channel. In addition, this Web Listener will be used to accept connections from the Outlook 2007 client to obtain autodiscover information.


Figure 2

On the Authentication tab you set what method of authentication you want the client to use to authenticate with the ISA Firewall. When a connection is made to a published Web server, there are actually two authentication events taking place:

  • First, the external client authenticates to the ISA Firewall
  • Second, the ISA Firewall forwards the client’s credentials to the published Web server and the Web server authenticates the user

As you can see, the user is authenticated twice – by the ISA Firewall and then by the published Web server. Only after successfully authenticating with both devices is the connection allowed to the published Web server. In addition, the user must be authorized to access the Web server – this authorization is enabled in the Web Publishing Rule itself, not by the Web Listener.

Notice that HTML Form Authentication is enabled on this Web Listener. In ISA 2004, selecting forms-based authentication for Outlook or any non-Web browser client would not work, because the non-Web browser application would not know what to do with the form. In contrast, with ISA 2006 Firewalls, the ISA Firewall will examine the client-agent header and if the client-agent is not a Web browser, the ISA Firewall’s Web Listener will fall back to Basic Authentication. Therefore, Outlook and ActiveSync clients will use Basic Authentication when authenticating with the ISA Firewall.


Figure 3

The Forms tab allows you to use built-in and custom forms for authentication. When you use the Web Publishing Rule wizard for Exchange services, you do not need to make any changes in this dialog box regarding Form Customization. However, since we are using the Web Listener for our OWA Web Publishing Rule, you might want to consider enabling password management features such as Allow users to change their passwords and Remind users that their password will expire in this number of days. Enabling these features will have no effect on the Outlook 2007 clients connecting through this Web Listener, though.


Figure 4

The SSO tab is where you define your single sign on domains. Users who authenticate with any of these domains will not need to reauthenticate when connecting to another server within the same domain.

Discuss this article


Figure 5

On the Networks tab you define the IP addresses that the Web Listener will listen on for incoming connections. In the example you see below, the Web Listener is configured to listen on two IP addresses bound to the external interface and one IP address bound to the internal interface.

The two IP addresses on the external interface resolve to two different FQDNs: 192.168.1.71 resolves to owa.msfirewall.org and 192.168.1.72 resolves to autodiscover.msfirewall.org. IP address 10.0.0.1 resolves to owa.msfirewall.org for internal clients. As always, we employ an integrated split DNS infrastructure, so that external clients resolve names to externally accessible addresses and internal clients resolve names to internally accessible addresses. Internal clients resolve the name owa.msfirewall.org so that they can benefit from the ISA Firewall provided form and security screening provided by the HTTP Security Filter in the same way as external clients.


Figure 6

Now that we see that multiple IP addresses can be bound to a single Web Listener, the next thing we need to take care of is binding a certificate to each of those IP addresses. In the figure below you see the Certificates tab for this Web Listener. ISA 2006 Firewalls enable you to bind a certificate to each IP address when you select the Assign a certificate for each IP address option and then click the Select Certificate button.

As you can see, IP addresses 10.0.0.1 and 192.168.1.71 have the owa.msfirewall.org certificate bound to them so that when calls are made to owa.msfirewall.org to those IP addresses, the Web Listener will be able to establish an SSL session with the client. IP address 192.168.1.72 has the autodiscover.msfirewall.org certificate bound to it, so that when calls are made to autodiscover.msfirewall.org on that IP address, the ISA Firewall will be able to establish an SSL session with the client.


Figure 7

The figure below shows how to bind the certificate to an IP address handled by the Web Listener. First you select the IP address as shown in the figure above and then click Select Certificate. Then you see the Select Certificate dialog box as seen in the figure below. Then you click on the certificate you want bound to that IP address and click Select. Notice that in this dialog box you get information about the Validity of the certificate and the Expiration Date.


Figure 8

ISA 2006 Web Publishing Rules

Web Listeners are not much use without a Web Publishing Rule to connect it to. In this example of dealing with Web Listeners and Web Publishing Rules for OWA, ActiveSync and RPC/HTTP and Outlook Autodiscover, there are a few key elements that need to be included in the Web Publishing Rule.

In the figure below you can see the Properties dialog box of our Outlook Anywhere Web Publishing Rule. On the Public Name we include two public names: one for owa.msfirewall.org which is the name used by the Outlook Client to connect to the ISA Firewall to connect to the RPC/HTTP on the Client Access Server and the other is autodiscover.msfirewall.org which is used to connect to the /Autodiscover folder on the Client Access Server.

It is important to note that these two names resolve to two different IP addresses. That is OK, because the Web Listener that is used by this Web Publishing Rule is configured to listen on these IP addresses and each IP address has the correct Web site certificate bound to it with a common name that matches one of these Public Names.


Figure 9

On the Paths tab is a list of paths that this Web Publishing Rule will forward connections to. For example, when the external Outlook 2007 client connects to the RPC/HTTP proxy on the Client Access Server, it will use this rule to gain access to the resource located at https://owa.msfirewall.org/rpc

In addition, since this Web Publishing Rule is also listening for connections to autodiscover.msfirewall.org, this rule will be able to forward connections made to https://autodiscover.msfirewall.org/AutoDiscover


Figure 10

Now we see how we can publish multiple SSL sites with different public names using a single Web Listener and a single Web Publishing Rule. The key to understanding how we can do this is to understand that a single Web Listener can be listening on multiple IP addresses and that you can bind a separate certificate to each IP address. This enables us to use a single Web Publishing Rule to publish all of these secure Web sites. This works because we want to use the same authentication at the ISA Firewall for each of these sites.

Discuss this article

Conclusion

OK, everything looks good on paper and from Jim and Jason tell me, it should work. However, I will believe it when I see it! In the next article we will build on the 7 part Exchange 2007 publishing scenario and see if we can get Outlook Autodiscovery to work. We might even see if we can get the Offline Address Book to work too while we’re at it, and if things go our way, we will see if we can get File Share access from the Exchange 2007 OWA.

Cross your fingers and I hope to report success next week! –Tom.

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.

About The Author

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