Cloud Portal permissions - Should permissions be granted to roles or groups?

Showing results for 
Search instead for 
Do you mean 
Participant II
Posts: 7
Registered: ‎09-06-2017
#1 of 2 1,724

Cloud Portal permissions - Should permissions be granted to roles or groups?

I'm granting access to a privileged account using the Cloud portal (on-prem) and CPS so that a user can check out the privileged account's password. I'm following some instructions and wondering if they are following best practices.


In a nutshell, we're granting view access to the domain containing the privileged account. My instructions say to assign the rights to an existing role, and that role contains an AD group. Is that correct or is it backwards? I was of the opinion that while the AD group should be a member of a particular role, I should be granting permissions in the console to that group, not directly to the role.


Any advice is appreciated.

Centrify Guru I
Posts: 2,449
Registered: ‎07-26-2012
#2 of 2 1,715

Re: Cloud Portal permissions - Should permissions be granted to roles or groups?



Great question.  Your initial assumption is not far off.


Ultimately, the product offers flexibility, and any of the practices depend on how your internal processes work today. Let's do an old identity management exercise to look at this.  Let's look at:

  • User Populations
  • Entitlements 
  • Rights: Systems, Accounts, Domains, Databases, Services, etc.
  • Scopes (Global, Set, Object)
  • Reporting


User Populations

Privilege Service can have different identity sources:  AD, LDAP, Google Directory, Centrify Directory, Federated Users and even Social Media users.  That being said, depending on how complex the organization's scenarios are, they may use one or several identity sources.  The question here is:  Should we leverage the identity source grouping or manage straight on CPS.


The way you should govern access is based on your existing process.  For example:  Let's say you have self-service workflow and approvals for users requesting access to CPS and the system is AD Security group based (e.g. the system brokers the approvals, and the final action is an add/move/change in an AD group.


Then, in that case, what I would do is leverage that same process and create AD groups that correspond to the CPS entitlements.  E.g.  Centrify-CPS-Admin;  Centrify-CPS-Users, Centrify-CPS-PowerUsers, Centrify-CPS-PortalUsers

I would in turn make CPS Roles  that contain the corresponding AD groups.  This way, you conquer several problems:

  • There is documented evidence of the approval for access to the system (in your workflow system).
  • There is no administrative burden for CPS admins to do Add/Move/Changes.
  • The attestation/audit point becomes the AD group.   This means that all you need to come audit or attestation time is to validate the memberships to each group.

Bottom-line:  The best practice to grant access to CPS entitlements is to leverage the source Directory's process.


Note that there's nothing against managing those directly in CPS roles, as long as there's an established process that enforces 



What entitlements should I grant?

The answer here varies as well.  However, the key here is separation of duties.  There are 4 CIP rights that grant access to CPS:


  • Privilege Service Administrator:  Use this sparringly.  Roles with this entitlement have access to all objects in CPS.
  • Privilege Service Power User:  This is ideal for Security Officers.  They can see all objects, but can only access objects that are explicitly granted access.
  • Privilege Service Users:  I'd say 90% of your users belong here.  This provides a "limited" administrative experience with only access to systems that they can view + a given right.
  • Privilege Service User Portal:  This does not allow the user to switch to the CPS portal, but they can access systems or accounts that they were granted the " Portal Login"  right.  This is good if a user needs access to a handful of accounts or systems.  Limited users and limited contractors belong here.

These will change over time as CPS continues to evolve monthly.  For example; we are releasing OATH2 support very soon; this will take care of many of the "headless" use cases out there.


What about workflow?

This can be a confusing topic.  Note that an approver (or a member of an approval chain) does not need access to CPS to participate in workflow.  This enforces separation of duties.



Rights vary depending on the resource type (system, account, domain, database, service, secret, etc.); but there are several things to keep in mind here.  Since 90% of your users should be using the Privilege Service User entitlement, make sure that you grant the view permission to the objects they need to see.

As far as rights go, here are some quick hits:

  • Leverage temporary access controls.  If someone needs access to an object "forever"  give them access for a year.
  • Secure access (login instead checkout) is much better than both.  Checkout is for break glass.
  • If you see the list of Portal Login systems being requested growing, switch the user to PSU.
  • Keep in mind that for SSH Jumpbox access there are two rights:  shell and file transfer.
  • For objects related to sensitive data, leverage MFA.



Since early this year CPS introduced the concept of Sets.  Static sets are quite powerful since you can control the member permissions.  Leverage sets as much as you can.   Keep in mind that there is a Global Scope (for accounts and systems), AD domains are " sets"  in themselves.



Since 17.10 CPS includes the Parameterized reports (Effective Reports);  these are your friends when working with your Security counterparts.



I hope this helps.





Want to learn more about practical Centrify examples? Check out my blog at
Follow Centrify: