Publishing Exchange 2007 Services with ISA Server 2006 – Creating the Publishing Rule for Outlook Anywhere with Transparent Windows Authentication

This post covers publishing Exchange 2007 Outlook Anywhere using ISA Server 2006, but the key differentiator being that we can achieve all of the following:

• Provide transparent authentication for external Outlook Anywhere users if they are logged into domain member computers with cached credentials. This means that the Outlook password prompt seen with Exchange 2003 will no longer be present.
• Provide ISA Server pre-authentication for all requests, thereby providing the ultimate level of protection for Exchange 2007 Client Access Servers.
• Provide access to advanced Exchange 2007 Outlook Anywhere features like Autodiscovery, Out of Office, Offline Address Book, Unified Messaging and the Auto Account Setup Wizard etc.

Before getting started on the ISA Server configuration, it is helpful to provide an example environment upon which to base the examples. The diagram below shows an overview of a relatively standard architecture for external remote access to Exchange.

A summary of the environment is provided below:

• A single ISA Server 2006 (pre-SP1) firewall named ISA2K6.
• A single Exchange 2007 Client Access Server named CAS01.
• Two SSL server certificates are installed on the ISA Server. These are issued from a public Certificate Authority (CA) each with unique common or subject names of email.msfirewall.org.uk and autodiscover.msfirewall.org.uk respectively.
• A single SSL server certificate is installed on the Exchange CAS which replaces the default self-signed certificate. This is issued from an internal CA and is a Subject Alternate Name (SAN) certificate (sometimes called a Unified Communications (UC) certificate). The common or subject name of this certificate is email.msfirewall.org.uk and the primary SAN entry is also email.msfirewall.org.uk. Additional SANs have been defined as per the diagram to cater for alternate access names used by internal clients.

• ISA Server is configured to trust the internal issuing CA that issued the Exchange CAS certificate and also trust any additional Root or Intermediate CAs, as necessary.
• The ISA Server and Exchange CAS are both members of the same Active Directory domain.

• SSL bridging is used to ensure all communications are encrypted across both the public and private networks.
• All clients are using Microsoft Outlook 2007.
• A dedicated FQDN is defined for Outlook Anywhere which resolves to a dedicated public IP address.

Please Note: In order to minimise potential problems with ISA Server 2006 pre-SP1, it is recommended to define the Exchange CAS certificate common name and first SAN as email.msfirewall.org.uk. This configuration will negate likely problems with ISA Server 2006 pre-SP1 from reading multiple SAN entries as discussed here. For the purposes of this article I have assumed that ISA Server is running the RTM pre-SP1 version and we would also be publishing access to Outlook Web Access using a URL of email.msfirewall.org.uk.

Although not covered in this article, it is possible to extend the simple approach defined above with the use of additional certificates to personalise external DNS names to specifically match each Exchange service. An overview of this architecture is shown below.

This configuration is not technically necessary, but it does provide a slightly more elegant solution and makes things a little bit more intuitive when looking at DNS names in Windows Mobile or Outlook configuration screens. However, apart from 'elegance', a solution comprising of two individual SSL server certificates is more than sufficient for a working configuration.

Please Note: In theory it is possible to use a single wildcard certificate for this scenario, but from my own testing I have found that the use of a wildcard certificate had an adverse effects on the Outlook Auto Account Setup wizard which I was unable to resolve (even after enabling the 'Set-OutlookProvider -identity EXPR -CertPrincipalName msstd:*.yourdomain.com' PowerShell command as defined here). We also need to consider that Windows Mobile 5 does not support wildcard certificates, so if you have a mixed Windows Mobile client base this will also cause issues. Based upon this, for the time being (and for this example solution) I have been cautious and used individual certificates for most of my deployments.

One of the challenging aspects of Outlook Anywhere publishing is how to achieve transparent authentication (e.g. not having to enter a password in Outlook when away from the office) and also ensure that all Outlook Anywhere connections are pre-authenticated by ISA Server. ISA Server pre-authentication is a vital part of any ISA Server deployment as this ensures no anonymous connections can ever reach the internal Exchange infrastructure.

In it's current form, ISA Server is not able to require Windows integrated authentication and then delegate credentials using NTLM delegation. This is based upon the fact that this authentication protocol is designed to use a challenge/response process and specifically prevent 'man-in-the-middle' attacks. As ISA Server is the 'man-in-the-middle' in a reverse proxy topology, this is just not possible to achieve. Therefore, in order to authenticate Outlook Anywhere connections using Windows authentication is it necessary to use Kerberos Constrained Delegation (KCD). ISA Server 2006 introduces support for Kerberos constrained delegation to enable published Web servers to authenticate users by Kerberos after their identity has been verified by ISA Server using a non-Kerberos authentication method. When used in this way, Kerberos constrained delegation eliminates the need for requiring users to provide credentials twice. For example, because it is unrealistic to perform Kerberos authentication over the Internet (no access to the KDC server), Windows authentication might be used for authenticating users at the ISA Server computer. After ISA Server verifies the user's identity, ISA Server cannot pass the Windows credentials provided by the user to a published server, but it can impersonate the user and obtain a Kerberos service ticket for authenticating the user (client) to a published Web server.

