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

This was a special situation where most of the site appeared to work, but certain links under Site Settings would fail with 403 Forbidden. For example: Themes Master Pages Solutions Composed looks List Templates Most document libraries Actually, in some cases, the page request would result in Access Denied, and redirect the user to the

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 the third part of a series on the “Check Permissions” function. It’s focused on Trusted Provider authentication aka: SAML-claims. The way “Check Permissions” works varies by authentication method. For Windows or FBA auth, see my other posts: Windows-Claims Authentication: https://joshroark.com/sharepoint-troubleshooting-check-permissions-windows-auth/ Forms-based Authentication (FBA): https://joshroark.com/sharepoint-check-permissions-and-external-tokens-fba/ Notes: I’ll be talking about Active Directory Federation

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 SharePoint 2016 configured to import user profiles using Microsoft Identity Manager (MIM) 2016 as the External Identity Manager. You have configured MIM to import profile pictures from Active Directory (AD). After the pictures have been created in SharePoint, you decide to reverse the flow to export profile pictures from