Managing Access in SharePoint

As your SharePoint environment starts to become populated with important business documents, it’s important to manage access properly. Users who require information to do their jobs should be able to easily locate and then access information. In cases where you have sensitive information on the portal, it’s crucial that only users who have a business requirement to access it have the rights to do so. Because SharePoint will become a central storage location for important business information, it is critical that this information be protected. This means locking out those who could cause harm to the system or should not have access to information.

Understanding the SharePoint Membership Groups

A SharePoint site group defines the specific roles and permissions for users. By default, SharePoint has several groups, which vary depending on the type of site you create and the type of activities users perform on that site. The following list shows the different types of site groups that SharePoint has to offer and explains the purpose of each:

• Site Members:   Members can view, add, edit, or delete content in existing site elements, such as lists and document libraries. In a collaborative setting, team members in this group generally have no reason to create new instances of lists or libraries but participate by constantly adding and reading existing content. This is the group that most closely resembles the “Contributor” role from WSS version 2 and SharePoint Portal Server 2003.

• Viewers:   Members can only view pages, documents, and list items and have limited options in the File drop-down menu (see Figure 9-4). If an application exists to handle file viewing, members of this group can access files via that application. For example, if a member of a group opens a spreadsheet stored in a reports library using Excel Services, that person can view the spreadsheet through the browser rather than via Excel.

  
  Figure 9-4

• Site Visitors:   Users in this site group have read-only access to site content. This group most closely resembles the “Reader” role from WSS v2 and SharePoint Portal Server 2003.

• Site Owners:   Member have complete control over a specific SharePoint site. Members can create new content elements and subsites, and specify access and permissions for other users. This most closely resembles the “Administrator” role from WSS v2 and SharePoint Portal Server 2003.

• Designers:   This represents users who contribute and approve content, create new content elements, and customize the site’s presentation through page templates and style sheets. This group is specific to sites that have the Publishing feature enabled.

• Hierarchy Managers:   Members can create new lists, edit pages, and add content to existing lists, but also create and manage subsites. This group most closely resembles the “Web Designer” role from WSS v2 and SharePoint Portal Server 2003.

• Approvers:   Members have permission to edit, create, and approve content. Members of this group can decide whether to approve or reject documents or list items. Items pending content approval are not seen by users unless this group, or someone with equal rights, approves it.

• Restricted Readers:   Members of this group can access the latest versions of published content but cannot view the historical versions or view any information on who has access to the content.

• Quick Deploy Users:   Specific to the content deployment functionality, members can publish content using the Quick Deploy method. Typically only a site owner can do this.

Tip 

The Quick Deploy User makes use of the content deployment functionality of SharePoint 2007, which is a function of the Publishing feature and Web Content Management (WCM), discussed in Chapter 13.

Working with Site Groups and Permission Levels

Now that you have an understanding of the various SharePoint 2007 site groups, let’s take a look at some of the ways you can manage access to the content stored with sites by working with the site groups and permission levels. This section looks at how you can create your own site groups as well as change the access rights of a user by adding them to a site group or changing their existing permissions. You also learn how to control how users request access changes related to your site.

If the site groups listed in the previous section do not meet your specific requirements, you can create your own groups with the specific rights and permissions. For example, if you want a group where users can view, add, and edit content, but you don’t want them to delete content, you can create a site group called “Limited Member” with that restriction. Although you can edit the permissions level of a standard group, this is generally not recommended unless you intend to do so for the group across all sites in your server farm. Minor changes to the default settings can be difficult to identify later as the environment grows and may lead to improper assumptions on who has access to do what. In cases where you require a slight modification to an existing site group, it’s better to copy the group and make the changes to the copied version.

In the next set of Try It Outs, you create a group that is very similar to the Members group; however, you name it “Limited Membership” to identify that it was slightly different than the default Members group. You then add the new team members to your site groups. If you find later that you need to change permissions on a group or user that you’ve already created, or totally delete a user altogether, you learn to do so in the third and fourth Try It Outs. In the last Try It Out of the section, you find out how to enable access to a site when a user requests it.

Try It Out-Create a New Site Group

In this example, you create the specific permission level, which allows users to create new content and edit existing content but prevents them from deleting documents. Existing permission levels do not separate content editing from content deleting. You will notice that selecting the rights to edit content automatically enables the rights to view items and pages because these additional abilities are required to edit content. Once you define a permissions level, you can create a new site group to use it. Separating the group and a permissions level allows one or more groups to use a single set of permissions, which gives you greater flexibility and control and is therefore the recommended practice when defining new permissions.