Based upon this approach, the following diagram shows an overview of the authentication elements used in our solution example.

A key element of successfully using KCD is ensuring that the correct Service Principal Names (SPNs) are defined and used. Rather than creating new SPNs, it makes sense to me to utilise the built-in SPNs that are created by default. Hence, this example makes use of the default SPN created for the Exchange CAS. As we are publishing web services on the Exchange CAS, this means that we are specifically talking about the HTTP SPN. In our example solution (as shown above) the default system generated SPN for the Exchange CAS is http/cas01.internal.msfirewall.org.uk so we will use this in our configuration.

In addition to thinking about SPNs, for KCD to function correctly it is also necessary to configure the ISA Server computer object in Active Directory and enable delegation. In order for the ISA Server to be trusted for delegation, it needs to be correctly defined. Furthermore, to ensure we provide a least privilege solution, we will use constrained delegation to ensure that we only trust ISA Server to delegate the appropriate service (HTTP in our example) and not all services (hence constrained).

This can be achieved using Active Directory Users and Computers. Firstly, find the computer object for the ISA Server and select Properties. Click on the Delegation tab. Select the option for Trust this computer for delegation to specified service only, then select Use any authentication protocol. Finally, click the Add button and browse for the Exchange CAS computer object (CAS01 in our example). On the list of available SPNs defined for CAS01, select the entry for http/cas01.

Once configured, you should see the following:

If you tick the Expanded option, you will actually see that both NetBIOS and FQDN are listed as shown below:

So, with the above configuration, we have configured ISA Server to be trusted for delegation of credentials, but only to the Exchange CAS, and only for the HTTP service, hence the term constrained.

Please Note: Active Directory will need to be running at Windows 2003 native functional level (or greater) in order to see the Delegation tab. Also, both computer objects will need to be in the same Active Directory domain for KCD to function (even with ISA Server 2006 SP1).

As Windows authentication and Forms Based Authentication (FBA) are mutually exclusive, it is not possible to use a single web listener for all Exchange 2007 publishing and achieve transparent authentication within Outlook Anywhere. Therefore, as part of this solution it is necessary to create a dedicated web listener that is used exclusively for Outlook Anywhere and associated services like Exchange Autodiscovery, EWS, OAB, UM etc. This is a bit of a shame, but an acceptable compromise in my opinion and likely to remain until ISA Server is able to perform fallback to NTLM. The introduction of a dedicated web listener for Outlook Anywhere also introduces the need for an additional public IP address.

Without going into specific details (more detail can be found here) the Outlook Anywhere client relies upon the Exchange 2007 Autodiscover service in order to determine where to find information about supplementary services like EWS, UM, and OAB. Therefore, within our solution we need to provide access to the Exchange 2007 autodiscover service located on the Exchange CAS. The Outlook Anywhere client is hard coded to look for the autodiscover services using the following URLs:

https://smtpdomain.tld/autodiscover/autodiscover.xml https://autodiscover.smtpdomain.tld/autodiscover/autodiscover.xml.

In our example, these become:

https://msfirewall.org.uk/autodiscover/autodiscover.xml https://autodiscover.msfirewall.org.uk/autodiscover/autodiscover.xml.

In reality, we only really need to consider the second of these URLs as this contains a specific hostname value which is more practical. Seeing as though this URL will always be required by the Outlook Anywhere client, it makes sense to me to reuse this URL as the Outlook RPC over HTTP(S) proxy definition URL. This ensures that a single URL and single SSL server certificate will be sufficient for all Outlook Anywhere functionality, including advanced features.

One of the critical steps in getting Outlook Anywhere to be fully function is to define external URLs for each Exchange service used by Outlook. This ensures that when Outlook is used externally (without access to Active Directory or the Exchange Service Connection Point) it will be able to determine the correct external URLs using the autodiscover process, as opposed to using the default internal URLs defined as part of the Exchange setup process. The default internal URLs will normally contain internal URLs of the form https://cas01.internal.msfirewall.org.uk which will probably not function externally.

At this time, I am not including specific details on configuring the Exchange CAS (as this is quite an in-depth subject!) but the following summary covers the key configuration steps:

Using the Exchange Management Console, enable Outlook Anywhere; define the external hostname as autodiscover.msfirewall.org.uk and client authentication method as NTLM authentication.

Using IIS Manager, ensure the following virtual directories have Integrated Windows authentication enabled:

• Autodiscover
• EWS
• OAB
• RPC
• Unified Messaging

