Thủ thuật Sharepoint 2010 part 21 pdf

228

CHAPTER 9 claims-Based aUtheNticatioN
across the enterprise so that you can accommodate the needs of all the applications. The solution to
this can become very complicated. You need to satisfy two key requirements:
How users will gain access to the enterprise’s applications, regardless of their location.

How different types of user information will be retrieved by the applications so that the

applications can accomplish their required functions.
User Access Challenge
Will the application be accessed by employees from within the organization, from outside the organi-
zation, from the public Internet? One technology may not be enough and the organization may have
to support multiple technologies. For example, you could use Windows Integrated security for inter-
nal users and Forms-Based Authentication (FBA) for users outside the organization; but we all know
the complexity this introduces in terms of providing a single authentication mechanism and the need
for storing different user information in multiple locations. In addition, neither Windows Integrated
security nor FBA provide much information about the user, with the latter providing username and
password information only. And what about providing access to partner or vendor employees? For
that you need to implement identity federation, so that the users won’t need a separate login. Finally,
keep in mind that the application requiring login may exist in the cloud, as this scenario is rapidly
gaining popularity; or you could have a hybrid scenario, with applications both on the premises and
in the cloud.
User Information Storage Challenge
How will information about users be stored and retrieved? The application can query the user for some
information, and look up other information. This may not sound like a big issue, but consider the
number of different applications in an organization, and that each may need to store and retrieve
information that is specific to its functionality. Even when your organization requires simple identity
capability, such as all users across the enterprise authenticating using Active Directory, this type of
login provides very little information about the user.
Solution

After this brief review of two key challenges, you are probably thinking that the solution is simple.
Why not create a single identity approach for all scenarios that provides each application with the
specific information it needs? If so, you guessed correctly. Claims-based identity satisfies these
requirements.
Claims-based identity provides a common way for applications to acquire identity information from
users, irrespective of whether they are inside the organization, in other organizations, or on the Internet.
Identity information is stored in a security token, often simply called a token. A token contains one or
more claims about the user. Think of a claim as metadata about the user that stays with them through-
out their enterprise journey. For example, this could include username, manager’s name, address, e-mail
address, group memberships, etc.
Implementing claims-based identity generally requires using and understanding a set of core technolo-
gies: Windows Identity Foundation (WIF), Active Directory Federated Services 2.0 (ADFS), and
Claims-Based Authentication
WhAt’S IN thIS chAPtER?
Using claims-based identity

SharePoint authentication options

Creating claims-based web applications

SharePoint Server 2010 utilizes a new authentication model called claims-based authentication
(CBA). CBA is based on the concept of identity and utilizes open source standards and proto-
cols so that it works with any corporate identity system, not just Active Directory and not just
Windows-based systems. Identity is represented by a security token. This token is presented to
any application to which the individual is attempting to gain access. The individual’s token, and
therefore his or her identity, is verifi ed by some system. This is normally some directory service
that contains username and password information, but the beauty of CBA is that it is not limited
to just username and password information.
CBA provides a trust-based system between applications and a centralized provider that issues
the token. The application trusts the individual because they trust the provider. Therefore, in

addition to providing a single sign-on environment, this alleviates the need for each application
to authenticate the user, enabling the application to focus on what permissions to assign, and
how the application interacts with, the user. This chapter is an introduction to CBA, and it
will provide you with the knowledge necessary to begin using CBA for SharePoint websites.
cLAImS-bASEd IdENtItY
User identity is a fundamental requirement for application security, both user authentication
and user authorization. Knowing who is requesting access to websites and access to object
information is critical to providing a secure environment. The challenge is deciding which
identity technology is the right one for a specifi c application, and then which one is the best
9

summary

225
5. In the Choose System Settings section, be very careful. Here you can specify the entered account
to operate as the System account. This is rarely selected. Do not select this option for regular
users. The only time this is okay is when you have a new service account that needs complete
access — Farm Administrators, Email Service account, Email Crawl account, Application Pool
accounts, overall administrative account (i.e. any administrative user account).

6. Click Finish.
SummARY
Configuring security and user access can be a daunting task and heavy responsibility. Be sure to
have a firm grasp of the concepts in this chapter and have a clearly defined security plan before
opening content to users. The following points reiterate the most important pieces of information
from this chapter:
Access can be granted at a granular level, with users given access to a specific piece of content

in SharePoint, or a web application policy can be used to grant users access to an entire web
application and its sites.

Permissions are divided among permission levels, and permission levels are used to grant

users access.
An administrator can restrict the set of available permissions for a web application through the

Central Administration site, but this requires being a member of the Farm Administrators group.
SharePoint groups are available throughout an entire site collection. Membership can be

managed at any level with the appropriate permissions, but access must be granted to the
specific securable object.
Inheritance restricts permission management. To customize permissions on a securable

object, you have to stop inheritance. Inheritance can always be reset.
For the sake of easy manageability, inheritance should be leveraged wherever possible.

Be sure to document securable objects using unique permissions.

As a general rule, the default permission levels and site groups should not be edited or

deleted. If another option is needed, create it.
When configuring user access, it is better to be restrictive when granting permissions. Only

grant users access to content they need.
Use the site groups (Owners, Members, and Visitors) as much as possible.

Limit the number of users in the Site Collection Administration and Owners groups.

Adhering to these policies will help keep your server farm content secure.
224
❘

chAPtER 8 secUriNg aNd maNagiNg site coNteNt
FIguRE 8-25
WEb APPLIcAtION POLIcY
The access options discussed in this chapter so far are related to the granular capabilities of SharePoint,
and they enable administrators to give users access to content and various securable objects. At the
other end of the spectrum is the option to create a web application policy. This is a broad configura-
tion that will grant (or deny) a user or group access to an entire web application. This can be handy
if auditors are coming in, or if the legal department needs to search for content based on keywords.
Web application policies are the only place in SharePoint where a user or group can be denied access
to an object. You can use them to verify that an entire group cannot access a specific web application.
For instance, if you have many domains in your environment, you can prevent members from a
specific domain from accessing a web application, despite any attempts from site collection adminis-
trators to give them access. The nice part about this option is that this policy cannot be overridden
by security settings in the sites themselves.
To set up a web application policy you must be a farm administrator and make the configuration in
Central Administration. Follow these steps to create a web application policy:

1. Open Central Administration.

2. Click Security. Under Users, click Specify web application policy. Here you can add, edit, or
delete selected policies. Click Add Users.

3. Select the web application and zone for the policy. Click Next.

4. Enter the user(s) and select the permissions. By default, there are four permissions levels to
choose from: Full Control, Full Read, Deny Write, and Deny All.
If none of the default levels will suffice, you can create your own permission policy. From
the Central Administration homepage, click Manage Web Applications. Select a web appli-
cation and click the Permission Policy link in the Ribbon.
Granting Permissions

❘
223
FIGURE 824
Once a site is using unique permissions, you always have the option to inherit
permissions from the parent. Simply click the Inherit Permissions link in the
Ribbon. This is a nice way to reset permissions if you ever need to troubleshoot
unique permissions errors.
Editing User Access
Once a user, AD group, or SharePoint group has been given access, you can edit this access from the
Ribbon on the Site Permissions page (or permissions page for the corresponding securable object).
To edit or remove the permissions, select the user, AD group, or SharePoint group and click Edit
User Permissions or Delete User Permissions, respectively.
Managing Access Requests
If a user does not have access to your sites and tries to access them, he or she will get an Access Denied
error. If the Allow requests for access setting is enabled, the error message will include the option to
contact the administrator and request permission to the site. As the administrator for your sites and/
or site collection, you can confi gure this option from the Site Permissions page. In the Ribbon you will
see a link titled Manage Access Requests. You have two confi guration options: enable or disable the
feature; if enabled, enter an e-mail address to receive requests. Figure 8-25 shows the screen with the
feature enabled.
222
❘
CHAPTER 8 secUriNg aNd maNagiNg site coNteNt
Breaking Inheritance and Granting User Access
Follow the instructions below to customize permissions for a securable object that is inheriting
permissions from its parent:

1. You can confirm that the site is inheriting permissions by looking at the status bar running
horizontally across the page, as shown in Figure 8-22.
FIGURE 822

2. To be able to grant new permissions, you must select Stop Inheriting Permissions, indicated
in Figure 8-23. A pop-up will appear asking you to confirm the request. Click OK. The status
bar changes to inform you that the site is using unique permissions, as shown in Figure 8-24.

3. Select Grant Permissions. You can now customize permissions.
FIGURE 823
Granting Permissions
❘
221
FIguRE 8-21
You cannot add a SharePoint group to another SharePoint group. This is known
as “nesting” and it is not compatible with SharePoint 2010. If you try to nest
groups, SharePoint will give you an error. Therefore, if you plan to grant access
by adding to a SharePoint group, your entry must be a user or AD group.
5. Select whether to e-mail the user(s) a notifi cation.

6. Click OK.
When you fi rst confi gure security for your site collection, although it may seem
more convenient to give individual users direct access, it is not recommended. It
might be manageable with a couple dozen users, but imagine doing this for sev-
eral hundreds or thousands of users. It would be an administrative nightmare.
220
❘
CHAPTER 8 secUriNg aNd maNagiNg site coNteNt
FIGURE 820
GRANTING PERMISSIONS
Giving users access can be achieved in three ways: You can grant access to SharePoint security groups,
to AD groups, or directly to users. Fortunately, the same procedure is used for each option. As previ-
ously stated, you must grant access to the specific securable object. For many environments, users will
have different access for the various sites in the SharePoint environment.

For the following procedures, you will follow the first two steps to start:

1. Navigate to the securable object. In this example, the securable object will be a site.

2. Select Site Actions ➪➤Site Permissions.
Granting Access to a Top-Level Site
To grant access to a top-level site, continue with the following steps:

1. Because this is at the top-level site, you do not have to worry about inheritance. Select Site
Actions ➪ Site Permissions.

2. Click Grant Access.

3. Enter the user name(s), AD group name, or SharePoint group name and validate.

4. When granting permissions, you can add the desired user or AD group to an existing SharePoint
group or you can give permission directly. The drop-down menu of existing SharePoint groups
also shows the corresponding permission level for each group. Adding a new entry to this
group gives that user the listed permission level. If you select Grant users permission directly,
the permission levels options will be displayed and you can select the desired access (see
Figure 8-21).
Security Groups

219
AD domain. The advantage to using this group is that for environments that will be acces-
sible by all your domain users, this guarantees access for all your users and is easy to manage.
The downside is that this group represents all your users, granting them all access. Imagine
if this group were given access to secure content. As such, this option should be used with
caution. This also includes trusted domains, not just the domain your SharePoint servers are
in. If you are using a trusted domain for extranet users, for instance, they will all also have

access to any content secured with NT AUTHORITY\Authenticated Users.
NT AUTHORITY\Authenticated Users is an Active Directory group. Use of
this group requires Windows Integrated Security.
Anonymous Access

— This authentication method allows any user(s) to access your SharePoint
sites. Primarily seen with Internet sites, this option is useful when the users who will be access-
ing your content do not have corresponding user accounts in your domain. Anonymous Access
can only be enabled at the web application level. Once enabled, it can be available for all site
collections and sites within the web application. Since this is confi gurable at the site level, it is
up to the site collection and site administrators whether they want this enabled in their environ-
ments. Similar to using the NT AUTHORITY\Authenticate Users group, this option should
be used with caution. Anonymous access can be confi gured from the Site Permissions page, as
shown in Figures 8-19 and 8-20.
Anonymous Access can only be confi gured at the site level once it is enabled in
Central Administration in the authentication settings.
FIguRE 8-19
218

