Thủ thuật Sharepoint 2010 part 35 docx

220 ❘ chAPtER 8 secUriNg aNd maNagiNg site coNteNtFIguRE 8-20 gRANtINg PERmISSIONS Giving users access can be achieved in three ways: You can grant access to SharePoint security groups,

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)

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

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 applicaconfigura-tion 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

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