Category: SharePoint 2019

  Consider the following scenario: You have one of the following User Profile Synchronization configurations for SharePoint: SharePoint 2010, which utilizes Forefront Identity Manager (FIM) for User Profile Synchronization. SharePoint 2013, using the “Use SharePoint Profile Synchronization” option, which also uses FIM. SharePoint 2016 or 2019, using the “Enable External Identity Manager” option, which (typically)

  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

Update 4/15/20: I have now tested this with AD Import and both SharePoint 2016 and 2019. It’s the same problem in both versions. This problem manifests itself in a few different ways: You create an Audience based on “Member Of” the “Domain Users” group. You notice there are only a couple (or maybe even zero)

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

Consider the following scenario:     You have SharePoint 2016 set up to import user profiles from an External Identity Manager. We’ll say you’re using Microsoft Identity Manager (MIM) 2016 to import profiles from some 3rd party LDAP directory. The profiles should be imported as Trusted Provider type users (SAML-claims). You run a Sync, and everything goes

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