none
Security Groups RRS feed

  • Question

  • Hello,

    What's the difference between going to Resource Center, adding a new user, assigning them to a security group such as Team Members, applying those Team Members permissions globally using the Team Members Template, and going to Site Actions->Site Permissions, creating a new group, adding that same user, and assigning him to Team Members?

    I realize that using the first option is much more granular as I can add/take permissions away, but would adding a user to a new group through Site Actions->Site Permissions and assigning them to Team Members give them just as much access as going through Resource Center?

    Thanks!

    André

    Tuesday, June 16, 2015 7:10 PM

Answers

  • Andre --

    I will give you my opinion, but will gladly invite others to share their thoughts as well.  From the perspective of the Project Server administrator, your mantra should be KISS (Keep It Simple, Silly) when it comes to managing Project Server security.  This means that your general rule of managing security should almost always be to add users to security Groups to give the users the permissions they need within the system.  When one or more people need some kind of custom permissions, I strongly recommend that you create a new security Group (and optionally a new security Category, if needed), set the specific permissions for the new security Group, and then add those users to that new security Group.  This will make your life much EASIER as the Project Server administrator.

    Your second choice is a manual way of managing security for a user, and in essence you are creating a security override for that user.  How are you going to remember which users you have a manual security override?  The more of them you have, the more difficult it is to manage security in your Project Server instance.  Add users to security Groups, but NEVER add security Categories to user accounts, and NEVER set Global Permissions for any user account, since in each case you are creating a security override.

    Regarding using SharePoint permissions via a custom SharePoint group, again, you are going the manual route.  Steer clear of this.  Manage permissions by adding users to security Groups and make your life much easier.

    Hope this helps.


    Dale A. Howard [MVP]

    Tuesday, June 16, 2015 9:39 PM
    Moderator
  • Mixing and matching between Project and SharePoint for managing permissions is a potential recipe for disaster.

    First, please don't use the security templates until you've fixed them. I think you are ok with Team Members. http://aboutmsproject.com/dont-get-burned-by-your-security-templates/

    Second, if you've got permission sync turned on for PWA, there's no need to go into SharePoint to do anything so the Site Permissions is unnecessary.

    Third, if you have Project Site sync turned on, then the role of the person on the project plan already gives them the appropriate contributor rights. If they are on the project team, they automatically get access.

    Fourth, if you need to add someone to the site that isn't on the project plan, the PM can do this using the Project Permissions button on the Project Center or Project pages. Again, no need to go into SharePoint for this.

    Lastly, please don't maintain permissions at the user level. It's a trail of tears in the long run. Assigning the permissions at the group level ensures consistency.

    For editing the resource, that's a category permission as a category is simply a data feed and you want permissions to act upon the data. In the group, select a specific category and you'll see the permissions show up.

    Treb Gatte | Blog | Twitter | CIO Magazine Blog

    Tuesday, June 16, 2015 11:28 PM
    Moderator

All replies

  • Andre --

    I will give you my opinion, but will gladly invite others to share their thoughts as well.  From the perspective of the Project Server administrator, your mantra should be KISS (Keep It Simple, Silly) when it comes to managing Project Server security.  This means that your general rule of managing security should almost always be to add users to security Groups to give the users the permissions they need within the system.  When one or more people need some kind of custom permissions, I strongly recommend that you create a new security Group (and optionally a new security Category, if needed), set the specific permissions for the new security Group, and then add those users to that new security Group.  This will make your life much EASIER as the Project Server administrator.

    Your second choice is a manual way of managing security for a user, and in essence you are creating a security override for that user.  How are you going to remember which users you have a manual security override?  The more of them you have, the more difficult it is to manage security in your Project Server instance.  Add users to security Groups, but NEVER add security Categories to user accounts, and NEVER set Global Permissions for any user account, since in each case you are creating a security override.

    Regarding using SharePoint permissions via a custom SharePoint group, again, you are going the manual route.  Steer clear of this.  Manage permissions by adding users to security Groups and make your life much easier.

    Hope this helps.


    Dale A. Howard [MVP]

    Tuesday, June 16, 2015 9:39 PM
    Moderator
  • Hi Dale,

    That's a great answer and I completely agree.  This is a new environment for a new client and I'll do my best convince them to go this route (which is what I've always done in the past but I've never ran into this situation where they wanted to create groups on the fly) and hopefully they'll agree.

    Thanks again!

    André

    Tuesday, June 16, 2015 10:32 PM
  • Andre --

    For the sake of your client, please do not allow them to tell you how to set up Project Server security.  Cite industry best practices to them, tell them you have always followed these best practices, and then do your best to insist that they follow these best practices.  Good luck and let us know how this all turns out!  :)


    Dale A. Howard [MVP]

    Tuesday, June 16, 2015 10:41 PM
    Moderator
  • Thanks Dale.  I actually forgot to ask two more questions about security:

    1.  When dealing with Project Sites, those are completely different when using Site Permissions as they by default inherit permissions from PWA correct?  I generally disable inheritance and let the Project Manager take care of removing/adding which users can access their Project Site.  But if they were to create groups, those permissions would be outside of the permissions from Resource Center correct (no manual override) ?

    2.  In Resource Center, when editing a users permissions, under Global Permissions, which permission(s) affects whether or not a user can add/edit users in Resource Center?

    Thanks!

    André

    Tuesday, June 16, 2015 11:06 PM
  • Mixing and matching between Project and SharePoint for managing permissions is a potential recipe for disaster.

    First, please don't use the security templates until you've fixed them. I think you are ok with Team Members. http://aboutmsproject.com/dont-get-burned-by-your-security-templates/

    Second, if you've got permission sync turned on for PWA, there's no need to go into SharePoint to do anything so the Site Permissions is unnecessary.

    Third, if you have Project Site sync turned on, then the role of the person on the project plan already gives them the appropriate contributor rights. If they are on the project team, they automatically get access.

    Fourth, if you need to add someone to the site that isn't on the project plan, the PM can do this using the Project Permissions button on the Project Center or Project pages. Again, no need to go into SharePoint for this.

    Lastly, please don't maintain permissions at the user level. It's a trail of tears in the long run. Assigning the permissions at the group level ensures consistency.

    For editing the resource, that's a category permission as a category is simply a data feed and you want permissions to act upon the data. In the group, select a specific category and you'll see the permissions show up.

    Treb Gatte | Blog | Twitter | CIO Magazine Blog

    Tuesday, June 16, 2015 11:28 PM
    Moderator
  • Thanks Dale and Treb, that was all fantastic information, very much appreciated!!

    André

    Wednesday, June 17, 2015 2:07 PM