Oh Federal Information Processing Standard (FIPS) 140-2 AKA FIPS 140-2…You got me again! See the original post here:
As stated in several Official Microsoft documents, SharePoint uses several Windows encryption algorithms for computing hash values that do not comply with FIPS 140-2..therefore you CANNOT enable the FIPSAlgorithmPolicy registry key. Here’s some info:
So in this situation we found that the group policy was applied so we retracted that and SharePoint was “back up.” At this time sites were loading, but I was seeing a bunch of errors related to search and distributed cache in the eventvwr/ULS Logs:
System.ServiceModel.Security.SecurityNegotiationException: A call to SSPI failed, see inner exception. —> System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. —> System.ComponentModel.Win32Exception: The encryption type requested is not supported by the KDC
This led me to the following blog post: http://blogs.msdn.com/b/openspecification/archive/2011/05/31/windows-configurations-for-kerberos-supported-encryption-type.aspx
In this scenario 3 things still needed to happen:
First, IIS Crypto was ran and set to FIPS 140-2 mode. This needed to be reverted as this blocks MD5 hashes.
Then, the AD attribute msDS-SupportedEncryptionTypes needed to be changed from 24 to 28 on all SharePoint 2013 servers. The value of 24 does NOT include MD5 hashes..which SharePoint desperately needs.
After this was set Local Security Policy needed some tweaking (“Network Security: Configure Encryption types allowed for Kerberos”)
This was set to the following (Blocking MD5):
Once checking ALL boxes containing MD5 we were back up and running..Search was working and distributed cache was happy..SharePoint was happy..we were all pretty happy in fact 🙂