Update 4/1/22: Added Important note to Issues #2 and #6 Update 1/26/21: Added Issue #7 NTLM authentication is not great. It’s not the fastest. In most cases, that honor would go to Kerberos. It’s not the most secure. Again, Kerberos. It’s not all that flexible. For example, it doesn’t work well for extranets or anything cross-firewall.
This is kind of a “fringe” case, but since it may not be the last time it happens, here’s a post: Consider the following scenario: In SharePoint 2013+ you’re using Active Directory Import to import user profiles as trusted provider-type (SAML) profiles. You find that profiles for some users are not imported. You have already
Problem: You may find that certain functions within the farm that rely on Distributed Cache are not working. You review the SharePoint ULS logs and find errors like the following: Unexpected Exception in SPDistributedCachePointerWrapper::InitializeDataCacheFactory for usage ‘DistributedBouncerCache’ – Exception ‘Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode:SubStatus:Cache referred to does not exist. Contact administrator or use the Cache administration tool to
Consider the following scenario: You have a SharePoint web application that uses Trusted Provider (SAML) authentication. When trying to open a Microsoft Office (Word, Excel, PowerPoint, etc) document from a SharePoint library, the Office app pops up a dialog with a “Sorry, something went wrong” error: Outlook calendar sync behavior: Users have SharePoint calendars that
Consider the following scenario: You’re using SharePoint 2016 or 2019 and using Active Directory Import to import user profiles. You decide to switch to using an external identity manager utilizing Microsoft Identity Manager (MIM). You configure MIM and run a Full Import on the SharePoint Management Agent (SPMA). The Full Import does not import anything
Consider the following scenario: You have a SharePoint 20xx (doesn’t matter) site and have configured People Picker to search a trusted Active Directory Forest or Domain. You have a security group of type “domain local” in the trusted forest that has several users in it. You use People Picker to search for the group,
TLDR: This can also be caused by a mismatch in security policy “Network Security: Configure encryption types allowed for Kerberos“. Consider the following scenario: You have a web site set up to use Kerberos authentication. It doesn’t matter what kind of site, but we’ll say it’s a SharePoint site, since that’s the theme around