AD Groups cannot be used to assign permissions in SharePoint

Se aplica a: SharePoint Server 2010


Consider the following scenario:

You have created a SharePoint 2010 Web Application using NTLM authentication and decided to manage the SharePoint Security using Active Directory Groups.

  • The AD users are added as members into Security Groups and the groups are granted permissions in SharePoint.
  • You delete one of the groups in Active Directory and re-create it using the exact same name and members.
In this scenario, you may receive the following message when you check a group member’s permissions from 'Check Permissions' control in SharePoint 

Permission levels given to USER (DOMAIN\USER)



SharePoint will not be able identify the group being used due to a change in the security identifier (SID) when you recreate the group. This is an expected behavior, as SharePoint relies on the security identifier (SID) as the unique identity of users and groups, and subsequently a GUID, which is internal to SharePoint.


Use PowerShell to check the SID of the AD group:

$w=Get-SPWeb http://yourwebapplication
$user=$w.Users | where {$_.UserLogin -eq “DOMAIN\Group 1”}

The "Stsadm -o migrateuser" command will not work for the Active Directory group migration and will fail with "The user does not exist or is not unique" error. You need to use the "Stsadm -o migrategroup" command to change the group SID. Here's the command syntax

Stsadm.exe -o migrategroup
-oldlogin <DOMAIN\name>
-newlogin <DOMAIN\name>

Ex: Stsadm -o migrategroup -oldlogin Domain\Group –newlogin Domain\Group

After this you should be able to check permissions correctly, and the users who belong to the affected AD groups should have the permissions set correctly.

Note: You can use the "Stsadm -o migrategroup" command after you apply the hotfixes listed in the following knowledge base article

You cannot change the name of an Active Directory security group in SharePoint Server 2007:

More Information

NOTE: This can happen if you migrate the groups between domains without running the 'migrategroup' command, so there are multiple reasons for this issue to occur but the main point of this article is to isolate the specific behavior and effects so that the users can fix this.

See the following articles for more information:

Delete a user account: Active Directory:
Object-Sid attribute (Windows):
Access control in Active Directory: Active Directory:
How SIDs and Account Names Can Be Mapped in Windows: