NTLM or Cross Platform or Domain Authentication failing from Windows 2008 R2 or Windows 7

Posted on 9/2/2011 @ 12:20 PM in #SharePoint by | Feedback | 1509 views

Put this in the esoteric-istan.

There is a slight difference between Windows 2008 R2 and Windows 2008 SP1 that may affect your SharePoint installations.

Usually, all servers that you are delegating to using Kerberos, ideally, should sit inside the same domain. We all know, this may or may not be the case.
There are frequently extremely complicated AD forests with all sorts of rules applied. Usually this is something that you are not privy to because technically this is the production network that only the domain admin can see.
And usually, there is no way in hell a client will let you see this directly (or worse poke around with it), because literally every business system depends on this.

As a result, frequently we cheat – as long as the last leg of the authentication hop server scenario is our end sub-system, we cheat and use the same username/password on either side for the system account. This causes the NTLM hash to be the same and the authentication passes. WOOHOO!! Not so fast charlie.
And you will most definitely run into this issue when delegating to a non-windows server, such as Unix or Java based systems.

This article was published on winsmarts.com. Stealing content is not cool.

This cheato-approach we used to use, won’t work in Windows 2008 R2. The issue here is,

Windows 7 and Windows Server 2008 R2 support Extended Protection for Integrated Authentication which includes support for Channel Binding Token (CBT) by default. As a result, the following scenarios will fail,

  1. Basic server hop NTLM auth will fail, even if the other server is Windows (even 2008R2).
  2. Authentication through proxy servers will fail
  3. Non-Windows Kerberos servers cannot be delegated to.
  4. Non windows NTLM servers cannot accept your auth, and
  5. Authentication will fail when the last-leg server and the delegating server are in different timezones.

Dammit!

Okay so how do we fix this? The reason this is occurring is because Windows 7 and Windows Server 2008 R2 support Extended Protection for Integrated Authentication. This means, you can’t cheat anymore :). The delegated to server has to be a legit server in the same domain. That’s a good thing. With the above mentioned side effects of course. In Windows 7 or 2k8R2, this is ON by default. When a client attempts to connect to a server, the authentication request is bound to the Service Principal Name (SPN) used.

Luckily, you can fix this via a registry setting, to control the extended protection behavior, create the following registry subkey:

Key Name: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
Value Name: SuppressExtendedProtection
Type: DWORD

For Windows clients that support channel binding that are failing to be authenticated by non-Windows Kerberos servers that do not handle the CBT correctly:

  1. Set the registry entry value to “0x01.” This will configure Kerberos not to emit CBT tokens for unpatched applications.
  2. And if that does not resolve the problem, then set the registry entry value to “0x03.” This will configure Kerberos never to emit CBT tokens.

Whew! This was fun to fix (not!). Pretty sure I’ll forget this, so putting on my blog.

Sound off but keep it civil:

Older comments..


On 9/2/2011 2:47:09 PM Robert Seso said ..
Thanks Sahil, I bookmarked this because my gut feeling tells me that this will save my a*s some day...


On 9/2/2011 3:03:49 PM Sahil Malik said ..
Robert, believe me it will. Win2k8R2 systems are just becoming very prevalent in production environments. You will run into this sooner or later.