CHAPTER 8 secUriNg aNd maNagiNg site coNteNt
The two preceding procedures are for adding and deleting users, but you can
follow the same steps to add an Active Directory group to a SharePoint group.
In the people picker, specify the Active Directory group, rather than the name
of a user, and then validate the name. You can search for an Active Directory
group the same way you search for a user.
Active Directory Groups
In addition to using SharePoint security groups, you can also use Active Directory (AD) groups.
For security, you must use AD e-mail-enabled security groups. Distribution lists cannot be used. In
order for an object to be used in security it must have a Security ID (SID) in Active Directory. User
accounts have SIDs, so they can be used. Distribution lists do not have SIDs, which is why they can-

not be used as security objects in SharePoint. AD groups and individual users are granted permis-
sions in similar fashion. As such, their use is covered later in this chapter.
SharePoint Security Groups versus Active Directory Groups
Because you can use either SharePoint security groups or Active Directory groups, let’s discuss the
benefi ts and downsides to using either option. In most cases, it really depends on the environment
and the governance policy in place.
In most environments, the AD structure is much older than the SharePoint implementation and
already setup. If your SharePoint security structure needs match those of the current AD setup, then
it will be much easier to deploy AD groups, rather than recreate the same structure and add users
to SharePoint security groups. If this is not the case, and your SharePoint site structure has com-
pletely different user access confi guration needs, this is a picture-perfect example of when to choose
SharePoint security groups over AD groups.
Another thing to consider is the user who will be managing the security structure and user access. With
AD, it is almost always an information technology specialist, who may or may not have SharePoint
access. With SharePoint, the site collection administrator or site owner may be an IT professional, but
there is a good chance that it will be a manager or power user, who will not have AD access. Most
organizations avoid turning control of IT application security over to a non-IT professional. In situ-
ations where the site collection administrator and/or site owners are non-IT members, a combined
approach is common. One signifi cant drawback to AD groups is discoverability. There is no way in
SharePoint to see the members of an AD group, making it diffi cult or impossible to know who has
access to something if AD groups are used.
Special Groups and Authentication Options
There might not always be a user or group that exactly fi ts the bill when you want to add permissions
at a large level. If you need to provide access to a large group of people that is dynamic, you may need
to employ some special tactics to open your content to everyone that needs access.
All Authenticated Users

— One AD group that can be very useful is the NT AUTHORITY\
Authenticated Users group. This group represents any and all users who authenticate to your
Security Groups

❘
217
FIguRE 8-18
3. Enter or remove one or more security groups from the displayed groups.
Adding Users to SharePoint Security Groups
To add users to SharePoint security groups, follow these steps:

1. Navigate to the All Groups page (follow steps 1 and 2 of the “Adding a SharePoint Security
Group” procedure).

2. Select a group by clicking on the name of the group.

3. Click the New drop-down menu and select Add Users.

4. Enter the user’s name and validate.

5. Select whether or not you want to have an e-mail sent to the user informing them of their new
access.

6. Click OK.
Deleting Users from SharePoint Security Groups
To delete users from SharePoint security groups, follow these steps:

1. Navigate to the All Groups page (follow steps 1 and 2 of the “Adding a SharePoint Security
Group” procedure).

2. Select a group by clicking on the name of the group.

3. Select the users you want to remove.

4. Click Remove Users From Group.
216
❘
chAPtER 8 secUriNg aNd maNagiNg site coNteNt
3. Click the New drop-down menu and select New Group, as shown in Figure 8-17.
FIguRE 8-17
4. Enter a name and description for the new group. For this example the name will be New
Group 1, with no description. Specify the Group Owner (only one user can be the group
owner). Typically, the only people who can view the membership of the group are the mem-
bers of that group. Additionally, only the Group Owner can edit the membership of the
group. For obvious reasons, it is not a good idea to give several users this capability. You can
also configure if and how you want to receive membership requests.

5. Click Create. Your group will now be created.
Deleting a SharePoint Security Group
Deleting a SharePoint security group is simple:

