Category: Authentication

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 (2013, 2016, 2019, Subscription

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

  Consider the following scenario: You have a SharePoint 2016 site that has been enabled for anonymous access. You have some Microsoft Office (Word, Excel, PowerPoint, etc) documents in a library that anonymous users also have access to. A user clicks on a (for example) Word document to open it. They receive a credential prompt,

This post covers the scenario where users log in via Trusted Provider / SAML-claims,  (like ADFS, Ping, Okta, Site Minder, etc) and intermittently, they are redirected back to the login page to re-authenticate. There are a few pieces of information you need for a scenario like this (beyond normal scoping): 1. Output of Get-SPSecurityTokenServiceConfig from one