Windows SharePoint Services, which is available as a free download for Windows Server 2003, packs a lot of functionality—especially for small-to-midsized businesses (SMBs) that want an inexpensive collaboration application. Often, such organizations start out using the application as a public space in which users can collaborate, share information, and track projects. Too often, limiting or securing user access to this data comes as an afterthought to management—and to administrators who are new to Windows SharePoint Services.
Has the time come to tighten up access to certain areas within your Windows SharePoint Services implementation—perhaps to document libraries that hold confidential data or to calendars that require limited distribution? Are you unsure of how to begin? If so, you'll be happy to know that Windows SharePoint Services provides an access-control model that gives you granular control over the resources that users can access and the ways in which they can do so. Let me show you the basics of how this access control works—and share some Windows SharePoint Services security tricks that I've learned along the way.
The Basic Plan
Windows SharePoint Services access control boils down to linking Windows user accounts (either accounts in the Windows SharePoint Services server's local SAM or domain accounts in Active Directory—AD) to SharePoint document libraries and lists, then defining the types of access that users can employ on the items that those libraries and lists contain. Using domain accounts is usually more efficient than using local accounts, but local accounts are viable under special circumstances (for example, if you don't have AD). Better yet, you can use Windows domain groups to further simplify the process of granting access to Windows SharePoint Services resources; this is the approach I describe in this article. When you add (aka register) users or groups to Windows SharePoint Services, you must make the user or group a member of a SharePoint site group or cross-site group. (Cross-site groups are similar to site groups; the primary difference is that you can grant cross-site groups access to any site in a SharePoint site collection, whereas site groups can access resources only in the SharePoint site in which the group is created.) You can then grant access at the site level (a SharePoint site being a group of related SharePoint Web pages), which gives users the specified rights to every list or library in the site, or at the list or library level. The basic rights that govern user access to SharePoint lists and document libraries are Add, Edit, Delete, and View Items. Additional rights, such as Manage Site Groups, Usage Data, Cancel Check-In, and Personalize Views, govern access to the site itself.
Simplify with Groups
Typically, administrators who are new to Windows SharePoint Services grant users access to SharePoint sites on an individual basis by adding user accounts to the sites that the user needs to access. However, a more practical approach is to add Windows domain groups rather than adding individual Windows user accounts. Using Windows groups lets you leverage existing groups (e.g., department groups) whose members need similar levels of access to the same resources. Adding groups is quicker and easier than having to add many individual user accounts. And when a user leaves the organization or transfers to a different department and thus changes Windows group membership, the user's access to Windows SharePoint Services will adjust accordingly; you won't need to remember to update individual Windows SharePoint Services permissions.
To grant a Windows group access to a SharePoint site, open the SharePoint site in a Web browser while logged on as a local Administrator, click the Site Settings option from the home page menu bar, then click the Site Administration link. On the Site Administration page, click the Manage Users link. On the Manage Users page, click Add Users and enter the name of the Windows group (you can add multiple groups by using semicolons to delimit the group names). The Windows group will appear under the Manage Users page's Domain Groups heading, as Figure 1 shows.
When you first add a Windows group to Windows SharePoint Services, you must select at least one SharePoint site or cross-site group to which the Windows group will belong. Site groups are specific to and exist strictly within Windows SharePoint Services and all site groups require at least View access to resources in the site. To view the site groups that are defined for a given SharePoint site, go back to the Site Administration page and click the Manage Site Groups link. Windows SharePoint services automatically creates several default site groups: Guest, Reader, Contributor, Web Designer, and Administrator. To view the permissions that have been granted to a site group, click the desired group name; doing so displays the Members page for the group. Then, click the Edit Site Group Permissions link. The Contributor site group, for example, grants members rights to Add, Edit, Delete, View Items, Browse Directories, View Pages, and all four personal rights (i.e., Manage Personal Views, Add/Remove Private Web Parts, Update Personal Web Parts, and Create Cross-Site Groups.) When you add a new Windows group to a SharePoint site group, all the Windows group members will automatically gain access to the corresponding SharePoint site resources. For example, Figure 2 shows that the marketingstaff Windows group is a member of the Contributors site group. Now, any member of marketingstaff will have all the permissions assigned to Contributors; I don't need to add each member of marketingstaff to the site. If you add a Windows group to multiple site groups, members of the Windows group gain all the permissions granted to all those site groups combined. To edit a site group's permissions or membership, click the site group name on the Manage Site Groups page to open the Edit Site Group page. This page shows you the current membership of the site group and lets you add or delete members. This page also lets you create custom site groups that function like the prebuilt groups.
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.