To say that the permissions interface in Office SharePoint Server 2007 (MOSS) is confusing would be an understatement. The ability to assign unique permissions to a user or group at the document library level is available and effective. But knowing how to do it might require a few minutes of your time spent reading this post and understanding more about how security is implemented in MOSS. Note that your users will want to know how to do this, so be sure to train your non-technical end-users on how to administrate permissions in MOSS. Much of what I cover in this blog is also covered in our line of end-user courses, which can be found on our web site at Mindsharp or by contacting our sales staff at email@example.com.
In the previous version of WSS/SPS, site permissions were grouped into site groups and then users and AD (Active Directory) groups were associated with the site groups. Whiel this architecture still exists in MOSS, this architecture is not enforced and different permission assignment methods are more flexible in MOSS. Permissions are now grouped into permission levels and these permission levels can be assigned directly to either an individual user or AD group. Furthermore, SharePoint groups can be populated with Active Directory (AD) user accounts and/or group accounts. So, let's get going on learning how to assign unique permissions at the document library level to a user or AD group. We'll start by looking at permissions for the document library in the Document Center, which is a default site in the Collaboration Portal site template.
To access the permissions interface, click on Site Actions, then Site Settings, then People and Groups. When you first open the permissions for a document library, you're presented with this screen in Figure 1:
The default is to show the membership of the users for the <site_name Members> group when you click on People and Groups using the Detail View. You can also select the List View from the drop down arrow if you don't want to see each user's picture. This default view lists out the users and/or AD groups that belong to this SharePoint group. In the Quick Launch pane, the other SharePoint groups that are created in this site are listed as well. If you highlight the other SharePoint groups in the Quick Launch pane, you'll find that the membership of those groups will be enumerated in the same way as you see pictured in Figure 1.
Understanding the Quick Launch Pane
The Quick Launch pane actually has three different sections, each of which is a link that expands to show you the groups, users or permissions levels for the site. These sections are:
- All People
- Site Permissions
If you want to see a listing of the Groups for this site, then click on the Groups link. Be default, this is already given to you when you entered this part of the site. If you want to see everyone who is a member of this site, regardless of their SharePoint group membership, then click the All People link. If you want to see all of the current permission levels for this site, then click the Site Permissions link, which will invoke the real permission page that you're probably looking for. The interesting thing is that this is the page (Figure 2) that you would normally expect to see when you click on People and Groups.
By default, each web part in a site inherits it's permissions from the site-level permissions. Referring back to Figure 2, you'll notice that there are no links in this view – no method to change the permission level for any given user or group for this document library. This is because permission inheritance is turned on automatically and by default, you'd have to change the permissions at the site level in order to change the permissions on the document library. Remember, that permissions in SharePoint do not act or behave like NTFS permissions where we have the ability to both inherit permissions and add unique permissions. The model in SharePoint is still one or the other: you either inherit permissions or you don't. In order to control permissions at the granular level, you must first break inheritance.
So, how do you do this? You click on the Actions menu and select Edit Permissions, as illustrated in Figure 3.
Click on this selection will prompt this pop-up box, illustrated in Figure 4:
Click OK to continue. This will break inheritance between the document library and the site's permissions. This action, as indicated in Figure 3, will copy the site's current permissions to the library, then break permission inheritance. Once permission inheritance is broken, you can then modify permissions on individual user accounts in the library. Note that each user accounts, after inheritance is broken, becomes a link to their individual permission assignments as well as receiving a check box next to their name. The checkbox allows you to select multiple users and/or groups and make identical permission changes in one administrative action. The new view of users with permission inheritance broken is seen in Figure 5.
So, How do I Change the Permissions of an Individual User?
To change the permission level assigned to an individual user or group, click on the user's or group's name, which is now a link. That will invoke the Edit Permission page, as illustrated in Figure 6. Just select the permission levels you wish to assign to the user or group, then click OK.
Working with Permission Levels
To change, modify or create new permission levels in a site, you'll need to click on the Permissions Level link from the Settings menu. Note that you'll need Administrator rights in order to accomplish this activity. This link is illustrated in Figure 7.
When you click on this link, you're taken to the Permissions Level screen (Figure 8). The default groups and their permission summaries are illustrated as well:
Notice that there are, by default, 9 different SharePoint permission levels in a Document Center document library. Notice also that there is an Edit Permission Levels link that you can click to edit these permission levels. What is incredibly interesting is that even though you have broken permission inheritance between the web part and the site, you have not yet broken inheritance between the site's permission levels and the document library's permission levels. This is because the permission inheritance for users and groups is different and distinct from the permission level inheritance between the document library and the site. If you click on the Edit Permission Levels link, you are given a similar warning message that was illustrated in Figure 4. Once you click OK, you're taken to the role.aspx page, which is illustrated in Figure 9.
It is from this menu that you can either add a new permission level or modify the existing permission levels. Once you have the permission levels they way you want them, you can assign them directly to users and/or groups in your document library so that you can maintain granular control over access to a library.
This post would be incomplete without mentioning per-item security. Per-item security is implemented in every list and document library in SharePoint Server 2007. However, permission inheritance is the default here, only now the documents in the library inherit their permissions from the document library itself. They don't inherit from the site. So even though you might break permission inheritance for the document library and permission inheritance for the permission levels, you haven't broken item-level permission inheritance within the document library. Before you can assign unique permissions to a document within the library, you'll need to break the item-level permission inheritance on a per-item basis. This means that even if you break per-item permission inheritance for one item (document) in the library, this doesn't break inheritance for the other documents in the library.
To break inheritance between the document itself and the library, click on the down arrow for the document and select Manage Permissions, as illustrated in Figure 10. When you make this selection, you're presented with a list of users and groups – along with their permission levels – that have been inherited from the web part. This page will look nearly identical to Figure 2.
If you were to click on the Edit Permissions link from the Actions menu (this will be the only menu option available), then you would be breaking inheritance for this individual document. What you will not be doing is giving per-item level permission for all items in the document library. To my knowledge, I've not found a way to globally break inheritance for all documents in a library in a single administrative action. If someone knows how to do this, please email me at firstname.lastname@example.org.
Once you have broken permissions between the individual item and the library, you'll be able to assign permissions to that document directly. Note that you can break per-item permission inheritance within a document library or list without having to first break inheritance between the library and the site or the library's permission levels and the site's permission levels.
So, What Are the Things I Wish I Could Do, but Can't?
Well, first of all, you cannot open an AD group from within the SharePoint interface and enumerate that group's membership for permission purposes. That feature just isn't ITB (In The Box) in SharePoint Server 2007. Secondly, you can't assign unique permissions to a selected subset of documents in a library. This must be done on a document-by-document basis. Thirdly, you can't get a report on who has permissions to which document in a library. If you need this functionality, you should consider DeliverPoint, by Barracuda Tools.
Assigning permissions to a document library or list item is something that can be done, but depending on the granularity of what you want to do, you may find that you'll need to break up to three different inheritance verticals and then create and/or assign unique permissions as needed.
For more information on Mindsharp's OnPath suite of education and consulting services, be sure to contact email@example.com. If you have questions about this post, please contact Bill English directly at firstname.lastname@example.org.