INTRODUCTION
This is a series:
- Managing Risks in Sharepoint 1 – Aligning the Environments
In the previous article I mentioned about how quickly the content in our development/Test environments will be outdated. Sharepoint content database consists of:
- Sites
- User accounts added to Sharepoint
- Site Settings
- Pages
- Documents and list items
- Content types
- Meta-data
- Features activated
- etc
Within a day there may be a lot of activities happening in your Sharepoint farm including users uploading new documents, sub-sites are created, users are added/removed to/from SP, etc. In this opportunity I want to discuss about user permissions because if we are not careful, assigning correct permission to the wrong users will end up creating risks for your Sharepoint environment (or even breaking it).
Managing Risks in Sharepoint 2 – User Permissions
1. "Deny all then allow" rather than "allow all then deny"
By default I would deny EVERYONE then I would start giving permission to those who need to have access to Sharepoint.
2. Using AD Group and not "authenticated users"
Thou shall NOT give NT_AUTHORITYauthenticated_users a READ access to your portal. Why? Because it means that every domain user (ie. all users who have an AD account) will have read access to your portal. This can be dangerous.
For example, user A is a contractor, he has a temporary AD account. Logically, you would disable his account once his contract is finished but in this scenario you can't because you are using a third-party software or application that requires his AD account to be active. Since his AD account is still active, he will still be able access your portal. You want to remove him from everything else (including Portal) except the application that requires his AD account to be active. You can't do that, because at the moment you have "authenticated users" added as the Reader of your portal. If you remove "authenticated users" you would deny other people's access. I'm speaking from my own experience. At the moment, the farm I'm managing is a bit of a nightmare. We've had several complaints from people who suddenly lost their access simply because we tried to remove "authenticated users" from the Readers group.
So, if I'm given a second chance to rebuild the Portal, I would start with creating an Employees group in AD. Let's say it's called MYDOMAINEmployees. Within it I will add ALL employees' AD accounts (including contractors'). I would then add this domain group to Sharepoint. When there is a contractor who's just finished his contract, I can simply remove him from this AD group and he will no longer have access to the Sharepoint portal.
Note: Making sure that you "wrap" your AD group in a Sharepoint group. Sometimes you would have a nested AD Group within an AD group. Sharepoint will have problems (especially with the Audience functionality) if this is the case. There is a patch that Microsoft releases that will fix this nested AD group problem but for it to work you have to add the AD group (that has nested AD groups) into a Sharepoint group.
So, I would create an Employees Sharepoint group that has READ permission then I'll add the MYDOMAINEmployees group to this SP group.
3. Don't let user modifying your content types and meta-data
ALL custom meta-data and content-types HAVE TO BE – in some way – DOCUMENTED! It can be done either through manual documentation or deployed through Visual Studio using solutions/features deployment. I personally use feature and solution deployment for all of my custom content types and features. I will NOT give general users (even site/department owners/managers) permission to add content-types and meta-data. From my experience with Sharepoint, content-types and meta-data are the core part of your farm. I've had lots of problems before when content-types and meta-data are not defined correctly.
At this very moment, I can no longer use the "Add from existing site column" functionality from the GUI because I got an error message whenever I'm trying to do so. The error message is something like "An object cannot have the same ID" or something like that. At the moment, whenever I want to attach an existing site column to an existing content type, I have to use the object model.
Once again I'm speaking through my experience. I will not let general employees (unless SP developers/administrators) access to add custom content-type and meta-data.
4. Break permission inheritance
Based on the "deny all then allow" principal, I would not hesitant to break permission inheritance for departmental sites. This means that ALL other users (other than deparmental users) are denied access unless stated otherwise. For example, I created a HR site, I will deny ALL users but HR people. I will only give general users access to some (or little) part of HR site that are meant to be shown to public.
Once again, always use an AD group wrapped in a Sharepoint group. I would never add an individual user to Sharepoint unless it's very-very needed because security maintenance will not be easy (ie. you won't know/remember who has access to what if you start adding individual users to Sharepoint).
Note: It's better to accidentally hide public documents rather than deliberately – by default – show private documents. Your documentation (in terms of who has access to what) needs to also be very complete and tight.
CONCLUSIONS
So there you go. Please share your experience. On the next series I would talk more about the development side of things.
Cheers,
Tommy
As a developer, there is nothing worse than writing a documentation. Anyway, it's EXTREMELY important to document the setup process for both Test and Prod. Take screenshots as you go through each step and document them. You can use MS Word to Copy Paste things easily or even OneNote with its screen clipping feature. It's really-really handy. Just like taking your wedding photographs for memory, that's how valuable documentation is for us. 
tommysegoro