The “Limited Access” permission is one of the most confusing things about SharePoint security. Here’s what Microsoft’s TechNet has to say about the “Limited Access” permission:

“You cannot assign this permission level to users or SharePoint groups. Instead, Windows SharePoint Services 3.0 automatically assigns this permission level to users and SharePoint groups when you grant them access to an object on your site that requires that they have access to a higher level object on which they do not have permissions. For example, if you grant users access to an item in a list and they do not have access to the list itself, Windows SharePoint Services 3.0 automatically grants them Limited Access on the list, and also the site, if needed.”

–from http://technet.microsoft.com/en-us/library/cc262690.aspx

But what does this really mean? To test this, I first created a blank team site (with Standard, Enterprise and Publishing site collection features inactive) with just me as the only Site Collection Administrator:

At this point, the “All People” page looks like this:

The “Site Permissions” pages look like this because in a “Team” site (also known as “Collaboration” site) these three groups, Owners, Members and Visitors, are created automatically.

Turning on “Standard Site Collection Features” at the Site Collection level does not cause any changes in security but activating “Enterprise Site Collection Features” does. It adds a “Viewers” group and gives me, the Site Collection Administrator, a “Limited Access” permission. Clearly this “Limited Access” permission makes no sense since there are no objects yet and as Site Collection Administrator, I would have all rights to them in any case. That’s the first buggy thing you notice about the “Limited Access” permission but it won’t be the last(!):

Adding the “Office SharePoint Server Publishing Infrastructure” feature at the site collection level creates more changes in Permission, adding a number of new groups that can be used with SharePoints Web Content Management system. But since these groups are so confusing to look at, the rest of this document will just deal with the groups that are added by the “Enterprise” site collection feature.

NOTE: Deactivating the Enterprise of Publishing features does NOT remove the SharePoint groups that they added..

To test MS’s statement that “Limited Access” is necessary to give users rights to higher level objects let’s delete all users and groups from the website. To do this, go to Site Actions, Site Settings, Advanced Permissions and select all the users and groups and “Remove User Permissions”. Now only the Site Collection Administrators have rights to the site.

NOTE: The SharePoint Groups STILL EXIST, even though they do not have rights to anything, including the top level Sharepoint site (you just deleted those rights). However, the “Limited Access” permission has disappeared because it was connected to a username:

You can see that these Groups have no rights when you go to add a user to the site. In the “Add users to a SharePoint Group” dropdown, you will see “[No Access]” next to the group name:

Now create a new list called “Test List” and add a test user with Contributor rights:

This will automatically give a “Limited Access” right to the user at the site level (NOTE: This will happen even if you don’t have the Enterprise or Standard Site Collection features enabled):

Now, while viewing the new list, use the “Sign in as a Different User” option to login as the test user. You should not get an error since the user has “Contribute” rights to the list. However, “Site Actions” should disappear since your test user is not an Administrator.

Now, try to go to the Home page of the site. You’ll get an access denied error since you only have “Contribute” rights to the document library:

Next, sign back in as yourself, and remove the test user’s “Limited Access” permission:

Then go back and view the Test List again and use the “Sign in as a Different user” option to login as the test user again. You will receive another “Access Denied” error.

So we see that the “Limited Access” permission IS REQUIRED for the test user to see the list. In fact, the “Limited Access” permission assigns five necessary rights to the test user ID so that it can open the test list:

1. View Application Pages

2. Browse User Information

3. Use Remote Interfaces

4. Use Client Integration Features

5. Open

If you look at the permissions on the list now you’ll see that when you deleted the “Limited Access” permission, Joe’s “Contribute” right to the list was also deleted automatically. Needless to say, this is really bad since in the real world someone can easily delete the “Limited Access” permission, thinking it’s not required (for instance, as is the case when the Site Collection Administrator is assigned this permission when the Enterprise Site Collection feature is first enabled). Also, power user administrators may not be aware of the “Limited Access” permission’s role and delete it by mistake. After all, they can’t see the permission it’s enabling!

However, there is a way to eliminate the “Limited Access” permission altogether. Assigning the “Contribute” right to the Test List only gives the user rights to that list, and nothing else on the site, including the home page. This is usually not what you want. You don’t want to have to give the users the exact URL to the list. It’s much more convenient to just give them the URL of the site and then let them choose the list from the Quick Launch menu. However, in order to access the main URL of the site, they need to have “Read” rights at the site level.

So go ahead and give the test user the “Read” permission to the site:

Now, when you give “Joe” the “Contribute” permission to “Test List”, no “Limited Access” permission is created since the user already has permission to read the site. This is because the “Read” permission includes all five “Limited Access” permissions, plus five more besides.

RED ALERT: Note that if you now delete Joe’s “Read” Permission at the site level, it also automatically deletes Joe’s “Contribute” permission to “Test List.” This is no doubt one way rights “disappear” with no explanation, a complaint I often hear about SharePoint.

Anyway, best practice dictates that the default SharePoint “Visitors” group, which by default has the “Read” permission, should be used, instead of adding Joe as a single user. One would expect SharePoint to act the same way as it did when we added Joe as a single user. BUT NOT SO! With Joe added via the “Visitors” SharePonit group rather than as an individual user, SharePoint adds the “Limited Access” permission at the site level when you add Joe to “Test List” with the “Contribute” permission. This is seriously buggy behavior!

BOTTOM LINE: The “Limited Access” is buggy permission that should never be deleted unless you’ve absolutely sure what you’re doing since it can delete permissions on lower level objects automatically. Also, in certain circumstances deleting a “Read” permission can also delete permissions on lower level objects automatically.