1. Navigate to the All Groups page (see steps 1 and 2 of the preceding “Adding a SharePoint
Security Group” procedure).

2. When viewing the available groups, click the Edit icon for the desired security group.

3. Scroll down and click Delete.
Managing SharePoint Security Groups in Current Navigation
To manage SharePoint security groups, follow these steps:

1. Navigate to the People and Groups page (follow steps 1 and 2 of the “Adding a SharePoint
Security Group” procedure). This procedure describes how to edit the groups displayed here.

2. Select Settings ➪➤Edit Group Quick Launch, as shown in Figure 8-18.

Security Groups
❘
215
The available default permissions will vary with the version of SharePoint 2010
you are running. SharePoint Foundation 2010 does not have all the same per-
missions that SharePoint Server 2010 has.
Adding a SharePoint Security Group
In addition to site groups and groups that are created when a new site is created using unique per-
missions, you can create your own SharePoint security groups, assuming you have suffi cient permis-
sions. This group will be usable within the entire site collection, not just within the site in which
it was created. When you assign a permission level to the group, that access applies to the current
securable object and all child securable objects.
This is an area where people are easily confused. When you create a SharePoint
group, you can specify the group’s permission level or you can leave it blank.
If you leave it blank, you can always confi gure the group’s access to another
securable object. If you confi gure the group’s access, the access will only be for
that securable object and any securable objects that inherit permissions from the
parent. Once the SharePoint security group is created, you can navigate to any
securable object’s permission settings page and add access for the group.
To add a SharePoint security group, follow these steps:

1. Navigate to the People and Groups page in any site within your site collection by clicking Site
Actions ➪➤Site Settings.

2. Under the Users and Permission header, click People and Groups. By default, the page will
display the fi rst SharePoint group that is listed in the Current Navigation under Groups. To
see all groups within the site collection, click on the link for Groups (see Figure 8-16) to open
the All Groups page.
FIguRE 8-16
214

❘
chAPtER 8 secUriNg aNd maNagiNg site coNteNt
If you select Use unique permissions (as shown in Figure 8-14) and click Create, you will be prompted
to configure three new user access groups: [New site name] Owners, [New site name] Members, and
[New site name] Visitors (see Figure 8-15). This creates a customized security structure and only
users who are members of these groups will have access to the site.
FIguRE 8-14
FIguRE 8-15
Security Groups

213
FIguRE 8-13
[Site collection name] Owners

— This group is created for all site collection templates; by
default, members of this group will have Full Control.
[Site collection name] Members

— This group is created for all site collection templates; by
default, members of this group will have Contribute access.
[Site collection name] Visitors

— This group is created for all site collection templates; by
default, members of this group will have Read access.
Viewers

— This group has View Only access, and is created for Collaboration and Meeting
site templates.
Approvers


— This group has Approval access, and is created for Enterprise site templates and
Publishing site templates.
Designers

— This group has Design access, and is created for Enterprise site templates and
Publishing site templates.
Hierarchy Managers

— This group has Manage Hierarchy access, and is created for
Enterprise site templates and Publishing site templates.
Restricted Readers

— This group has Restricted Read access, and is created for Enterprise
site templates and Publishing site templates.
Configuring Permissions During Site Creation
When you create a new site, within an existing site collection, you select your template and then
you enter a name, URL, and description for your site. To configure permissions during site creation,
from the Create screen click the More Options button. The Permissions options will appear, as
shown in Figure 8-14. The default value is to Use same permissions as parent site — that is, inherit
permissions from the parent site. This means that access to the new site is the same as that used on
the parent one. No new groups will be created.
212

CHAPTER 8 secUriNg aNd maNagiNg site coNteNt
SharePoint Security Groups
SharePoint security groups are groups of users that are created from within the browser and can be
used within a given site collection. By default, SharePoint creates security groups (site groups) when
a new site collection is created. The groups that are created vary according to the template that is
used. The following are the site groups that may be created:
Site Collection Administrators


