Proper information integrity involves ensuring that data cannot be added, deleted, or changed without proper authorization. The enforcement of integrity within information systems is generally provided via access control and permissions. Access controls allow well-identified users access to a given information resource. If the user is defined as having access to the resource, permissions will define what activities that user may perform on the information resource. SharePoint Server 2007 provides the opportunity to define access controls and security permissions at various configuration levels for different reasons and to accomplish different goals. With few exceptions, SharePoint Server 2007 provides access controls by granting access to a user based on the entries defined for a given object instance. Once an entry has been found, SharePoint Server 2007 uses the associated role definition or specific assigned permissions to determine what a user can and cannot do. Because access is largely controlled via the granting of access, SharePoint Server 2007 is able to provide a security-trimmed user experience in which users see only objects within the system for which they have been given access.
SharePoint Server 2007 changes the way groups are handled compared to prior versions. Central to this change is the introduction of the SharePoint group, which is essentially a single-object type that can represent either a group of individual users who have been defined within SharePoint or an Active Directory directory services role group. The significance of this change is that it provides a single mechanism for defining a group of users, regardless of where that group of users is actually defined. This provides clear advantages over the distinction made between groups and cross-site groups in previous versions.
Many organizations have adopted Active Directory and Active Directory groups as a central element of their overall authentication strategy. As a result, they often attempt to mandate the usage of Active Directory groups when provisioning user access within SharePoint Server 2007. Although this appears to be a reasonable requirement that would be well supported by the new features, it often isn’t possible.
The following are some of the primary challenges to enforcing the strict usage of Active Directory groups within SharePoint:
Active Directory groups cannot be used to assign site collection administrators.
Active Directory group membership cannot be displayed and/or managed.
Active Directory groups for members restrict specific My Site functionality.
The choice to use Active Directory groups or SharePoint groups really depends on your specific requirements. Most likely, you will use a combination of both. Thus, the best practice is consistency in your design. Whether you primarily use Active Directory groups or SharePoint groups, deviating from your standard should be an exception and not the rule.
Active Directory groups cannot be used to provide site collection administrator access. Although it is generally considered a best practice to limit the granting of site collection administrator access to users who are directly responsible for the management of content within a specific site, this often creates difficulties when you attempt to provide support to those individuals. Consider the scenario where, in order to provide support to a site collection administrator, an individual central IT support user must have explicit site collection administrator access. This creates a problem because, in order for the central IT support user to be granted this level of access, one of two things must occur—either the site collection administrator requesting support must grant this access or the central IT support user must have farm administrator access to self-grant the needed access. In either case, there is a significant risk that the access needed to provide support may not be removed once it is no longer needed. Where the central IT support user has farm administrative access, we have created an obvious risk in that the user providing support most likely does not need such far-reaching privileges in order to accomplish his task.
If it were possible, providing the needed access via membership in an Active Directory group would provide shelter from these described risks. It would also be far easier to manage in that the group memberships used for granting users access for performing specific tasks could provide them the needed access by simply adding them to a single, predefined Active Directory group which, through automation or process, could be added to each new site collection upon creation. When a user no longer needed this level of access, it would be easy to have her removed from all site collections in the enterprise, ensuring such access did not persist beyond her justifiable need for it. Fortunately, there is a way to provide this level of access while leveraging Active Directory groups through the use of Web application security policies. Simply put, these policies provide the ability to grant access privileges to members of an Active Directory group throughout all site collections within a given Web application. To implement this, simply add a new security policy for the target Web application, and select the Full Control check box (shown in Figure 17-4). Although not exactly intuitive, this effectively makes all members of the specified Active Directory group site collection administrators for all site collections within that Web application.
Because the individual members of an Active Directory group cannot be displayed within SharePoint Server 2007, many site administrators face a challenge when attempting to find the correct group and verify its membership. This makes it difficult for information owners to ensure that the information contained in their sites is secure from unauthorized access. Compounding this challenge, it is not possible to manage the membership of an Active Directory group from within the SharePoint Server 2007 interface. This means that information owners must rely on the effective execution of proper Active Directory group management to ensure that intended users are granted access to information in a timely manner. Because inline access requests handled by SharePoint Server 2007 grant access by adding a member directly to a SharePoint Group, this access is often seen as residual because it takes no account of the membership of any Active Directory group. These challenges make it difficult to mandate the use of Active Directory groups. The inherent delays and procedures associated with doing so make management of a fluid, collaborative environment difficult and often result in a breach of the mandate, further complicating the goal of maintaining information integrity.
My Site provides many new features that, when properly implemented, offer a convenient user experience, both within the Web interface as well as within Microsoft Office 2007 applications. One new feature provides users with a convenient list of sites in which they are members. This list is available via the My Links button available on all pages within the system, as well as via the My SharePoint Sites folder found in all Office 2007 file dialogs. In order for a site to be displayed in this list for a given user, the user must be defined explicitly in the SharePoint group that is defined as the site’s associated members group (shown in Figure 17-5). In order for this highly popular feature to work, a user cannot be granted member access to a site via membership in an Active Directory group. This means users who are members must have their access provided directly from within SharePoint.
The significance of the associated members group is not limited to My Site functionality. Many common features, such as the Site Members Web part and user presence, are negatively affected should a member user be granted access to a site through Active Directory group membership.
Access to information can be controlled at many different levels within SharePoint Server 2007. The question of where best to implement control of user access is answered only with a thorough understanding of available options and implementation requirements. In this section, we will review a few best practices for taking advantage of the options available, as well as a few scenarios that place these best practices in context. The best practices are as follows:
Consider the audience and intended use of a specific site or site type when deciding how to assign permissions.
As a general rule, use SharePoint security and explicit group membership for management of site members.
As a general rule, grant access at the lowest possible level without breaking permission inheritance.
Use Web application security policies for granting broad access via tightly controlled Active Directory groups.
Create a global deny group for use when retiring user accounts.
Table 17-1 shows common site type audience/usage combinations. It’s important to understand how a site will be used and by whom. Without this information, it becomes difficult to make intelligent decisions about how to best secure the information contained within the site. It also becomes far more likely that a given site and its defined user access will morph over time, creating a scenario in which unintentional access and even participation might occur.
Table 17-1. Common Audience/Usage Combinations
Audience | Usage |
|---|---|
Member audience (equal viewers/contributors) | Team collaboration, Document collaboration, Meeting collaboration |
Wide audience (many viewers, few contributors) | Publishing site, Collaboration Portal |
Managed audience (controlled, role-specific access) | Records Center |
Collaboration sites tend to be used for the creation and development of content. More often than not, the only people who need access to these sites are those individuals directly involved in the content development process. This is especially true in the case of ad hoc collaboration sites. It is generally a best practice to limit access to collaboration sites to members, as explicitly defined within the standards those groups provided. When broad audience viewer access is granted to collaboration sites, it often results in viewer access to incomplete or confidential information.
Publishing sites tend to be used for the dissemination of approved content to a wider audience. Because most of the users accessing the site will be viewers rather than contributors, it is considered a best practice to use Active Directory groups whenever possible to grant viewer access. The rationale behind using Active Directory groups is that, because the membership of these groups is managed outside of SharePoint Server 2007, users being added to these groups over time will automatically be granted access to these sites. Ad hoc viewer access for specific individuals can optionally be added and removed as deemed necessary by site administrators.
Records Center sites have specific role groups for processing content according to the defined retention and hold policies. In most cases, the membership of these groups is tightly controlled and involves a limited number of users.
The Web application security policy settings provided through Central Administration (shown in Figure 17-6) is the only place from which you can deny access. The preconfigured role definitions created for any given Web application provide the ability to assign specific users/groups Full Control or Full Read over all objects within the Web application. You may also set access to Deny All, which effectively locks the specified user/group out of all sites located within the Web application. Once an assignment has been made at the Web application security policy level, it effectively trumps all security permission assignments on all objects within the Web application unless the specific assignment provides a higher level of permissions than those granted via the Web application level policy.
A common usage scenario for taking advantage of Web application security policies occurs when a legal or audit group needs access to an entire Web application. In most cases, these types of groups need Full Read access to information. There are three main advantages to providing this access at the Web application level rather than at the site level.
First, users in these groups can access all of the information stored within the entire Web application with Full Read permissions. In addition, they can access any information with Edit or Manage permissions located in sites for which they are specified as a user and assigned such permissions.
Second, by configuring read access at the Web application level, the ability to manage and control this access from a footprint perspective is significantly reduced because you only need to grant users access at the Web application level, whereas before you may have had to grant this group access to specific site collections or sites. Should you ever need to remove their access rights, there is only one place where you must make a settings change.
The last advantage, but not the least by any stretch, is the ability to mask the activity of users in these groups as activity performed by the system account. This eliminates audit log entries and item versions from being created by users performing discovery activities on information they do not intend to disturb, as doing so may result in altering an item’s disposition, versioning, and so on.
Site collection administrators are the most privileged administrative users within a site collection. As discussed earlier, it is not possible to use Active Directory groups to provision site collection administrator access. It is a best practice to tightly control this level of access and to limit it to individuals who will be performing specific activities that require such access. Such activities include master page customization and the management of site collection level settings for search, auditing, and object caching. Lastly, it should be noted that site collection administrators have no administrative powers above the site collection level. The risk footprint for these users is high within the site collection, but does not extend to other site collections or up into the Web application or farm levels.
Within each Microsoft Windows SharePoint Services 3.0 object, such as a site, list, or list item, at least two key pieces of information determine how that object is handled during a request. The first key piece of information is a single-object property that specifies whether the object inherits its security from its parent object. In the case of a site, this could be a subsite inheriting its security permissions from its parent site. In the case of a list, this would be the site in which the list was located, unless that site itself was inheriting its security permissions.
The second key piece of information a given object holds is an array of permission assignments. For each entry in this array, information is stored that indicates that a specific security principal (e.g., SharePoint user, Windows NT user/group) has access to the object and what specific permissions are granted to that security principal. Remember, the only place you can effectively deny access is at the Web application level; each object stored at the site collection level and below will have only grant permissions for specific users and/or groups. This is important to remember because there isn’t an easy way to grant access to a parent object (e.g., site or list) and then deny access to a specific child object (e.g., list or list item) without breaking the security inheritance for that object. Once the security inheritance is broken for a given object, its manageability is significantly reduced, as changes to the permission assignments of its parent object have no effect on it. The addition of new users/groups to the parent will not automatically grant access to the child object.
As shown in Figure 17-7, security permissions are applied within Windows SharePoint Services 3.0 at an object type level, with each level in the tree representing the object exposed through the object model. For each request of an object, the highest level of applied permissions is determined by checking assignments made at the Web application level and below. The highest level of permission available to the requestor, based on the system’s review of the permission assignments, is the permission level granted. For example, if a user has read-only access to a document but the same user is listed as a site collection administrator, the user will be granted site collection administrator access to the document, which includes the ability to both edit and delete the item.
Note
Determining user permissions can be challenging because no one interface allows for an administrator to easily check what objects a user has access to within a SharePoint site hierarchy. The SharePoint Access Checker Web Part, which is available on CodePlex, provides one option for getting some of this information. Vendor partner solutions are also available and provide a wider range of capabilities for both assessment and management of user and group security assignments.