Project Server Security question
-
quinta-feira, 9 de setembro de 2010 07:25
We are in the process of deploying project server (working with a consultant), and we noticed that anyone who was a project manager on any project was able to edit/update everything to do with ALL projects that exist within the instance of project server.
This is clearly undesirable, as we would like to be able to schedule resources across the entire company, but we don't (for example) want managers of HR projects to be able to update IT projects and vice versa.
We have been told that this is just the way it is, and that it is fixed in project SErver 2010.
Can anyone confirm that this is the case - it seems to be quite strange if this is the case?
The result that we would like to achieve is to have a single, enterprise wide instance of project server. If you are set as the project manager of a particular project, you are able to manage that project, but not be able to update (or even see) other projects if you are not involved.
Is this possible??
Thanks in advance for any assistance!
Todas as Respostas
-
quinta-feira, 9 de setembro de 2010 07:45Moderador
Hi Arduk,
there are more possibilities to change security.
Here an example that allows PMs to edit their own projects and only view projects, if they are team members. http://www.projectserverexperts.com/ProjectServerFAQKnowledgeBase/Read-OnlyAccessForPMTeamMembers.aspx I hope that will give you a point to start with. Good luck!
Barbara
-
quinta-feira, 9 de setembro de 2010 07:59Moderador
Hi arduk,
You have been told wrong!
Project Server (2003, 2007, 2010) has a very extensive security model that allows you to grant access just the way you like.
Let me briefly explain the security model to you to understand how it works:
- Users: These are the people that will work with project server. You can set security on a per users basis, but this is not recommended
- Groups: You can think of groups as security roles. You add users to one or more groups. A group is a collection of security settings that define which features are available to the users in the group. For example, you can specify that the group 'Project Managers' can logon, have access to Project Center and Resource Center in PWA, etc. Groups do not define which project they can read or edit.
- Categories: A category is a collection of objects (projects, resources and views). You can define a category as a fixed list of projects, or dynamically (all projects for which you are the owner, all projects and resources, or based on the RBS (more on this later)...).
- Category-Group permissions: you can link a category to one or more groups and vice versa, to define what actions the group can perform on the objects of the category. E.g. you can define that the group 'Project Managers' can read all projects (category My Organisation), but only edit their own projects (My Projects).
- RBS: You can set a category definition dynamically based on the Resource Breakdown Structure. The RBS is a hierachy that you assign to your resources. This is the most difficult part of defining the security, but also gives you the most control when defined correctly.
So in your case, you might want to use the RBS. The RBS should contain at least 2 branches: HR and IT. Assigne the HR value to all HR resources. Do the same for IT. Now define your categories to use the RBS. Doing so will make sure HR resources can only read and/or edit HR projects. Same for IT.
If the RBS is too difficult to use in your organisation, you can also modify security (group-category permissions) to make sure a PM can only edit his own projects.
I hope this helps,
Hans
My EPM blog: Projectopolis- Marcado como Resposta Michael Wharton, MVPMVP quinta-feira, 9 de setembro de 2010 12:37
-
sábado, 11 de setembro de 2010 08:04
Hi arduk,
You have been told wrong!
Project Server (2003, 2007, 2010) has a very extensive security model that allows you to grant access just the way you like.
Let me briefly explain the security model to you to understand how it works:
- Users: These are the people that will work with project server. You can set security on a per users basis, but this is not recommended
- Groups: You can think of groups as security roles. You add users to one or more groups. A group is a collection of security settings that define which features are available to the users in the group. For example, you can specify that the group 'Project Managers' can logon, have access to Project Center and Resource Center in PWA, etc. Groups do not define which project they can read or edit.
- Categories: A category is a collection of objects (projects, resources and views). You can define a category as a fixed list of projects, or dynamically (all projects for which you are the owner, all projects and resources, or based on the RBS (more on this later)...).
- Category-Group permissions: you can link a category to one or more groups and vice versa, to define what actions the group can perform on the objects of the category. E.g. you can define that the group 'Project Managers' can read all projects (category My Organisation), but only edit their own projects (My Projects).
- RBS: You can set a category definition dynamically based on the Resource Breakdown Structure. The RBS is a hierachy that you assign to your resources. This is the most difficult part of defining the security, but also gives you the most control when defined correctly.
So in your case, you might want to use the RBS. The RBS should contain at least 2 branches: HR and IT. Assigne the HR value to all HR resources. Do the same for IT. Now define your categories to use the RBS. Doing so will make sure HR resources can only read and/or edit HR projects. Same for IT.
If the RBS is too difficult to use in your organisation, you can also modify security (group-category permissions) to make sure a PM can only edit his own projects.
I hope this helps,
Hans
My EPM blog: Projectopolis
Here's a detailed explanation on how it works: http://msdn.microsoft.com/en-us/library/ms422445(office.12).aspxThe article still applies to 2010.
The following is for 2010, if you prefer videos: http://technet.microsoft.com/en-us/library/cc197354.aspx
-
terça-feira, 14 de setembro de 2010 04:47Thanks very much for your assistance on this one - some consultants really just don't know what they're talking about....