Chapter 11: Users and Permissions (Part 2 of 2)

  • Article

This article is an excerpt from Mastering Windows SharePoint Services 3.0 by C.A. Callahan from Wiley Publishing (ISBN 978-0-470-12728-5, copyright Wiley Publishing 2008, all rights reserved). No part of these chapters may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, electrostatic, mechanical, photocopying, recording, or otherwise—without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.

Previous part: Chapter 11: Users and Permissions (Part 1 of 2)

Contents

  • Applying Permissions

  • Planning User Access

  • The Bottom Line

  • Additional Resources

Applying Permissions

Now that we have covered a good bit of ground, it is time to set permissions on the stuff inside Windows SharePoint Services. Several different objects that can be secured are in the Windows SharePoint Services system. A securable object is an object upon which permissions can be configured (for example, a site, list, library, folder within a list or library, list item, or document). Permissions for users and SharePoint groups can be assigned to any securable object. The Windows SharePoint Services system defaults to assigning permissions at the Site level, and those permissions filter down through permission inheritance to the contained objects such as lists, list items, and the like. A user with the Manage Permissions permission can edit the permissions for any of the contained objects, breaking the hierarchy of inheritance chain. This permission is assigned to the Site Owners group by default.

Inheritance

Inheritance means that a site and its contents inherit their permissions from their parent object; so subsites get their permission from their parent site; the subsite’s lists and libraries get their permissions from the subsite, and list and library items get their permissions from the list or library in which they reside. This chain of inheritance makes it possible to administer permissions for entire site collection from one place and have those changes trickle down to all other objects contained therein.

Figure 11.32 shows a top-level site with a set of permissions called Permission Set A. The two subsites underneath it also have Permission Set A, as do the lists and list items underneath the sites. All of the objects in my example are shown inheriting permissions from the top-level site.

Figure 11.32 Inherited Permissions

If you change the permissions set on Subsite 2, the permissions for the list contained there will also change so that they both will have Permission Set B. See Figure 11.33.

Figure 11.33 Subsite 2 permissions change

You could also change the permissions on List Item 2 to a different set of permissions, Permission Set C (see Figure 11.34).

Figure 11.34 List Item 2 permissions change

And on a larger scale, instead of drilling down on the permissions of a site versus a single list item, the permissions of sites and subsites also have a bit of flexibility.

Figure 11.35 shows a top-level site with a set of permissions we’ll call Permission Set A. Subsites 2 and all subsites beneath it are configured to inherit permissions, and therefore also use Permission Set A throughout their pages, lists, and libraries.

Figure 11.35 Subsites with different inherited permissions

However, there are times when you need a set of subsites that break inheritance in order to have their own, unique permissions. In this diagram, one of the subsites two levels below the top-level site, subsite 1-A, has broken inheritance to use its own permissions. For the sake of discussion, we’ll call its permissions, Permission Set B. That means that all lists and libraries on that site will be effected Permission Set B (unless set to do otherwise). If any subsites are created beneath subsite 1-A, and are set to inherit permissions, they will inherit Permission Set B. This gives subsite 1-A permission capabilities akin to a top level site. Changes to the permissions at that level trickle to the other two subsites.

One of the nice things about Windows SharePoint Services 3.0 is that it will actually allow you to reestablish the inheritance relationship. Anywhere inheritance can be applied, from the site level to the item level, inheritance can always be restored. This means that these decisions are not unchangeable. On the Permissions page where you make the change, you can choose to inherit permissions, as shown in Figure 11.36.

Figure 11.36 The Edit Permissions option

Once you choose this option, you will lose any and all customizations you have made to the current object and you will revert to inheriting permissions from the parent object. Should you decide to go back to custom permissions from inherited permissions, you would need to redo the unique permissions for the object.

Change Subsite Permissions

Occasionally a subsite is created in a site collection that requires unique permissions, such as an accounting subsite that should be accessed by only a subset of the users in the Members group. In that case, inheritance must be broken so those changes can be made.

Inheritance comes in two parts. The subsite can choose to have its own groups and users without breaking away from the parent site’s permission levels, or you can break inheritance for both.

To change a subsite’s permissions:

Go to the subsite’s permissions page (in my example I am using my Tech Support Wiki site), and on the action bar, select Actions, then click Edit Permissions (Figure 11.37).

Figure 11.37 Edit Permission on subsite

This will trigger a warning dialog box reminding you that you will be breaking inherited permissions with the parent site (Figure 11.38).

Figure 11.38 Breaking Inheritance Warning

What that really means is a copy of all groups and permission levels will be made on the site, but the connection with the parent will be severed at that point, so if changes are made to permissions at the parent level, they will not affect this site. Click OK.

At that point, all the groups will be there to be changed as you would at a top-level site. So you can add groups, change the groups copied there, even remove groups. As you can see in Figure 11.39, inheritance has been broken with the parent on this site for Groups.

Figure 11.39 Web Site does not inherit permissions

However, if you try to change a permission level, you will find that you haven’t quite broken inheritance.

Click on Permission Levels on the Settings menu of the action bar. When you reach the Permission Levels page, you will see in Figure 11.40, that permission levels are still being inherited. To edit permission levels at this site, you will need to click the Edit Permission Levels link in the action bar. This will trigger another dialog box warning you that you are about to break inheritance. After clicking OK you will be able to create your own permission levels, and customize or delete the ones copied from the parent.

Figure 11.40 Permission levels still need to be disinherited

This separation of groups and permission levels allows a site administrator to break from the parent site enough to have different users and different groups, but still keep permission levels. However, it is good to know that making a clean break takes two steps.

When you break inheritance between a subsite and its parent, it does not really take it out of the site collection. The users that exist for the site collection will show up in the All People page, even if you don’t give them access on your site (and deleting users from the All People page deletes them from the site collection). If that is a problem, just take those extra users out of your groups and don’t apply them to anything if you don’t want them using your site. Breaking inheritance just unshackles the subsite from being unable to create its own SharePoint groups or permission levels, and delete the ones forced on it by the parent (in my case, the top-level site).

Set Up Groups for the Subsite

If you check the subsite’s Groups quick launch bar, it still shows the parent site’s groups (you see them in Figure 11.39). If you want to create Member, Visitor, and Owner groups for the site itself, instead of making them from scratch, the easiest way is to use the Set Up Groups option.

Go to any of the Group pages (or the All Groups page from the top of the Groups Quick Launch bar—which, not surprisingly, displays all groups for the site collection), click on Settings in the action bar, and select Set Up Group.

On the Set Up Groups page (Figure 11.41), there are sections for applying the standard permission levels for Visitors, Members, and Owners groups. Instead of using the existing SharePoint groups, select Create a new group for each of the sections you desire.

Figure 11.41 Set Up Groups page upon opening

The sections will drop and allow you to name the group and add users (as you can see in Figure 11.42, I added a number of users and confirmed their names). Notice that, in the Visitors section, you can add all authenticated users if you wish (which I don’t).

Figure 11.42 Creating new groups on Set Up Groups page

After entering your data for the groups, click OK. Back on the Groups page, you’ll see that there are now three new groups (Figure 11.43). Now you have groups of your own devising, containing users you want for the site. Feel free to keep the groups copied from the parent but not use them (unless you want to), or you can delete them. Keep in mind that you are removing them from the site, not the site collection.

Figure 11.43 Three New Groups on People and Groups page

Remove Inherited Groups

To conveniently remove the groups that were copied from the parent site, simply go to the Permissions page, select the groups, click on Actions, and select Remove User Permissions. As you can see in Figure 11.44, it will pop up a dialog box warning you that you are removing the groups from the site (which can reassure you that you are not deleting them from the site collection).

Figure 11.44 Remove Groups from subsite

Now, the groups from the parent site, despite their being removed from the site itself, will still show up in the Groups Quick Launch bar (and the All Groups page). To get rid of them, from the Quick Launch bar simply edit the Groups Quick Launch off of the Settings menu on any Group page. However, even if those groups do show up on the Groups Quick Launch bar, they are truly gone. For example, if you were to view the permissions of a list on the site, the parent groups that were removed would not be listed (Figure 11.45).

Figure 11.45 Permissions on the site after removing groups