— This group is created for all site collection templates. It
has Full Control permissions and can do anything on this site collection. These permissions
cannot be overridden. When a new site collection is created, the creator has to specify a
value for the primary site collection administrator, and he/she will have the option to enter
a user for the secondary site collection administrator. These specified users are added to the
Site Collection Administrators group and will be able to perform the administrative tasks
associated with the site collection. These options are available from the Site Settings menu
on the top-level site collection (see Figure 8-12). These users will also be the only users
who can view the members of the Site Collection Administrators group. The Site Collection
Administrators group is also accessible from the Site Permissions page of the top-level site, as
shown in Figure 8-13.
FIGURE 812
Security Groups
❘
211
The following procedure will walk you through editing a permission level that exists on a site based
on the Team site template:

1. Follow the steps in the earlier instructions to navigate to the Permissions Level page.

2. Click the permission level you want to edit. If you select the Full Control or Limited Access
permission levels, you will notice that all of the permissions are grayed out. You will not be
able to edit these permission levels. If you select a permission level other than these two, you
can deselect current permissions and/or add permissions.

3. When fi nished, click Submit. This will save the changes you have made. Note that this change
will affect this entire site collection.
Deleting a Permission Level
In the event that you no longer wish a permission level to be available, you can remove it from the

Permission Levels page:

1. Follow the steps in the earlier instructions to navigate to the Permissions Level page.

2. Select the permission level you want to delete. For this example, the Custom Permission Level
1 will be deleted. Select this permission level and click Delete Selected Permission Levels. As
the option states, you can delete more than one permission level at a time if you so choose.

3. Once you click Delete Selected Permission
Levels, a pop-up window will appear asking
you to confi rm the deletion of the selected per-
mission level (see Figure 8-11). Click OK.

4. The selected permission level will be deleted and
will no longer be available from the Permission
Levels page.
When you delete a permission level it will no longer be available. When the
permission level is removed, any users or groups that are leveraging this permis-
sion level for access will be removed from the Site Permissions page. In order for
these users or groups to have access again, you must grant them one of the avail-
able permission levels.
SECURITY GROUPS
So far this chapter has covered the individual permissions that make up permission levels and how
these permission levels are used to grant users and groups access to SharePoint content. Now it is
time to discuss the users and groups that will be assigned the previously stated permission levels.
FIGURE 811
210
❘
CHAPTER 8 secUriNg aNd maNagiNg site coNteNt
3. Enter a name and description for your new permission level. For this example, the name will

be Custom Permission Level 1, with no description.

4. Select the permissions you want to be associated with the permission level and click Create.
You should now see your newly created permission level in the Permission Levels page, as
shown in Figure 8-10.
FIGURE 810
In step 4 of this procedure, you may notice that when you click on a permis-
sion, others are automatically selected. Some of the permissions in SharePoint
are dependent upon others — selecting one automatically selects the others.
For example, several other permissions are dependent on the View Items per-
mission. Because many other permissions are related to performing actions on
items, it is prudent to fi rst be able to view the item. Therefore, if you select the
Edit Items or Delete Items permissions, for example, SharePoint will automati-
cally select the View Items permission.
Editing an Existing Permission Level
As previously mentioned, sometimes the permissions that exist on your sites are not exactly what
you are looking for. Fortunately, you can edit these permission levels by selecting and deselecting the
individual permissions that make up the permission level.
Following Microsoft “Best Practices,” editing default permission levels is not
advised. Instead, edit custom permission levels.
Permission Levels
❘
209
FIGURE 88
FIGURE 89
Creating a Permission Level from Scratch
If the default permission levels don’t provide a good starting point for a permission level your envi-
ronment requires, you have the option to create a permission level from scratch. You start with a
blank slate and select the desired permissions that will be needed.

1. Follow steps 1-3 in the preceding set of instructions to navigate to the Permissions Level page.

