Joel Oleson's Blog - SharePoint Land

SharePoint Groups, Permissions, Site Security, and Depreciated Site Groups

I had an email from one of Ted Pattison's students on "security in SharePoint."  When I first started reading it, I expected to have some question about server hardening or firewalls, but the question was about permissions.  It's been so long that security meant permissions that I was a bit stumped.  Where did our info on permissions go?  Is this some IW thing?  I found some good content, but it can be confusing.  There are some decent quotes from the content on MSDN.

The basics are on the office.microsoft.com site, designed for the information worker.  I recommend starting here, it's the easiest to understand and digest.

http://office.microsoft.com/en-us/sharepointtechnology/CH100649861033.aspx

• About security features of Windows SharePoint Services 3.0
• About controlling access to sites and site content  
• Permission levels and permissions
• Manage permission levels
• Manage permissions for a list, library, folder, document, or list item
• About managing SharePoint groups and users
• Manage SharePoint groups
• View users and SharePoint groups and edit the Quick Launch group list
• Remove users and groups from site access
• Enable anonymous access
• Configure permissions for a blog

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

• About site security elements
• About assigning permissions
• About fine-grained permissions and permission inheritance
• Choose which levels of site security to use
• Plan for permission inheritance

Note on TechNet: The way that groups and permissions interact has changed significantly from the previous version. In the previous version, site-level groups were used to contain both users and permissions — that is, when you added a user to a site group, you automatically determined the permissions that the user was granted for a site. In this version, the concepts of groups of users and permissions have been separated: SharePoint groups at the site collection level contain the users, permission levels contain the permissions, and groups have no permissions until they are assigned a permission level for a specific securable object (such as a site, list or library, folder, item, or document).

If you aren't confused after reading this, this isn't new to you... Read on...

From Windows security on what to use when creating your AD groups:

"For each group, you need to know what objects it can contain, as well as the overall purpose of the group.

For the group scope, you are determining where the group should be used within the Active Directory enterprise. Your group selection here determines a lot about how you want to use the group within the overall assignment of permissions. Before we discuss each group specifically, the overall picture of 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 security groups to the SharePoint Group which have the appropriate Roles which have role definitions (permissions levels) and role assignments (granularity).

Example:

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."

The terminology has changed and I'm sure many of you are questioning if it's better.  What's new?  Granular permissions on items, documents, contacts, etc... permissions management itself is so much richer.  The web based people picker with ajax in the little check to validate the user, it's is a ton better and is extremely flexible even working cross forest when configured properly.

The question I got was around security group nesting and if there was anything problematic about it.  He was also asking about best practices for managing security on sites.

My best practice is this...

For sensitive sites at the site collection level - least priviledged 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 that will ensure the site auto delete features do what you'd expect. 

For search reasons, you want to keep things open.  Adding "authenticated users" on content that is outward facing will make it discoverable.  Blogs nearly always should be open to read/browse with "authenticated users."  Of course on the internet, it's about having nearly all of your site read only access to anonymous.

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 site level.  There are some changes that have happened between V2 to V3 that I'd like to address here.  Cross Site Groups are now just SharePoint Groups, and Site Groups have been depreciated.  Upgrading WILL NOT break security on your sites, but it will be a frusterating experience if you used a lot of site groups.

The current best practice is to add users and domain groups to the permission level/cross site group (site collection groups).  The cross site group looks and feels like a role on the site collection and can be used across sites within the site collection.  If you are using WSS 2.0 and reading this, avoid using site groups, use the roles/permissions levels, and use cross site groups which will become SharePoint Groups.

Dev Tip from Jim Sturms: You cannot create groups or permission levels declaratively in XML – you’ll need to create these using the OM with a solution.

Although permissions inheritance is easily broken and granularized, I don't recommend it unless you need to.  It's a pain to manage, let me tell you.  There are a bunch of partners out there that would love to help you manage your site permissions and help you add users across all the sites when someone joins the group.  It's a ton better to add security groups and users at the site collection level and use the sharepoint groups and add people to those roles that you see right out of the box.  Sure you can break inheritance on special sites, but I'd recommend not making that the rule more the exception.

Permissions on sites with security groups is definitely a good practice.  Nested security groups beyond a couple 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:

• 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 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.

Common Issues

• Inheritance isn't setup as expected
• Rights 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 (use the timer service)
• 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 the userinfo table (by design)  There is a timer job you can use to modify what happens.

I'll see what I can find as far as documentation when I get back in the ofc on wed.

