How to Remove Access to SharePoint

…And prevent SID Mismatches along the way by disabling the user

Let me start by explaining the wrong way, and why it is wrong. Simply removing a user from a group and/or deleting them from Active Directory (AD) or your Management Tool of choice will not be sufficient.

While it’s true that when you remove a user from AD, they will no longer have access to the site, but suppose you need to recreate this user in the future. Maybe they took a Leave of Absence, or quit and returned later. Whatever the case, what you have done is create an SID mismatch since the user still exists in SharePoint. A SID is the Security Identifier and is stored in the Object-SID (objectSID) property of a User or Group object.

This is important to know because SharePoint users are given permission with this same attribute stored in their User Profile. When the AD User Object is recreated, it will no longer have the same SID, thus causing the SID mismatch. This means, while it may appear that the user is added and has permission to the site or resource to you (The Admin), the user will not be allowed to log in as though they do not have permission.

SharePoint site hasn't been shared

This is not what you want to see…

It is never necessary to delete an AD User. Simply right click the object and choose ‘Disable’.

Now, if you remove the user from a single group or remove their permission, you are potentially still allowing this user access to your site since permission may still be present elsewhere that were not removed.

Remove a SharePoint user to prevent access to any company resources:

  1. Locate the User in Active Directory, right click the User Object and choose Disable. This step alone does it, but let’s be thorough. You are likely paying for each User CAL that is on your site anyway.
  2. Load your SharePoint Site and go to Site ActionsSite SettingsPeople and Groups on your Top Level Domain.SharePoint Site Settings
  3. When you locate the user, checkmark their line item, go to ‘Actions’ at the top ribbon and choose ‘Delete from Site Collection’.SharePoint Site Home Members
    1. Pro Tip: Let’s manipulate your URL. After ‘MembershipGroupId=’, there is a number which indicates which list (Group) you are viewing. Since there is no ‘All Items’ link available, we can force it by changing this value to 0 (zero). It will load every User from every Group that has been created for the Site Collection.SharePoint MembershipGroupId
  4. To test that the user no longer has access, go to Site ActionsSite Permissions
  5. See next screenshot for reference. In the ribbon, click on Check Permissions.
    1.  Type the username, click the Check Now button.
    2. If the user has no permissions, you will see the error as shown in the screenshot or “No Exact Match was found for ‘user’” in SharePoint 2010.
      1. If it places a black underline under the name, click Check Now and it will tell you where and what permissions they have. This can be used anytime, not just for this process.SharePoint Intranet

So now, when Bobby gets rehired (the job market is rough right now), you can easily add him back to the site. Of course, you did let him go for a reason…

2014-03-17T10:00:42+00:00 March 17th, 2014|


  1. […] How to Remove Access to SharePoint… and prevent SID Mismatches along the way […]

  2. Ben October 10, 2014 at 9:31 am - Reply

    Hi Steve,

    In my case, I removed the user from the group, say ‘store.’ The user now should not have access to Store site, but when i checked the permission I can see that He still has the permission to ‘store’. How is it possible when I already deleted him from ‘Store.’ How can i fix it?

  3. Steve Lattina October 10, 2014 at 9:50 am - Reply

    @Ben Hi Ben. Thanks for reading. To answer your question, this user may likely still have permissions granted through another Group, Directly or as a Site Collection Administrator. If you have access to the Web Front End, you can sniff our this information using PowerShell. There is a good conversation on this topic here;

  4. Lee January 14, 2015 at 3:12 pm - Reply

    I know it’s not the most convenient thing to do, but the way we are setting up a document library requires us to create multiple subfolders within a library.

    I’m trying to granulate permissions on the folder and have tested if I’m doing it correctly. I broke the inheritance from the parent and removed a user but she was still able to get to the folder.

    What did I do wrong or what do I need to do to make it work?

  5. Renee April 2, 2015 at 2:00 pm - Reply

    Hi Steve,

    We are dealing with an ongoing set-up. We are being asked to manage permissions, but it looks like some of the groups were set-up under different owners outside of the main administration group. How can we determine who the owner of the group is in order to update permissions?


Leave A Comment