2. Click Add a Permission Level.
208
❘
CHAPTER 8 secUriNg aNd maNagiNg site coNteNt
Creating a New Permission Level Based on an Existing
Permission Level
Depending on your environment, you might find that the default permission levels aren’t adequate for
the user access needs of your organization. One of the most common issues is that the Contribute per-
mission level allows users to have Delete Items permission. To remedy this problem, you can create a
new Contribute Without Delete permission level and base this new permission level on the default
Contribute permission level. Rather than build a new permission from scratch, you can start with
the Contribute permissions and then deselect the Delete Items permission and you will be good to
go. The following procedure will walk you through this process:

1. Navigate to your top-level site.

2. Click on Site Actions and select Site Permissions (or Site Actions and select Site Settings for
the Publishing site options). Under Users and Permissions, click on Site Permissions.

3. In the Ribbon, click on Permission Levels (see Figure 8-7).
FIGURE 87
4. Select the permission level that you want to use as a reference for your new permission level.
For this example, the Contribute permission level will be selected.

5. Scroll down to the bottom of the page and click Copy Permission Level (see Figure 8-8).

6. You will be prompted to give the copied permission level a name, a description, and the
desired permissions. Since all that is needed is to remove the Delete Items permission, simply

scroll down to that permission and deselect it.

7. Scroll down to the bottom of the page and click Create. This will create your new permission
level. Note that the permissions list in Figure 8-9 now includes Contribute Without Delete.
Permission Levels

207
permission level is based on the Read permission, but it doesn’t have all the same permissions.
A few key distinctions are that users with this permission level will not be able to open list
and document library items, browse user information, or use client integration.
Approve

— Edit and approve pages, list items, and documents. For Publishing sites only. This
permission level is designed to work with the Publishing Approval workflow template. Users
and groups with this permission level will be able to edit and approve items submitted, and
leverage the Publishing Approval workflow. They will also be able to approve items in lists
and document libraries that have Content Approval enabled.
Manage Hierarchy

— Create sites; edit pages, list items, and documents. For Publishing sites
only. Similar to the Design permission, this permission level allows users to edit the design
and components that make up the site. This permission level does not include all the permis-
sions that users with the Design permission level have. A key difference is that users with the
Manage Hierarchy permission level cannot approve items leveraging the Publishing Approval
workflow or Content Approval features.
Figure 8-6 shows the default Publishing permission levels when using the Publishing template.
FIguRE 8-6
An important thing to remember when working with these permission levels is that, for the most
part, moving down the hierarchy of permission levels, levels will contain all the permissions of the
permission levels that precede them. Therefore, Full Control contains all the permissions of all

the permission levels combined. The Contribute permission will have all the permissions of Read,
Restricted Read, View Only, and Limited Access.
206

chAPtER 8 secUriNg aNd maNagiNg site coNteNt
Read

— Can view pages and list items and download documents. This is the standard per-
mission level for users and groups you want to access content, but not have the permissions
to add, edit, or delete content.
Limited Access

— Can view specific lists, document libraries, list items, folders, or documents
when given permissions. This permission level cannot be assigned. Instead, it is the result of
customizing permissions for a securable object. In essence, when you see this permission level
for a user or group, the users have access to a securable object in the current container, but
not to all the securable objects in the container.
View Only

— Can view pages, list items, and documents. Document types with server-side
file handlers can be viewed in the browser but not downloaded. The key concept here is that
users and groups with this permission level can’t download copies of documents with server-
side file handlers.
Figure 8-5 shows the permission levels for team sites.
FIguRE 8-5
To see all of the default permission levels, you have to create a site based on a Publishing site tem-
plate. Only the Publishing site template deploys the total set of permission levels. These include the
permission levels available with the team site as well as those in the following list:
Restricted Read


— View pages and documents. For Publishing sites only. This permission
level is similar to the Read permission level, but it only has four of the eleven Read permis-
sion level permissions. Key distinctions are that users with this permission level will not be
able to create alerts, browse user information, or use client integration.
View Only