Hopefully this gives you an idea of how to break inheritance at the subsite level. Changing permission levels (once you break inheritance there) is more straightforward than messing with groups. And always remember, you can always re-establish inheritance by going to the permissions page, Actions menu, and choosing Inherit Permissions. The same goes for the permission levels.

Through the Users’ Eyes

Generally, as administrators, we will rarely log into a SharePoint site with less than administrative privileges. But, because security filter works in this version, for a user with deprecated privileges, such as Visitors (with the Read permission level) or Members (with the Contribute permission level), logs in, features that we take for granted are missing.

When a user logs on with only the permissions available with the Read permission level, they cannot personalize any pages or change any site settings, so the Site Actions menu is missing altogether. The Welcome menu does not offer the user the chance to personalize the page. On lists and libraries, the New and Settings menus are gone, and the only button on the action bar is Actions, allowing the visitor to be able to set an alert, open the list in Explorer, export to a spreadsheet, or set an RSS feed.

When a user logs in with the Contribute permission level (Members have this by default), they can personalize their view of the home page, but not change the site settings or create new pages, so there is a new option on the Welcome menu for them to personalize the page, but Edit is the only option. On a list or library, they are not allowed to change the settings, so that menu is completely missing for them, but both the New and Actions menus are available.

Just keep in mind, when using and applying permission levels, that the user experience will vary considerably, depending on the permissions they have.

Change List or Library Permissions

Sometimes the need to customize occurs, not at the subsite level, but at the list or library level. Often is the case that a document library needs to be created that will hold secure documents that the users that otherwise populate the site should not see. Because of this, it needs to have custom permissions.

To change permissions on a List or Library, you need to break the inheritance chain from the parent site before you can set custom permissions.

  1. Open the list or library on which you want to change permissions. My example uses the Shared Documents library. Select Settings ➢ Document Library Settings.

  2. When the Document Library Settings page opens, click Permissions for this Document Library under the Permissions and Management category (see Figure 11.46).

    Figure 11.46 The Document Library Settings page

  3. The Permissions: Shared Documents page will open. This page contains the permissions currently inherited from the parent site. Choose the Actions menu and select Edit Permissions (see Figure 11.47).

    Figure 11.47 The Permissions page and Actions menu

  4. After you select Edit Permissions, a dialog box will warn you that you are about to create unique permissions for this library (see Figure 11.48).

    Figure 11.48 The Permissions changes warning

  5. After you click OK on the warning box, the Permissions page will open again. You can select any of the entries and modify their permissions. Use the Action menu to make your modification.

Once you have broken inheritance:

  • You can add new users or security groups to the library. To do this simply click on New on the permissions page of the library, and add the user or security group via the new user page.

  • You can remove a SharePoint group allowed to access the library (or user if they were added with permission levels instead of a group), by selecting the group or user, going to Actions, and selecting Remove User Permissions. The person or the people in the group will summarily be unable to access that library from that point (but still easily access the rest of the site, unharmed).

  • You can edit the permission levels applied to the SharePoint groups for the list. In my example I am going to add (only for the sake of demonstration, I don’t suggest you do this at home) the List Managers permission level to all of the contributors to the Shared Documents library (Figure 11.49). When you do this on a list or library that has broken inheritance, it does not change the true permission levels applied anywhere else on the site.

    Figure 11.49 Editing the permissions levels for a Group at the library level

  • You cannot simply create a new SharePoint group for the library.

  • You cannot create anew or modify the permission levels applicable for the library.

Keep in mind that you can always change your mind and restore inheritance by choosing Inherit Permissions at any time from the Actions menu on the list or library’s Permissions page. All changes you made during the non-inheriting time will be undone.

Change List Item or Library Item Permissions

New to Windows SharePoint Services 3.0 is the ability to set custom permissions at the Item level. In the previous version, you were limited to the Library or List level. This is a definite step forward in security measures, but it does entail more overhead because you have another level of permissions and controls to worry about. Changing the permissions on an item is fairly easy.

Note

PERMISSION LEVELS AND HIERARCHICAL LEVELS When discussing levels of permissions, keep in mind there are two definitions for the word level. Permission Levels are groupings of permissions (Full Control, Contribute, etc.) while hierarchical levels, such as the ones discussed here, refer to the depth of control. Items reside in Lists or Libraries, which reside in Sites, which are contained by Site collections, then web applications. Each of these objects can be referred to as levels (such as the Item level or Site level). So setting permissions at the List or Library level is referencing a hierarchy, while customizing permissions for the Read level is referencing a permission level.

