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

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.

Contents

• What Are Users, Groups, and Permissions?

• Individual Permissions

• Permission Levels

• Users and Groups

• Additional Resources

Controlling user access is a fundamental concern to SharePoint Administrators and it is where they earn a lot of our bread and butter. I mean, really, what good is Windows SharePoint Services if no one can use it? But nothing is worse than having users unable to get to the information they need or allowing someone to get to information that they are not supposed to see. Access management is a prime area of focus in the administrator’s life, if you plan and implement user access correctly, life goes much more smoothly. Windows SharePoint Services 3.0 user security is improved over the previous version with a finer level of granularity and more authentication options.

In this chapter, you’ll learn how to:

• Define users and groups in Windows SharePoint Services

• Add users and groups in Windows SharePoint Services

• Define permissions and permission levels in Windows SharePoint Services

• Set Permissions on a Site/List/List item for a user or a group

• Plan user access in Windows SharePoint Services

What Are Users, Groups, and Permissions?

When you start looking at security, chances are good that you start with the basics: who is allowed to access Windows SharePoint Services resources, what resources are they allowed to see, what resources are they allowed to use, and how are they allowed to use them.

The people who are allowed access to Windows SharePoint Services are commonly referred to as users. To add user accounts, Windows SharePoint Services utilizes the services of an authentication provider, such as Windows integrated Authentication (which on a domain uses Active Directory, on a stand-alone server it is that server’s security account manager database). Active Directory Directory Services stores its own user accounts, and people use it to log into their workstations to access network resources all the time. Windows SharePoint Services uses that authentication source for user accounts when setting up users in its own environment, which allows administrators to use accounts already available in Active Directory to populate its users and group. And, when a user logs into Windows SharePoint Services, it passes the authentication information to the authentication provider. If that account is okay with the provider and they authenticate it, then Windows SharePoint Services either lets the user get to the site they are trying to access, or if the account is not a member of the site, they are rejected. Once there, Windows SharePoint Services uses groups, permission levels, permissions, and other security to authorize the user to access the resources they were meant to, and blocks access to those they weren’t.

This is why the term “user account’’ is used in two ways:

• Domain user accounts refer directly to the accounts in Active Directory.

• SharePoint user accounts refer to the user accounts added to Windows SharePoint Services from Active Directory (or other authentication source).

Windows SharePoint Services manages what a user account can do with permissions. There is a large list of set permissions that are available at the web application level. These permissions, when applied to a user account, govern what it can do. Permissions are generally grouped together in what are called permission levels, to be applied to users based on the type of role they will play, or tasks they will perform in Windows SharePoint Services. There are a few default permission levels, such as full control (which usually is applied to administrators who require all permissions to be enabled), or contribute (which is usually applied to users who will be viewing content, adding content, editing content, etc.). Individual permissions can’t be applied to users directly, but permission levels can.

For the convenience of administrators, in addition to permission levels putting together useful permissions into role based combinations, Windows SharePoint Services uses another convention; the SharePoint group (sometimes known as a site group). SharePoint groups are useful because they are associated with particular permission levels (or even combinations of permission levels if necessary), so when the users are added to the group they are all given the same permissions. Changing a group’s permissions changes them for all users contained therein. Groups are an excellent organizational device (which is why Microsoft keeps using them), allowing users to be grouped together by applied permissions so they can all be added to a resource’s access list in one go (and removed that way as well). In addition, Windows SharePoint Services has a People and Groups page that displays the users in a particular group. Members of the group can go to that page and see the other members and access their user information (if they have permission to). If Directory Management Service is enabled, the group can have a distribution list associated with it in Active Directory, allowing someone to email all members of the group at once.

You can add users individually to SharePoint groups, or you can take advantage of Active Directory by adding entire security groups (such as adding the Sales_Dept security group as members of the Sales site collection). This is a good thing from a Windows SharePoint Services administrative point of view, because Windows SharePoint Services can only handle so many security objects (otherwise known as security principals). As far as Windows SharePoint Services is concerned, both a single user account and a security group are security objects, even though the security group can contain many user accounts. Using security groups to add users to SharePoint groups does add an extra layer of administration, because any change to that security group in Active Directory (such as removing a user) could have an obvious affect on whether or not that user can access Windows SharePoint Services. However, if you focus on managing users in groups at the Active Directory level, then it’s a snap to simply add their security groups to Windows SharePoint Services and not really worry about the individual users and whether or not they’ve been demoted, promoted, or fired at that level. The changes occur in Active Directory and then are reflected in Windows SharePoint Services. All this talk of groups leaves you with two different kinds of groups to consider:

• Domain security groups, created and controlled by the Active Directory administrators. A domain security group contains users and is a method for applying security uniformly to all users it contains.

• SharePoint groups, controlled, and that can be created by site collection administrators in Windows SharePoint Services. Intended to more easily apply permissions to groups of users at once. Secondarily, can be used to indentify contained users by the role they play in Windows SharePoint Services.

All Windows SharePoint Services groups are created at the site collection level and are available to any subsite in the site collection. However, you can choose to create a SharePoint group that has permissions only on a particular subsite, if you don’t want it to inherit permissions from the parent site. Although sites that are built on Windows SharePoint Services can, of course, have additional SharePoint groups, Windows SharePoint Services 3.0 provides three default SharePoint groups:

• Site name Owners (such as Company Site Owners, default permission level: Full Control)

• Site name Members (default permission level: Contribute)

• Site name Visitors (default permission level: Read)

Each of these Windows SharePoint Services groups is associated with a default permission level, but you can change the permission level for any SharePoint group as needed. Anyone who is assigned a permission level that includes the Create Groups permission can create custom SharePoint groups.

Before you start working with permissions or creating, editing, and changing groups, you need to clearly understand authentication and authorization. They are critical to a good fundamental understanding of security. Authentication is the process of establishing identity; in a security context, this is assessing the credentials of a user seeking access to resources under the control of the authentication provider. You can compare this to matching up someone’s face to the picture on their passport to make sure that they are the same. Authentication verifies that they are who they claim to be and you can proceed to the next stage, which is authorization. People frequently talk about authentication and authorization as if they were the same thing, but they most definitely are not. Authorization allows a user to do something with or to the resources their authentication gave them access to. It is the permission to do a particular task in a system, such as opening a page, reading a document, or managing permissions. All permissions make up the level of authorization for a user. That level of authorization can be considered a permission level inside of Windows SharePoint Services.

Permissions are the authorization to perform specific actions, such as viewing pages, opening items, and creating subsites. Windows SharePoint Services 3.0 provides 33 predefined permissions that you can use to allow users to perform specific actions. For example, users assigned the View Items permission can view items in a list. Each permission belongs to one of the following categories: List, Site, or Personal. Permissions are not assigned directly to users or SharePoint groups. Instead, permissions are enabled in one or more permission levels, which are in turn assigned to users and SharePoint groups. Permissions can be included in multiple permission levels, and it is possible to apply multiple permission levels to a single SharePoint group, user, or domain group. Permission levels will be covered later in the Permission Levels section.

Individual Permissions

Permissions are rights to do something; to view, create, delete, or edit something. Permissions are allowed or disallowed at the web application level using the User permissions for Web applications setting on the Application Management page, in Central Administration. Windows SharePoint Services breaks these permissions down into categories for assignment to users and groups. 33 separate permissions are divided across three categories (Site, List, and Personal). The following sections will describe them all. Table 11.1 is divided into four columns. The Permission Name is what appears on the pages where you select the permissions. The Description explains what the permission allows you to do. The Required permissions are additional permissions that the permission needs to have also enabled to function. The Permission Levels by Default lists the default permission levels containing this permission. This is also a useful guide to selecting or creating permission levels.

The permissions are shown Figure 11.1 and described in Table 11.1.

Figure 11.1 Permission Level List permissions

The List permissions govern the actions available to users in lists and on list items. You can combine them to reach your particular goals, but be careful about being overly gracious with what they are allowed to do, such as assuming that someone who needs to manage versioning and approve items should also Manage lists. Also, keep in mind that when you look at List permissions, they will be dependent on the choices made for the lists. For instance, View Versions will work only if you have Versioning turned on for the list; you could have permission to view versions but no ability to view them if versioning is turned off. Another interesting thing about the list permissions is that what you can do to a list item is broken out explicitly, but there are no explicit create list, delete list or change list permissions; they are all lumped under the Manage List permission. Therefore if you want someone to just be able to edit an existing list’s settings or add columns, they also have to be allowed to create more lists. Currently permissions are not quite as granular as they could be, and that alone is useful to know.

Table 11.1 List Permissions

Permission Name	Description	Required Permissions	Permission Levels by Default
Manage Lists	Create and delete lists, add or remove columns in a list, and add or remove public views of a list. This is the main control permission to allow control of the lists on the site.	View Items, View Pages, Open, Manage Personal Views	Design, Full Control
Override Check Out	Discard or check in a document that is checked out to another user without saving the current changes. This is actually a key administration feature, because it allows those who have the permission to effectively discard a check out and return the document to available status.	View Items, View Pages, Open	Design, Full Control
Add Items	Add items to lists, add documents to document libraries, and add web discussion comments. A Basic Member Level right, allowing the user to interact with the contents of the site.	View Items, View Pages, Open	Contribute, Design, Full Control
Edit Items	Edit items in lists, edit documents in document libraries, edit web discussion comments in documents, and customize Web Part pages in document libraries. A Basic Member Level right, allowing the user to interact with the contents of the site.	View Items, View Pages, Open	Contribute, Design, Full Control
Delete items	Delete items from a list, documents from a document library, and web discussion comments in documents. A Basic Member Level right, allowing the user to interact with the contents of the site.	View Items, View Pages, Open	Contribute, Design, Full Control
View Items	View items in lists, documents in document libraries, and view web discussion comments. To use any of the items on the site you must be able to view them first.	View Pages, Open	Read, Contribute, Design, Full Control
Approve Items	Approve minor versions of list items or documents. Versioning would need to be enabled for this to be in effect.	Edit Items, View Items, View Pages, Open	Design, Full Control
Open Items	View the source of documents with server-side file handlers. This allows the user to open the document in the source application, such as Word or Excel.	View Items, View Pages, Open	Read, Contribute, Design, Full Control
View Versions	View past versions of list items or documents. Versioning would need to be enabled for this to be in effect.	View Items, Open Items, View Pages, Open	Read, Contribute, Design, Full Control
Delete Versions	Delete past versions of list items or documents. Versioning would need to be enabled for this to be in effect.	View Items, View Versions, View Pages, Open	Contribute, Design, Full Control
Create Alerts	Create email alerts, so that the user can be notified via Outlook that something has changed in the item.	View Items, View Pages, Open	Read, Contribute, Design, Full Control
View Application Pages	View forms, views, and application pages. Enumerate lists. This allows you to open and use any pages, which is basic to all other functions.	Open	All