In WSS 2.0 this was the case (in italics is what has changed):

SharePoint Products and Technologies support three types of groups with the following characteristics:

• Windows domain groups
  • Can be nested inside each other
  • SharePoint Products and Technologies call Windows for user resolution
  • Can be a member of both of the following types of groups
• Cross-site groups (called SharePoint Groups in WSS 3.0)
  • Scoped to the site collection
  • Cannot be nested within each other
  • Can be a member of site groups, but not Windows domain groups
• Site groups
  • Scoped to an individual Web site
  • Cannot be nested within each other

Now:

There are no more "site groups".

There are still domain groups (security groups) which can be added to any of these groups above.

Users become members of a SharePoint object either indirectly through a group that has a role assignment, or directly through a role assignment. In addition, users can be members of a Microsoft Windows NT Domain Group that is added to a group or to a role. A role definition associates a user or group with a single right or set of rights corresponding to values of the Microsoft.SharePoint.SPBasePermissions enumeration. Each user or group has a unique member ID.

To give a user access to an object, you can do so either by adding the user to a group that already has permissions on the object, or by creating a role assignment object, setting the user for the role assignment, optionally binding the role assignment to the appropriate role definition with base permissions, and then adding the assignment to the collection of role assignments for the list item, folder, list, or Web site. If you do not bind the role assignment to a role definition when assigning a user to a role, the user has no permission.

Some Questions around Site Groups and Upgrade came up in a recent customer upgrade that fits in nicely...  Thanks Ambrose for the answers.

Q: What is the exact mapping for users, groups, cross-site groups and Domain groups? What is the best approach regarding these mappings?

A: These are upgraded as is.  They are not changed during the upgrade.  In terms of mappings…  User accounts are users, groups contain users and can be used to provide specific roles such as contributor or reader.  Cross site groups now called groups are special groups that can be used across site collections and can be assigned to a what was a site group now a group/role or permissions level such as contributor or reader.  AD (NT Security) groups can be added to groups or cross-site groups.

The best approach is to leverage NT Security groups where they already exist and add them to the site collection.  If the membership web part is desired, the users should be permissioned individually, or where an NT security group does not exist.

Q: After an upgrade Site Groups were mapped to Permission levels. Which permissions are automatically assigned to these permission levels? Can this be influenced during the upgrade process?

A: These legacy groups stay the same, same rights.

Q: Some site groups appear correctly after an upgrade. For some other site groups the permission levels are names like “Custom 2” or “Custom 3”. Why is that?

A: It’s a mapping and to avoid conflict.  Since there are only cross site groups and groups, they are used to avoid conflict.

Audiences:

Let's not get confused with audiences as security objects.  They are not.  They are used for targetting.  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 in the Shared service provider, while letting an individual site owner target to exisiting groups that already have."

A role consists of two parts: a role definition and a role assignment.

The role definition, or permission level, is the list of rights associated with the role. A right is a uniquely controllable action within a SharePoint Web site. For example, a user with the Read role can browse pages in the Web site and view items in lists. Unlike in Windows SharePoint Services 2.0, in Windows SharePoint Services 3.0 user permissions are never managed directly using rights. All user and group permissions are managed through roles. A role definition is a collection of rights bound to a specific object. Role definitions are scoped to the Web site (for example, Full Control, Read, Contribute, Design, or Limited Access) and mean the same thing everywhere within the Web site, but their meanings can differ between sites within the same site collection. Role definitions can also be inherited from the parent Web site, just as permissions.

Web App Policies

What about the ability to Deny?  There is no granular or 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 canonical 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. "

References:
TechNet: Plan Site Security
http://technet2.microsoft.com/windowsserver/WSS/en/library/700c3d60-f394-4ca9-a6d8-ab597fc3c31b1033.mspx?mfr=true
Managing Permissions and Security
http://office.microsoft.com/en-us/sharepointtechnology/CH100649861033.aspx
Role Assignments, Role Definitions, and Inheritance
http://msdn2.microsoft.com/en-us/library/ms414036.aspx
Users, Groups, and Authorization
http://msdn2.microsoft.com/en-us/library/ms414400.aspx

Security Notes for SharePoint Portal Server 2003 Developers (There is some good stuff here, but some things such as site groups has changed)
http://msdn2.microsoft.com/en-us/library/ms996097.aspx

Looking for more on Security?

My other posts on other SharePoint Security Topics

Adam Buenz [SharePoint MVP] http://www.sharepointsecurity.com

Check out a free trial of ScriptLogic's SharePoint Security Explorer