This example assumes that the team site is using unique permissions from the parent site. What this means is that any user who has access to the parent site, will not have access to the team site unless he is added as a user to the team site. If the permissions of your team site were inherited from the parent site, then any user who had access to the parent site would have the same access to the team site. If you do not have a site that uses unique permissions, it is recommended that you create a new site from the Site Directory of your Intranet Portal site collection using the steps discussed in Chapter 8 and select Unique Permissions during the creation process.

1. From the main page of your team site, select Site Actions Site Settings.

2. Select the Advanced Permissions link under the Users and Permissions section, as shown in Figure 9-5. You are redirected to the Permissions page.

   
   Figure 9-5

3. Select Settings Permission Levels from the toolbar. You are redirected to the Permission Levels page.

   Tip 

   If you do not see the Settings menu on the toolbar of the Permissions page in step 3, it is likely that your site is inheriting permissions. You can select Actions Edit Permissions to change from inherited permissions to unique permissions. Doing so copies any users and groups from the parent into the team site. Therefore, if any users or groups that had access to the parent but you did not want them to have access to the team site, you must remove them later. If your team site was configured to inherit permissions from the parent site, you also need to select Edit Permissions Levels prior to completing Step 4. This also breaks any associations with the permission levels from the parent site.

4. Select the Edit Permissions Level button. A window appears saying that you are about to create custom groups and custom permissions for the site. Select the OK button to continue. The toolbar changes to reflect the custom permission levels for the site.

5. Select the Contribute permission level. You are redirected to a page that lists all rights associated with the Contribute permission level.

6. Scroll to bottom of page and click the Copy Permission Level button. You are redirected to a page where you must define your new Permission Level as shown in Figure 9-6.

   
   Figure 9-6

7. Type a name and description in the Name field for your new permission level. For this example, enter Limited Contribute. In the description field, enter the following text:

   Important 

   Can view, add and update but cannot delete content.

8. Unselect the Delete Items and Delete Versions check boxes under List Permissions, as shown in Figure 9-6.

9. Click the Create button.

10. Select Permissions from the navigation breadcrumb above the words “Permission Levels.”

11. Select New New Group from the toolbar. The new group creation window appears.

12. Type a name for your new site group. For this example, use Limited Membership.

13. In the About Me field, enter the following:

    Important 

    Use this group to give people limited contribute permissions to the SharePoint Site. Members of this group will not have the ability to delete content.

14. Select yourself as the owner of this group. This should be the default setting.

15. For the Group Settings section (see Figure 9-7), keep the default settings that only group members can view the membership of the group, and only the group owner can edit the actual membership of group.

    
    Figure 9-7

16. Under the Membership Requests section, select Yes for Allow Requests To Join/Leave This Group and enter your own email address to receive the requests. Select No for Auto-Accept Requests.

17. For the Group Permission to this site, select the Limited Contribute option.

18. Click the Create button. Your new site group is created based on the permission level you specified.

How It Works

When you create your group, you automatically become a member because you are the creator. Although members of the new group cannot delete content, you can still do so because of your membership in other site groups, such as Site Owners.

The next step is to add new team members to your site groups. You do this in the next Try It Out.

Try It Out-Add a User to a Site Group

In this example, all members of the Local Administrators group become site owners for your site. You can do this either by assigning each individual or by using security groups in Active Directory. When possible, doing the latter is preferable. In most organizations, Active Directory security groups represent an organization’s job roles, such as sales manager or support representative, and are kept up-to-date with the organization’s access requirements for those roles.

In this example, you specify a security group from your own Active Directory or SharePoint server and give it full control over the site. The process for adding a user or group to a site group is exactly the same.

Tip 

You may run into situations where the people responsible for managing a SharePoint environment may not be experts in the Active Directory group structure that another administrative group establishes. To prevent this, whenever two groups plan a new SharePoint environment or site collection, they should consult each other to ensure that permissions are assigned in a way that benefits the entire organization and minimizes administrative overhead.

1. From the main page of your team site, select Site Actions Site Settings.

2. Select the People and Groups link under the Users and Permissions category.

3. Select New Add Users from the toolbar. The Add Users window appears, as shown in Figure 9-8.

   
   Figure 9-8

4. Add the name of the group you want to add to the site to the Users/Groups box and click the check names icon. This icon verifies that you entered a proper name in the box. If you do not know the exact name of the user or group you are adding, you can click the Browse icon to perform a search of the membership directory. This example uses “administrators,” which is a local administrative group on the SharePoint Server.

