Lock Down Security: My Best Practices (and restoring usability)
11 Dec 2007 Leave a comment
I’m sure many of you are need to establish and implement a security matrix on your SharePoint sites. What do you need to do to ensure that your users can actually do the stuff they need to do? After all they are the business they are bringing the actual money home.
This is my first of probably many blog articles about SharePoint security. It is a rather complex and annoying issue that most of us don’t really want to think about too much. Generally most people solve it in one of three ways:
- Grant everybody some standard permissions and forget about it
- Grant (too) many administrative rights and trust them not to mess it up
- Lock down security and accept the loss of usability as many features stop working
I tend to go with either 1 or 3. For my more advanced setup the standard groups (option 1) doesn’t quite cut it and I’m stuck with option 3. That being said I do take pains to ensure that as much functionality as possible continue to work – the very purpose of this article.
I usually think of (and use) SharePoint Groups as roles and permission levels as role definitions. Note that the security setup has changed substantially since WSS 2.0, so you might need to read up on it (see bottom).
Designing the Security Matrix
When you need to implement security you quickly discover that there really is no way to import/export the security definitions and you are stuck with manual configuration. Sorry. It’s on my to-do list of tools that I would like (someone) to build. I know of only one way to “copy” the security setup from one environment to the next and that is a stsadm backup/restore of the site collection. It can be useable once or twice if you plan it right.
So what you need to do is to document and plan it thoroughly before you start. Nobody likes to do the same work 5 times over which you will otherwise end up doing. And sadly you’ll need to involve your client/customer/user and get them to buy in on whatever security you end up implementing. If you are like me you’ll want them to be able to maintain it after the project is delivered and then you need them to understand what you are doing, why and how they should use it in the future.
I prefer to use excel with a simple sheet with the site hierarchy as the first column and subsequent user groups/roles on the next columns. In the cells you simply write something the places where you’ll break the security inheritance and invent some labels that describe what that particular group should be able to do at that particular site. Don’t be too creative and don’t use a 20 letter encoding of the SharePoint permission levels. Use a label and map that to a custom permission level later (client probably don’t care about that).
It almost goes without saying that you should plan for as much inheritance as possible so the spreadsheet should be fairly sparse. If it contains lists or individual list items you should consider other options as that will certainly go awry in a very short time.
Deciding on AD or SharePoint Groups
So should you use SharePoint groups or should you use AD security groups (I’ll skip the discussion of AD group scope here – domain local, universal etc.)? You’ll probably end up with both as there are benefits and tradeoffs with both:
|AD Security Group||SharePoint Group|
|Contains both users and other AD security groups||Contains both users and other AD security groups, but not other
|Must be maintained in the AD, usually by IT department and/or IT administrators||Permission to maintain groups can be assigned within SharePoint|
|Can be used (directly) within SharePoint for permissions||Can be used for permission assignment (obviously)|
And there are many more that I didn’t consider important here. Sharp readers will notice that I omitted server local groups here. Don’t ever use them. They are simply confusing, impossible to maintain and they don’t go well with a multi-server farm.
I usually prefer to have the AD deliver as much as possible, e.g. at least domain membership, probably department membership. I then assign those groups to a number of SharePoint groups that I use as roles and don’t worry too much about those. E.g. if you want to assign every user in the domain reader rights and a few (10%) some additional rights, then 90% of the users will be correctly assigned after adding “Domain Users” to your reader SharePoint group.
One word of warning: If your organization has been very creative in their domain setup and use excessively deep nesting in AD it might not work within SharePoint. It has been seen to happen. If you can assign that group properly to file share on the SharePoint server you should be quite certain that it also works in SharePoint.
The most important missing feature of the SharePoint groups is that they cannot be nested. It is a shame and the consequence is that you might need to add a given user to, say, 4 different SharePoint groups to make everything work. If it requires somebody to grant permissions on individual basis somewhere on the portal chances are that you should rethink your design.
Be sure to write down what is needed to grant a new user access to your portal that can be used as a reference for the SharePoint business owners at a later stage.
One very helpful tip in managing the memberships of the SharePoint groups is that each group is assigned a owner that can adjust the memberships (by default), but it will also work if you assign a SharePoint group that role.
Go to the edit group page to modify it and set your custom SharePoint administrator group as owner of the group. From that point on your membership handling can be delegated to somebody without excessive rights e.g. farm administrators.
Implementing the Security Matrix
One thing that I’ll always recommend: Don’t use the standard SharePoint permission levels. They are well designed and therefore you should take a copy of them and assign the copy to your groups where you need it. That will enable you to later modify the permission levels in one place (as opposed to going through everywhere you assigned permission to that group) without compromising the integrity of the standard permission levels. Nothing is worse than a Contributor permission that actually grants administrative rights…
Ensure that the right people can administrate various group memberships by making sure who the owner of the SharePoint groups is.
When you implement (click through it) your matrix make extensive use of the “View Group Permission” feature (from settings menu when viewing group memberships, people.aspx). Another thing for my to-do list is to extend this feature to handle users as well – it’s not as hard as it sounds.
In the following I’ll cover some specific quirks that you might need to remember to ensure that your users can still use the site after you did your work (oh, they will resent you for it…)
Making the Galleries Work (Again)
The web part, list and site template galleries might need special permissions (if you try to limit access to the site collection root), to continue to work. To go to the permission setup, go to the actual galleries through Site settings, then gallery settings and finally the permissions.
- Web Part Template Gallery: You should assign read permissions to this gallery to everybody (their group!) that should be able to add webparts somewhere. Otherwise the Add Web Part popup will be rather empty
- List Template Gallery: Users that need to create lists from saved list templates obviously needs read access and the people creating the list templates should have contribute/write permissions.
- Site Template Gallery: Users that need to create sites from the templates require read access. Users creating the site templates need contribute permissions on the gallery as well as the Site permission “Manage Permissions” (available on the permission level settings) on the target site that they want to save
On a publishing web site, i.e. publishing or collaboration site, there is a list in the site collection root named “Reuseable content”.
If you want the functionality to work on any subsites you need to assign all editors contributor right to the list and all other users read permissions. If some users lack the permissions they simply won’t see that particular item of content on your publishing page. There will be no sign that they do not see the complete page, which tend to be pretty confusing to end users.
Sadly there is no list or permission level that governs the customization of content types. You can’t prevent this through permissions if you also require some users to be able to manage your site permissions, i.e. add users.
You will want to prevent “people” (administrators) from changing all the content types that you defined in xml through feature deployment as that will disconnect your content type (see my two posts on that, 1 and 2) from the underlying xml source.
You can mark your content type as either read only or sealed with following tradeoffs
- Read only: Will prevent accidental changes and allow inherited content types to delete/hide inherited columns. Administrators can actually override this setting if they really want to (but then they are not “in good faith”)
- Sealed: Will prevent all changes through the GUI, but will also lock child content types so they can only hide inherited columns, not delete them
Both cases will not affect your ability to update the underlying xml files, i.e. it is actually not supported to change them after initial deployment. You can do it, but then you’ll need to update all inherited content types to preserve or restore their “inheritance” (see post). (A proper fix for this is another item on my to-do list)
Master Pages, Page Layouts and Styles
Just maintain the default “Style Readers” group and you should have no problems with these lists. If you do change the style readers group too much you need to ensure that
- all users can read from the master pages catalog (“/_catalogs/”), otherwise they are completely blocked from your pages
- all users can read from “/Style Library”
I hope that these guidelines will help you a little bit. They helped me, but don’t for a minute consider them to be complete.
There are a number of features that require some special permission here and there if you tighten security on something else. It’s bound to happen and it is tedious and hard to test thoroughly.
You can find some general information from Microsoft that defines all the basics and provides some guidelines here.
As usual Joel Oleson has something worthwhile to read on the subject.