The second category of permissions is Site permissions. These permissions govern the user’s access at the site and subsite level and what they can do concerning sites there. The permissions for the SharePoint site are shown in Figure 11.2 and described in Table 11.2.

Figure 11.2 The SharePoint Site permissions

Table 11.2 SharePoint Site permissions

Permission Name	Description	Required Permissions	Permission Levels by Default
Manage Permissions	Create and change permission levels on the website and assign permissions to users and groups. This permission enables control of other permissions. It is typically reserved for administration-level people.	View Items, Open Items, View Versions, Browse Directories, View Pages, Enumerate Permissions, Browse User Information, Open	Full Control
View Usage Data	View reports on website usage. A key method of gathering metric data on the site. This permission is typically reserved for administration-level people.	View Pages, Open	Full Control
Create Subsites	Create subsites such as Team sites, Meeting Workspace sites, and Document Workspace sites. This permission deals with the structure of the site and should be reserved for administration-level people to allow for the tightest control of the environment.	View Pages, Browse User Information, Open	Full Control
Manage Web Site	Perform all administration tasks for the website and manage content. This permission is the high-level control permission that gives full administration control to the holder.	View Items, Add and Customize Pages, Browse Directories, View Pages, Enumerate Permissions, Browse User Information, Open	Full Control
Add and Customize Pages	Add, change, or delete HTML pages or Web Part pages, and edit the website by using a Windows SharePoint Services–compatible editor, such as SharePoint Designer. This permission enables more site changes.	View Items, Browse Directories, View Pages, Open	Design, Full Control
Apply Themes and Borders	Apply a theme or borders to the entire website. As this permission deals with presentation and design, it is not restricted to administration-level people but should also include the designers and developers.	View Pages, Open	Design, Full Control
Apply Style Sheets	Apply a style sheet (css file) to the website. As this permission deals with presentation and design, it is not restricted to administration-level people but should also include the designers and developers.	View Pages, Open	Design, Full Control
Create Groups	Create a group of users that can be used anywhere within the site collection. This is a security-based permission that will allow control of access to the site. This is administration level.	View Pages, Browse User Information, Open	Full Control
Browse Directories	Enumerate files and folders in a website by using Microsoft Office SharePoint Designer and Web DAV interfaces.	View Pages, Open	Contribute, Design, Full Control
Use Self-Service Site Creation	Create a website by using Self-Service Site Creation. This permission allows users to create a site. This permission is only active if Self-Service Site Creation is enabled on the web application, otherwise it is ignored.	View Pages, Browse User Information, Open	Read, Contribute, Design, Full Control
View Pages	View pages in a website. This permission is for everyone.	Open	Read, Contribute, Design, Full Control
Enumerate permissions	Enumerate permissions on the website, list, folder, document, or list item. This is a security-based permission that will allow control of access to the site. This is an administration-level permission.	Browse Directories, View Pages, Browse User Information, Open	Full Control
Browse User Information	View information about users of the website. This permission allows users to discover public information about other users and engage in social networking.	Open	All
Manage Alerts	Manage alerts for all users of the website. This is an overriding permission to the List Permission Create Alerts permission. It allows the administrator to change what other alerts are doing.	View Items, View Pages, Open	Full Control
Use Remote Interfaces	Use SOAP, Web DAV, or Office SharePoint Designer interfaces to access the website. This permission just allows external access to the site from other Windows SharePoint Services component pieces.	Open	All
Use Client Integration Features	Use features that launch client applications. Without this permission, users must work on documents locally and then upload their changes. This permission enables the web-enabled collaboration that is the heart of Windows SharePoint Services 3.0.	Use Remote Interfaces, Open	All
Open	Open a website, list, or folder to access items inside that container. This one is needed for almost all other permissions to function.	None	All
Edit Personal User Information	Users can change their own user information, such as adding a picture. This permission is the one that allows users to make public the information others might browse if they have the Browse Information permission.	Browse User Information, Open	Contribute, Design, Full Control

Site permissions are the basis of control at the site level. Combinations of these permissions are what define user’s effective control of their environment. This category of permissions contains powerful, administrative capabilities, such as managing permissions and seeing site usage information, versus the ability to open documents using the correct client or see document libraries using webDAV (Explorer View) for users.

As a matter of fact, if a user cannot use Explorer View, make certain they have the Use Remote Interfaces permission. Despite the fact that that permission also makes it possible for them to open the page in SharePoint Designer, it’s needed for all browsing of libraries with Explorer.

The third category of permissions is Personal permissions. The Personal permissions from the SharePoint site are shown in Figure 11.3 and described in Table 11.3.

Figure 11.3 The SharePoint Personal permissions

Personal permissions deal with an individual user’s view of the website, including being about to manage their own personal view of lists, libraries, and web part pages (particularly the home page). Unfortunately, if you allow users the permission to change web parts, intending to let them personalize the home page, they can also modify web parts on the list and library pages as well. So consider carefully the ramifications of what personalizations you allow them to do.

