Q: Microsoft eliminated NTLM as an authentication method in Exchange 2010 RTM, yet it was reinstated in Exchange 2010 SP1 -- should I use it or not?
A: A number of third-party MAPI, POP3 and IMAP4 connectors rely on Windows NT Lan Manager (NTLM) to authenticate to Exchange Server. And while Microsoft still encourages various authentication mechanisms, NTLM was disabled in Exchange 2010 RTM as an attempt to persuade Exchange administrators to move away from it.
The attempt wasn’t successful, but it is helpful to know why Microsoft made this decision and continues to discourage using NTLM to authenticate to Exchange Server.
NTLM sends logged-in user credentials to Exchange. Data is encrypted by a cryptographic hash for security purposes. NTLM’s major advantage is integration and users need only sign in once.
When Microsoft released Exchange 2007 SP1, both NTLM and basic authentication in the /rpc virtual directory were considered security risks. Neither inherently caused security problems, but having both available simultaneously could lead to issues.
This setup was still allowed however, because there were specific circumstances where it was useful. Microsoft’s own documentation describes one such scenario as “when additional services for RPC over HTTP are proxied to the same Client Access server that provides Outlook Anywhere access.”
With the Exchange 2010 RTM release, NTLM support was discontinued for POP3 and IMAP4 connectivity. The only two authentication methods Microsoft supported for Exchange via POP3 or IMAP4 were Kerberos or plain-text authentication over secure sockets layer (SSL).
So why did Microsoft do this? The Exchange team went into some detail in a TechNet blog post about why they recommend Kerberos or even plain-text with SSL over NTLM. In Exchange Server 2010, Exchange clients connect to an Exchange server that has the client access server (CAS) role installed, rather than directly to the information store or mailboxes.
More importantly, this configuration allows for a slew of architectural improvements in how Exchange connections are handled. This includes better management for SOX-style compliance features, a more seamless implementation of Exchange’s high-availability features and better load-balancing architecture and logic.
It’s the load-balancing aspect that turned out to be an issue when it came to using NTLM. The more NTLM connections made, the higher probability there is for a bottlenecks on the authentication side. This is a direct result of how the domain controller channels and handles NTLM requests.
The greater chance for bottlenecks is something I imagine Microsoft didn’t want plaguing its biggest enterprise customers. Also, NTLM authentication doesn’t work across many firewalls or through many proxies, making it impractical to use in WAN scenarios unless a VPN is in use.
Faced with this dilemma, Microsoft had two options:
- Redesign the way NTLM requests are handled on the server side, or
- Start discouraging its use.
Along with the announcement that NTLM support was being eliminated came a massive backlash. This mostly stemmed from the number of hard-to-replace legacy apps that rely on NTLM to authenticate with Exchange.
In the most recent iteration of its restriction of NTLM document, Microsoft notes that NTLM authentication not only can be, but should be selectively blocked. This is not just to prevent performance problems, but to also prevent credential leakage across insecure channels.
In the end, NTLM is convenient because it is widely implemented and understood. But that convenience comes at a cost. Not just the cost incurred on the back-end when numerous clients are authenticating simultaneously with NTLM, but the possible costs in security where Kerberos is stronger, and convenience, where basic authentication over HTTPS is easier to implement, especially in Web-based apps.
Microsoft restored NTLM authentication in Exchange 2010 SP1 as a gesture of goodwill for those companies locked into legacy apps that authenticate with NTLM by default, not because NTLM makes sense to use with Exchange moving forward.
ABOUT THE AUTHOR:
Serdar Yegulalp has been writing about computers and IT for more than 15 years for a variety of publications, including SearchWinIT.com, SearchExchange.com, InformationWeek and Windows magazine.
This was first published in April 2012