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
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”
Kerberos authentication fails – The local machine must be a Kerberos KDC (domain controller) and it is not
This issue is not particular to SharePoint, but that’s how I came across it, so I’ll present it that way. However, keep in mind that you could see this behavior for any IIS site using Kerberos. Problem: Users are unable to authenticate via Kerberos (Negotiate). They try to access a site and get
When the SAML Identity Provider (ADFS, SiteMinder, Ping Federate, OKTA, etc) token-signing certificate is renewed or rolled over, SharePoint can be in trouble. This is because there’s currently no functionality in SharePoint to automatically update the certificate within the Trusted Identity Token Issuer on the SharePoint side when it’s been updated on the Identity
I came across this topic troubleshooting a support case where users were getting Access Denied to a site using Trusted Provider (SAML) authentication. The Issue: Users were given permission to the site using a group that had other groups nested in it. The users were not direct members of the group being used for permission.
Disclaimer: The below is a summary of observations made as the result of some reverse-engineering and Source Code review. It’s not necessarily to be taken as “official,” but does check out according to my testing. This is post is not about configuring Forms-based Authentication (FBA). There’s plenty of other posts out there about that. The
This is a pretty unique scenario, but it came up recently and exposed a little-known configuration “gotcha” with SharePoint. Consider the following scenario: You have two Trusted Providers (SAML auth) and are using them both for the same web application. For example, you have an Internal zone using URL https://teamsInternal.contoso.com that uses Trusted Provider “ADFS-Internal”