5. In the Give Permissions section, you can either assign your users to a site group or select a permissions level. This example assigns the administrators to the Site Owner group.

6. You can send an email to let users know you have added them to the SharePoint site as part of the selected group. In this example, you have left the box unchecked. If you were adding a user, the email address would likely be automatically populated. Typically when you specify a group, this information is not available on the server so you can either manually enter an alias or distribution list address for the group or leave it blank. This approach requires you to notify the users that they have been added via alternate means.

7. Click the OK button.

How It Works

If you checked the option in step 6, the users receive an email letting them know that you’ve added them to the SharePoint site. Using Active Directory groups ensures that as new employees are added to an appropriate role, they are automatically provided access to the SharePoint sites with which those groups have been associated. For example, if the Sales Manager Active Directory security group is added to the Member site group of the sales site, then whenever an employee is added to the sales manager security group in Active Directory, he automatically becomes a member on the Sales site in SharePoint. This provides a more seamless access management environment and helps standardize access across groups.

Try It Out-Modify the Permissions of an Existing User or Group

In some scenarios, it’s necessary to change the specific rights that a single user or site group has on a site. This may be related to a direct request from a business manager, a change in requirements or perhaps because you need to grant a certain user rights to a workspace beyond what he or she currently has. This may be because the user has demonstrated exceptional skills and would make a good candidate to assume more responsibility for managing the SharePoint site. In the next example, you see the process for identifying and modifying the group membership and site permissions of a single user.

1. From the main page of your team site, select Site Actions Site Settings.

2. Select the People and Groups link under the Users and Permissions category.

3. Click the Site Permissions link.

4. Select the check box next to the Limited Membership group you created in a previous Try it Out in this chapter.

5. Select Actions Edit User Permissions from the toolbar, as shown in Figure 9-9. You are redirected to the user permissions page.

   
   Figure 9-9

6. Because the requirements for the Limited Membership group have changed, you must now grant all members of that group the permission to Approve content. Select the Approve permission level.

7. Click the OK button. You are returned to the Site Permission page.

How It Works

When you review the list of users, you’ll notice how the Limited Membership group now has Approve and Limited Contribute rights under the Permissions column, as shown in Figure 9-10.

Figure 9-10

You may later need to reduce a user’s or group’s permission to limit his access. This process is very similar to the previous steps, but you would remove the user from his current site group membership and add him to another group with fewer privileges.

Try It Out-Remove a User from a Site Collection

Rather than elevate or reduce a user’s or group’s access as shown in the last Try It Out, you may need to remove him completely from the site. This may be necessary if, for example, the user transfers to another division, or to a new position where his current access to site is no longer necessary. Alternatively, the scope of a project may change, which might lock a site so that only a few users still have access. In the following example, you look at what steps are required to remove a user from a site collection.

1. From the main page of your team site, select Site Actions Site Settings.

2. Select the People and Groups link under the Users and Permissions category.

3. Click the All People link.

4. Select the check box next to the user’s name that you want to remove from your site collection.

5. Select Actions Delete Users from Site Collection from the toolbar, as shown in Figure 9-11.

   
   Figure 9-11

   Tip 

   Note that you cannot delete anyone that is listed as the owner of a site collection because that user has built-in rights, and it is generally not good practice to remove owners of a site collection without ensuring that someone else has filled the role.

6. You are prompted with a message in a pop-up window asking you to confirm that you want to remove the selected user from the site collection. Click the OK button. The page refreshes, and your selected user is removed from the site collection.

How It Works

In previous versions of SharePoint, removing a user meant removing his or her name from all files that he or she created or modified. This caused obvious problems for companies that needed to retain these files. This problem was rectified in SharePoint 2007. If you remove a user from the site on which he or she currently has tasks assigned, you need to manually reassign these tasks to other team members. For this reason, it’s a good idea to review any task lists before removing a user.

For more about task columns, see Chapter 2. For more on assigning a workflow task to another user, see Chapter 5.

Try It Out-Enable Membership or Site Access Requests

So far, you’ve seen tasks that you, a site owner, can complete to assign access to team members or groups. However, certain situations may require that users request access to a site. For example, a user might click a hyperlink to a site of which he or she is not a member. SharePoint has a built-in access management feature that allows users to request access via the web interface by clicking a Request Access link. In the following example, you see how a user can request access to a site.

1. From the main page of your team site, select Site Actions Site Settings.

