Connecting the world…

publish

Microsoft ISA publishing – it’s all in the “path”

I have installed multiple reverse proxy servers based on Microsoft ISA 2006. These reverse proxy servers are mainly deployed to publish services like Outlook WebAccess, PDA synchronization, SharePoint or regular websites. Services like Outlook WebAccess are published using secure session protected by SSL certificates. Microsoft ISA server uses “Listeners” to match and intercept traffic from public users.

I have seen multiple ISA publishing rules with only match traffic when the user enters the specific URL in the browser. Let’s take OWA as an example. When users would like to access OWA, they need to enter the following URL: https://webmail.booches.nl/owa. The base URL is webmail.booches.nl and users need to add /owa manually, because internally the Exchange server is configured with a virtual directory called owa. Sometimes I see Listeners configured for HTTP and HTTPS and all HTTP traffic is redirected to HTTPS.

Is this solution user-friendly? What happens when the users makes a typo and enters http://webmail.booches.nl/ower? I try to configure the publishing rules to be user-friendly and I always configure separate Listeners for HTTP and HTTPS traffic. When publishing OWA I configure 3 firewall policy rules.

  1. 1. The first rule redirects all HTTP traffic (http://webmail.booches.nl/* to https://webmail.booches.nl/owa;
  2. 2. The second rule intercepts all the OWA traffic (https://webmail.booches.nl/owa);
  3. 3. The third rule redirects all HTTPS traffic (https://webmail.booches.nl/* to https://webmail.booches.nl/owa);

The first rule uses a Listener, which is configured for HTTP-only traffic and doesn’t use authentication. The firewall policy is intended for All Users and there is no authentication delegation.

action-http Action for HTTP and HTTPS redirect is to block the request and redirect the request to the correct URL for OWA
Listener-http The Listener for HTTP is configured without Authentication method and the rule is intended for All Users
path-http The public path contains /*

The second rule uses a Listener for HTTPS-only traffic and uses HTML Forms Authentication with LDAP, RADIUS or another authentication method. The associated firewall policy is intended for all Authenticated Users and uses authentication delegation based on Basic Authentication or Negotiate (NTLM / Kerberos) authentication.

Listener-owa The Listener for HTTPs is configured with FBA as authentication method and the rule is intended for Authenticated Users. The authentication delegation is configured for Basic Authentication or Negotiate
path-owa The public path configuration contains the appropriate Exchange virtual directories

The third firewall policy uses the same Listener as the second rule, but doesn’t use authentication delegation and is intended for all users. The configuration of the path, users and authentication delegation is the same as the first rule.

When you need to publish additional services, like ActiveSync or Outlook Anywhere, you have to add the specific publishing rules between the second and the third rule, so the redirection doesn’t mess up your publishing.

This setup is very user-friendly, at least that’s my opinion. The public user only needs to type the base URL (webmail.booches.nl) correct and he is always redirected to the OWA sign-in page. Service like ActiveSync or Outlook Anywhere are automatically configured to use the correct public path (/Microsoft-Server-ActiveSync or /rpc).

Exchange 2007 with ISA 2006

Today I have be working on publishing Microsoft Exchange Outlook WebAccess and Active Sync to the Internet. We had some discussions with some Microsoft Consultants about a secure way to publish Outlook Web Access to the Internet, especially the authentication part of such a solution.

Some people are talking about publishing OWA directly to the Internet. In my opinion, this results in a major security thread, because you directly publish a TCP/80 and TCP/443 connection from the Exchange server to the Internet. An vulnerability or exploit in these services could end up in an hacker who takes over the Exchange server.

A second solution is placing a front-end server in a DMZ segment, but making the server a domain member for authentication. In my opinion still a security leak, because somebody who hacks the DMZ server has maybe the ability to hack or corrupt the Active Directory.

The third solution, and the solution we advise, is using a Microsoft ISA 2006 server as a front-end server in the DMZ. We configure a RADIUS or LDAPS (if you would like the option to change the password) connection to a RADIUS server or a domain member on the internal LAN segment. This ensures a secure way of authenticating users and even if somebody hacks the ISA server, he still hasn’t hacked a domain member server or a vulnerability in TCP/80 or TCP/443 of the Exchange server.

I have had a lot of help of an article on isaserver.org from Thomas Shinder while configuring the solution. I had some problems with publishing Active Sync. Ended up with enabling Basic Authentication on the Active Sync virtual directory (Microsoft-Server-ActiveSync).