Monday, August 20, 2012

Project Server Security Demystified and Explained in 5 Mintues

Understanding Project Server Security. One of the most common places I need to extra time on when training new Project Server Administrators is the Security section. Most people generally grasp the concept of users, groups and permissions but when we throw in Categories into the equation I am often faced with blank stares and confused looks. I always pull out my trusty slide, which I’m about to share, to help me get the concept across simply… well as simple as possible J

1.       Groups. They are containers which are associated to a set of ‘global permissions’. These permissions determine what the members of the group can and can’t do in Project Server and MS Project Professional.

2.       Then we introduce Users. Many users can be associated to one or more groups. Users also contain a list of all the configurable ‘global permissions’ seen at the group level. Generally best practice is to set global permissions on groups and add users to the group to avoid the need of setting permissions at an individual level. In saying that though there may be specific needs to do this but understand with security, the more granular the requirement, the more administrative overhead it will create.

3.       Then we have Categories. Categories only do three things. They determine what projects, resources and online views can be seen by the group/user.

4.       When a category is associated to a group, we get an additional set of properties which are known as the ‘Category Permissions’. Theses category permissions determine what the group can do to the projects, and resources associated to that particular category. One or more categories can be assigned to an individual group which means each category permission set can be unique to the group.

5.       As with ‘Global Permissions’ you can also assign one or more categories to an individual user.

6.       The security model can get quite complex very quickly if care is not taken in how the system is configured. Devil is in the detail so as a general rule, keep security as simple as possible. Where required use groups to determine access and avoid setting user specific permissions as this will complicate the environmental security. It is also worth mentioning that a ‘Deny’ value on a permission will always override an ‘Allow’ Permission. If both deny and allow are not ticked then the permission will not be granted to the group/user. Allow of course will allow the permission.

 

So there you have it. Project Server Security explained in 5 minutes. Hope this helps others understand the basic principles of Project Server security. It’s not as scary as it looks but the model is so flexible it can become difficult to diagnose if you don’t set things up correctly. Let me know if this was helpful.

5 comments:

  1. Piet - a good post, I once had it explained to me that membership of a Group determines what a user can DO in the Project/PWA environment and that Categories determine what things a user can DO things TO in the Project/PWA environment with views being the medium by which they access information.

    I am always very wary of assigning Categories to individual users, far better for them to be permitted things through group membership.

    ReplyDelete
    Replies
    1. Thanks Dominic. Yes agree, best practice is to set global permissions and category permissions on a group and assign users to that group. I have seen cases of when it was valid to set user permissions but this is generaly more an exception type scenrio.

      Delete
  2. How does the RBS functionality fit into this explanation? Do you ignore the RBS for simplicity? I am referring to Project Server 2010 security.

    Thanks.

    ReplyDelete
  3. I'm extremely pleased to uncover this page.
    I wanted to thank you for ones time for this particularly wonderful read!!
    I definitely loved every part of it and I have you book marked
    to see new things in your blog.

    My blog post - make money online forum

    ReplyDelete