2. Select the People and Groups link under the Users and Permissions section.

3. Click the Site Permissions link.

4. Select Settings Access Requests. You are redirected to a page for enabling access request on the site.

   Tip 

   If you do not see this item in the Settings menu, your server may not be configured to send email. You can change this by having your system administrator configure the outgoing email settings from the Operations tab of the SharePoint Central Administration site.

5. Select the check box to enable access requests, and enter your own email address as shown in Figure 9-12.

   
   Figure 9-12

6. Click the OK button.

How It Works

Once a user clicks the link, he or she can input a message and click a Send Request button as shown in Figure 9-13. The advantages to this include the following:

• Users can request access without having to access another tool or interface.   The system automatically provides all the information that is required to effectively address the request and routes the request to the appropriate individual responsible for the site. This is the person (or group of people) associated with the email address specified in the previous steps. This saves both parties valuable time and is a benefit in large organizations that use ticket tracking systems to give such access.

• Users requesting access do not know who is responsible for the site.   It discourages people from going around a defined methodology and using more direct access request methods such as telephone or manual email, which could be potentially more time-consuming and distracting.

  
  Figure 9-13

Understanding the Different Levels of Access in SharePoint

Everything you’ve learned so far has been related to controlling access and rights on a SharePoint site. However, SharePoint 2007 also supports permissions management on the list and item level. This means that while a user may contribute to his team’s collaborative site, he may only be a reader for a particular document library or even a single document on a library. This section discusses the different levels of access that you can have on a SharePoint site.

Site Level Access

Each example thus far in this chapter has applied to managing access at the site level because, by default, this is the level where access is defined. From a restriction standpoint, you do not want to over-complicate access - and you want to keep things simple unless your requirements dictate it.

When you work on a site level, you need to determine whether you want a subsite to inherit permissions from a parent site or not. Your decision generally depends on your requirements:

• Inheriting permissions:   When you inherit permissions from a parent site, you create a scenario in which any user who has permission to the parent site will have the same permissions and rights on the child site. This cuts down on the tasks and effort associated with managing permissions and creates a consistent access experience for all users.

• Creating unique permissions:   Creating a site with unique permissions allows you to manage permissions and access to your child site, independent of the settings specified for the parent site. Therefore, a user who can add content on the parent site may not necessarily have access to the child site. Users perform different roles from site to site. This means that you’ll have to spend more time setting up and managing the site, but you will have greater flexibility in meeting the access requirements of each individual team. Sometimes it’s beneficial to give users greater access rights on a subsite than they have in a parent. For example, in a sales proposal document workspace, members of the sales team may be able to create lists and libraries to aid in their production of the proposal, whereas on the sales team site they may only have permissions to add content to existing lists.

Figure 9-14

Try It Out-Stop Inheriting Permissions from a Parent Site

You may have created a site and selected the option to inherit permissions from the parent, but at a later time, realize you need to manage the site’s permissions independently of the parent site. The following example uses the weblog site that you created in Chapter 8 and assumes that the weblog has different usage patterns from your team collaboration site; the people most responsible for creating and managing content have very limited permissions on the team site. You change the permissions settings on the site, which copies all site groups and users from the parent into the weblog site so that you can manage them separately.

Remember that if users have permissions on the parent site and you do not want them to have access to the weblog, you must remove them after breaking the inheritance because SharePoint copies the permissions, groups, and users from the parent into the child. You don’t have to do this if you do not select to inherit permissions when you first create the site. In that case, once the site is created, it has a blank set of permissions, and no users of the parent have access to the site unless explicitly given access. The exception, of course, is a site collection administrator or site owner on the parent site.

Tip 

If you did not create a weblog under your team site in Chapter 8, you can create any subsite on your team site that inherits the permissions of parent. The same steps apply regardless of what site template you use.

These steps walk you though the process for breaking the permissions inheritance from a parent site.

1. From the main page of your team weblog site, select Site Actions Site Settings.

2. Select the Advanced Permissions link under the Users and Permissions category.

3. Select Actions Edit Permissions from the toolbar, as shown in Figure 9-15. You receive a warning window, shown in Figure 9-16, that says you are about to stop inheriting from the parent and that any changes you make to the parent will no longer affect this site.

   
   Figure 9-15

   
   Figure 9-16

4. Click the OK button to continue.

How It Works

You now see a message above the toolbar stating:

Important 

Use this page to assign permission levels to users and groups. This web site does not inherit permissions from its parent.

List or Library Level Access

