SharePoint SAML Migration Guide – Part 1 Planning

SharePoint SAML Migration Guide – Part 2 Trusted Identity

SharePoint SAML Migration Guide – Part 3 Migration

SharePoint SAML Migration Guide – Part 4 Web Applications

SharePoint SAML Migration Guide – Part 5 User Profiles

Part 1 – Planning

With most everything in SharePoint, planning and testing is key before slamming it into production. We will need to review some high-level concepts of SharePoint to help determine which patch works for your organization.

Clam Providers – This is the same as people picker. With Windows Authentication, there is an Active Directory (AD) Claim Provider which will send LDAP queries to AD. SAML authentication does not come with a claim provider unless we use -UseDefaultConfiguration.

Trusted Identity Provider – This is created in SharePoint to hook up the SAML provider. This may redirect to SAML providers like ADFS or other 3^rd party providers. SharePoint’s PowerShell commandlet to display them is Get-SPTrustedIdentityTokenIssuer
Identity Claim – This is claim that will uniquely identify a user. This is usually Email, UPN, or sAMAccountName.

Migrating from Windows Claims to SAML Claims requires to know the different paths and choices we can make. We can migrate the users and groups using Move-SPUser or Convert-SPWebApplication (only available when using -UseDefaultConfiguration).

Choosing an Identity Claim

The identity claim is unique to the user and must be passed in the SAML token from the SAML provider. As stated above, this could be Email, sAMAccountName, UPN, or something different. The value should be unique for that user and no other users would have this value or we’re going to have trouble down the road with user profiles, permissions, migration, etc. Note: Currently the Convert-SPWebApplication does not work with UPN. This will be important to user profiles when they are imported.