Thủ thuật Sharepoint 2010 part 35 docx

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).
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.
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

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.
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.
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.