I really wanted to figure out the difference between Basic and NTLM authentication (also known as Integrated Windows authentication) when enabling Outlook Anywhere. Here is what I’ve found searching around. Let me know if you think differently.
When you enable Outlook Anywhere using Enable-OutlookAnywhere (or configuring it afterwards with Set-OutlookAnywhere) or the GUI you have to specify Basic or NTLM Authentication. This seems to cause a lot of confusion out there since many step-by-step guides simply told you to Basic (not telling you why) and some guides simply told you that you could choose the one you wanted to use but didn’t explain the differences – not much help.
Let’s see the scenario first. Outlook Anywhere (formerly called RPC-over-HTTP) is used when clients are out on the Internet and need access to their mailbox using a locally installed Outlook and traffic travels over HTTPS (tcp/443). Most common ways to accomplish this I would say are:
- (left picture) The preferred method – proxy all the HTTPS traffic using ISA/TMG (or any 3rd party proxy/load balancer) from the Internet to your internal CAS.
- (right picture) Put the CAS-server inside the firewall (configuring it with a public IP or NATing a public IP to it) and allow HTTPS traffic (tcp/443) to it.
In short, if you’re using a proxy which is ISA/TMG, NTLM should work. If you’re using a 3rd party it’s not sure it will proxy NTLM authentication correctly so you need to use Basic. This article, even though for Exchange 2003, explains it quite well.
If you have a firewall that examines HTTP traffic and modifies it in any way, you may have to use Basic authentication, instead of NTLM authentication. NTLM authentication fails if the RPC proxy server does not trust the authentication information. For example, you may have a firewall that ends the session from the Internet and establishes a new session to the RPC proxy server, instead of passing the HTTPS (SSL) session to the Exchange server without modification. This process is known as reverse proxying or Web publishing. Certain firewalls, such as Microsoft Internet Security and Acceleration (ISA) or Threat Management Gateway (TMG), can successfully reverse proxy or Web publish the session and still permit NTLM authentication to succeed.
So in the end (what I think), run NTLM if it works and your firewall/proxy support it – otherwise use Basic. With Basic, the user will always get prompted for username/password when they start their Outlook configured for OA. I appreciate Exchange Team’s comment on my question in their blog which explains it pretty well:
With regard to Basic vs NTLM from a user perspective, Basic, with any version of Outlook prior to 2010, results in a pop up dialog asking for creds. Outlook 2010 makes the ‘save this password’ actually work, so in an Outlook 2010 world, Basic can mean no need to authenticate every time you open/reconnect, but in all earlier versions, you will have to enter creds every time.
NTLM, when used by a client that is domain joined and logged in with cached creds, results in the client simply sending the cached in creds to the server, resulting in what looks like a pretty seamless single sign on experience. However, if you want to do pre-authentication at something like TMG, and not let the traffic go all the way to CAS, you need to configure TMG for this. That’s in the future Whitepaper. [Note 2011-09-26: this probably means the whitepaper Publishing Outlook Anywhere Using NTLM Authentication With Forefront TMG or Forefront UAG . Thanks Ben!]
NTLM on a machine without cached creds will again result in a pop up – or… there is a way to avoid that, but again for that you’ll have to read the upcoming whitepaper on how to get OA NTLM to work through TMG… yes, it’s a teaser… Reason is, the steps to get OA/NTLM to work, with pre-auth are complex, and I’d rather I give you all the steps you need than ask you to join the dots. It won’t be long before it’s ready.
Why all this and all the confusion? This and this article points out a clue why. You see, before Exchange 2007 SP1, the /rpc virtual directory had both Basic and NTLM authentication enabled by default and couldn’t be changed. In SP1 they decided this was a security vulnerability and changed it so you could choose.
Oh and how does the client know if it should use Basic or NTLM? It’s provided to the client using the AutoDiscover service.
I hope this explained it a bit… or maybe even confused you even more 🙂