We are going to identify some of the common misconfigurations and issues when using Microsoft Internet Security and Acceleration (ISA) to protect an Exchange Server. We find that many 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 are some good rules of thumb to follow:
- If you access the virtual directory using your web browser, you can protect it any way you want to, 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 accessed using a rich client such as Outlook or some third-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 the wizard needs to be run 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 screen shot shows the publishing of the user accessible pages that you access using your web browser. Most people do this part correctly.
Note: screenshots below refer to Exchange 2010. Refer to Microsoft TechNet articles for exact steps for your version of Exchange.
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 reviewed. Without this step, you cannot access your Exchange Server using Outlook Anywhere or any third-party applications that use web services such as EWS.
One major flaw of ISA is that both of these published rules require different web listeners (if you want to protect it using ISA Forms Authentication, which is the default setting). This is because we need two different authentication settings: 1) ISA Forms Authentication and 2) Non-ISA Forms Authentication. This in turn complicates your deployment, 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.
This screen shot shows that 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. 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 simply pass the requests directly through to Exchange and allow it to handle the requests for you, rather than using FBA.