In this post, we’re going to identify some of the common misconfigurations and issues when using ISA to protect an Exchange Server. We find that over half of the ISA servers that protect Exchange are not configured properly.
The first thing you need to understand are the authentication requirements for the various virtual directories that Exchange publishes. Here’s a good rule of thumb to follow:
- If you access the virtual directory using your web browser, you can protect it with pretty much any means you prefer. i.e. ISA Forms Authentication, direct pass-through, Basic, etc
- If you do not access the virtual directory using your web browser, but rather it is access using a rich client such as Outlook or some 3rd party application (through web services), it cannot be protected with forms authentication. If you hit the URL and you see a forms-based authentication prompt, you’ve misconfigured it
The second thing you need to understand is how ISA works and how it publishes Exchange. Most people run the Exchange publishing wizard that is provided by ISA. What people do not realize is that you need to run the wizard twice. Once to publish all of the user accessible pages that you access with your web browser and a second time to publish the web services. The following screenshot shows the publishing of the user accessible pages that you access using your web browser. Most people do this part correctly.
You will then need to run the ISA publishing wizard a second time to publish the web services as shown below:
This step is missed by more than half of the ISA servers that we have looked at. Without this step, you cannot access your Exchange Server using Outlook Anywhere or any 3rd party applications that use web services such as EWS.
One major flaw of ISA is that both of these published rules requires different web listeners (if you want to protect it using ISA Forms Authentication which is the default setting). This is because we need 2 different authentication settings: 1) ISA Forms Authentication and 2) Non-ISA Forms Authentication. This in turn complicates your deployment now as the two different web listeners needs different settings and cannot overlap. You need to change one or more of the following between the two web listeners:
- IP Address
- Server Port
You cannot publish the two rules with the same IP address, FQDN and port and yet have different authentication settings. If this sounds too complicated for you, we suggest a simpler approach.
- Do not enable ISA Forms Authentication. Make the authentication a direct pass-through and allow the client to authenticate directly with the server.
- Publish all of the Exchange virtual directories (client access and services) using the same rule.
As you can see from the above screenshot, we have disabled authentication on the web listener. You most likely have this set to be protected using ISA Forms Authentication (Front-End Back-End Authentication otherwise known as FBA).
Make sure you also include all of the services paths within the published Exchange rule also. The published paths should look as follows:
The paths you will most likely be missing are:
There are many ways to publish these settings but if you are not a firewall/Exchange/authentication expert, we suggest you just pass the requests directly through to Exchange and allow it to handle the requests for you rather than using FBA.