Collaborate in Confidence

Break It Down
By default, Windows SharePoint Services enforces access control at the site level rather than for individual objects; all resources in a SharePoint site inherit the permissions you define at the site level. If you create a subsite under an existing site, the workspace or subsite inherits the site's permissions by default. Consider the analogy of a file system. You can think of a SharePoint site as a folder; all the resources within the site are like files within that folder, and subsites beneath the site are like subfolders. Just as files and subfolders inherit permissions from the parent folder by default, so do SharePoint subsites and resources. When you create a SharePoint subsite, you have the option to Use same permissions as parent site (the default) or Use unique permissions. You can change this option at any time by opening the Site Administration page, clicking the Manage permission inheritance link, and selecting Use unique permissions. Note that when you open the Site Administration page for a subsite that's configured with to Use same permissions as parent site, you won't see the links to Manage users or Manage site groups because the subsite has no security settings of its own. Managing permissions at the site level works fine for the typical SharePoint site developed for a small group of users. But you can grant subsites or resources their own permissions, separate from the parent site. When you do so, Windows SharePoint Services flags the resource as having unique permissions and from that point on, the resource is independent of any permissions that you grant or revoke at the site level.

How do you define unique permissions for a given SharePoint resource? First, you need to change the resource's settings so that it no longer inherits permissions from the site. To view a SharePoint resource's permissions, open a resource (e.g., list, document library) on the site , then click the Modify Settings and Columns link. For example, open the home page of a site built by using the Team Site template (a site template is a prebuilt site designed for a specific purpose; you can create a copy of the template when you need that type of site), click the Events list link to display the default view for that list, then click Modify Settings and Columns. Windows SharePoint Services will display the Customize Events page; click the Change permissions for this list link to open the Change Permissions: Events page. As Figure 3 shows, this page displays the current users and groups that have permissions to the Events list and their respective permissions. These permissions match those defined for each site group. If you were to create a new site group called Viewers and grant it View Items access from the Site Administration\Manage Site Groups page, you would then see a new entry on the Change Permissions: Events page, granting Viewers the View Items permission. To turn inheritance off for an object, simply make any change to the resource's permissions: Add a user or group, delete an existing user or group, or edit the permissions assigned to a current user or group. As soon as you change the resource's permissions in this way, Windows SharePoint Services removes permissions inheritance for the resource. If you want to build resource-specific permissions starting with an empty slate, simply remove all the default site groups from the resource. Only administrators will have access to the resource, so be sure you have Administrator permissions. Then, add the Windows, site, or cross-site groups to which you want to give access to the resource and grant those groups the appropriate permissions. Don't worry about the default permissions that the site group has at the site level: Because the object now has unique permissions, the group's site-level permissions have no effect.

Get Practical
Now that you're aware of some of the basic concepts behind Windows SharePoint Services access control, let's look at a practical application that requires a different approach. Suppose you have a SharePoint site that contains quite a few resources used by a project team of a few people, all of whom needed the same site-level permissions. Now, the team wants to extend limited access to a document library and discussion board to a wider group of users—but those new users can't have access to anything else on the site. First, place those new users in a Windows group—let's call it ExtendedTeamAccess. So far so good. However, you can't simply add the Windows group to a site group because all site groups must always have at least View access at the site level, which would let the ExtendedTeamAccess members view resources other than the document library and discussion board. You don't want to enable unique permissions for every object in the site; doing so would complicate management too much in this case.

This is where the Guests site group comes in. As I mentioned earlier, whenever you add a Windows group to a site, you must make that Windows group a member of at least one site group. But the default Guests site group has no permissions to any objects within the site. You can't directly edit the membership of Guests, which Windows SharePoint Services maintains internally. To add ExtendedTeamAccess to the Guests site group, edit the permissions of one of the resources you want the new users to access; for example, grant ExtendedTeamAccess the View Items permission to the document library. When you do so, the document library will gain unique permissions, and Windows SharePoint Services will add ExtendedTeamAccess to the Guests site group. You can then give the Guests group View Items access to the document library. Repeat the process for the discussion board.

Let's look at another example. Suppose you want to restrict the Events calendar so that only team leaders and managers can view the calendar. You already have two AD domain groups called Team Leads and Management. Open the Change Permissions: Events page and delete the default entries for site groups. Click Add Users; on the Add Users: Events page, enter the Windows groups Team Leads and Management (delimited by semicolons). Specify the appropriate permissions—in this case View items, as Figure 4 shows. Click Next, then Finish. The Change Permissions: Events page now displays a heading called Domain Groups, and under that heading is an entry for Team Leads and Management, showing that both groups have View Items access.

Simple and Secure
Securing access to Windows SharePoint Services is easy when you understand how site-level permissions and resource-level permissions interact with Windows groups and SharePoint site and cross-site groups. Take advantage of Windows SharePoint Services' integration with Windows security so that you can avoid repetitive tasks (such as adding many users individually to Windows SharePoint Services) and the mistakes that often accompany such tasks, and so that you can leverage groups you already maintain in AD. Grant unique permissions at the resource level to further control user access to important resources while getting more mileage from the time you spend creating and maintaining your AD infrastructure.