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