User automatically removed from SharePoint Group

During my current project we received an access request from a user. We did what we normally do, we checked the request and added the user in the appropriate SharePoint Group and notified the user.

After 15 minutes the user told us that it wasn’t working. We looked at the User Group and found out that the user was not in the group. So we added the user again because we thought that we forgot this step. After some time we received another mail from the user telling us that it still wasn’t working.

We requested the account details from the user and tried it our self, we found out that the user was missing again and added the account again. We logged in with the user opened a document with Office Web Applications and took another look at the members of the specific SharePoint group. WTF the user was gone!

After digging into the ULS files and looking in the Event log we did not found a clue of what was happening. After a small conversation with the user she told us that everything worked fine before and that she had several problems since see re-joined the company.

What happened was the following the user was removed from the active directory and when she got back a new account was created with the same login name.

When the user re-joined the account had the same login name but did not have the same SID. SharePoint saves information about an account by using the login name and the SID (Security Identifier) of a user. Because of the mismatch SharePoint was removing the applied security rights.

This issue can be fixed by using different commands:

• Move-SPUser : http://technet.microsoft.com/en-us/library/ff607729(v=office.15).aspx
• STSADM Migrate User: http://technet.microsoft.com/en-us/library/cc262141(v=office.12).aspx

The commands look as followed:

$user = Get-SPUser -Web [SiteUrl] -Identity [Login Name]
Move-SPUser -Identity $user -NewAlias [Login Name] -IgnoreSID

For the PowerShell commando you will first need to retrieve the specific user.When retrieving the user and setting the new alias you should always use the claim login name: “i:0#.w|Domain\user”.

stsadm -o migrateuser -oldlogin [Login Name] -newlogin [Login Name] -ignoresidhistory

The STSADM command looks almost the same as the PowerShell command if you also look at the parameters they both have something to Ignore the SID history. The parameter is included because if you do not include the parameter it will check the SID references and as we all know they do not match.

“Possible Problem: When performing one of these options you can receive a “Object reference not set to an instance of an object”. The solution to this problem is pretty simple, When it happens your user does not have enough rights. Try it with another account or give your current user rights to the User Profile Service Application.”