One of the biggest headaches I’ve heard from SharePoint users and administrators is the ability to manage users, or rather the lack thereof. It is a large task to fully understand it all, and I hope to clarify some of it now.

Quality user management is by far the most lacking area within SharePoint. There are 3^rd party add-ons available which help ease the task, but now you’re looking at spending more on top of your existing investment in SharePoint. I think it’s ridiculous that I can’t click on a user in SharePoint and see all groups that person is a member of… Seriously! Can’t do that, you can in AD, but you can’t in SharePoint. I think the SharePoint guys could learn something from the AD guys…

So I take a few moments to cover some of the heads ups, gotchas, and oopsies with managing users and permissions within SharePoint.

A quick primer

Permissions in SharePoint can be very intricate and act a lot like Active Directory on how you may protect a folder or file on a network drive. You can pull in a group (AD or SharePoint group) of users and specify that this group of users should have write access to this list, and others should have only read access. You can even bring it in tighter and say that one or two users have write access to a single item within a list, and hide it from view for all others.

Adding users and groups is a simple task and can be found almost anywhere on the internet, so I won’t walk through that here. Also, check out this blog Five Key Steps to Managing SharePoint Users for some great pointers on governance and management. We will be taking a different direction in an effort to help clarify using permissions and user management in SharePoint.

Using groups of users to simplify

There are two major methods which can be utilized to manage users. The first and the more popular method, usually seen in larger deployments, is to use Active Directory groups. This allows your IT department to manage their AD groups as usual, and when users are added to their AD groups, they’re in SharePoint automatically. The other method, usually smaller deployments, is to add users directly into SharePoint as individual user accounts.

Use groups whenever possible, it should be an extremely rare case when you need to specify an individual user anywhere within SharePoint permissions (not to be mistaken for the Assigned To field ;). Site collection administrators have to be individual users, otherwise everywhere else use groups, you’ll be glad you did. A group can be an Active Directory group or a SharePoint group.

• If you’re using Active Directory groups, still throw that group into a SharePoint group. Using SharePoint groups will give you more flexibility in the future. Consider this example, if you add your HR AD group to SharePoint and give them specific access to their sub site, and in a year your executives want access into that site, you can
  • Add the executives to your AD group HR (which wouldn’t be right since they’re technically not HR users)
  • Add the Executive AD group into SharePoint and try to replicate all of the permissions the HR group has
  • Add the Executive AD group into the SharePoint group the HR AD group is in.
  • Which sounds easier? Apparently the last one would be easiest, if this is how you configured it initially.
• If you’re not using AD groups, start! But if you can’t for whatever reason, and you’re only pulling in individual users, then make sure they’re in SharePoint groups. This will make managing permissions the easiest throughout SharePoint.
• One pain point is that you cannot put a SharePoint group inside of another SharePoint group. So using the example in the previous bullet, we cannot add the Executive SharePoint group into the HR SharePoint group, instead we’ll need to try to replicate their permissions as much as possible.

Know where you are!

It’s vital to know where you are when you’re managing permissions. It’s very easy to get spun around and start changing permissions on something you didn’t mean to. The best way to know where you are is to look at the URL and the page title. The combination of the two should tell you where you are and what you’re managing.

Document Library Permissions

Site Permissions

Sub Site Permissions

Who has access to what?

Yup, the best question and the hardest to answer. Again, there are 3^rd party add-ons which can answer this quickly, and if this is a reoccurring question I suggest checking them out. However, if you can’t swing the cost of another application, here’s how I do it.

First, go to what you have the question about. For example, if you want to know about a list, go to List Settings. If you want to know about a site, go to Site Settings.

Second, click Permissions (Permissions for this list/library or Site Permissions for Site Settings). This will list all groups which currently have access to this list or site. Simple enough right? Welp, I’d bet you want to know who is in each group next right? From here, make note of the groups names. No, you can’t just click on them, that manages their permissions on the list/site.

Third, go to Site Actions > Site Settings > People and Groups. Now you can click on each group and determine who’s in what group, and who has access to what. Unfortunately this can be a painful exercise. If you’re using AD groups, you might be off the hook, simply pass the ball to your IT dept and ask them to give you a list of users per group. If you are the IT dept, sorry…

All People is for the entire site, NOT your current site!

This applies to SharePoint 2007, Microsoft removed this from 2010 (one improvement). You probably have seen the link in the quick launch while managing users (Site Settings > Site Actions > People and Groups) which says All People. You may click this link and see everyone. This is great, a simple list of everyone in SharePoint. Now go to one of your secure sub sites and do the same, and you’ll still see everyone. Annoying right? This list shows all users in SharePoint (in your site collection, not the current site). When you’re in your secure sub site, you may want to remove people from All People since they’re not supposed to have access to this site, unfortunately if you remove a user or group from this list you’ll remove them from SharePoint completely (unless they’re member of an AD group which has permission).

All People of the site, not the sub sites. But is it all of them?

One other weird thing that happens with this list: this list is showing you everyone who has a login account into SharePoint and has already logged in or has been added directly. If you’re not using AD groups, then you’ll see everyone who has been added to SharePoint. If you’re using AD groups, you’ll only see the users who have actually logged into SharePoint at least once. If an AD group has 200 users, and only 100 have logged into SharePoint, you’ll only see those 100 users here, the other 100 have permission to login, but until they do they won’t show in this list.

#$&%! Limited Access

“How do I use Limited Access? I don’t see it as an option.” “What does the user have limited access to?” are my two favorite questions. If you see Limited Access, curl up under your desk and cry. While you’re under there take a quick nap and then collect yourself and come back up because you have a lot of work to do. Limited Access means that user or group has some sort of unique permissions to something in your site. If you grant a user permission to a single item or list, you will see this same user under Site Permissions as Limited Access. There is no easy method to determine what and where the user has this limited access. You will also see this user as Limited Access throughout SharePoint for any list or sub site that inherits from the site.

Let me explain a different way. John Smith is a member of the Members group and the SharePoint administrator determines that he needs unique permissions to the Shared Documents library as a designer so he can approve documents. Instead of creating a new group (groups are best) and manage the group, the admin adds John Smith directly to the list. Instantly, the site permissions will list him as Limited Access, and each list, library and site which inherits the permissions also shows the same. A month later that admin looks at site permissions and sees John Smith listed as Limited Access and asks how did that happen? How do I find out what he has access to?

There are a few methods I’ve found in correcting this issue.

1. SharePoint 2007 – Navigate and look at the permissions on every list in SharePoint. This way you’ll find which list has unique permissions. However, if unique permissions were setup on the list item, say one document in a library, then you’ll need to check permissions on every single item within SharePoint. This could be hundreds to thousands of items. It’s okay to cry.
2. SharePoint 2010 – One improvement that makes this a little easier. Instead of having to navigate throughout the entire site to find what is unique, SharePoint 2010 now has a basic reporting tool which will provide this to you. When looking at Site Permissions, you may see a little bar above the list which states there is uniquely secured content. Click the link and it’ll show you the few lists which are unique, and which items within a list if applicable. This will make reviewing your lists a little easier.
3. The second method is easier and a little more effective. Go to Site Permissions (Site Actions > Site Settings > Site Permissions) and remove the user. Don’t worry, this will only remove the specific permissions for the user. The user’s existing permissions through other groups will remain.
1. This method will remove the user’s permissions, but not reset the list/library/item’s permissions to inherit again. That you’ll still need to find and fix.