You are currently offline, waiting for your internet to reconnect

AD Groups cannot be used to assign permissions in SharePoint

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:
AD groups; Migrategroup; Check Permissions; SID
Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.

Article ID: 2809787 - Last Review: 02/15/2013 21:21:00 - Revision: 3.0

Microsoft SharePoint Server 2010, Microsoft SharePoint Server 2010 Service Pack 1

  • KB2809787
/html>ml>: none; " src="">arClickTracking = 1; var varCustomerTracking = 1; var Route = "76500"; var Ctrl = ""; document.write(" varCustomerTracking = 1; var Route = "76500"; var Ctrl = ""; document.write("