Chapter 8: Securing and Managing Site Content
What’s In This Chapter?
- The administration hierarchy
- Security terminology
- User permissions
- Permission levels
- Security groups
- Granting users access
As the capabilities and use of SharePoint technologies continue to increase, so does the amount of content stored in SharePoint sites. To maintain and manage this content, you need an effective security structure in place to ensure that this content is only accessed by users with the proper permissions. To assist administrators with this gargantuan task, configuration options exist to grant users access with both broad and fine-grained settings. Additionally, you can configure this access at several hierarchical levels, making it easy to secure content throughout an environment. The security structure built at the onset of a SharePoint deployment plays a major role in the overall success or failure of the solution and is not to be taken lightly. In this chapter you get an in-depth look at the security configuration options available with SharePoint 2010 and how they can be used to lock down your environment.
Before diving into how site security can be set up, it is vital to understand the vocabulary that represents the various components of user access. These terms are often dependent upon each other so it is easy to get subjects confused. Be sure to have a firm grasp of these concepts before moving on to the next sections:
- Permissions — These are single units of access that represent specific tasks that can be performed at the list, site, or personalization level. Permission levels are made up of sets of permissions. SharePoint ships with a list of permissions. This list cannot be edited or added to, and permissions cannot be deleted.
Although you can’t delete a permission, you can control the permissions that are available for a site collection. For example, if you have a site collection that is storing archived content and you want to eliminate the possibility of users deleting list and library items, you can remove the permission to “Delete Items.” This type of configuration can be made from Central Administration.
- Permission levels — Permission levels are pre-defined sets of permissions that are used to grant users access to content in SharePoint. The level of access that users with the assigned permission have is based on the permissions that make up the permission level. Several permission levels are created by default. These permission levels vary according to the type of template you use to create your site collections and sites. Each permission level is covered in detail later in this chapter, in the section “Permission Levels.”
- Users — The smallest value to which access can be granted. This value corresponds to an account in Active Directory or another host application for user accounts.
- Groups — A group is a set of users who will have identical access needs. Users in the same group typically have the same role within an organization. Using groups, rather than granting permissions to individual users, makes it easier to manage user access.
- Securable objects — Securable objects are levels within SharePoint 2010 that can be “locked down,” or secured, by setting specific user access. Sites, lists, libraries, and items are all securable objects. User access at each of these levels can be customized so that only the appropriate or approved users have access to the content.
- Inheritance — Inheritance is used to describe how user access is created by default within SharePoint. Whenever a securable object is created, it is created with the same user access as its parent. For new sites that you create, you specify whether you want the site to “inherit” permissions or whether the site should have customized permissions. When user access is inherited, any changes made to the parent securable object(s) will update the child securable object(s). When permissions aren’t inherited, no updates are made to the access users and groups have within the securable object(s). If you choose to customize your user access and not inherit from the parent site, it is paramount that you document any changes to your security structure so that your team is aware of which sites will not be automatically updated. This does not mean that membership to groups will not be updated; it means that the access that users or groups have will not be updated. Group membership can be edited in any site within the site collection, but these changes will affect the group for the entire site collection.
- Site groups — These are specific groups that are created for you by default when a new site is created. The types of groups that are created vary according to the site template used to create the site. The “Security Groups” section goes into more detail regarding the different types of groups and how they can be used within SharePoint 2010.
Administration Hierarchy in SharePoint 2010
User access can be set at several hierarchical levels in a SharePoint 2010 environment. This helps break up the task and responsibility of security administration. At the higher levels, IT members will most likely be responsible for managing security for the server farm down through the services, features, and site collection administrator levels. This gives your IT department control over the servers and provisioning and managing site collections. Once site collections and sites have been created, along with the corresponding lists, libraries, pages, etc., the responsibility of securing content should be redirected to the users that “own” the specified content. This takes a large burden off of your IT department, and allows them to focus on maintaining the SharePoint environment as a whole, rather than managing every little piece. At the site collection level is the site collection administrator. This is typically a manager or department head that oversees all the users and content within a given site collection. Moving down the chain, individual users or power users can be delegated control of child sites, lists, and libraries. Note that if you intend on having non-IT staff manage security at the lower levels, an extensive amount of training is recommended, as well as an effective backup/restore plan. Having such high access allows those users to perform a wide variety of tasks, some of which can be fatal for environments. In the next few sections, each hierarchical level is covered in more detail.
Server or Server Farm Administrators
The server farm access level includes two groups:
- Local Administrators — Members of this group are also members of the Farm Administrators group. In addition to all the administrative tasks they can perform as farm administrators, local administrators can perform additional activities, even tasks unrelated to the SharePoint environment, on servers in the farm — including installing patches and service packs, administering IIS, starting/stopping services, SQL maintenance, reviewing Event Viewer logs, etc. Like farm administrators, these users do not have access to SharePoint sites by default. To manage users in this group, you must do so from the server itself.
- Farm Administrators — Members of this group have administrator access to all servers in the server farm. With this access they can perform any administrative task within the Central Administration site. Users in this group can also use PowerShell cmdlets for various administrative activities and assign users administrative roles for service applications. By default, this group does not have access to SharePoint sites, but it is possible for them to give themselves access through a web application policy.
To manage server farm administrators, follow these steps:
1. From Central Administration, select Site Settings People and Groups.
2. Click Manage the farm administrators group. Here you can add and remove users from this group.
3. To add a user, click the New drop-down menu and select Add Users, as shown in Figure 8-1.
4. To remove a user, click the checkbox next to his or her name and then click Actions Remove Users from Group, as shown in Figure 8-2.
Although farm and local administrators do not have access to SharePoint sites by default, they can access and configure anything in Central Administration. With this access, they can grant themselves permissions by adding themselves to the Site Collection Administrators group for a site collection or by creating a web application policy that will grant them access to any site collection within that particular web application.
Service Application Administrators
Service application management is delegated to two groups. For more details check out Chapter 7.
- Service Administrators — Delegated by members in the Farm Administrators group, these users can manage settings for a specific service application within the server farm. These users cannot access any other service application unless they are given access by a farm administrator. Members of this group cannot create new service applications or perform any farm-level operations. To manage the Service Administrators, go to Central Administration Manage Service Applications (under the Application Management header). Highlight a service and in the Ribbon, under the Service Applications tab, click on Administrators.
- Feature Administrators — Delegated by farm or service administrators, members of this group are associated with a specific feature within a service application. Users can manage the subset of service application settings related to this feature, but only for this feature. Most service applications do not have this flexibility. An example of one that does have this capability is the User Profile service application. Here you can drill down and give users very specific permissions such as the ability to only manage audiences or profiles. To manage the Feature Administrators, go to Central Administration Manage Service Applications (under the Application Management header). Highlight a service and in the Ribbon, under the Service Applications tab, click on Permissions. If the service is available in the Permissions for user section you will see multiple permissions you can assign.
Site Collection Administrators
Members of the Site Collection Administrators group have Full Control permission level settings for all sites within the site collection. This access cannot be overridden for this site collection except through a web application policy, and this access is available to all content, whether the users are given explicit permissions or not. In addition to the administrative capabilities, the Primary and Secondary Site Collection Administrators receive additional notifications for quotas and user access requests. The Primary and Secondary Site Collection Administrators are specified when the site collection is created.
To manage users in a Site Collection Administrators group you have two options. For the first option:
1. Open Central Administration.
2. Click Application Management.
3. Under Site Collections, click Change site collection administrators. On the Site Collection Administrators page that appears (see Figure 8-3), you must select a site collection, and then you can add users as Primary or Secondary site collection administrators. Only one user can be added as a Primary site collection administrator; likewise for the Secondary site collection administrator. User groups cannot be entered for either of these sections.
The other option for managing the Site Collection Administrators group is from the site collection itself:
1. From the top-level site in your site collection, click Site Actions Site Permissions.
2. In the Permission Tools tab, click Site Collection Administrators to display the screen shown in Figure 8-4.
3. Here you can add and remove users from this group, similarly to the method shown earlier for farm administrators.
As a rule, the Site Collection Administrators group can never be empty. If you try to remove all the users, you will receive an error. If you find a way to do it programmatically, very bad things happen.
Site Administration
Users in the Site Owners group have been added to the Owners group and have Full Control to content on this site. Unlike site collection administrators, this access can be overridden by customizing permissions settings on a child site or lower level. By default, if you specify this at site creation, a [site name] Owners group is created. This group’s members will have full control to the site.
Administration Beneath the Site Level
Management of content below the site level does not always require group membership:
- Document library or list — There is no specific group that manages content at this level, but permissions can be configured. This is useful when you want only a small portion of your content, on one site, to have restricted access.
- Individual items — Similar to the previous level, there is no set group that administers individual items at this level, but permissions can be configured. Providing granular control over user access is a powerful feature in SharePoint 2010.
When SharePoint is installed, a set of permissions is created. This set can be viewed by opening Central Administration and clicking on Application Management Manage Web Applications. From there, highlight a web application and click on User Permission (in the Ribbon, under the Web Applications tab). Not only can you view the available permissions, you can select the permissions that will be available for the web application and its site collections.
It is these permissions that enable administrators to configure user access at a granular level and, by doing so, secure content at various levels within SharePoint sites. Each permission level is one of three types of permissions: List, Site, or Personal. As previously mentioned, these permissions are combined to create permission levels. This method is the recommended approach for configuring SharePoint security. Figure 8-5 shows a partial list of the available options; for a more comprehensive look at permissions, see Table 8-1. This table provides the list of all permission levels, including what type of permission it is. It also displays the default permission levels that have each of these permissions out of the box.
Table 8-1: User Permissions
Permission levels are the sets of permissions that administrators use to grant users access to site content. Depending upon the access a user or group of users require, an administrator can use the out-of-the-box permission levels or create one that will fulfill the user access requirements.
Unlike permissions, permission levels are manageable from the site where they are being used. From the Site Permissions page, you can access the current permission levels available for your site. It is here you can create your own permission levels, delete existing permission levels, and modify existing permission levels.
There are a few “best practices” when it comes to managing permission levels:
- It is not a good idea to modify a default permission level. If a default permission level is not configured the way you like, you can create a new permission level.
- When you create a new permission level, you are often only changing one or more permissions assigned to a default permission level. To ensure that you keep all the desired permissions, make a copy of the default permission level and then edit the permissions for the copied permission level.
- It is not recommended to delete a default permission level. If you don’t think you need it, there is no harm in keeping it. If you need it down the road, you won’t have to create it from scratch and risk not configuring it the same way it was originally.
By default, a set of permission levels is available when a new site is created. This set of permissions will depend upon the site template that was used to create the site. For team sites there are six default permission levels:
- Full Control — Users and groups with this permission level will have access to everything on the site and can perform any site administrative tasks. This shouldn’t be confused with site collection administrators. Users and groups with Full Control permissions cannot perform site collection administrative tasks.
- Design — Can view, add, update, delete, approve, and customize. A step up from Contribute, this permission also allows users to customize the site and its pages. Additionally, this group can approve items that are in containers with Content Approval enabled. For the most part, users and groups with this permission level can do anything on the securable object except for administrative tasks.
- Contribute — Can view, add, update, and delete list items and documents. This is the standard permission level used to grant users access to content and containers when they need to add, edit, and delete content.
- Read — Can view pages and list items and download documents. This is the standard permission level for users and groups you want to access content, but not have the permissions to add, edit, or delete content.
- Limited Access — Can view specific lists, document libraries, list items, folders, or documents when given permissions. This permission level cannot be assigned. Instead, it is the result of customizing permissions for a securable object. In essence, when you see this permission level for a user or group, the users have access to a securable object in the current container, but not to all the securable objects in the container.
- View Only — Can view pages, list items, and documents. Document types with server-side file handlers can be viewed in the browser but not downloaded. The key concept here is that users and groups with this permission level can’t download copies of documents with server-side file handlers.
Figure 8-5 shows the permission levels for team sites.
To see all of the default permission levels, you have to create a site based on a Publishing site template. Only the Publishing site template deploys the total set of permission levels. These include the permission levels available with the team site as well as those in the following list:
- Restricted Read — View pages and documents. For Publishing sites only. This permission level is similar to the Read permission level, but it only has four of the eleven Read permission level permissions. Key distinctions are that users with this permission level will not be able to create alerts, browse user information, or use client integration.
- View Only — View pages, list items, and documents. If the document has a server-side file handler available, users can only view the document by using that file handler. Again, this permission level is based on the Read permission, but it doesn’t have all the same permissions. A few key distinctions are that users with this permission level will not be able to open list and document library items, browse user information, or use client integration.
- Approve — Edit and approve pages, list items, and documents. For Publishing sites only. This permission level is designed to work with the Publishing Approval workflow template. Users and groups with this permission level will be able to edit and approve items submitted, and leverage the Publishing Approval workflow. They will also be able to approve items in lists and document libraries that have Content Approval enabled.
- Manage Hierarchy — Create sites; edit pages, list items, and documents. For Publishing sites only. Similar to the Design permission, this permission level allows users to edit the design and components that make up the site. This permission level does not include all the permissions that users with the Design permission level have. A key difference is that users with the Manage Hierarchy permission level cannot approve items leveraging the Publishing Approval workflow or Content Approval features.
Figure 8-6 shows the default Publishing permission levels when using the Publishing template.
An important thing to remember when working with these permission levels is that, for the most part, moving down the hierarchy of permission levels, levels will contain all the permissions of the permission levels that precede them. Therefore, Full Control contains all the permissions of all the permission levels combined. The Contribute permission will have all the permissions of Read, Restricted Read, View Only, and Limited Access.
Creating a New Permission Level Based on an Existing Permission Level
Depending on your environment, you might find that the default permission levels aren’t adequate for the user access needs of your organization. One of the most common issues is that the Contribute permission level allows users to have Delete Items permission. To remedy this problem, you can create a new Contribute Without Delete permission level and base this new permission level on the default Contribute permission level. Rather than build a new permission from scratch, you can start with the Contribute permissions and then deselect the Delete Items permission and you will be good to go. The following procedure will walk you through this process:
1. Navigate to your top-level site.
2. Click on Site Actions and select Site Permissions (or Site Actions and select Site Settings for the Publishing site options). Under Users and Permissions, click on Site Permissions.
3. In the Ribbon, click on Permission Levels (see Figure 8-7).
4. Select the permission level that you want to use as a reference for your new permission level. For this example, the Contribute permission level will be selected.
5. Scroll down to the bottom of the page and click Copy Permission Level (see Figure 8-8).
6. You will be prompted to give the copied permission level a name, a description, and the desired permissions. Since all that is needed is to remove the Delete Items permission, simply scroll down to that permission and deselect it.
7. Scroll down to the bottom of the page and click Create. This will create your new permission level. Note that the permissions list in Figure 8-9 now includes Contribute Without Delete.
Creating a Permission Level from Scratch
If the default permission levels don’t provide a good starting point for a permission level your environment requires, you have the option to create a permission level from scratch. You start with a blank slate and select the desired permissions that will be needed.
1. Follow steps 1-3 in the preceding set of instructions to navigate to the Permissions Level page.
2. Click Add a Permission Level.
3. Enter a name and description for your new permission level. For this example, the name will be Custom Permission Level 1, with no description.
4. Select the permissions you want to be associated with the permission level and click Create. You should now see your newly created permission level in the Permission Levels page, as shown in Figure 8-10.
In step 4 of this procedure, you may notice that when you click on a permission, others are automatically selected. Some of the permissions in SharePoint are dependent upon others — selecting one automatically selects the others. For example, several other permissions are dependent on the View Items permission. Because many other permissions are related to performing actions on items, it is prudent to first be able to view the item. Therefore, if you select the Edit Items or Delete Items permissions, for example, SharePoint will automatically select the View Items permission.
Editing an Existing Permission Level
As previously mentioned, sometimes the permissions that exist on your sites are not exactly what you are looking for. Fortunately, you can edit these permission levels by selecting and deselecting the individual permissions that make up the permission level.
Following Microsoft “Best Practices,” editing default permission levels is not advised. Instead, edit custom permission levels.
The following procedure will walk you through editing a permission level that exists on a site based on the Team site template:
1. Follow the steps in the earlier instructions to navigate to the Permissions Level page.
2. Click the permission level you want to edit. If you select the Full Control or Limited Access permission levels, you will notice that all of the permissions are grayed out. You will not be able to edit these permission levels. If you select a permission level other than these two, you can deselect current permissions and/or add permissions.
3. When finished, click Submit. This will save the changes you have made. Note that this change will affect this entire site collection.
Deleting a Permission Level
In the event that you no longer wish a permission level to be available, you can remove it from the Permission Levels page:
1. Follow the steps in the earlier instructions to navigate to the Permissions Level page.
2. Select the permission level you want to delete. For this example, the Custom Permission Level 1 will be deleted. Select this permission level and click Delete Selected Permission Levels. As the option states, you can delete more than one permission level at a time if you so choose.
3. Once you click Delete Selected Permission Levels, a pop-up window will appear asking you to confirm the deletion of the selected permission level (see Figure 8-11). Click OK.
4. The selected permission level will be deleted and will no longer be available from the Permission Levels page.
When you delete a permission level it will no longer be available. When the permission level is removed, any users or groups that are leveraging this permission level for access will be removed from the Site Permissions page. In order for these users or groups to have access again, you must grant them one of the available permission levels.
So far this chapter has covered the individual permissions that make up permission levels and how these permission levels are used to grant users and groups access to SharePoint content. Now it is time to discuss the users and groups that will be assigned the previously stated permission levels.
SharePoint Security Groups
SharePoint security groups are groups of users that are created from within the browser and can be used within a given site collection. By default, SharePoint creates security groups (site groups) when a new site collection is created. The groups that are created vary according to the template that is used. The following are the site groups that may be created:
- Site Collection Administrators — This group is created for all site collection templates. It has Full Control permissions and can do anything on this site collection. These permissions cannot be overridden. When a new site collection is created, the creator has to specify a value for the primary site collection administrator, and he/she will have the option to enter a user for the secondary site collection administrator. These specified users are added to the Site Collection Administrators group and will be able to perform the administrative tasks associated with the site collection. These options are available from the Site Settings menu on the top-level site collection (see Figure 8-12). These users will also be the only users who can view the members of the Site Collection Administrators group. The Site Collection Administrators group is also accessible from the Site Permissions page of the top-level site, as shown in Figure 8-13.
- [Site collection name] Owners — This group is created for all site collection templates; by default, members of this group will have Full Control.
- [Site collection name] Members — This group is created for all site collection templates; by default, members of this group will have Contribute access.
- [Site collection name] Visitors — This group is created for all site collection templates; by default, members of this group will have Read access.
- Viewers — This group has View Only access, and is created for Collaboration and Meeting site templates.
- Approvers — This group has Approval access, and is created for Enterprise site templates and Publishing site templates.
- Designers — This group has Design access, and is created for Enterprise site templates and Publishing site templates.
- Hierarchy Managers — This group has Manage Hierarchy access, and is created for Enterprise site templates and Publishing site templates.
- Restricted Readers — This group has Restricted Read access, and is created for Enterprise site templates and Publishing site templates.
Configuring Permissions During Site Creation
When you create a new site, within an existing site collection, you select your template and then you enter a name, URL, and description for your site. To configure permissions during site creation, from the Create screen click the More Options button. The Permissions options will appear, as shown in Figure 8-14. The default value is to Use same permissions as parent site — that is, inherit permissions from the parent site. This means that access to the new site is the same as that used on the parent one. No new groups will be created.
If you select Use unique permissions (as shown in Figure 8-14) and click Create, you will be prompted to configure three new user access groups: [New site name] Owners, [New site name] Members, and [New site name] Visitors (see Figure 8-15). This creates a customized security structure and only users who are members of these groups will have access to the site.
The available default permissions will vary with the version of SharePoint 2010 you are running. SharePoint Foundation 2010 does not have all the same permissions that SharePoint Server 2010 has.
Adding a SharePoint Security Group
In addition to site groups and groups that are created when a new site is created using unique permissions, you can create your own SharePoint security groups, assuming you have sufficient permissions. This group will be usable within the entire site collection, not just within the site in which it was created. When you assign a permission level to the group, that access applies to the current securable object and all child securable objects.
This is an area where people are easily confused. When you create a SharePoint group, you can specify the group’s permission level or you can leave it blank. If you leave it blank, you can always configure the group’s access to another securable object. If you configure the group’s access, the access will only be for that securable object and any securable objects that inherit permissions from the parent. Once the SharePoint security group is created, you can navigate to any securable object’s permission settings page and add access for the group.
To add a SharePoint security group, follow these steps:
1. Navigate to the People and Groups page in any site within your site collection by clicking Site Actions Site Settings.
2. Under the Users and Permission header, click People and Groups. By default, the page will display the first SharePoint group that is listed in the Current Navigation under Groups. To see all groups within the site collection, click on the link for Groups (see Figure 8-16) to open the All Groups page.
3. Click the New drop-down menu and select New Group, as shown in Figure 8-17.
4. Enter a name and description for the new group. For this example the name will be New Group 1, with no description. Specify the Group Owner (only one user can be the group owner). Typically, the only people who can view the membership of the group are the members of that group. Additionally, only the Group Owner can edit the membership of the group. For obvious reasons, it is not a good idea to give several users this capability. You can also configure if and how you want to receive membership requests.
5. Click Create. Your group will now be created.
Deleting a SharePoint Security Group
Deleting a SharePoint security group is simple:
1. Navigate to the All Groups page (see steps 1 and 2 of the preceding “Adding a SharePoint Security Group” procedure).
2. When viewing the available groups, click the Edit icon for the desired security group.
3. Scroll down and click Delete.
Managing SharePoint Security Groups in Current Navigation
To manage SharePoint security groups, follow these steps:
1. Navigate to the People and Groups page (follow steps 1 and 2 of the “Adding a SharePoint Security Group” procedure). This procedure describes how to edit the groups displayed here.
2. Select Settings Edit Group Quick Launch, as shown in Figure 8-18.
3. Enter or remove one or more security groups from the displayed groups.
Adding Users to SharePoint Security Groups
To add users to SharePoint security groups, follow these steps:
1. Navigate to the All Groups page (follow steps 1 and 2 of the “Adding a SharePoint Security Group” procedure).
2. Select a group by clicking on the name of the group.
3. Click the New drop-down menu and select Add Users.
4. Enter the user’s name and validate.
5. Select whether or not you want to have an e-mail sent to the user informing them of their new access.
6. Click OK.
Deleting Users from SharePoint Security Groups
To delete users from SharePoint security groups, follow these steps:
1. Navigate to the All Groups page (follow steps 1 and 2 of the “Adding a SharePoint Security Group” procedure).
2. Select a group by clicking on the name of the group.
3. Select the users you want to remove.
4. Click Remove Users From Group.
The two preceding procedures are for adding and deleting users, but you can follow the same steps to add an Active Directory group to a SharePoint group. In the people picker, specify the Active Directory group, rather than the name of a user, and then validate the name. You can search for an Active Directory group the same way you search for a user.
Active Directory Groups
In addition to using SharePoint security groups, you can also use Active Directory (AD) groups. For security, you must use AD e-mail-enabled security groups. Distribution lists cannot be used. In order for an object to be used in security it must have a Security ID (SID) in Active Directory. User accounts have SIDs, so they can be used. Distribution lists do not have SIDs, which is why they cannot be used as security objects in SharePoint. AD groups and individual users are granted permissions in similar fashion. As such, their use is covered later in this chapter.
SharePoint Security Groups versus Active Directory Groups
Because you can use either SharePoint security groups or Active Directory groups, let’s discuss the benefits and downsides to using either option. In most cases, it really depends on the environment and the governance policy in place.
In most environments, the AD structure is much older than the SharePoint implementation and already setup. If your SharePoint security structure needs match those of the current AD setup, then it will be much easier to deploy AD groups, rather than recreate the same structure and add users to SharePoint security groups. If this is not the case, and your SharePoint site structure has completely different user access configuration needs, this is a picture-perfect example of when to choose SharePoint security groups over AD groups.
Another thing to consider is the user who will be managing the security structure and user access. With AD, it is almost always an information technology specialist, who may or may not have SharePoint access. With SharePoint, the site collection administrator or site owner may be an IT professional, but there is a good chance that it will be a manager or power user, who will not have AD access. Most organizations avoid turning control of IT application security over to a non-IT professional. In situations where the site collection administrator and/or site owners are non-IT members, a combined approach is common. One significant drawback to AD groups is discoverability. There is no way in SharePoint to see the members of an AD group, making it difficult or impossible to know who has access to something if AD groups are used.
Special Groups and Authentication Options
There might not always be a user or group that exactly fits the bill when you want to add permissions at a large level. If you need to provide access to a large group of people that is dynamic, you may need to employ some special tactics to open your content to everyone that needs access.
- All Authenticated Users — One AD group that can be very useful is the NT AUTHORITYAuthenticated Users group. This group represents any and all users who authenticate to your AD domain. The advantage to using this group is that for environments that will be accessible by all your domain users, this guarantees access for all your users and is easy to manage. The downside is that this group represents all your users, granting them all access. Imagine if this group were given access to secure content. As such, this option should be used with caution. This also includes trusted domains, not just the domain your SharePoint servers are in. If you are using a trusted domain for extranet users, for instance, they will all also have access to any content secured with NT AUTHORITYAuthenticated Users.
NT AUTHORITYAuthenticated Users is an Active Directory group. Use of this group requires Windows Integrated Security.
- Anonymous Access — This authentication method allows any user(s) to access your SharePoint sites. Primarily seen with Internet sites, this option is useful when the users who will be accessing your content do not have corresponding user accounts in your domain. Anonymous Access can only be enabled at the web application level. Once enabled, it can be available for all site collections and sites within the web application. Since this is configurable at the site level, it is up to the site collection and site administrators whether they want this enabled in their environments. Similar to using the NT AUTHORITYAuthenticate Users group, this option should be used with caution. Anonymous access can be configured from the Site Permissions page, as shown in Figures 8-19 and 8-20.
Anonymous Access can only be configured at the site level once it is enabled in Central Administration in the authentication settings.
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 previously 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).
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 notification.
6. Click OK.
When you first configure 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 several hundreds or thousands of users. It would be an administrative nightmare.
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.
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.
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 configure this option from the Site Permissions page. In the Ribbon you will see a link titled Manage Access Requests. You have two configuration 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.
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 configuration 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 administrators 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 application 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.
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.