AD Groups cannot be used to assign permissions in SharePoint

Article ID: 2809787 - View products that this article applies to.
Expand all | Collapse all

Symptoms

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)

None

Cause

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.

Resolution

Use PowerShell to check the SID of the AD group:

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


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: http://support.microsoft.com/kb/974550

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: http://technet.microsoft.com/en-us/library/cc779035(WS.10).aspx
Object-Sid attribute (Windows): http://msdn.microsoft.com/en-us/library/windows/desktop/ms679024(v=vs.85).aspx
Access control in Active Directory: Active Directory: http://technet.microsoft.com/en-us/library/cc785913(WS.10).aspx
How SIDs and Account Names Can Be Mapped in Windows: http://technet.microsoft.com/en-us/library/ff428139(v=WS.10).aspx
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.

Properties

Article ID: 2809787 - Last Review: February 15, 2013 - Revision: 3.0
Applies to
  • Microsoft SharePoint Server 2010
  • Microsoft SharePoint Server 2010 Service Pack 1
Keywords: 
KB2809787

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com