In my example, the Tasks list contains a Security Test item which has been selected. See Figure 11.50.

Figure 11.50 The Security Test Item menu

On the dropdown menu, you can see the Manage Permissions option, which is the means to manage permissions on a single item. When you click it, you’ll get the Permissions: Security Test (where Security Test is the name of your Item) page, as shown in Figure 11.51.

Figure 11.51 The Permissions Item page

From this page, you can select the Actions menu, which has two items on it. Manage Permissions of Parent will allow you to manage the Lists permissions. To break inheritance choose Edit Permissions; you will again get the Warning dialog box that says you are creating Unique Permissions for the item.

After you click OK on the Warning dialog box, the Permissions page will redisplay. On it, you will be able to select a user (if you added one to the site collection without adding them to a group) or SharePoint group and modify their permission level for the items (including remove users or groups that are currently allowed to access this item). See Figure 11.52.

Figure 11.52 The Permissions page with selectable options

To modify a user or group’s assigned permission level, select that user or group and go to the Action menu and select Edit Permissions (you can also remove the selected users from this menu).

The next page that will appear is Edit Permissions: Item Security Test (where Security Test is the name of the item), shown in Figure 11.53. It will list the user or group you selected and their currently assigned permission levels. You can choose any available permission level for them, and that will assign them that level on this item. It will not affect any other items in the list. This is the item-level granularity that is available in Windows SharePoint Services 3.0.

Figure 11.53 Edit Permissions: Item Security Test

Planning User Access

Windows SharePoint Services user access takes a considerable amount of planning. Security starts at the web application level, affecting user access with permissions and policies. Then the effect trickles down to the site collections, sites, lists, and even list items. The top levels can affect the permissions and security of the lower levels, so it’s a good idea to know what settings are where when you are responsible for Windows SharePoint Services authorization.

Tip

AUTHORIZATION, NOT AUTHENTICATION. Remember that permissions are all about authorization, and control what a user is permitted to do on the site. Authentication has nothing to do with permissions as they pertain to Windows SharePoint Services.

User Access at the Web Application Level

The first place to plan user access and authorization is at the Web Application level. If you already have a web application that provides the exact configuration you need (from allowing or disallowing the correct permissions to enabling SSL), you may want to place your new site collections there. Otherwise you will need to create a new web application to provide the exact settings you require. The configuration of a web application is covered in Chapter 8, “Site Collections and Web Applications.’’

When planning user access, first examine these considerations at the web application level before moving lower down the hierarchy.

  • Allow Access to Anonymous Users   You may want to enable anonymous access. If anonymous access is allowed for the web application, site administrators can decide whether or not to grant anonymous access at the Site Collection, Site level, at a List or Library level, or to block it from sites, lists or libraries entirely. If anonymous access is prohibited at the web application, no enclosed sites can have anonymous users. If anonymous is enabled, each site collection can choose to enable it or not at their level.
  • Available Permissions   As discussed earlier you can enable and disable available permissions at the web application. When a permission is disabled at the web application, it is not available for any Permission Level on the enclosed site collections.
  • Policy for Web Application   You can create permission policy levels at the web application, just as you can create permission levels at site collection level. You can then apply those permission policy levels to a security principal (user or security group) directly for that web application, giving that security principal that level of permissions to all site collections in the web application, regardless of the site collections’ settings. These permission policy levels can be modified and customized just like permission levels for site collections. Creating a web application policy for a security principal will grant that user or security group the applied permission policy level to every site collection in the web application, even if they are never added to the site and do not appear in All People or All Groups. Policies can modify the effects of anonymous access as well. See Chapter 10, “Central Administration: Application Management,’’ for more information on Policies.
  • Additional Configuration   There are several other settings at the web application level that affect and define user access that can require a separate web application. For example, Alternate-Access Mapping, Kerberos, and SSL. These are related to how the user connects to the site and to authentication, but not necessarily to authorization and permissions. See Chapters 8 and 15 for more details.

User Access at the Site Collection Level

