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”
I’ve been over this concept with customers and support engineers so many times, that I’m not sure why I haven’t posted about it before. My colleague Adam posted on this topic a while back, but I wanted to expand on that a bit. The Setup: Let’s say you have a SharePoint (2010, 2013, 2016, 2019,
STS Background: In SharePoint 2010, 2013, 2016, etc, the Security Token Service (STS) is a web service hosted under the “SharePoint Web Services” IIS site on HTTP port 32843 and HTTPS port 32844, in a virtual directory called SecurityTokenServiceApplication. In SharePoint 2010, it contains 2 web services:Securitytoken.svcWindowstokencache.svc In SharePoint 2013 and 2016, it contains 3
This post is a similar to my previous post on Check Permissions, except here, we’ll be talking about Forms-Based Authentication (FBA). The way “Check Permissions” works varies by authentication method. For Windows or Trusted Provider auth, see my other posts: Windows-Claims Authentication: https://joshroark.com/sharepoint-troubleshooting-check-permissions-windows-auth/ Trusted Provider Authentication: https://joshroark.com/sharepoint-check-permissions-and-external-tokens-adfs-saml-auth/ With Forms-Based Authentication, all of the same