It may be overly ambitious to expect you to
keep your security model up to date, but if there is any documentation
worth maintaining as you evolve your site design, this is the one to try
to maintain. In fact, it may not be a single document but a collection
of completed document templates (if you choose to decentralize security
management). If you always follow the best practice of assigning users
to groups rather than assigning permissions to individuals, maintaining
the document won’t be too difficult because you will only need to make
an update if you add a new group or a add unique permissions to a
securable object. Is it realistic to assume that you can keep the
security model document current in a dynamic environment? Probably not.
So you will definitely want to take advantage of the ways SharePoint
2010 allows you to “unpack” your security model directly in your site.
Here’s what you can do pretty easily:
- Check the permissions that have been assigned to a group across the entire site collection.
- On
an individual object, display the permission levels and how those
permissions were applied (for example, “given directly” or “given
through the [Site Name] Members group”).
Here’s what you can’t do with the native interface:
check the permissions that have been assigned to an individual across
the entire site collection (which should give you the best incentive
possible to try to always put users in a group and avoid giving users
individual permissions) or audit who has made security changes to
various securable objects.
Checking Permissions Assigned to a Group
To examine how permissions have been assigned to a
group across a site collection, you must have Full Control privileges.
At the root of the site collection, select Site Settings, Users and
Permissions, and then “People and groups.” Highlight the group in the
quick launch and select Settings/View Group Permissions. You will see a
list similar to the image in Figure 1,
which enumerates the permissions for the Home Visitors group in a
sample site collection. The list shows the URL of each securable object
and the permission level that has been assigned to each group. Notice
that this group has Read access to the Team Beta blog site, but that they
have Contribute permissions to the Comments list. This explicit
permission level assignment allows people who only have Read access to
the entire site (the default permission for the default SharePoint
Visitors Group) to post a comment (Contribute) to the Team Beta blog but
not generate a new post.
Displaying Permission Levels on an Object
To examine permission levels for an individual
object, you have to navigate to the object and look “under the covers”
to find out how permissions have been assigned.
If you have a very complex security model, you will have to turn over a
lot of covers to audit the security across the entire collection.
From the individual object where you want to display permissions, navigate to the settings for that object.
For a site, this will be found under Site
Settings, Users and Permissions. Click Site permissions to access the
Check Permissions button. Note that People and Groups will show
individuals and site groups that are available to the entire site
collection, not just the current site.
For a Document Library, select List Settings and then the Permissions for this list option under Permissions and Management.
When you click the Check Permissions button, you will
see the permissions that have been granted for a group or a user of
that object. While you cannot check an individual user’s permission
across the entire collection, you can
check a person’s individual permissions inside a given object. However,
you will not be able to identify that user Chris has Contribute
permissions for most documents in a document library but only Read for a
specific more secure document without examining each document to see
where unique permissions have been applied. Save yourself some audit
pain—if you are going to secure individual documents or items in a list
or library, write down what you did in your security model and keep it
current. Better still, put more secure documents in a separate document
library with more restricted access. Another best practice tip is to
create a test user account and use it for security validation. If you
are someone with security application privileges, you automatically have
access to the associated content. To verify security changes you make,
add the test user as a member of the appropriate security group. Log in
as that test user and validate that the content is accessible. Remove
the user from the group and test again to ensure content is no longer
accessible.
Figure 2
shows the results of the Check Permissions action from the perspective
of the Comments list on the Team Beta Blog site shown in Figure 8-6.
You can only enter one user or group name at a time when you check
permissions. When permissions were “managed” for this list, the Site
Owner left the Read permission level checked and then also checked the
Contribute permission level, which is why you see that this group has
both Contribute and Read permissions. Note that the “highest” set of
privileges will always apply. Because the Contribute permission level is
the same as the Read permission level with additional permissions to
add, edit, and delete items and versions, it would have been OK to uncheck the Read permission level in this example, as shown in Figure 3.
The concept of “highest” set of privileges will
always apply is an important one. This means if a user is a member of
two groups, Group A and Group B, where Group A has Read access to a site
and Group B has Contribute access, then the user is a contributor. This
is sometimes confusing from an administration perspective but can be
managed somewhat by limiting the number of security groups applied to a
securable object.
Troubleshooting
This section contains some examples of reported
issues and questions with security application in SharePoint and the
associated potential resolutions/answers. This list is not exhaustive
but is intended to demontrate some additional learning elements
associated with Share Point secuity management.
“SharePoint is denying me access to a site.” First, it is very important to note that SharePoint handles authorization but not authentication.
You can’t get to a SharePoint site without first being authenticated
(that is, associated with valid credentials). Once SharePoint knows who
you are, it applies security to determine whether you are authorized to
see all, some, or none of the content. If a user does not have access
rights, a dialog box is presented so alternate credentials may be
entered. After three failed attempts, the dialog box is removed, and the
user is redirected to an error (or access denied) page. The security
model would need to be altered to grant this user the appropriate
access.
“Certain users can no longer access their team site, and security has not been changed.” There
is a scenario worth mentioning here. If a site contributor places an
image on the site and the image is located (and secured) in a different
location, then that security is applied at the time of page rendering.
So in this example, a user may be prompted with the security dialog box
because that user does not have access to that image. This is why
security must be well-mapped in early stages where, in this case, an
openly available image library has the necessary read access.
“How do I know if I have site administration rights?”
The quickest and simplest indicator is the Site Actions button. If you
see it on a site, you have access to the underlying administration
pages. If you don’t, then you don’t!
“How do I know if I have contribution rights to a library?”
Similar to the previous point, if you see the library’s tool bar with
the associated contribution actions in the ribbon, then you do.
