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.
Racing APK says
Well, thanks a lot! It is a bit old but still helped :)
halfluke says
ok, everything is working fine now. I think one of the main issue was that ISA was not joined to any domain and I was using FBA with AD in the listener, now I've configured FBA with LDAP. I also removed the anonymous authentication from autodiscover. Now everything works with one rule only, one listener, just adding the autodiscover fqdn to the Public tab in the rule. To tell the truth, I'm using Exchange 2010, not 2007, with all the roles on the same machine, and as I said before, FTMG 2010. OWA is fine as well. Haven't tried ActiveSync. Happy to share! :)
halfluke says
ok, don-t worry… I've just found out I have many other problems along with that one… :-s
halfluke says
Unfortunately not…
my config works only with Basic in the authentication delegation and FBA with AD in the listener.
That way, the autodiscover works, but only AFTER you have created a profile.
When you create a profile on an external client, you have to use manual settings the first time.
Then, you can successfully test autodiscover in outlook, download OAB, use OOF etc..
In the public name I added autodiscover.domain.com to make it work this way.
But I can't find a way to create a new profile with autodiscover…
any idea?
Elan Shudnow says
Turn Anonymous off. I think that may be breaking it.
halfluke says
Hi,
problem here is that when I use the Basic method for Outlook anywhere, and I create a new rule for Autodiscover with the same listener set on FBA, when I want to create a new profile externally, it doesn't work.
It keeps prompting me for password 3 times then it fails…
the new rule has No delegation, but client may authenticate directly.
In iis autodiscover has anonymous, integrated and basic.
This is with Forefront threat management gateway 2010, which looks to me almost identical to isa 2006 for this aspect.
Is it a problem with SAN certificates? Should I request a new certificate to be used for Autodiscover, and create a new Web listener? See here: http://www.isaserver.org/tutorials/Publishing-Exc…
Elan Shudnow says
Yes, “Bypass Pre-auth” = “No delegation, but client may authenticate directly”
Adam says
I’m obviously missing something or mis-understanding something. I’m missing where you set the “Bypass Pre-auth” piece. Is this the same as setting “No delegation, but client may authenticate directly”? Or is it different?
Also, I’m using Basic authentication versus NTLM.
Elan Shudnow says
Adam, when Autodiscover is on its own rule and you set to bypass preauth, you don’t modify the autodiscover virtual directory at all on Exchange. You’re just telling the client to auth via NTLM directly to the virtual directory. That’s the entire point. You still allow NTLM to Autodiscover without ISA being a man in the middle.
Adam says
When you say “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.” under the section about Basic Authentication, are you setting the selection on the Authentication Delegation tab? If so, are you setting it to “No delegation, but client may authenticate directly” or “No delegation and client cannot authenticate directly”?
Also, if you are choosing the later, do you set the IIS Virtual Directory for AutoDiscover to accept anonymous connections?
Thanks!
Nomi says
Hi, sorry for posting test comments earlier, the reason for that i’ve question on Post “Office Communications Server 2007 R2 Enterprise Deployment – Part 5” and i couldn’t able to post reply on that post, when i click Submit comments the blank page appear but in this post i can submit comments.
I am sorry to do but appreciate if someone can help to put following question into related post or answer over here.
================================
I am setting up edge server without ISA (reverse proxy), director & loadbalancer. I’ve 1x EE and 1x edge server (DMZ).
Edge server configuration:
While configuring “Configure Other Internal Servers and Pools for External User Access (http://technet.microsoft.com/en-us/library/dd425276(office.13).aspx)”.
1a) “On the Trusted Access Edge and Web Conferencing Edge Servers page” should i define access edge server and web conferencing edge server FQDN which i define in “Configure edge server wizard – External interface”.
1b) Under “Specify the Access Edge Server that internal servers will use for outbound traffic” should i define access edge server FQDN which i define in “Configure edge server wizard – External interface”.
2) On the “Web Conferencing Edge Server” the external interface FQDN will be web conferencing edge server FQDN which i define in “Configure edge server wizard – External interface” but what should i type in “Internal FQDN” (I’ve no internal FQDN for web conferencing). Should I type Pool name in internal FQDN or edge server full computer name/ the name I specified for edge server internal interface.
=========================================================
I understand from your document the FQDN for internal interface will be FQDN of edge server Full computer name but is it ok to define (create A(host) in internal DNS) with another FQDN for internal interface.
If other FQDN can be use for internal interface so when requesting certificate for private interface the CN should be other FQDN not the edge server computer name.
=========================================================
In part 5 you have requested Access/Web Conferencing Edge Certificate together, have you checked both “Access edge server public interface & web conferencing public interface” option on OCS certificate wizard or one by one with same CN and SAN.
=========================================================
In “Configure edge server wizard/external interface” do we must have to specify A/V IP and FQDN even if it is not in scope? Can we just type access & web conferencing edge server IP and FQDN.
=========================================================
Elan Shudnow says
Nomi,
1a) Enter the internal FQDN of your Edge Server. This will be the internal NIC FQDN
1b) Same as 1a
2) The internal FQDN for web conferencing is the internal NIC FQDN. For external web conferencing, it would be something like webconf.externaldns.com
When not using load balancing, you’ll need to make sure that it’s the servername.domain.com and the FE should be configured to point to that servername.domain.com in 1a and 2a. If you’re using load balancing, your FE to Access Edge communication uses a separate FQDN which is the VIP of your load balancer and for FE to web conf, it uses the servername of the computer (which uses PSOM unencrypted.)
As for requesting cert, you can do either. The checkmarks are more for enabling. You still have to either request each cert manually since the supported method by MS is to have a dedicated cert for each service. But you could create the certificate wizard request and add the rest of your names as SAN names and then when you’re asked to create the cert requests for the remaining services, you can just assign the existing SAN certificate.
You can leave A/V unchecked if you don’t require this service. It won’t ask you to configure DNS/etc…