Since writing the first part of this article here, I’ve seen a lot of questions about how you really publish things like the Autodiscover as there have been many articles out there where they keep the Autodiscover in the Outlook Anywhere rule and others where they separate it out. I wrote the first part of this article a while back when Autodiscover was quite unknown and I was a bit new to ISA and figuring things out. Since then, I have done quite a bit with Autodiscover and written several articles about it as well as done a lot with ISA itself. Because of that, I wanted to create a part 2 and really detail on the different methods which you can use in regards to authentication and how it really ties together.
One thing needs to be taken into consideration. Integrated Authentication in IIS uses NTLM or Kerberos. These protocols were designed to prevent man in the middle attacks. What this means is that when you create an ISA rule, you cannot typically have your rule’s authentication delegation using Integrated Authentication as this will mean that ISA is attempting to do a man in the middle attack. There are two ways to make this work. One is by using Kerberos Constrained Delegation in which you use a separate listener which listens on NTLM and then use Kerberos Constrained Delegation to talk to Exchange. This way, you enable Outlook Anywhere for NTLM, then allow ISA to request Kerberos tickets and pass that right to Exchange. The other method is to set the rule to not require the client to authentication to ISA but the client can authenticate directly to Exchange. This prevents ISA from delegating NTLM and then allows the client to NTLM auth directly to Exchange. This way you can have 1 listener because when you configure the bypass, it’ll trump the requirement to authenticate to the listener. And because Autodiscover uses Integrated Auth, you can have Autodiscover on the same rule.
An important thing to note is that if you do decide to go with Kerberos Constrained Delegation, both the ISA and CAS computer accounts need to be on the same domain. It is because of this, the KCD method will not work when ISA is joined as a workstation.
So the existing ways to publish Exchange with Autodiscover are the following:
- Outlook Anywhere NTLM
- Two Configurations
i. Increased Security and added complexity – Utilize a separate listener just for your OA rule that utilizes NTLM and then configure Kerberos Constrained Delegation as the Authentication Delegation mechanism within the OA rule to authenticate to IIS on the Exchange CAS RPC Proxy Server
ii. Reduced Security and less complexity – Utilize the same listener for all Exchange Services including OA and take ISA Pre-Authentication out of the mix and allow the client to authenticate directly to the Exchange Server. Because ISA Pre-Authentication is taken out of the mix, NTLM will work and the user will not be prompted since there’s nothing in the middle preventing a man in the middle attack.
- Because you’ll be using NTLM with OA, you can use Autodiscover on the same rule
- Two Configurations
- Outlook Anywhere Basic
- Use the same listener for all Exchange Services.
- Set listener to forms based authentication since the listener will fall back to Basic Authentication since OA does not support Forms.
- Configure each rule with the appropriate authentication delegation mechanism so each service in the /path/* for that rule contains the same authentication within IIS. So for example, if I have OAB and EWS on that same rule and Basic Authentication delegation is configured for that rule, IIS for both OAB and EWS will need to contain Basic Authentication
So let’s take a look at Outlook Anywhere with NTLM. Because we’re using NTLM, we’ll need to either create a new listener and have that use NTLM and then use Kerberos Constrained Delegation. This way, a client on the internet can use NTLM and then the ISA machine needs to be able to request Kerberos tickets on behalf of the authenticated user and then pass this service ticket to the Exchange Server. This gets around the man in the middle attack. But because of this, you’ll need the NTLM listener and then a different listener for things such as OWA/EAS/Etc.. With this method, you’ll have 2 listeners. Because you’re using NTLM, you can have your Autodiscover path (which passes NTLM to Exchange) on the same rule as Outlook Anywhere.
Now with Kerberos Constrained Delegation, that’s the only time you’ll have a 2nd listener. Any other situation you’ll have just a single listener. You can still use Outlook Anywhere with NTLM, but in this case, you’ll have to configure your rule to not require authenetication from ISA and to just allow the client to authenticate directly. This way, you’re bypassing Pre-Authentication. But even with bypassing pre-authentication, you’re still being authenticated.
Now with any of the above 2 configurations, you can have Autodiscover on the Oulook Anywhere rule because you’re essentially allowing the client to use NTLM (first method uses NTLM on listener and KCD to authenticate to the Exchange Server and second one bypasses ISA pre-authentication and lets client authenticate directly to Exchange in which NTLM will work.)
Now if you’re using Basic Authentication for Outlook Anywhere, you can just have 1 listener that just does Forms Based Authentication. This is because if the service authenticating to the listener does not support FBA, ISA 2006 (not ISA 2004) has the capability to fallback to basic authentication. It’s this reason you can use a single listener. Then for all the services, you’ll need to make sure the rule’s authentication delegation is set approproiately. Authentication Delegation is always only set on a rule and the delegation type has to match what is set in IIS on Exchange. So if you authenticate to ISA’s listener via FBA, ISA will then look at the rule’s authentication delegation and then use that authentication type to authenticate back to Exchange. It knows which rule to use by looking at the /path/* in the rule.
When you use this method, I will typically put Autodiscover in its own rule and set that to bypass pre-auth while all other services are not bypassing pre-auth. I don’t leave the /autodiscover/ path in the Outlook Anywhere rule because they will now be using different authentication types. And I don’t want to be authenticated by Autodiscover and Outlook Anywhere (if using basic) so I let Autodiscover bypass pre-auth but still require Outlook Anywhere to authenticate.
One thing to keep in mind here, is with ISA 2006, if you configure a rule to bypass pre-auth, it’ll trump the listener and the client won’t need to satisfy the listener authentication and the authentication will pass through in which Exchange will then perform the necessary authentication.