Permissions, individually, are never applied to users or groups. Instead Permission levels are created by making combinations of these permissions, and those permission levels are applied to users and groups. Therefore, it is only fitting that we take a look at permission levels next.

Table 11.3 SharePoint Personal Permissions

Permission Name	Description	Required Permissions	Permission Levels by Default
Manage Personal Views	Create, change, and delete personal views of lists.	View Items, View Pages, Open	Contribute, Design, Full Control
Add/Remove Personal Web Parts	Add or remove personal web parts on a Web Part page.	View Items, View Pages, Open, Update Personal Web Parts	Contribute, Design, Full Control
Update Personal Web Parts	Update web parts to display personalized information.	View Items, View Pages, Open	Contribute, Design, Full Control

Permission Levels

Permission levels enable you to assign a set of permissions to users and SharePoint groups so that they can perform specific actions or tasks on your site. Most permission levels (and SharePoint groups for that matter) are role related, aligning the set of permissions with a task that must be performed. With permission levels, you can control which permissions are granted to users and SharePoint groups on your site. For example, by default, the Read permission level includes the View Items, Open Items, View Pages, and View Versions permissions (among others), all of which are needed to read documents, items, and pages on a SharePoint site.

The following permission levels are provided by default: Full Control, Design, Contribute, Read, and Limited Access. Anyone assigned a permission level that includes the Manage Permissions permission can customize permission levels (except for the Full Control and Limited Access) or create new ones. Site owners are assigned the Manage Permissions permission, by default.

The defaults each have their own uses and purposes, which are described in Table 11.4.

As you look at the levels and try to decide what to do with them, remember you always want to give the minimum amount of permission to do a task that the user will need. You can see in the table that each succeeding level has all the permissions of the level before it and then adds more. You cannot directly edit either the Full Control or Limited Access permission levels, the two far ends of the spectrum, but they can be changed at the Web Application level in the Central Administration tool.

Table 11.4 Windows SharePoint Services 3.0 Default Permission Levels

Permission Level	Description	Included Permissions
Limited Access	This level is designed to be combined with fine-grained permissions to give users access to a specific list, document library, item, or document, without giving users access to the entire site. This level allows very focused control of access. Cannot be customized or deleted.	View Application Pages, Browse User Information, User Remote Interfaces, Use Client Integration, Features Open
Read	Read-only access to the website. This is a default for <<Site name>> Visitors group. Not intended to add, edit, or delete items, or be able to personalize their views.	Limited Access permissions plus: View Items, Open Items, View Versions, Create Alerts, Use Self-Service Site Creation (when enabled at web application), Browse User Information, View Application Pages, User Remote Interfaces, Use Client Integration, Features View Pages
Contribute	Can add and edit items in existing lists and libraries, and personalize page views. This is a default for <<Site name>> Members group. Not intended to manage lists, create subsites, or manage permissions.	Read permissions plus: Add Items, Edit Items, Delete Items, Delete Versions, Browse Directories, Edit Personal User Information, Manage Personal Views, Add/Remove Personal Web Parts, Update Personal Web Parts
Design	Can create (and if necessary, manage) lists and document libraries, and edit pages in the website. This would generally be used for modifying the look and feel of your pages in the site. Cannot create or manage groups, alerts, sites, or permissions.	Contribute permissions plus: Manage Lists, Override Check Out, Approve Items, Add and Customize pages, Apply Themes and Borders, Apply Style Sheets, User Remote Interfaces, Use Client Integration, Features Manage Lists
Full Control	Has all permissions enabled. Specifically, can manage and create sites, permission levels, alerts, groups, and view usage data. This is the default for <<Site name>> Owners group. Cannot be customized or deleted either. Required for full site management.	All permissions without restriction

As you look at the levels and try to decide what to do with them, remember you always want to give the minimum amount of permission to do a task that the user will need. You can see in the table that each succeeding level has all the permissions of the level before it and then adds more. You cannot directly edit either the Full Control or Limited Access permission levels, the two far ends of the spectrum, but they can be changed at the Web Application level in the Central Administration tool.

Removing a Permission Removes it Completely

Now that you know about permissions at the web application level you can see another reason why a web application is considered a security boundary. Not only can each web application specify its own authentication, anonymous access, or whether or not it uses SSL, but it can also control exactly what permission are or are not available for all site collections contained therein.

If you disable a permission at the web application level, at the site collection level absolutely no permission level will have that permission available (not even Full Control).

Manage Permission Levels

Now that you’ve seen the out-of-the-box permission levels, you might need to do some customization. The Read, Design, and Contribute permission levels can be copied or modified, and otherwise new permission levels can be created for a site. In other words; you can use the pre-made permission levels as they are; you can use those levels but modify them; you can copy those levels, then modify the copy; or you can apply your own and ignore the default levels (with the exception of Limited Access). For example, if you have a server with a large number of users and groups assigned the Read permission level and you decide you want to restrict these users further (or give them more control), you can edit the Read permission level to provide the precise combination of permissions desired, without having to give all these users a new permission level. On the other hand, if you create a new site, or want to add a lot of new users with unique permission needs to an existing site, you can create a new permission level with the correct permissions; either by using an existing level as a template or by creating one from scratch. Permission levels were meant to be easy to manage; as long as you know what the individual permissions actually do (particularly in combination) you can have a lot of control over your Windows SharePoint Services resources, and therefore over your users.

