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.

Creating a Private Document Library in the Project Site

Project Server contains its very own Security model. The Project Site however actually leverages off the SharePoint security model as Project Server is a SharePoint application. Certain actions such as a Project Publish event for example trigger Project Server to interpret and assign permissions of the project team in the Project site based on their individual permission set under the Project Server model.

Out of the box Project site permissions are triggered by following actions

Read Access	By adding a named Enterprise Resource to the Project schedule and the schedule has been published. The means the user would be visible under the ‘Resource Sheet’ view.
Edit Access	A named Enterprise resource is assigned to one or more tasks in the schedule and the schedule has been published. Edit access allows the user to create and edit items in lists or libraries within the project site. If using Generic resources you will need to create a dummy task in the schedule with 0% unit assignments to trigger this process.
Designer Access	This is generally provided to the project manager as the owner of the project. It extends the edit access by allowing this user to perform design type changes such as adding or modifying list columns, views and certain list or library type settings.
Full Access	Administrator access which provides Full Access to the project site.

 

This generally handles the majority of security requirements however there are situations whereby your project site requires a bit more flexibility. For example the Project Manager may require a secured area to maintain Project sensitive documentation. To achieve this requirement we can utilise the SharePoint security model but there are some rules to abide by. The following process provides instructions on how private document library can be configured and secured in a project site. Please note the same concept can be applied to any SharePoint list or library within the Project Site.

1.      Navigate to the Project site.

2.      From the ‘Site Actions’ menu select ‘New Document Library’

3.      Complete the base details. Consider turning on version control as this is a nice SharePoint feature to utilise. Click ‘Create’ to create the private document library in the Project site.

4.      Under the library tab, click ‘Library Permissions’. By default the library will inherit permissions from its parent. Since we want to secure this area and make it unique, click the ‘Stop Inheriting Permissions’ button. Click OK to confirm the change.

5.      Tick all the users you would like to remove permissions from in this library and click the ‘Remove User Permissions’ button. Ensure you leave administrator accounts and most importantly, your own account. Click ‘OK’ to confirm the change.

6.      The trick with configuring unique project permissions is to ensure the user is not associated to any of the project server permission. They are easily identified by the ‘(Microsoft Project Server)’ suffix. Let’s say a new user is granted edit (Contribute) access to the new secured document library. If you left the permission suffixed with ‘(Microsoft Project Server)’, the next time project server triggers its site synchronisation job it will note the user is a member of a Project Server monitored permission, and if the matching Project Server permissions do not provide access to that area, the permissions will be reset or removed from that user accordingly.

7.      Edit an existing user from this library by selecting the corresponding check box and click the ‘Edit User Permissions’ button.

8.      In this example we will grant Amy ‘Contribute’ access to this private documents area so Amy can edit and modify any documents within this library. Ensure we use the SharePoint equivalent and NOT the permissions with the ‘(Microsoft Project Server)’ suffix. Leaving the Project Server permission could result in a loss of permissions the next time a project site permission synchronisation job is triggered. Click OK to apply the permission change.

9.      Unique project permissions have now been applied to the new ‘Private Documents’ library within the Project Site in a way which won’t be overwritten by the Project Server Security Model.

 

Using this same technique, unique permission can be applied to any list or library within the project site. Adversely you could create a ‘Public Documents’ library which provides a more general access area. Even pure SharePoint users (Non Project Server) can be granted access to such areas of the Project Site. It is also worth mentioning this example reveals how to secure an individual document library but unique permission could also be set at an individual item level within the library or list.

The following table provides a mapping between SharePoint permissions and Project Server monitored permission within the Project Site

SharePoint Permission	Project Server Monitored Permissions	Description
Read	Readers (Microsoft Project Server)	As the name suggests, provide read access to the project site. This access is generally triggered by adding a named Enterprise Resource to the Project schedule and the schedule has been published. The means the user would be visible under the ‘Resource Sheet’ view.
Contribute	Team Members (Microsoft Project Server)	Provides edit access to the project site. A named Enterprise resource is assigned to one or more tasks in the schedule and the schedule has been published. Edit access allows the user to create and edit items in lists or libraries within the project site. If using Generic resources you will need to create a dummy task in the schedule with 0% unit assignments to trigger this permission change.
Design	Project Managers (Microsoft Project Server)	This is generally provided to the project manager as the owner of the project. It extends the edit access by allowing this user to perform design type changes such as adding or modifying list columns, views and certain list or library type settings.
Full Control	Web Administrators (Microsoft Project Server)	Administrator access which provides Full Access to the project site.

 

Even AD groups can be added and granted permission in the same way as a single user.  It is also worth mentioning SharePoint groups can also be used to maintain project site permissions.