Article
0 comment

Move users from Domain A to Domain B in SharePoint with claims authentication enabled

Recently I stumbled in a new challenge I haven’t had for a long time. One of my customers wants to migrate users from Active Directory Domain A to Active Directory Domain B. The problem was that all the previously edited documents should get mapped to the new users.

Picture showing the headline of this blogpost "Move user with claim authentication enabled"

On the interweb, I found some information, but none of them was pleasing, working or were eventually not supported. Most of this articles was pointing to a PowerShell command-let named Move-SPuser. It works fine when you have classic authentication enabled but not with claims authentication. The official documentation says that you have to use the ‘–ignoredsid’ argument.

This example migrates DOMAIN\JaneDoe to the new account of DOMAIN\JaneSmith when using Windows Claims. -IgnoreSid must always be used with Move-SPUser when using a Claims Identity, such as Windows Claims.

So far so go this works but when you use the user to login end up with two users. The old user that was used previously but got the new log-on name assigned and the new user. When I checked the user information list, there were those two entries visible. It looks somehow ok, but I wanted to have all documents on the same user in the user information list instead of having two accounts listed there.

The solution

The most important thing to this solution is that the new user in Domain B has an intact SIDHistory assigned to the user object. Strangely enough, there is a support article that is named “User accounts migrated with their SID history across forests are not resolved in SharePoint” and states:

This behaviour is expected.

When you migrate a user from ForestA to ForestB together with its SID history, the ForestB\user1 account has a new SID in the new domain, and its SIDHistory attribute is populated by using the SID of ForestA\user1. Then, the new SID is resolved to ForestB\user1 by a local domain controller (DC) in ForestB.

The suggested workaround is to not have both user accounts from both domains active at the same time.

For the user migration first up use the current version of the “ADMT – Active Directory Migration Tool” and make sure that all users have set the SIDHistory property.

Once the new user got migrated to the new Active Directory Domain including its old SID on the SIDHistory the migration in SharePoint can happen.

Step 1: Move-SPUser –ignoresid

What ‘Move-SPUser’ actually does is to rewrite the old alias with a new alias in the content database. IgnoreSID is required because with Claim Authentication the users SID cannot be evaluated against Active Directory during the move. You even get an error message that this is unsupported when claims authentication is enabled. The following PowerShell commands move the user for you.

The problem now is that the changed user still has the wrong SID because it chooses to ignore the SID to move the user. The user can log into SharePoint without any problem but because the SID haven’t updated a new user in the user information list gets created. So we now have two users with the same alias in the user information list of the site collection. The old documents will be still referring to the former user while new document will indicate to the new user. It looks on the front end, but in the back, the information is messed up a bit.

Before the user signs into SharePoint the first time, there is another step to take.

Step 2: Set-SPUser with SyncFromAD

The final step is to sync the migrated user from Active Directory into SharePoint.

First, the new user needs to be queried again from the user information list. This step is required because the old user fetched previously during the move has become invalid. Now we have the changed user account and can sync it from active directory.

What now happens is that SharePoint finds the mismatch between the current SID and the old SID but look up the old SID in the SIDHistory, finds a match and assigns the new history to the give user account.

The user is now able to sign in, see all the documents he previously created on the right user account and no additional new one gets generated.