Permission levels are most often modified at the site collection’s top-level site and then inherited by the subsites below it. So most of the exercises will be done at the top-level site of the site collection (which in my case is Company Site). Be aware that you can break inheritance at any subsite, where they then can do as they wish with their SharePoint groups and permission levels at that point.

Viewing Site Permissions

To work with permission levels, you must get to the Permissions page for the site. Both the Advanced Permissions link in Site Settings for the site, and the last option on the Quick Launch bar, Site Permissions, will take you to the Permissions page. This page (Figure 11.4) will allow you to see all the groups and security principals on your site to which permission levels have been assigned directly, what those permissions are, and the type of object they are (user, SharePoint group, etc).

Figure 11.4 The Permissions page

Typically this list will simply be a list of your SharePoint groups only, but it can also contain individual user accounts or security groups as well. During the adding of a new user, if you had elected to assign permissions to the new user or domain security group directly (instead of adding them to a SharePoint group), they would then appear in this list. This is because, usually, user permissions are managed for the users in their respective groups, but if you apply a permission level directly to the account, they need to be listed somewhere so they can also be managed. Site Permissions is the last bastion of hope for them in that case.

On a Permissions page for the site (my example is the top-level, Company Site), the standard Quick Launch bar is moved down and the Groups Quick Launch bar replaces it on the top left of the page. This bar lists the SharePoint groups available on this site; a More... link, which takes you to a page listing all groups (including, oddly enough, any security groups you might have added to any SharePoint groups); an All People link which lists all users for the site, regardless of their group affiliation; and a Site Permissions link, which takes you to, conveniently, to the Permission page you are on now.

The Action bar has the standard three buttons; New, Actions, and Settings.

• New allows you to add either a new user or a new group.

• Actions allows you to either edit or remove the permissions of a selected group.

• Settings allows you to manage site collection administrators, enable or disable access requests, and configure permission levels.

Access Requests

Access Request is generally enabled by default, is a site level feature, and allows users to, when faced with a denial of access, if it’s a missing menu item or a blocked list item, click Request Access in the Welcome menu, but if they are completely denied access to a list, library, or subsite; an Access Denied page will come up with a link to request access available for them.

If they click it they can request access and send the request. It is obviously up to the user to explain what they need access to and why they need that access.

According to the menu option, the request will be sent to the site administrator, but actually it will be send to the address in the Access Request Settings section. This address is by default is the original site collection administrator, but it can be changed.

This feature is a double-edged sword. It lets you know what lists, libraries, or subsites users would like to use, but it is also frustrating if they are denied access for a good reason that will not change. Obviously those requests for access can be disabled on the site level by going to the Permissions page, Settings menu, Access Requests.

Edit an Existing Permission Level

To customize an existing permission level you take a permission level that is almost what you need and you edit it. You can include or exclude specific permissions as necessary. Editing an existing permission level will replace the existing level with your new permission level. Although I prefer to create a copy of the original and work with that, there may be times when your company requires that there be as few permission levels as possible, requiring that you modify the existing levels to better suit your needs.

Doing this will require a few steps:

1. Navigate to the Permissions page for the site (such as going to the Site Settings page for the site, then clicking on the Advanced Permissions link in the Users and Permissions category).

2. On the Action bar, select Settings ➢ Permission Levels (see Figure 11.5).

   Figure 11.5 Select Permission Levels

   

3. In the list of permission levels, click the name of the permission level you want to customize. This example uses the Read level (see Figure 11.6).

   Figure 11.6 Choose the Read level

   

   When you click on the permission level, the Edit Permission Level page opens (see Figure 11.7).

   Figure 11.7 Edit the current permission level

   

4. On the Edit Permission Level page, enter a name for the modified permission level in the Name box (see Figure 11.8). While changing the name of the level is not required, it is recommended so you can easily see the permission level has been modified from the default. My example uses, imaginatively enough, Modified Read.

5. Adjust the permissions that are applied to this permission level, adding or removing select permissions until Modified Read provides the exact permissions you desire. This will change the permission level, and any user or group with this permission level assigned will receive the new permissions (my example adds the Edit Items permission).

   Figure 11.8 The modified name

   

6. Click Submit at the bottom of the page, and the modified permission level will be saved. This will overwrite the Read permission level with the new Modified Read permission level.

Copy an Existing Permission Level

As I mentioned, the preferred method of modifying a permission level is to copy and modify an existing one. If the custom permission level that you want is similar to an existing default permission level, and you need to use both the default permission level and your custom permission level, you can copy the default permission level, modify the copy, and save it as a new permission level.

To do this, follow these steps:

1. Get to the Permissions page whatever way you choose; by using the Quick Launch bar ➢ People and Groups ➢ Site Permissions; or on the Site Settings page, under Users And Permissions, click Advanced Permissions.

2. On the Action bar in the Permissions page, select Settings ➢ Permission Levels.

3. In the list of permission levels, click the name of the permission level you want to copy (see Figure 11.9). My example will copy Modified Read, since we are already familiar with it.

   Figure 11.9 Choose the Permission level to copy

   

