Permissions 101

The basics of SharePoint permissions haven’t changed too much over the versions, but there are things Microsoft has done with SharePoint 2013 with sharing I do not appreciate. Worse is the newer permission level of edit. Maybe my users are worse than your users, and you’ve been able to train people to not add columns without planning to lists and libraries. I’ve not met users who don’t eventually do something undesirable with edit permissions. Contribute used to be the default permission level for regular users/members of a site. I’d suggest changing it back to contribute for all of your future sites.

The worst thing that Microsoft did with its permissions has everything to do with semantics. At least with my clients in my market, they like to be in control of their empire, regardless of how small it is in a 50,000-person organization. When Microsoft automatically creates for you ABC Visitors, ABC Members, and ABC Owners when you create a new site, the management of the office often insists it is in the Owners group. This means that the people who often have the least technical skills in the office have the power to create apps and will see more things to click on than they should. Data owners are not the same as site owners; trying to explain that in such a large organization is difficult but possible. You just need to fight lots of little battles and ruffle a lot of feathers. The easy way around this is to create a new group called ABC Leadership and put them in there while you rename the default owners group to ABC Site Administrators. You could use ABC Management instead, but calling them leadership makes them feel better. Words have meanings, and you should pay attention to the emotions they can elicit.

If you take away nothing else from this writing, please use that advice on renaming the groups.

You should have created your groups before you created your site, assuming it is not the root site of the site collection. Do not let SharePoint create them for you. You should already know the different audiences of your organization and most of the different roles you will encounter. You will want a single group to represent everyone in your organization. I’d suggest that this is your ABC Visitors group or an equivalent. Add everyone to that group. Never again should you create another visitors group with the same population inside of it. It is one of the most common things I see. I’ve looked at many site collections where there are multiple owners groups and visitors groups with the same handful of people in many owners groups and the entire organization in all of the visitors groups. Imagine cutting down the number of groups to manage by up to 66% by just not creating all of those redundant groups.

SharePoint permissions pass down from the site to the subsites and lists and even the items inside until you break inheritance. A site’s overall permissions are by default the permissions of the Pages and Site Pages libraries you might have on your site and, therefore, the home page of your site. Ask yourself if everyone who has contribute rights on your site should have the ability to modify the home page of the site? Maybe, but probably not. Often times, I see the site administrators lock down the Site Pages library to prevent people from making edits, but they often make it so that the organization cannot even view the homepage. Be careful how you do that. I’d suggest that you break inheritance on the library, not just on the page. Like with all places where you break inheritance, it isn’t obvious that the permissions on one object might have different permissions than another or its parent. For this reason you should be careful to break inheritance only when you need to. It would be a wise move to not only document a matrix (permission map) of all of the permissions each group has compared to each list or library on the site but to also add in the descriptions of each that it has unique permissions and what that means for the people looking at the list or library.

I’d also suggest that you do not break inheritance at the folder or item level within a list or library unless it is highly documented or—even better—controlled by a workflow so that you remove the human element from being able to accidentally grant or deny people you should not. Everything is truly business requirement specific when you make these decisions, but a good example of this would be to an human resources library where you have a folder for everyone in the organization. You would likely allow HR to have contribute to all of those folders, the individual to have read or contribute no delete (you should probably create this permission level), and each individual’s supervisor to have some level as well. The beauty of this is that HR will see all of the folders, supervisors would only see their own and those of the people they manage, and individuals would only see their own.

This is because security trimming in SharePoint does not allow a user to see that an object even exists if that individual cannot access it. Alternatively, you can use audiencing to selectively show web parts and links. Audiencing is not a method of security. It just allows you to better advertise directly to the right consumers. This is very important because most apps you build will need to have at least two very distinct audiences: those who add the content and those who consume the content. Sometimes they are the same groups of people, but usually it is a smaller group to create the content than to consume it. So the links in your current navigation could go to a number of extra views that matter only to the creators of content if without cluttering up the list of options for external visitors of your site. Everyone might have access to the same list, but you don’t need to advertise all of the views the creators might want. Could you imagine going to a restaurant and seeing all of the dishes that have an ingredient you don’t want automatically removed from the menu? That is exactly what you are doing when you use audiencing. Use it wisely, and document it.

When creating all of the groups to your site, you may be tempted to use the ABC Members group and groups like it in ways that are not desirable in the long run because of the management burden. If you had an HR directorate in your organization with branches A, B, C, and D, you would likely create HR A Members, HR B Members, HR C Members, and HR D Members. That would be totally reasonable. So if you had an HR site and a subsite for each of the branches, you might have already created an HR Members group. This is why you should plan all of these groups on paper long before you build. Because you know you’ll already need to create sub-population groups, it is against your best interest to have a group where you have put them together as well. This is because the parent HR site should have the following groups with these default permissions:

By creating an HR Members group as well, you’d have yet another group to update as people joined and left HR. By mapping out all of the groups you’ll need at the smallest manageable group, it becomes much easier to get granular without the management overhead you’ll have with SharePoint creating all of these groups for you.

At the same time, I’ve sometimes seen site administrators add users from other organizations to the default members group of the site. Assume that a few in Legal often work with the folks in HR B. If you add them to the HR B Members group, you’ll inadvertently give them access to things that you might not want them to access. This isn’t about you not trusting them, but they might not like it either. You could have a workflow that sends out email notifications when anyone in the company updates a service feedback survey for when HR helps people. If that workflow uses HR B Members as the distribution of that notification, you’ll start spamming the Legal people. Use role-based access control (RBAC) when planning your groups. If you add Legal Members as another group that can contribute to the library where they collaborate with HR B, you fix all of these issues. You also save yourself some pain when Legal hires a new person. By just adding that person to the Legal Members roles, the new person gets all of the accesses of all of the other Legal people where he or she should have that level of access. You should not ever need to hit 20 sites to add the person to a different group because that is where the other Legal people have access.

