How to control access to your Site Collection
When SharePoint is installed, the user account entered in at that time is known as the Farm Admin Account, that is the only account that can access all information in SharePoint. That account can be used to to set up other Farm Administrators as well. Only the Farm Administrators knows the password. When a site collection is created, Primary and Secondary Owner are assigned. These two people have full control of the site and the security model including all subsides and all information. They can even delete the site and can lock themselves out of a site, this site collection is theirs to manage in full per the features enabled by the Farm Administrators.
The concepts are simple: groups, users, permission levels, permissions and last but not least inheritance, think of them in this order. SharePoint groups contain the users, permission levels contain the permissions and Groups are assigned a permission level. This structure is inherited everywhere to secure all objects. (I found that when I first tried to figure out how to control access to my site that it was very confusing because of the words “Permission Level”, now I think of them as “Permission Groups” or sub-set of available out of box (OOB) permissions)
Out of the box there are 5 Permission Levels set up that allow for immediate control of your content. Each one has permissions assigned to it from the Permissions list. You can change them or add more to suit but you need to know what you are doing so when first getting started be careful.
There are 4 preconfigured Groups (OOB) on most Site Collections (Portal and Collaboration Sites have more to suit more complex roles but the same concept applies). All groups are managed at the site collection level, you can create a Group on a sub site but you have to beak inheritance between the Site Collection and the Sub-site and the new sub-site Group will show in the Site Collection set of groups and can be managed there also. This behavior does not apply to Permission levels, permission levels are site/sub site specific.
So the concept to grant access to your Site Collection is simple, just add users to the OOB Site Collection groups. All securable objects such as a site, list or library, folder, item, or document will inherit permissions from the Site Collection Group Permissions Level configuration. The UI to configure permissions takes a while to get used to; there are so many pages, menu items and settings. For example the Create/Edit Group has a myriad of settings, you can control who owns the group, who can see members of the group, manage requests to join the group and set permissions. Lots of power and flexibility, see the graphic below.
Some people believe that Groups are roles others see the Permission Levels as roles. I find that once you throw the word role into the equation, you need an interpreter find out what that that means in SharePoint. My customers know their business and their typical roles and usually want to secure information by roles so they are confused at first, but it is all quite simple.
Managing Security for Specific Use Cases
Usually after the Site Collection is in use, people will come across the need to customize permissions to suit special cases, e.g.a new list that only 2 people can edit the list items and 20 others can only read the list items and all others cannot ever see or read the list. This is where it gets fun. All you need to do is follow the same concepts that Microsoft did when they set up the OOB security structure. To do that here are some other things you need to know.
You can add users individually to the site and assign them to a specific permission level. in other words you do not have to add them to SharePoint Groups. You add the user, pick a preconfigured permission level and that is it. The user will show up in the listing of Groups so it looks like a Group in the UI which is confusing to me.
You can create your own Permission Levels (groups of permissions) to suit special cases and this is where you can really get granular control of what users can and cannot do on your site collection. There are over 30 permissions to choose from in the list of Permissions to allow you to combine them into a custom Permission Level to suit your specific conditions. Then you can use it like you would use an OOB Permission Level and assign it to Groups as required.
You can set Item Level Permissions on an item in a list or library in a similar manner to adding site level permissions. This is very powerful but should be uses wisely to ensure you do not end up spending your days managing permissions. You really need to focus on the inheritance, set you permissions on the Site or Library and let inheritance take care of item level permissions if you can.
Large User Bases
Users are likely already members of a Microsoft Windows NT Domain Group (aka, AD Group) that can be added to a SharePoint Group. Adding an AD Group saves a lot of time when you need to give access to your site to many people. Just think of an AD Group as a person’s user account when adding them to your site, the same rules apply. The tricky part now is that you will not immediately see the complete list of users in the “All People” list on the Site Collection but the users in the AD group will have the access. The user will only appear in the “All People” list if they have logged in at least once, then each user will get a unique member ID and will become an SPUser Object in SharePoint.
Let’s not get confused with audiences as security objects. They are not. They are used for targeting. They can be used to direct people at places like different trusted my site locations as well. With SharePoint server Venky explains…"You can target any list item or web part directly to rule based Audience, DL or SharePoint groups. This allows for rule based audiences to be created and maintained while letting an individual site owner target to existing groups that already have."
Bryant says "Audiences are a global concept, whereas SharePoint Groups are a relatively local concept. For example, you might reuse the same audience across multiple portals, which will each have their own groups. Unfortunately, there is no way to define an audience rule based on groups.
On the other hand, most of the places where you use audience targeting (such as content by query WP or web parts), you can also target to SharePoint Groups (you can pick from any groups available from the site you are browsing)."
Web App Policies
What about the ability to Deny? There is no deny at a site level, but you can do a deny at a web application level with a web application policy. I wrote up a fairly extensive post on web application policies. Jim explains it well: "Policy is merged with local permissions to arrive at the user’s effective permissions.
There are three examples of using Policy:
Audit – a way to give a lawyer or auditor read access to all content in a web application in a single gesture instead of editing permissions for hundreds or thousands of webs, lists, and documents.
Compliance – a simple way to ensure that a server is in compliance with regulations, e.g. I can put a Deny All policy on the Traders group to ensure that no trader gets inadvertently invited to site. The Deny will override any Grant of permissions.
Lockdown – a single way of locking down an Extranet site, e.g. I can put a Deny Write policy on all domain users sitting on a server in an extranet forest to make sure that any edits to the site only happen from the Intranet. "
More about AD Groups (your best friend)
You should leverage the existing AD groups on the Domain to ease the burden of providing access to large user base. AD groups currently exist on probably all windows networks to secure access to documents on file shares. These same groups can and should be used to lock down or open access to SharePoint sites and content unless of course they were not designed right, but if the design worked on file shares it will work in SharePoint without changes needed.
If you already have AD groups in your company, find out the names and member of the Groups using the right Tools and start using them. AD groups are almost always nested inside of other AD groups to ease the burden for the persons managing the AD groups. See this article from Windows security if you are interested in creating your own AD groups.
AD group and user nesting is designed to be as follows:
Users go into Global Groups, Global Groups go into Domain Local Groups, and Domain Local Groups are listed on the Access Control List (ACL) of the resource.
I highly, highly recommend avoiding using server local groups anywhere anymore minus the built in administrator group. It’s just confusing and painful.
If Universal Groups are used, then the following nesting rules apply:
Users go into Global Groups, Global Groups go into Universal Groups, Universal Groups go into Domain Local Groups, and Domain Local Groups are listed on the Access Control List (ACL) of the resource."
So what’s the rule for SharePoint?
Add your existing AD security groups to the SharePoint Group which have the appropriate permissions levels and role assignments.
If I was creating a team site for my team, I would go into the site collection permissions and add users/groups such as the Redmond\TPM domain security group, to the SharePoint group "%Site Name% – members" which has permissions assigned to it, or assign permission levels directly such as "Contribute."
The UI itself has a very straight forward explanation. "Choose the permissions you want these users to have. You can add users to a SharePoint group (which is already assigned to a permission level), or you can add users individually and assign them to a specific permission level. SharePoint groups are recommended as they allow for ease of permission management across multiple sites."
Nested AD security groups beyond a few can be problematic especially when a contact or DL is in the mix or when a global group is used improperly. Our help desk has found it simply requires a lot of trial and error to discover when a security group has been invalidated by having contact objects.
Here’s a quick list of problematic groups scenarios:
Distribution Lists with contacts in them
Security groups with contacts in them
Global security groups used in a separate "resource" domain (often happens in cross domain/cross forest migrations)
Security groups which contain contacts
The deeper the nesting the more likely windows itself will freak out.
Rule of thumb: If it works to secure a file on the file system in the same domain as your SharePoint server, you’re 99% likely it will work in SharePoint. I say 99% because, I have myself removed and re-added a user, a number of times to reapply security to get it to work. It is a common troubleshooting step to remove the group or user, then remove their entry in the user info list to clean it up completely. When attributes change on users, in the past it often would leave residue in the user info table that wouldn’t get cleaned up. Most of this has been addressed, but I still use this as a troubleshooting practice.
For sensitive sites at the site collection level – least privileged access, don’t delegate the site owner or admin roles, you should have a couple of site administrators and/or site owners, using individuals here is a good practice. You’d think why not create a group, but at this level it’s good to have an individual owner that has an email address.
For search reasons, you want to keep things open. Adding "authenticated users" on content that is outward facing will make it discoverable.
Managing site security should start at a site collection level and be managed as much as possible at that level. It can then be either inherited or be managed at a sub-site level.
Although permissions inheritance can easily be un-coupled and/or reverted to allow for specific granular access control, I don’t recommend it unless you need to. It’s a pain to manage, let me tell you. You do not want to get into situations where you have to add users across all the sites when someone joins the group. It’s a ton better to add AD groups at the site collection level and only add users in Adhoc situations. Sure you can break inheritance on sites, Lists, Libraries, documents etc, but I’d recommend not making that the rule more the exception.
Inheritance isn’t setup as expected
Rights/Permissions Levels aren’t configured as expected or by default
Membership web part won’t display users in a group (by design)
Owner/admin leaves company and no one else is site owner or site administrator
Reusing existing user objects causes unexpected security issues (manually delete and add new)
When a user leaves the company, the profile is cleaned up, but the ACLs are still on the objects, and the user is still in an SPUser in the userinfo table (by design)
Rookies will alter the security Model with SharePoint Designer potentially changing the behavior of the Security Model.
Resources and References:
Some of the Information in this Blog item is from Joel Oleson’s blog item.
Site Collection owners would want to learn how to secure their site and its content by reading Office.Microsoft.com product information. Such as this article. http://office.microsoft.com/en-us/sharepointtechnology/CH100649861033.aspx
TechNet has some content on the topic as well, designed for the IT professional. This was semi helpful. It needs the text above to make sense out of it. http://technet2.microsoft.com/windowsserver/WSS/en/library/700c3d60-f394-4ca9-a6d8-ab597fc3c31b1033.mspx?mfr=true
Managing Permissions and Security
Role Assignments, Role Definitions, and Inheritance
Users, Groups, and Authorization
Security Notes for SharePoint Portal Server 2003 Developers (There is some good stuff here, but some things such as site groups has changed)
other posts on other SharePoint Security Topics
Adam Buenz [SharePoint MVP] http://www.sharepointsecurity.com
Questions and Answers from Joel’s Blog
Is it possible to target audiences to AD Security groups? What I did was compile the profiles and target a webpart to the security group. I tried but it doesn’t seem to work. Am I missing something here? The compilation also does not get all the security groups. You can target web parts at security groups, DLs, and SharePoint groups and audiences. Audiences are defined by profile attributes that can be imported from various locations.
As per Microsoft guidelines given on http://technet2.microsoft.com/Office/en-us/library/6a13cd9f-4b44-40d6-85aa-c70a8e5c34fe1033.mspx?mfr=true, Per Web site, maximum 2,000 Security principals are acceptable. It further says that The size of the access control list is limited to a few thousand security principals (users and groups in the Web site). The same website says that users in groups can be 2 million per website. I am very much confused about what is the difference between security principals and Users in groups. Can you please elaborate on what are security principals in sharepoint with some example.
The 2000 security principals guidance is what you’d see when you go to site settings, permissions and look at what is listed. Domain\user or domain\group, both would be security principals you could have 1000 people in that group and it would still count as one. If you added 2000 users individually that would be 2000 security principals. So we can add 1000 users in an group but it will be taken as 1.Great.
Though your have written clearly domain\group, i would like to recheck here that in your statement, are you talking about SharePoint groups or active directory(domain)groups.
What is the maximum limit in this.Can i got beyond 2000 users in an group.
Please ignore the line below if by groups, you mean active directory based groups.
I have got bit worried from the last lines of your comment about 64k limit of ACL.
As per my understanding, the ACL of sharepoint groups(not windows groups) is stored in SQL Server.So this limit should not apply to sharepoint unless we are using domain(AD) groups.
If my understanding on this is incorrect, please let me know so that i can try for windows tools to check the ACL list and its size.
I read a sharepoint article at http://www.sharepointblogs.com/mirjam/archive/2007/01/03/moss-2007-performance-guidelines.aspx in which Mirjam say’s that security principals are users and SharePoint groups while you stated that it is domain\user and domain\group. That created confusion in my mind stated in my earlier comment today.
As I looking for an 50000+ user base SharePoint implementation, based on 64K ACL limits,what is your suggestion to overcome this issue.
Rajiv, 50,000 users doesn’t pose a problem. That’s a very manageable deployment. Internally we have 110,000 profiles and have portals that have that many users that have access by adding domain\domain users with browse/read access. If someone needs contribute access they could be added individually or added by adding them to an AD security group. In your case you don’t add all 50,000 users individually on the site. Use domain\domain users, authenticated users or use existing or new security groups from your AD (or membership provider in the case of LDAP). SharePoint really can scale to millions of users, you just need to be smart about how you add them. There isn’t any difference to what I’m saying from what Mirjam is saying. Users and groups, users and SharePoint groups both add up. 64K is a TON of individual permissions aka security principals. The thing were talking about avoiding is adding users granularly. Stick with adding users in less than a 100 at a time or using domain groups and you’ll never reach 2000 security principals. This doesn’t need to be confusing.
Referencing to link Windows security in the blog post, is it that we can target audiences to ONLY AD Security groups ? Is there any chance or way that it is possible to target audiences to Distribution Groups also? you can target web parts to distribution groups. Go to the web part look at the targeting settings and you’ll see you can. It’s similar to targeting to an audience.