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

Now that we have our Identity provider built we can move on to Migration. There are some misconceptions about SAML users and Windows users. There are a few blog posts out there(including mine) explaining why we need to migrate.

Depending on how the trusted provider was built in step 2 will determine the way we will migrate the users. The two options are to use Move-SPUser or Convert-SPWebApplication.

Move-SPUser

Move-SPUser has been around since the 2010 version shipped and is the same as stsadm migrateuser command. This can be used to migrate users or groups. Running Move-SPUser is a farm wide migration. This means, all web applications, user profiles, etc. will be migrated. There are many scripts out there that we get the users and groups from the site collections which then migrates them to the SAML claims.

$user = Get-SPUser -Identity "i:o#.w|contoso\user1" -Web https://contoso"
Move-SPUser -Identity $user -NewAlias "i:05.t|SAML|admin@contoso.com"

This process can take some time to complete for migrating users depending on how many users and how many site collections are in the farm.

Convert-SPWebApplication

This method is only available for Trusted Providers that are created with -UseDefaultConfiguration. This will migrate users and groups to use SAML only within the web application that is run against this. Unlike Move-SPUser this will only affect the web application that is specified. Check out my ADFS guide here

 
$wa = Get-SPWebApplication https://contoso 
$ap = Get-SPTrustedIdentityTokenIssuer "SAML" Convert-SPWebApplication -Identity 
$wa -From CLAIMS-WINDOWS -To CLAIMS-TRUSTED-DEFAULT -TrustedProvider $ap -RetainPermissions 

Note: If a user does not have an identifier claim in AD(like a missing email), that user is not migrated. This will show up in the ULS logs and the UserInfo table of the content databases.

After we migrated the users and groups we need to shut down the Windows Authentication so we do not have the users log in with the Windows accounts. This would cause them to receive access denied and many other undesirable behaviors.

Resources

Move-SPUser
https://docs.microsoft.com/en-us/powershell/module/sharepoint-server/move-spuser?view=sharepoint-ps

Convert-SPWebApplication
https://docs.microsoft.com/en-us/powershell/module/sharepoint-server/convert-spwebapplication?view=sharepoint-ps

Permissions

If we don’t have any users to migrate or just want to test accessing sites, we would need to add in the user to user policy at the web application level. This spot is the easiest way to look at the claim we are adding while giving permission to a test account.

We can see the user first ‘User1’ is the ADFS claim and the second is the Windows claims.