Oh Federal Information Processing Standard (FIPS) 140-2 AKA FIPS 140-2…You got me again! See the original post here:

http://www.andrewjbillings.com/fips-compliance-keep-away-from-sharepoint/

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.

msDS-SupportedEncryptionTypes

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):

secpolMD5Issue

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 🙂

-AJB