Choose security groups (SharePoint Foundation 2010)

  • Článek

 

Applies to: SharePoint Foundation 2010

This article describes the security and distribution groups that comprise the Active Directory® Domain Services (ADDS). This article also provides recommendations for using those groups to organize the users of your SharePoint sites.

In this article:

  • Decide whether to add security groups

  • Determine which security groups to use for granting access to sites

  • Decide whether to allow access to all authenticated users

  • Decide whether to allow access to anonymous users

  • Worksheet

Introduction

Managing users of SharePoint sites is easier if you assign permission levels to groups rather than to individual users. SharePoint group is a set of individual users and can also include Active Directory groups. In Active Directory Domain Services (ADDS), the following groups are commonly used to organize users:

  • Distribution group   A group that is used only for e-mail distribution and that is not security-enabled. Distribution groups cannot be listed in discretionary access control lists (DACLs), which are used to define permissions on resources and objects.

  • Security group   A group that can be listed in DACLs. A security group can also be used as an e-mail entity.

You can use security groups to control permissions for your site by adding security groups to SharePoint groups and granting permissions to the SharePoint groups. You cannot add distribution groups to SharePoint groups, but you can expand a distribution group and add the individual members to a SharePoint group. If you use this method, you must manually keep the SharePoint group synchronized with the distribution group. If you use security groups, you do not need to manage the individual users in the SharePoint application. Because you included the security group instead of the individual members of the group, ADDS manages the users for you.

Note

For ease of security management, the following items are not recommended in managing Active Directory groups.

  • Assign permission levels directly to Active Directory groups.

  • Adding security groups that contain nested security groups, contacts, or distribution lists.

Decide whether to add security groups

Adding security groups to SharePoint groups provides centralized management of groups and security. The security group is the only place where you manage individual users. Once you add the security group to a SharePoint group, you do not have to manage security group members in that SharePoint group. If a user is removed from the security group, the user will be automatically removed from the SharePoint group.

However, using security groups in SharePoint sites does not provide full visibility of what is happening. For example, when a security group is added to a SharePoint group for a specific site, the site will not appear in the users’ My Sites. The User Information List will not show individual users until they have contributed to the site. In addition, security groups with deep nested structure might break SharePoint sites.

Considering the previous advantages and disadvantages, here are the recommendations:

  • For intranet sites that are broadly accessed by your users, use security groups because you do not care about the individual users who accessed the intranet site home page.

  • For collaboration sites that are accessed by a small group of users, add users directly to SharePoint groups. In this case, there is more of a need to know who is a member so the group members know each other’s e-mail addresses and how to contact each other.

Determine which security groups to use for granting access to sites

Each organization sets up its security groups differently. For easier permission management, security groups should be:

  • Large and stable enough that you are not continually adding additional security groups to your SharePoint sites.

  • Small enough that you can assign appropriate permissions.

For example, a security group called "all users in building 2" is probably not small enough to assign permissions, unless all users in building 2 have the same job function, such as accounts receivable clerks. This is rarely the case, so you should look for a smaller, more specific set of users, such as “Accounts Receivable”.

Decide whether to allow access for all authenticated users

If you want all users within your domain to be able to view content on your site, consider granting access to all authenticated users (the Domain Users Windows security group). This special group allows all members of your domain to access a Web site (at the permission level you choose), without your having to enable anonymous access.

Decide whether to allow access for anonymous users

You can enable anonymous access to allow users to view pages anonymously. Most Internet Web sites allow anonymous viewing of a site, but might ask for authentication when someone wants to edit the site or buy an item on a shopping site. Anonymous access is disabled by default and must be granted at the Web application level at the time that the Web application is created.

If anonymous access is allowed for the Web application, site administrators can decide whether to grant anonymous access to a site or any of the content on that site.

Anonymous access relies on the anonymous user account on the Web server. This account is created and maintained by Microsoft Internet Information Services (IIS), not by your SharePoint site. By default in IIS, the anonymous user account is IUSR. When you enable anonymous access, you are in effect granting that account access to the SharePoint site. Allowing access to a site, or to lists and libraries, grants the View Items permission to the anonymous user account. Even with the View Items permission, however, there are restrictions to what anonymous users can do. Anonymous users cannot:

  • Open sites for editing in Microsoft Office SharePoint Designer.

  • View sites in My Network Places.

  • Upload or edit documents in document libraries, including wiki libraries.

    Important

    To improve security for sites, lists, or libraries, do not enable anonymous access. Enabling anonymous access allows users to contribute to lists, discussions, and surveys, which will possibly use up server disk space and other resources. Anonymous access also allows anonymous users to discover site information, including user e-mail addresses and any content posted to lists, and libraries, and discussions.

Permission policies provide a centralized way to configure and manage a set of permissions that applies to only a subset of users or groups in a Web application. You can manage permission policy for anonymous users by enabling or disabling anonymous access for a Web application. If you enable anonymous access for a Web application, site administrators can then grant or deny anonymous access at the site collection, site, or item level. If anonymous access is disabled for a Web application, no sites within that Web application can be accessed by anonymous users.

  • None   No policy. This is the default option. No additional permission restrictions or additions are applied to site anonymous users.

  • Deny Write   Anonymous users cannot write content, even if the site administrator specifically attempts to grant the anonymous user account that permission.

  • Deny All   Anonymous users cannot have any access, even if site administrators specifically attempt to grant the anonymous user account access to their sites.

For more information about permission policies, see Manage permission policies for a Web application (SharePoint Foundation 2010).

Worksheet

Use the following worksheet to list the security groups that you will use and the permission levels that the groups will need at each level of your site hierarchy.