When Centrify built its Infrastructure Services product, implementation engineers came across many things that made it far easier to get the job done in the field. Through this field tested experience, Centrify built a script for that solution to automatically build sample OU's, groups, and content in Active Directory to make it far easier to manage the Centrify solution.
In our App Management solution however, there is a lot of flexibility on how you might build things, and sample data doesn't exist in this area. Because of this fact, this article will offer a few suggestions on sample data and practices which may make your experience with the Centrify solutions easier.
In order to set up roles, it is good to understand the components of a role in the system. Within each role you have four key elements where you can specify data, or select options. Those elements are:
- Description - This is where you name your role, and describe it's function.
- Members - This is where you add users or groups to your role for whom the role has an effect.
- Administrative Rights - This is an optional selection, but where you can define what rights the role grants in the system.
- Assigned Applications - This is the Core of App management, where you assign apps to the role for users to use.
Here are some suggestions for each of these elements to help you make the system easier to use, as well as to better document your system for new users.
In the description section, there are a few things you should know. In the current version of the Centrify solution at the time this article was written, version 17.8.169 is the current version of the cloud solution. In this version and older, you cannot rename roles. In future yet to be released versions, you CAN rename a role. This is an important feature for a few reasons.
The first reason why this is important is simply for your ongoing maintenance. You may change a role periodically and not want to change all the elements of a role. As systems evolve, this is only natural. But there is another reason which is confirmed in one service, and possible in others.
The second reason is that when you federate systems, such as Centrify with your AWS environment, you will discover that you may need to select a role from within the external solution and add OUR role to their role. AWS actually has a system limitation (again, at the time of this writing), where the Centrify Role cannot have any spaces in the name. So in the event that you walk through the step by step procedure for creating the integration into another system, and you do all the member, admin rights, and assigned apps, only to find out later that the name doesn't fit the naming convention, you can at least change that in the upcoming version.
Now, on to a documentation point regarding the Description Element. Naming your roles effectively will make your life a LOT easier when you implement the Centrify Solution. It is pretty clear that you can pick descriptive names, but an enhancement to this is to actually categorize your roles ahead of time. This can be a department, capability, or right the role grants to users. Now getting to how to name a role based on apps is not too hard, but let's put that off to later. The first way to identify the categories for your roles has to do with the Administrative Rights you may use with each role.
When you first build your roles, I would suggest you consider creating one role for each administrative right, just so you can put a user in that role and test out exactly how each one functions. Many are obvious, so this may become redundant. However, if you look at all the administrative rights, they actually group into a set of categories Naturally. Here are those categories starting from the top of the list when you open the dialog box to select:
- Device Management - There are 3 Administrative rights associated with Device Management, and define how users can interact with the Device Management features of the product.
- Enroll on Behalf of Others
- Privilege Service - There are four Administrative Rights related to Privilege Services, and these actually describe the levels of access and views into the Privilege Service.
- Power User
- User Portal Access
- System Management - There are 8 Administrative Rights that focus on Systems Management. These Administrative rights are intended to control how users can administer the system and it's capabilities.
- Linux System Enrollment
- Register Connector
Now you will note, I didn't explain any of these features. This is because it is already very well documented in our help system. My recommendation to you is to have you actually leverage that help system when filling in the Description field in the Description element of the role.
To get this description, you would have to click on the Administrative Rights item on the left, and hit the Learn More, as you can see below:
That will launch you into the help system, where you will find all of the descriptions for each Administrative Right:
Just copy the text from under the "Associated permissions" column, and paste it into the description field of the Description Element. This will create a tool tip float as well that will allow you to float over the role in the "Roles" menu, where you see all your created roles, and you can then read the complete description when it pops up for each documented role.
In the next article, I will complete the discussion on Roles, and then move on to other naming elements, and also using Categories and Tags.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.