Choose which security groups to use (Windows SharePoint Services)
Updated: April 16, 2009
Applies To: Windows SharePoint Services 3.0
In this article:
For easier user management, we recommend that you assign site permissions to groups rather than to individual users. In the Microsoft Active Directory directory service, the following two types of groups are commonly used to organize users:
Distribution group A group that is only used for e-mail distribution and that is not security-enabled. Distribution groups cannot be listed in discretionary access control lists (DACLs) used to define permissions on resources and objects.
Security group A group that can be listed in discretionary access control lists (DACLs) used to define permissions on resources and objects. A security group can also be used as an e-mail entity.
You can use security groups to control permissions for your site by directly adding the security group and granting the entire group permissions. You cannot use distribution groups in this way; however, you can expand a distribution list and add the individual users to a SharePoint group. If you use this method, you must manage the process of keeping 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 itself and not the individual members of the group, Active Directory manages the users for you.
Determine which Windows security groups and accounts to use for granting access to sites
Each organization sets up its Windows security groups differently. For easiest permission management, security groups should be:
Large and stable enough that you aren't constantly adding additional 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 it happens that 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 set of users, such as "accounts receivable" or some other smaller, highly-related group.
Decide whether to use 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 to anonymous users
You can enable anonymous access to allow users to view pages anonymously. Most Internet Web sites allow anonymous viewing of the site, but might ask for authentication when someone wants to edit the site or buy an item on a shopping site. Anonymous access 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, then site administrators can decide whether to:
Grant anonymous access to a site.
Grant anonymous access only to lists and libraries.
Block anonymous access to a site altogether.
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 your SharePoint site. By default in IIS, the anonymous user account is IUSR_ ComputerName. 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:
Use the Microsoft Office SharePoint Designer remote procedure call (RPC); in other words, they cannot open sites for editing in Office SharePoint Designer. They can also not use DAV (the Web Folders protocol in Windows); in other words, they cannot view the site in My Network Places.
Upload or edit documents in document libraries, including wiki libraries.
To create more secure sites, lists, or libraries, do not enable anonymous access. Enabling anonymous access allows users to contribute to lists, discussions, and surveys, possibly using up server disk space and other resources. Further, it allows anonymous users to discover site information, including user e-mail addresses and any content posted to lists, and libraries, and discussions.
You can also set permission policies for the anonymous user for different zones (Internet, Extranet, Intranet, Other) if you have the same Web application serving content in those different zones. The policies are described in the following list:
None No policy. This is the default option. No additional permission restrictions or additions are applied to site anonymous users.
Read Anonymous users can read content, unless the site administrator turns off anonymous access.
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.
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.
Site and content security worksheet (http://go.microsoft.com/fwlink/?LinkID=73136&clcid=0x409)
Download this book
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable books for Windows SharePoint Services.