To document all of these permissions well, you need to create a permission map for each of your sites. You can just create a little table in Excel or on a wiki page. It doesn’t matter what your preference is as long as you do it for all of your sites and preferably the same way. It’ll eventually look something like this:

After you have mapped out what the permissions should be, you can use this as a checklist to ensure that they stay that way. Inevitably, you’ll add someone to your site administrators group who will mess it up, so periodically review the lists to ensure that you have the permissions set according to your plan. Of course this is just an example. You’ll likely have many more lists and libraries as well as groups to map out. Like all settings for a list or library, you should make a very conscious decision about what the permissions should be for each of them and add it to the map you’ve made.

Sometimes you will want to create some special permission levels. For HR, you might have a few libraries where you want everyone to be able to submit a form but not be able to modify it or even read it afterward or maybe read only your own. Create the additional groups with caution as some features might need a particular setting to work correctly. A general rule in SharePoint is to never mess with the out of the box configurations but to copy and modify to create new. So don’t open the contribute permission level and remove the ability for people to delete. Instead, create a new permission level Contribute No Delete. You can do a lot of unique things. I’ll repeat this ad nauseum: document what you do. When you get a promotion or go on vacation for two weeks, someone else will need to step into your role in case a change needs to happen, and that person will need to understand what you have made, how you made it, and why you chose one way vice another.

What you should not do is give a group multiple permission levels. I have seen many times over the years where a site administrator—or more often a person who got permission because of rank in the office without the technical training to support the duties—has given a group View, Read, and Contribute. That is so very redundant. I’ve even seen a group get Contribute and Contribute No Delete on the same library, and the person who did that cannot understand why the group can still delete things. SharePoint grants most privilege when there are competing permission levels. Grant each group the least amount of privilege it needs to do its job on the corresponding lists, libraries, and sites.

Sometimes, you might need to have a list that has thousands and thousands of items where HR A, HR B, HR C, and HR D have different levels of access as the item goes through its workflow. You have the option of copying the item to a new list with the different permission settings for that item to inherit the permissions from its new parent, or you can elect to keep the items in the list and have the workflow adjust the permissions. If you have only a handful of ways you would like to adjust these permissions, you can create folders in a list and assign different permission levels to these folders. Then your workflow can change the path of the item so that it inherits the permissions of that folder and then the next and so on. You would build your views to not see folders, but the folders would affect the permission levels. This is so that you only need to worry about a handful of permission scopes rather than thousands if you were to have the workflow change the permissions on each item. While a list can support up to 50,000 unique permission scopes, it is a pain in the butt to manage that way. Additionally, the extra folders can help you get over the 5,000 items in a view threshold even if they are never visible to most of the users of the app. This is also best for data integrity. If you were to move things from list to list to work through the permission changes, you would probably end up with new Created dates that don’t align to the items properly, so you’d need to add additional columns just to track the original created date. Version control would be almost useless.

Pet Peeve

When I look at permission groups while doing a site audit to find what all is broken, I often find these common issues:

• No text is in the description.
  
• The group is owned by the individual who created it.
  
• The group’s membership is visible only to those who are members.
  

Why is this bad?—

Everywhere you see a place to add a description, I’d beg you to add it except in your lists’ columns. A description for a permission group should probably include why it was necessary and no other existing group would work along with the date you created the group. Annotate in the description when you might have had to rename it. How often have you seen an office change its name? Don’t create a new group and delete the original. DON’T. It can create all kinds of issues later. If Human Relations changes to Human Capital, just change all of the HR references to HC. It’ll save you a lot of pain.

Groups should never have a single point of failure to update the membership, and you are that failure if you list only yourself as its owner. Make either the site’s administrators group the owner, or create new groups just for managing the membership. Assume your office is structured like CFO 1, CFO 2, CFO 3, CFO 4, CFO Leadership, CFO Front Office, and CFO Site Administrators. As the site administrator, your function is to build apps, and all of that stuff. You should not need to be involved in the office administration of bringing on new staff or removing them when they leave for a better position. If you make the CFO Front Office staff the owner of the CFO 1, CFO 2, CFO 3, CFO 4, and CFO Leadership groups but give them adequate training to understand why they shouldn’t allow someone from CFO 4 into the leadership group, there is little reason they cannot fulfill this duty better than you can. This is because you shouldn’t have all new users run through you. When I see this, it is usually because even the SharePoint site administrators now what their own little empire that so many others had been guilty of creating.

Lastly, unless you are a SharePoint site collection administrator for the Masons, everyone should be able to see the membership. Microsoft defaults this way in the rare event that your SharePoint environment is facing the open internet, and you don’t want someone to punch in the URL for each group to figure out who to phish. Obviously, if your SharePoint environment does have the open internet accessing it, lock that stuff down as much as you can and preferably with AD security groups so bad actors with nefarious motives cannot use the URLs to scan through all of the users of the environment. I usually find this kind of problem not during a site audit but when someone says their workflow won’t work. If your workflow wants to email everyone in the Leadership group but your average user doesn’t have access to see who is in that group, the workflow cannot create the email. And what does it say about your or the organization if you don’t trust your coworkers enough for them to know the membership of such groups? Should someone be walked out of your building because you believe they are a security risk?

To wrap this up, plan your permissions before you implement them, never grant permissions directly to individual users, and document everything you do. I hope that you have gotten something out of this.