Team Foundation Server 2017 and Kerberos Authentication
In Team Foundation Server 2017 we made a change to the default security support providers used by our IIS site for Windows Authentication. We didn’t anticipate this change attracting much notice, since we had ensured (through extensive testing) that there would not be any impact for existing TFS deployments and since we were making things simpler by taking away a little-used decision point during advanced configuration scenarios. We underestimated the detail-orientedness of our customers, however, and many people both noticed the change and mistakenly thought that they needed to react to it. The point of this blog post is to explain the change in a bit more detail and to reduce the confusion we mistakenly caused.
First, some backstory. The Microsoft Security Development Lifecycle was updated a while back to forbid explicit selection of the NTLM security support provider, due to various vulnerabilities in the protocol – see https://en.wikipedia.org/wiki/NT_LAN_Manager#Weakness_and_Vulnerabilities, for example. Instead, the SDL recommendation is to always use the Negotiate security support provider, which will attempt to use Kerberos, but will fall back to NTLM if Kerberos cannot be used. This same recommendation can be found in various other public documents. For example, https://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx has the following paragraph:
“Your application should not access the NTLM security package directly; instead, it should use the Negotiate security package. Negotiate allows your application to take advantage of more advanced security protocols if they are supported by the systems involved in the authentication. Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication.”
TFS had been using NTLM as an explicit default setting for the Windows Authentication security support provider for a long time, but in TFS 2017 we decided to comply with the SDL recommendation here as part of an overall push to make TFS more secure by default. (Another part of this effort was the set of changes around recommending the use of HTTPS bindings and an effort to make doing so easier.) After a bunch of testing, we discovered that using only the Negotiate provider would negatively impact certain clients. When we added both the Negotiate and NTLM security support providers, however, we could not find any clients which worked with our old default settings (just NTLM) and failed with the updated settings (Negotiate and then NTLM, in that order).
As such, we decided not just to update the default setting, but also to remove the need for customers to make any decisions about the supported providers. If you want to use Kerberos, it should just work (so long as you have set things up properly outside of TFS). If you want to use NTLM, it should also just work.
The only real impact here is the desired one – some customers who are using machine accounts for their TFS service accounts and who are not using multiple application tiers or custom host names will start using Kerberos authentication, and thus get the benefits of its increased security, without even noticing. We do not expect there to be any other impacts.
If you have reason to believe that this change has negatively impacted you, report it at developercommunity.visualstudio.com and we will work with you to get it resolved.