Domain User Migration: SharePoint and SIDHistory

One of the basic principles of an Active Directory domain migration is the access to resources in the source domain based on SIDHistory information of the migrated user-account or group. The SID of the object in the source domain is written into the SIDHistory attribute of the object in the target domain. This enables the access to resources in the source domain during the migration process.

Unfortunately, Microsoft breaks with this principle here. SharePoint and SIDHistory.

The SharePoint and SIDHistory problem

Microsoft Sharepoint 2007, 2010 and 2013 do not support the access to SharePoint content based on authorizations given by the SIDHistory. In case user accounts are migrated into another Active Directory domain and the SharePoint farm remains in the source domain for the time being, the migrated user account cannot access SharePoint contents.

The user can still access SharePoint manually with their account from the source domain, but this can only serve as a workaround.

Solution 1 – STSADM

A solution could be the exchange of the user accounts within the SharePoint authorizations. Before there were the new possibilities via Powershell, we could use the command line tool STSADM:

An important note is that the user accounts are exchanged resulting in the source domain account not having access to the SharePoint contents anymore. This has notable influence on the implementation planning and has to be considered at any rate.

Solution 2 – PowerShell (recommended for SharePoint 2010 and higher)

Since SharePoint 2010 Microsoft recommends the usage of PowerShell cmdLets for SharePoint. STSADM can still be used but will not be updated. It will probably be discontinued with one of the next SharePoint versions. Thus I recommend becoming familiar with alternatives of PowerShell.

The cmdLet “Move-SPUser” widely replaces the functions of “stsadm -o migrateuser“.

It you work with the cmdLet “Move-SPUser“, you quickly become aware of other similar cmdLets: get-SPUser and set-SPUser. The cmdLet get-SPUser displays a list of the authorizations of one site collection. With a little fantasy you can turn it into a little script reading the authorized user accounts of a site collection, swapping the domain name “old” against “new” and set the new authorizations with move-SPUser.

Depending on whether the Claims Based Authentication of the Web App was activated or not, the output looks as follows:

The following script lines are to be an inspiration for a migration script.

Add-PSSnapin Microsoft.SharePoint.PowerShell
$users = get-SPUser -web “https://webapplication/sites/sitecollection“
foreach ($oldUser in $users)
{
$oldUserSTR = $oldUser.userlogin
$newUser = $oldUserSTR.replace(“oldDomain“, “newDomain“)
move-SPUser -Identity $oldUser -NewAlias $newUser -IgnoreSID
}

Link to the Microsoft Technet website about  “Move-SPUser“