4. At the bottom of the page, click Copy Permission Level (see Figure 11.10). This will display the Copy Permission Level page (see Figure 11.11).

   Figure 11.10 Select the Copy Permission level

   

   Figure 11.11 The Copy Permission Level page

   

5. On the Copy Permission Level page, enter a name in the Name box for the new permission level. My example uses New Read.

6. In the Description box, enter a description for the new permission level.

7. From the list of permissions, select or clear the checkboxes to add permissions to or remove permissions from the permission level. As you may remember, some permissions have prerequisites, so pay attention to what you enable.

8. To create your new custom, copied permission level, click Create at the bottom of the page.

By using this method, you have created a new permission level while keeping the existing one in place, allowing you to use both permission levels in the site collection.

Create a New Permission Level

Creating a permission level from scratch is a good idea when none of the existing permission levels are close to what you need. You can create a permission level that will include exactly what you require. To create a brand new level, follow these steps:

1. Navigate to the Permissions page. For example, on the Site Settings page, under Users And Permissions, click Advanced Permissions.

2. On the Action bar in the Permissions page, select Settings ➢ Permission Levels.

3. On the Action bar, click Add A Permission Level (see Figure 11.12).

   Figure 11.12 The Permission Levels page

   

4. In the Name box on the Add A Permission Level page, enter a name for the new permission level (see Figure 11.13). My example will be a new permission level for List managers.

   Figure 11.13 The Add a Permission Level page

   

5. In the Description box, type a description for the new permission level.

6. In the list of permissions, select the checkboxes to add permissions to the permission level. If you want to create a level with almost Full Control, click Select All and then uncheck the permissions you want to remove. You can create as flexible a structure as you would like, but you should plan for consolidation because permission levels that are custom created are often duplicates of others already in the system. In my case I am enabling all of the list permissions to allow the list managers to freely work on lists in whatever capacity they require.

7. Click the Create button at the bottom to create your custom level.

At this point you know how to check the current permission levels of your sites to see what permissions they actually have; how to modify existing permission levels (and which you can’t); how to create copies of existing permission levels for customization; and finally, you know how to create your own permission levels to combine exactly the permissions you want into a permission level.

Users and Groups

Now that you understand the foundation of permissions in Windows SharePoint Services, it’s time to start looking at them inside the SharePoint site collection.

When adding users to Windows SharePoint Services, Microsoft recommends you add Active Directory security groups (domain groups) to SharePoint groups rather than individual users as much as possible. Windows SharePoint Services has a limit of 2,000 security principals (users and groups) for a website. According to Microsoft, going beyond this limit has not been tested and could cause performance issues. However, adding Active Directory security groups allows the number of supported users (assuming they are all in no more than 2,000 Active Directory security groups) to scale to 2 million.

Adding domain groups rather than individual users provides another distinct advantage: ease of administration. Rather than having to manage users in two places, you only need to manage Active Directory group membership.

For example, you can add all the managers in your organization to a Managers security group in Active Directory, then add that domain group to a Managers group that you created. You want these managers to have read and write access on the Sales Events subsite, read-only access on the Accounting subsite, and full control access on the Management subsite. You can accomplish this by adding the Managers Active Directory security group to a Managers group on the top-level site, then assigning the permissions you want for the Managers SharePoint group separately on each subsite. As managers join the team, you add them to the Managers Active Directory security group, the way you normally would without Windows SharePoint Services on the network. This automatically makes them part of the Managers SharePoint group, without having to manually add them to Windows SharePoint Services as an individual user. There is also no need to specify the permissions they have on different sites, because you have already assigned the permissions you want to the Managers SharePoint group for all three sites. If the manager leaves or gets transferred, you just remove the user account from the Managers Active Directory security group. And they will no longer be a member of the Managers SharePoint group. On the other hand, if you choose to add each manager directly to a site instead of using a domain group and a SharePoint group, you must assign each manager the appropriate permissions on each of the three sites. If they then change job roles in the company, you need to manually change their permissions for each site.

Editing Site Administrators

Before we get started with viewing, modifying, and creating groups, site administrators should be mentioned. When a site collection is created, you are given the option to enter primary and secondary user accounts for site collection administration. However, once the site collection is up and running, you can add more site collection administrators. And this is where it’s done.

Site collection administrators not only have full control permissions to the site collection, but they are considered responsible for the site collection in Central Administration and are the primary contacts for notification about the site collection. Ironically however, site collection administrators are not members of the Owners SharePoint group (except for the account assigned at the creation of the site collection), despite their having full control of the site. They stand apart from the real members of the site collection.

To get a look at the existing site collection administrators and make changes to the list if necessary, follow these steps:

1. From the home page of your site, go to Site Actions and choose Site Settings. The Site Settings page will appear (see Figure 11.14).

   Figure 11.14 The Site Settings page

   

2. By now this page is probably pretty familiar to you. You are going to be looking at the first column of course; Users And Permissions. It has three links underneath it: People And Groups, Site Collection Administrators, and Advanced Permissions. We’ve seen where the Advanced Permissions goes, now it’s time to explore the other two links.

3. Go ahead and click the Site Collection Administrators link to open that page (see Figure 11.15).

   Figure 11.15 The Site Collection Administrators page

   

   This page shows you the account (or accounts if you have a secondary) that are the current administrators. My example shows my default user, “sharepoint admin” (share admin).