Sometimes a list or library on a team site requires a different set of permissions than the rest of the site. For example, a document library containing sensitive financial performance reports should not be shared with everyone who has access to the site. You could create a separate site to store this information, but it’s easier to simply adjust the permissions on the library so that a subset of users can access the library. Another example is where only certain users can edit a specific list or library in which team members can only view content. For example, only a manager can create new items on an Announcements list for a team, but team members can contribute to list and libraries on the rest of the site.

Try It Out-Assign Unique Permissions to a List

In the following example, you modify the permissions on an announcements list so that only members of the Approvers group can create new content. Even though all other site members can add content to other lists, it is important that you restrict the Announcements to only allow Approver members to add new items. To accomplish this, you must stop inheriting permissions on the Announcements list from the site. Similar to the scenario in the previous Try It Out, when you stop inheriting permissions for a list from a site, all rights get copied from the site into the list, so you must update the settings to reflect your requirements. For this exercise, you use the team site you created in the last Try It Out that has unique permissions from its parent.

1. From the main page of your team site, select the Announcements title link from the Announcements Web Part.

   Tip 

   It might be more direct to click the title of a list Web Part to go to default view of a list than to navigate there using the View All Site Content link.

2. Select Settings List Settings. The Customize Announcements window appears, as shown in Figure 9-17.

   
   Figure 9-17

3. Select the Permissions for this List link under the Permissions and Management category. The Permissions page for the Announcements list appears.

4. Select Actions Edit Permissions from the toolbar. You receive a warning, shown in Figure 9-18, that you are about to disconnect from the permissions of the parent site.

   
   Figure 9-18

5. Click the OK button to continue.

6. Click the Select All check box to select each group. Then unselect the Approvers group.

7. Select Actions Edit User Permissions from the toolbar.

8. Select Read from the list of permissions.

9. Click the OK button.

How It Works

When you disconnect from the permissions of the site, all rights and users are copied to the permissions scheme for the Announcements list. Therefore, you must edit the rights of each group and user so that they can only read items. You selected every group and changed their rights to Read-Only, but then deselected the Approvers group so that members could edit content. Note that the Site Owners group can still add content, and you cannot remove this group from a specific list or library.

Item Level Access

By default, access to an individual list item is inherited from the list or library in which it resides. However, you may need to better define this. For example, a policies and procedures document that’s stored within a team’s shared documents library means anyone can contribute and add contents; however, for legal reasons, only certain managers should have the rights to edit it. You can restrict access in one document, even if it resides in a list or library to which everyone has access, as shown in the next Try It Out. In a second Try It Out, you learn how to limit access to a list.

Try It Out-Assign Unique Rights to a Document

In this example, you create a new document and restrict the rights so that only members of the Approvers group have the access to edit the document.

1. From the main page of your team site, select Shared Documents from the Quick Launch bar.

2. Select New from the Document Library toolbar.

3. Save the document with a file name of Team Policies and Procedures.doc.

4. Hover your mouse over the document and select the Manage Permissions item from the drop-down menu, as shown in Figure 9-19. The Manage Permissions page for the document appears.

   
   Figure 9-19

5. Select Actions Edit Permissions from the toolbar.

6. Click the Select All check box to select each group. Then unselect the Approvers group.

7. Select Actions Edit User Permissions from the toolbar.

8. Select Read from the list of permissions.

9. Click the OK button.

How It Works

In this example, you created a new document that has slightly different requirements over all other documents in the library, rather than placing it in a unique location. It’s far more effective to manage the rights of this document independent of the library and make the required changes on an item-by-item basis.

Try It Out-Customize Item Level Access Rights on a List

You can uniquely apply permissions to documents or list items in the same way as the last Try It Out. However, lists also have a unique function that allows for a site manager to determine which users can view or edit their own items or the items of others. For example, it may be helpful to allow team members to view each other’s appointments. However, a user should not be allowed to edit appointments belonging to a coworker. In the following example, you modify the default settings of the Calendar list so that users can view, but not edit, a coworker’s items. You can do this on SharePoint lists, but not with documents stored within document libraries.

1. From the main page of your team site, select Calendar from the Quick Launch bar.

2. Select Settings List Settings.

3. Click the Advanced Settings link. The List Advanced Settings window appears, as shown in Figure 9-20.

   
   Figure 9-20

4. In the Item-Level Permissions section, for Read Access, keep the default value that users can view all items.

5. In the Item-level Permissions section, for Edit Access, select that users can edit only their own appointments.

6. Click the OK button.