When a site collection is created, user access needs to be carefully planned. Finding the balance between ease of administration, performance, and the need to control specific permissions for individual items is important. If fine-grained permissions are used everywhere in your sites and subsites, you will spend significantly more time managing the permissions, and users may experience slower performance when they try to access site content (not to mention the potential problems with search displaying secured list items in the results—even if the user does not have the permissions to open it). When planning user access on a site collection, it is also important to follow the principle of “least privilege’’ when it comes to authorizing access to the site: Only give users the permission levels they need to use to accomplish their assigned tasks. It is generally a good idea to begin by using the standard groups (such as Site Members, Site Visitors, and Site Owners) and controlling permissions at the site collection level for the easiest administration experience. Most users will be best served by being members of the Visitors or Members groups. Always limit the number of people in the Owners group to those users who need to change the structure of the site or change site settings and appearance. You should design your site collections, and the collection’s sites, lists, and libraries with set groups for user permissions in mind.

If particular subsites, lists, libraries, folders, items, or documents contain more sensitive data and must be even more secure, you can then choose to break inheritance and create custom permissions. There is a big caveat though: there is no single page that shows a user’s personal permissions specific to lists, libraries, folders, items, or documents within a site. This means that it is difficult to quickly determine who has exactly which permissions on which objects, and it is also difficult to reset any fine-grained permissions in bulk.

Plan for Permission Inheritance

It is easiest to manage permissions when there is a clear hierarchy of permissions and inherited permissions. Managing permissions gets more difficult when some lists within a site have fine-grained permissions applied, and when some sites have subsites with unique permissions and some with inherited permissions. As much as possible, arrange site collections so their enclosed sites, subsites, lists, and libraries can inherit permission levels. Separate sensitive data into their own lists, libraries, subsites, or even a new site collection. Keep in mind that search can accidentally display secured list items in the results if security is too granular. Unless you intend to disable search for aspx pages, keep the fine-grained permissions as rare as possible. This will just make permission management easier on you.

Active Directory Security Groups

For easier user management, you should always assign permission levels to SharePoint groups rather than to individual users (although we have broken that rule for demonstration purposes a time or two in this chapter, this rule is still a good one to remember).

When adding members to the SharePoint group, look for an existing Active Directory security group rather than adding individual domain users to the SharePoint group.

If you can include the domain group itself and not the individual members of the group, Active Directory manages the users for you. This does mean you need to work with your Network Administrators to verify members of the Active Directory security groups.

Each organization sets up its Windows security groups differently, but often the existing Active Directory group structure will closely match your desired SharePoint groups. For those cases where you need unique groupings for Windows SharePoint Services, create a new SharePoint group and add the users individually.

Another example of exploiting the Active Directory user structure, if you decide that you want all users within your domain to be able to view the content on the site collection, you should consider adding all authenticated users, or the Domain Users security group, to the Company Site Visitors SharePoint group. This would give everyone in the domain the Read permission level for the site collection with very little effort.

Decide Which Groups to Use

Deciding how to organize your users and what permission levels to assign them is important in Windows SharePoint Services. You have already learned that Windows SharePoint Services has several default groups to help you organize your users based on their roles; however, you might have unique requirements that will cause them to fall outside the scope of the default SharePoint groups. Your first step should be to review the available default groups and then add additional groups if needed. SharePoint groups can be composed of many individual users, can hold security groups, or can be some combination of the two. SharePoint groups confer no specific rights to the site (their permission levels do that); they are merely a means to contain a set of users. Depending on the size and complexity of your organization, you can organize your users into a few, several, or many groups; the choice is yours.

The decision to create custom SharePoint groups is an organizational one. You should create custom SharePoint groups instead of using the default groups if any of the following situations apply:

  • You have more (or fewer) user roles within your organization than are apparent in the default groups.

  • If there are well-known names for unique roles within your organization that perform very different tasks. For the sake of familiarity, it may be a good idea to use those role names for the SharePoint groups.

  • If you want to preserve a one-to-one relationship between Windows security groups and the SharePoint groups.

Otherwise you can consider keeping the defaults and expanding on them. Or you could simply modify the existing defaults, such as changing the group name. Maybe Visitors doesn’t work for you; feel free to change it.

Decide Which Permission Levels to Use