4. If you wanted to add another administrator or two, you could type in their Active Directory user account names (separated by semicolons) in the people picker field, or you could click the Browse button, which looks like an address book, and use the Select People page to find the correct account. The Select People page (as well as the people picker) pulls accounts from the authentication source configured for the web application. In my case, if I were to type in a user name (see Figure 11.16), and click Find, the page will query Active Directory for the account name, and return accounts that match. From the list of found people (I have only one match), you can select the one that you want and click Add at the bottom of the page, then click OK to add the user to the site collection administrators people picker field. Remember, once the account is added to the people picker field on the Site Collection Administrator’s page, to click OK there as well to keep the change.

   Figure 11.16 Select People page

   

Viewing People and Groups

Now that you have seen where you can go to add site administrators, let’s visit the People and Groups page and see where you go to manage user accounts. Either make certain you are on the Site Settings page and click on the People and Groups link or, if you are on a page that has a Quick Launch bar, click on the People and Groups link there. Either way, find you way to the People and Groups page (see Figure 11.17).

Figure 11.17 The People and Groups main page

This page is essentially a list of the people and groups for the current site and generally defaults to displaying the users in the Members group (Saffron is there in my example because we added her in chapter 2). It allows you to manage the users in the groups as well as manage the groups themselves. On the Group Quick Launch bar, you can see the three default groups that Windows SharePoint Services added to the site: Company Site Members, Company Site Visitors, and Company Site Owners. The Company Site Owners SharePoint group has the Full Control permission level assigned, the Company Site Members SharePoint group has been assigned the Contribute permission level, and the Company Site Visitors SharePoint group has the Read permission level assigned.

The action bar for the People and Groups page generally relates to the group it is displaying, except for the New button.

The New button for any group offers the choice of creating a new user or a new group. Both of these open to the respective New object page, regardless of what page you chose them from.

The Actions button for the People and Groups page offers:

• Email Users: opens the local email client and using the email address in the user’s information, prepares an email message to the selected user(s). All of these options are plural because you can select more than one user at a time.

• Call/Message Selected Users: requires a SIP (session initiation protocol) address in the user information of the selected users, but will try to place an online call to the intended users. Requires additional configuration.

• Remove Users from Group: This option will delete the selected user (or security group) from the group. However, that user will stay in the all people list for the site, they just won’t have any permissions applied to them. They will have to be added to back to the site so they can have permissions applied to them again.

The Settings button for the People and Groups page offers:

• Group Settings: This page lets you edit the Group’s settings with a page almost exactly like the one we will use to create groups. It allows the name, description, group owner, who can view the group, whether users can request membership, and permissions to be edited.

• View Group Permissions: This will trigger a popup window that will conveniently show the URLs of the site collection that this group has access to, as well as what permissions are applied to the group there. In addition, if there are any subsites that are not inheriting permissions, but are using the group, they will appear in the list as well. I broke inheritance with the tech support wiki site in this example, and as you can see in Figure 11.18 it is listed separately.

  Figure 11.18 View Group Permissions

  

• Edit Group Quick Launch: From any of the Group pages in People and Groups, this settings is available. This makes it possible to remove (or add) a group to the launch bar, as well as rearrange them. The Edit Group Quick Launch page is not fancy; the groups are displayed in a text field, in order, separated by semicolons (See Figure 11.19).

  Figure 11.19 Edit Quick Launch page

  

• Set Up Groups: This page is actually pretty interesting, I’m not sure why it is here. It opens a page listing the three default groups, and the option to either use the existing default groups or create new ones (Figure 11.20). It is the page used for Self-Service Site creation to quickly add users to a new site collection. It is convenient at the subsite level if you want to add an existing default group to the level without having to re-establish inheritance with the parent site.

  Figure 11.20 Set Up Groups page

  

• List Settings: Because the Group page for people and groups is just a list (a very custom list, but a list nonetheless), you can. This option is available at the top-level site only.

Creating a New SharePoint Group

In Chapter 2, as one of the post configuration tasks, we added a user to the Company Site Members group, as an example. It’s easy to add users to existing SharePoint groups. But if you’d like to use a group that has different permission levels than the defaults, you’ll need to create it.

1. While you are on the People and Groups page click the New drop-down button on the menu (see Figure 11.21).

   Figure 11.21 The people and Groups New menu

   

2. Click New Group. This will allow you to add a new Group to the site. When you click it, the New Group Page will open (see Figure 11.22).

   Figure 11.22 The New Group page

   

   The top half of the page has several options that you can fill out:

   • The first option is the Group Name. Always use a unique name for the group. My example uses DemoGroup.

   • Directly under the Group Name is About Me, which is the description. My example uses Demonstration.

   • The next section for the group is Owner. The owner can be any user, SharePoint group, or domain security group. But keep in mind that owner is not plural, there can only be one item in that field, even if it is actually a group of users. The owner will have full control of the group by default. My example uses SharePoint Admin (shareadmin). The field will default to the user name of the person creating the group.

   • The next section is about the group members’ settings, specifically who can view the group members (only that group or everyone) and who can edit the group members (only the owners or all members). The defaults are as shown, with the group members being able to view group membership and the group owner being able to edit the group members. Those defaults are fine for this example.

     The bottom half of the page deals with the final options for the group, as shown in Figure 11.23.

     Figure 11.23 The bottom of the New Group page

     

   • The Membership Requests section is where you indicate whether or not you will allow requests to join or leave the group and whether or not you will automatically accept requests if they are allowed. The email address box is typically filled with the group owner or site administrator’s email address, although the request can be sent to anyone who has authorization to edit the group. The defaults are fine for our example also.

   • The Give Group Permission to this Site section is where you specify the permission levels for the group for the site to which the group is being added. My example assigns the new List Managers permission level for this group.