Using the Exchange Management Shell, define Exchange Web Services (EWS), Offline Address Book (OAB) and Unified Messaging (UM) External URLs as follows:

EWS: https://autodiscover.msfirewall.org.uk/ews/exchange.asmx

OAB: https://autodiscover.msfirewall.org.uk/oab

UM: https://autodiscover.msfirewall.org.uk/unifiedmessaging/service.asmx

This can be achieved using the following PowerShell commands:

Set-WebServicesVirtualDirectory -Identity 'CAS01\EWS (Default Web Site)' -ExternalUrl https://autodiscover.msfirewall.org.uk/ews/exchange.asmx

Set-OabVirtualDirectory -Identity 'CAS01\OAB (Default Web Site)' -ExternalUrl https://autodiscover.msfirewall.org.uk/oab

Set-UMVirtualDirectory -Identity 'CAS01\UnifiedMessaging (Default Web Site)' -ExternalUrl https://autodiscover.msfirewall.org.uk/unifiedmessaging/service.asmx

Please Note: For completeness, I would recommend defining the External URL reference for all services (as shown above) even if they are not in use at the present time. This minimises the risk of forgetting they have not been configured when you try to access a new Exchange service and it doesn't work via Outlook Anywhere!
If the above means nothing to you then I suggest you start by reading the Exchange 2007 Autodiscover Service whitepaper here for a bit of background/bedtime reading...

The Exchange 2007 CAS is now configured, Active Directory delegation is enabled and hopefully we have an understanding of the solution approach and proposed authentication elements. So, let's start configuring ISA!

From within the ISA Server Management Console, select the Publish Exchange Web Client Access wizard.

Enter a suitable publishing rule name like Publish Exchange 2007 Outlook Anywhere

Define the Exchange Version as Exchange 2007, select Outlook Anywhere (RPC/HTTP(s)) and Publish additional folders on the Exchange Server for Outlook 2007 Clients.

Select Publish a single web site or load balancer

Define the Internal site name as email.msfirewall.org.uk. Select the Use computer name or IP address to connect to the published server option and enter cas01.internal.msfirewall.org.uk into the Computer name or IP address field.

Please Note: Due to issues with ISA Server 2006 pre-SP1 and SAN certificates (discussed here) it has been necessary to use an internal site name that matched the actual subject name (or first SAN entry) of the SSL server certificate installed on the Exchange CAS (email.msfirewall.org.uk in our example) as opposed to using autodiscover.msfirewall.org.uk. However, this issue has been fixed in ISA Server 2006 SP1 so we could actually specify autodiscover.msfirewall.org.uk as this is listed in the SAN entries of the Exchange CAS certificate. However, with an ISA Server 2006 SP1 both FQDNs should work fine.

Enter autodiscover.msfirewall.org.uk into the public name field.

On the Select Web Listener page, click New and define a suitable name for the listener like Exchange Listener (Internet Integrated).

Select Require SSL secured connections with clients

Click Select Certificate and select the appropriate certificate from the list



Please Note: This step assumes that you have already purchased and installed certificates into the Local Computer certificate store on the ISA Server.

On the Authentication Settings page, select HTTP Authentication and Integrated.

Click Next and then Finish.

With the web listener created, click Next to continue.

On the Authentication Delegation page, select Kerberos constrained delegation and enter http/cas01.internal.msfirewall.org.uk into the SPN field.

Click Next

Click Finish to complete the rule wizard.

You should now see the rule defined in the firewall policy.


To make life a little easier for users, I generally enable HTTP to HTTPS redirection on the HTTPS listeners.

I also tend to enforce 128-bit (high) encryption for HTTPS traffic.

Looking at the Paths tab, we can clearly see all of the virtual directories used by Outlook Anywhere which should match the External URLs defined on the Exchange CAS earlier within this post.

So, with all this in place, all we need to do is configure Outlook with the appropriate settings. This can be done using the Auto Account Setup Wizard which is initiated from the Mail applet in Control Panel. The following diagrams show this process.

Looking at the Exchange Proxy settings (RPC/HTTP(s) settings) that have been configured by the wizard, you should see something like this:

So, you should now be able to start Outlook and successfully connect to Exchange 2007 without providing any credentials (assuming you are on a domain member computer and logged in with cached credentials).

Hopefully this blog entry has provided a good overview of the necessary elements required to publish Exchange 2007 via ISA Server with transparent authentication and ISA pre-authentication. Obviously, it does not cater for all scenarios (like wildcard certificates and ISA/CAS high availability for example) but it should be relatively easy to adapt to your specific needs.

I hope to add more blog entries for publishing other Exchange 2007 services, the next probably being publishing Exchange 2007 Outlook Web Access specifically covering the Document Access feature, which is pretty cool for remote users!

Download this Article

Post by http://blog.msfirewall.org.uk/2008/07/publishing-exchange-2007-services-with.html