Category: Authentication

SharePoint: SAML and FBA authentication fail from Word, Excel, Outlook, etc

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

Kerberos – KRB_AP_ERR_MODIFIED is not always an SPN problem

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

SharePoint: Quick Troubleshooting Tip: Add the Account column to User Information List

Often while troubleshooting authentication or permission problems, you need to see the actual account name for the user or group added to permissions. This is particularly important in SAML / Trusted Provider authentication because the way the claim is being passed in the SAML assertion must match exactly with the way claim has been added

Keeping SharePoint happy during your domain migration

We’ve seen a few of different problems occur in SharePoint (2013, 2016, 2019) when users are being migrated from one domain to another. They usually come up in one of the following areas: People Picker People Picker may show either or both accounts depending on which domain SharePoint is in, and how PP is configured

SharePoint 2016: Configure the SSRS Report Viewer web part

Starting with SQL Server 2017, there’s only one installation mode for Reporting Services: Native mode. As such, the SharePoint integration with SQL Server Reporting Services (SSRS) is pretty much limited to getting the Report Viewer web part to work. Installing SharePoint, SQL and SSRS are beyond the scope of this post, so let’s pretend you

SharePoint: Change the FedAuth Cookie name

  When using Trusted Provider (SAML / WS-Fed) authentication within SharePoint, we use a browser cookie to keep you authenticated. The default name of that cookie is “FedAuth”. If you have multiple web applications and / or multiple SharePoint farms that use Trusted Provider auth, using the same cookie name for all of them can

SharePoint: SAML auth login error: There are multiple keys on the token

  Consider the following scenario: Your users authenticate to SharePoint using “Trusted Provider” authentication. This is also known as SAML or WS-Fed authentication, typically provided by AD FS, Ping Federate, Okta, SiteMinder, etc. After SharePoint upgrade or security patching, users are no longer able to authenticate. They may see a “Server Error in ‘/’ Application”