3. Once you have made all your entries, click Create and the group will be created and displayed (see Figure 11.24). By default, because a group cannot be empty of users, the owner/creator of the group is always the first member.

   Figure 11.24 The people and Groups New menu

   

Adding a Domain User or Domain Group to a SharePoint Group

The People and Groups: DemoGroup page indicates that the group has one member, in my case that is the SharePoint admin. To add new users, follow the steps below:

1. You can add new members by going back to the New button and clicking Add User.

2. The page shown in Figure 11.25 allows you to add a new user or domain group to the SharePoint group. The first entry box is the People Picker into which you can add usernames. The username can be any existing SharePoint user, Domain user or Domain group in the system. In this box, you can enter multiple users and domain groups separated by semi colons. You can enter the names in the format of Domain\UserName or Domain\GroupName, just use the friendly name for the user and have the people picker resolve it to the user name in Active Directory, or you could even use the email address listed for the user or group in Active Directory. My example adds the Active Directory security group dem0tek\managers and the individual user dem0tek\citrine.

   Figure 11.25 Adding a new user

   

   There is a link in the Add Users section to add all authenticated users for the authentication provider if you don’t feel like adding individuals. Generally all domain users are not added to Windows SharePoint Services in this way, but it is a way to add a lot of users at once, all without adding as many security principal objects. One NT AUTHORITY\Authenticated Users security group containing a hundred users is easier than adding them all by hand, and easier on Windows SharePoint Services than a hundred individual user accounts. Of course, we are not using this feature in this example.

   Tip

   CHECKING NAMES After each entry, it’s a good idea to check the name immediately so that you can confirm the name is valid before trying to add them to the group. You can use the Check Names button just below the entry box to verify that you typed the name correctly. In my example, dem0tek\managers has been checked; Citrine has not yet been checked. When checked, the entered user account will change to show a user’s full name. Checked names are also underlined.

3. Then choose the SharePoint group or permission level that the new user and domain group will use on the site. Typically, you will choose to add them to a SharePoint group. Because you were on the DemoGroup page when you clicked New User, it defaults to adding the user and domain group to that SharePoint group. If you don’t want to add them to a SharePoint group, you can directly apply a permission level to them. This is generally not recommended because you should use SharePoint groups to control permission levels. In this case, they were meant to be added to the DemoGroup, so keep the default.

4. The last dialog box can be used to send a welcome message to users to let them know they have been added to a group (Figure 11.26). My example leaves this option in place.

   Figure 11.26 Welcome message setting

   

5. Once you click OK, you will be taken back to the Group page (see Figure 11.27). It will have three members in the group: SharePoint admin, Citrine, and the dem0tek\managers domain group.

   Figure 11.27 The group has three members

   

Removing a Domain User or Domain Group from a SharePoint Group

You can also remove a user or domain group from the SharePoint group in case they have been added incorrectly, have changed job functions, or no longer need to have the SharePoint permissions granted to the SharePoint group.

1. To do this, select the user or domain group in the list, go to the Actions menu, and choose Remove Users From Group (see Figure 11.28). My example will remove Citrine, one of the newly added members.

   Figure 11.28 Remove a user from the group

   

2. You will get a dialog box warning you that you are about to remove members from the SharePoint group permanently (see Figure 11.29). Once you click OK, the user and domain group will be removed from the SharePoint group. The user will not be deleted from the site, just from the current SharePoint group membership.

   Figure 11.29 The Remove User Warning dialog box

   

Viewing All People

This page was meant to allow you to see all users who have ever had the permission to access the site, regardless of their group affiliation. This is a quick way to find a user, then see what group they belong to (or not if their group has been deleted; those users are considered orphaned).

On the People and Groups page, select All People from the Quick Launch bar on the left to list all of the users in the site (see Figure 11.30). This page will allow you to edit individual user information (such as their job title), but you will not be able to directly edit the user’s authorization. For example, on this page there is no way to add an existing user to a SharePoint group, or apply permissions directly to the user. However, from here you can delete users from the entire site collection rather than simply remove them from a SharePoint group. You will notice that Citrine, previously removed from DemoGroup, still exists in the site as a user object. But since she has no permission level assigned and is not a member of any SharePoint group she cannot log in. If you want to add her to another SharePoint group or to assign a permission level directly to her account you will need to go through the New User process again. There is no other mechanism to simply give her permissions, unfortunately.

Figure 11.30 The All People page

Domain security groups added to the SharePoint site do not show up in All People; only individual user accounts do. In order to see the added domain security groups, you need to view the All Groups page for the site. The All Groups page, shown in Figure 11.31, is reached by clicking the More… link in the Groups Quick Launch bar. Here you will notice that dem0tek\managers still exists.

Figure 11.31 The All Groups page

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

Additional Resources

For more information, see the following resources:

• Users, Groups, and Authorization

• Windows SharePoint Services Developer Center