— View pages, list items, and documents. If the document has a server-side file
handler available, users can only view the document by using that file handler. Again, this
Permission Levels

205
PERmISSION LEvELS
Permission levels are the sets of permissions that administrators use to grant users access to site
content. Depending upon the access a user or group of users require, an administrator can use the
out-of-the-box permission levels or create one that will fulfi ll the user access requirements.
Unlike permissions, permission levels are manageable from the site where they are being used.
From the Site Permissions page, you can access the current permission levels available for your site.
It is here you can create your own permission levels, delete existing permission levels, and modify
existing permission levels.
There are a few “best practices” when it comes to managing permission levels:
It is not a good idea to modify a default permission level. If a default

permission level is not confi gured the way you like, you can create a
new permission level.
When you create a new permission level, you are often only changing one

or more permissions assigned to a default permission level. To ensure that
you keep all the desired permissions, make a copy of the default permission
level and then edit the permissions for the copied permission level.
It is not recommended to delete a default permission level. If you don’t


think you need it, there is no harm in keeping it. If you need it down the
road, you won’t have to create it from scratch and risk not confi guring it
the same way it was originally.
By default, a set of permission levels is available when a new site is created. This set of permis-
sions will depend upon the site template that was used to create the site. For team sites there are six
default permission levels:
Full Control

— Users and groups with this permission level will have access to everything on
the site and can perform any site administrative tasks. This shouldn’t be confused with site
collection administrators. Users and groups with Full Control permissions cannot perform
site collection administrative tasks.
Design

— Can view, add, update, delete, approve, and customize. A step up from Contribute,
this permission also allows users to customize the site and its pages. Additionally, this group
can approve items that are in containers with Content Approval enabled. For the most part,
users and groups with this permission level can do anything on the securable object except
for administrative tasks.
Contribute

— Can view, add, update, and delete list items and documents. This is the stan-
dard permission level used to grant users access to content and containers when they need to
add, edit, and delete content.
204
❘
chAPtER 8 secUriNg aNd maNagiNg site coNteNt
PERmISSION dEScRIPtION tYPE PERmISSION LEvEL
View Pages View pages in a website. Site Full Control, Design, Contribute,

Read, Approve, Manage
Hierarchy, Restricted Read
Enumerate
Permissions
Enumerate permissions on
the website, list, folder, docu-
ment, or list item.
Site Full Control, Manage Hierarchy
Browse User
Information
View information about users
of the website.
Site Full Control, Design, Contribute,
Read, Limited Access, Approve,
Manage Hierarchy
Manage Alerts Manage alerts for all users of
the website.
Site Full Control, Manage Hierarchy
Use Remote
Interfaces
Use SOAP, Web DAV, the
Client Object Model, or
SharePoint Designer inter-
faces to access the website.
Site Full Control, Design, Contribute,
Read, Approve, Manage
Hierarchy
Use Client
Integration
Features

Use features that launch cli-
ent applications. Without this
permission, users must work
on documents locally and
upload their changes.
Site Full Control, Design, Contribute,
Read, Limited Access, Approve,
Manage Hierarchy
Open Allow users to open a web-
site, list, or folder in order
to access items inside that
container.
Site Full Control, Design, Contribute,
Read, Limited Access, Approve,
Manage Hierarchy, Restricted
Read
Edit Personal
User
Information
Allow a user to change his
own user information, such
as adding a picture.
Site Full Control, Design, Contribute,
Approve, Manage Hierarchy
Manage
Personal
Views
Create, change, and delete
personal views of lists.
Personal

Permissions
Full Control, Design, Contribute,
Approve, Manage Hierarchy
Add/Remove
Personal
Views
Add or remove personal Web
Parts on a Web Part page.
Personal
Permissions
Full Control, Design, Contribute,
Approve, Manage Hierarchy
Update
Personal Web
Parts
Update Web Parts to display
personalized information.
Personal
Permissions
Full Control, Design, Contribute,
Approve, Manage Hierarchy
tAbLE 8-1
(continued)