User Permissions in SharePoint

I saw a post on one of the SharePoint Groups on LinkedIn about permissions and security to which I replied. I think this could be useful information for lots of people, so I am blogging it too.

Not knowing how big your organisation is, how you are planning to leverage SharePoint in it, or if it’s an intranet, extranet or internet solution; I won’t know if my information will be of assistance. Ours is an intranet only solution, and I am responsible for the team site web app with 15 000 people across almost 1800 sites on the platform so far. We have 4 web applications, and in the team sites web app, we have dozens of site hierarchies. Each site hierarchy has dozens of subsites across hundreds of business units.

We have Quest installed on our Enterprise platform and it is a nightmare!! I have not been able to get one single sensical report sent to me on user permissions to date. We have just installed a tactical solution called SP Limited Access Discovery. http://www.codeplex.com/SPLimitedAccessDisco. It is EXACTLY what we need on the front line. It is absolutely critical that you have a decent management tool at your disposal to extract reports on permissions. From an external auditor perspective, the first thing they require is to demonstrate security – who has access to what, how and when. Out of box reporting in SharePoint is not enough.

Permissions are an ongoing war and challenge on a daily basis. The primary support team cannot agree on the best way to handle it, but in my personal experience having been sole administrator on the platform for almost the entire life of it, I can tell you that what they say in theory is not necessarily how it works in real world situations. And just because you can do something, doesn’t mean you should.

Plan, plan, plan. I cannot stress this enough. Make sure that whatever you decide to do, is scalable and more importantly, flexible. Ideally you should use Active Directory groups to leverage on SharePoint. If however, your AD user profiles and groups are out of date (like ours are), it is not an option, and you will need to make use of the standard groups in SharePoint. We work with Members, Owners and Visitors and create more groups as required. If you are working with publishing sites too, it is going to have its own set of challenges with the Approvers groups and such.

You have 2 options when creating subsites, to inherit permissions or to create unique permissions. You need to think about this really carefully. Things change. Business units merge. People move. Site administrators take a long time to understand how permissions work.

In my experience, inheriting permissions across 20 or 30 subsites has failed 100% of the time, 100% of the time we have had to redo the permission structure on those site collections, disinheriting, creating new groups etc etc. And while the site owners were adamant that that is what they wanted, it took less than 3 months in every single case for the phone to ring and for us to step in and fix it. This can get very tricky depending on the size of the collection. There are a lot of things you need to remember to do. Site owners lock themselves out of their sites on a daily basis not remembering all the steps to follow.

It also depends on who is going to manage your platform. Are you having one administrator and that person has to add and remove people for the entire organisation? Or are you having individual site owners for each site and letting them manage their space? Ongoing management and administration of your platform will impact how you set up groups.

If you have a large organisation, don’t give business site administrators site hierarchy access. It is too much power. The maximum access they should have is Site Owner. Also, advise business units to have as few site owners as possible. Having 6 or 7 will create a free for all on the site and there will be no control. One or 2 at the most is ideal. Do not give users access to Central Admin and SSP under any circumstances. Those consoles are for the domain of the server administrators and platform owners only.

While it takes marginally more time to create unique permissions in the beginning, from a long term management perspective, it has proved to be the most effective way by far to manage the team sites. Obviously in some circumstances it will make sense to inherit, it really depends on the type of business you have.

If you just have one site collection with all your sites in it, and you are creating unique permissions, make sure you set naming standards for the groups. We did this on our POC environment, and it really helped. Just short abbreviations or initials are fine. If there are multiple business units, put the BU name is in the front, eg: for Marketing – Promotional Material site and subsite, create the groups as Mktg – PM Members, Mktg – PM Owners, Mktg – PM Visitors. This helps your primary support team to manage the environment and assist users that are locked out. You can have hundreds of groups overnight; you need to know where they all belong and naming standards will save a lot of time. This is not such a big a deal if you have different site collections for each business unit. But if that business unit plans on having lots of subsites, it might be a good idea for them.

You need to make sure site owners add users in actual groups, not on a site level – it is impossible to manage in the long run. You will see if they have done this in the Site Permissions view. Also try and avoid creating unique permissions on a library, list or item level. It gets very difficult to manage. Rather keep restricted content on a separate subsite where possible and restrict permissions on that level.

The default Members group has delete rights. We split that out and made a special Delete Rights Only group. This had proved to be a winner across the platform. As most of your staff could end up as Members on a site to update content, you don’t necessarily want them deleting things at will.

If you are new to SharePoint and are going to be in charge of sites or the platform, make sure you get the permissions and inheritance concepts firmly under the belt as soon as possible. If you are planning a large rollout, this is going to be crucial.

Then there is licensing implications. If you have just bought MOSS 2007 Core CALs and are not planning to purchase Enterprise CALs at all, then follow all this advice, likewise if you have bought all Enterprise CALs. If however, you have bought Core and are planning to incrementally buy Enterprise, then you need to rethink this in other ways as well. Remember if you can view it or edit it, you need a license for it, (KPI’s, dashboards, etc). You cannot allocate an Enterprise CAL to a document library with unique permissions. It doesn’t work like that. They are activated on a site level – so whoever has access to that site needs a license. This will impact how you grant permissions and set up your hierarchies again.

Hope this helps. If I think of anything else I’ll let you know.