Each SharePoint group needs to have a permission level assigned. Permission levels are designed to provide a general collection of permissions, covering a wide range of permitted actions. While SharePoint groups are role-based, permission levels are more task-based. However, they might not map exactly to your particular authorization needs. If the default permission levels do not exactly match the desired permissions for a SharePoint group, you can modify the permissions included in specific permission levels, or create custom permission levels.

The decision to customize permission levels is less straightforward than the decision to customize SharePoint groups. If you customize the permissions within a particular permission level, you must keep track of that change, verify that it works for all groups and sites affected by that change, and ensure that the change does not negatively affect your security or your server capacity and performance.

For example, if you customize the Contribute permission level to include the Create Subsites permission, contributors can create and own subsites, potentially creating large numbers of unused subsites. If you allow the Read permission level to keep the Create Alerts permission, all members of the Visitors group can create alerts, which might overload your servers.

You should copy and modify the default permission levels if either of the following applies:

  • A default permission level includes all permissions except a few that your users need to do their jobs, and you want to add those permissions (and they don’t allow more than you want the users to do).
  • A default permission level includes a few permissions that your users do not need. It is easy to deselect the permissions you don’t want the users to have.

Otherwise, if there is no existing permission level that is appropriate as a template, add a completely new permission level. Hopefully this chapter has given you an idea of how to better manage your users and their access to Windows SharePoint Services resources.

The Bottom Line

Define users and groups in Windows SharePoint Services   Windows SharePoint Services users are individuals with user accounts that can be authenticated by a server that is running Windows SharePoint Services. Users can be stored in one or more groups. Windows SharePoint Services understands two types of groups: SharePoint groups and Domain groups.

  • Master It   Differentiate between the SharePoint group and the Domain group. Determine the preferred method for adding users to Windows SharePoint Services.

Add users and groups in Windows SharePoint Services   New SharePoint groups can be created to organize user access to websites. User accounts and domain groups from Active Directory can be added to the server that is running Windows SharePoint Services directly or by being placed into a SharePoint group.

  • Master It   If you add a domain group to a SharePoint group, and then later delete that SharePoint group, how do you apply a permission level to the domain group directly?

Define permissions and permission levels in Windows SharePoint Services   Authorization in Windows SharePoint Services is handled by 33 distinct permissions. These permissions provide user access to lists, sites, and personal settings. They also determine if the user’s access is restricted to simply reading or browsing, can allow editing of objects, or even permit creation of new objects.

Permission levels are simply groups of permissions. A permission level can contain any or all of the 33 permissions, and can depend on prerequisite permissions. The permission level is then applied to SharePoint groups to provide authorization to members of that group. They can also be applied directly to users and security groups.

  • Master It   Describe what the Manage Permission permission does and what dependant permissions it requires. What permission level contains manage permissions by default?

Set Permissions on a Site/List/List item for a user or a group   Permission Levels are assigned to SharePoint groups, domain groups, or individual users starting at the Top-level site of the site collection. By default, these users and groups (along with their assigned permission levels) propagate throughout the site collection using permission inheritance. You can go to any object (site, list, library, or item) in the site collection and break inheritance, adding users and groups to the object manually, and then give them different permission levels.

  • Master It   If you break inheritance on a subsite of the main Company Site and start using custom permissions for that subsite, do the lists on the subsite retain their original permission settings from Company Site, or do they also gain the custom permissions set on the subsite?

Plan user access in Windows SharePoint Services   Planning user access for Windows SharePoint Services needs to be done from the top down. Start with the web application and move down the hierarchy, changing the user access settings, authorized users and groups or permission levels only where needed. Before placing a new site collection into an existing web application, confirm the new site collection requires the same security settings as the existing site collections in that web application. Before adding a new site to a site collection, determine if the inherited groups, users, and permission levels are desired, or if a new site collection would be more appropriate. Try to balance the ease of administration that inheritance provides with the granular control of custom permissions.

  • Master It   Which is the better option?

    1. Permitting anonymous access at the Web Application level, and then enabling anonymous access to a select few site collections within the web application.

    2. Denying anonymous access at the Web Application level, and then enabling anonymous access to a select few site collections within the web application.

Additional Resources

For more information, see the following resources: