Adding Full Admin Rights in User App/RBPM in IDM 4.5.X

As I’m sure many of you know when you are installing the NetIQ RBPM module (also known as User App or User Application) that it allows you to specify an administrator account.  This admin account is used for all sorts of behind the scenes activity and communication but it can also be used to login to the UI to perform any and all administration actions.  For developers, this account is great.  We can control the account during the install and setup process, and then we can use that account to perform all of our configuration tasks within that module without having to mess with anything else.

However, for most companies, this is not the ideal configuration to use for ongoing day to day tasks, especially companies that have groups of people that interact or manage their various IDM components.  For these groups, it is generally preferred that any user who will be managing IDM components (making changes to data, stopping/starting services, editing configurations, etc.) have their own account with the necessary rights or privileges to perform those actions.  While this is just a good protocol to use, most companies lean this way simply because of audits.  In an audit, it is important to be able to determine who made what change, when they made it, and why it was made.  Having individual accounts helps fit that bill, whereas if everyone shared a single account the audit report would not have that level of detail.

So How Do I Grant Administrator Rights To Other Users In User App?

This is where things can get tricky.  Within User App, you actually have several different aspects that users can be configured to control or edit.
Users can be a User App Administrator which allows them to manage other users to see what is in their queue or make basic configuration changes.  Users can be given a Compliance role which allows them to access the Compliance configurations.  They can be a role administrator or a role manager where as an administrator they can create role AND assign roles to users while as a manager they can only assign roles BUT not create them.

And The List Of Roles Goes On:

· User Application Administrator Assignment (configuration)
· Navigation Access Permissions (configuration)
· Compliance Administrator (role)
· Provisioning Administrator (role)
· Provisioning Manager (role)
· RBPM Application Administrator (role)
· Report Administrator (role)
· Resource Administrator (role)
· Resource Manager (role)
· Role Administrator (role)
· Role Manager (role)
· Security Administrator (role)

As you can see from the list above, most of the permissions are controlled through roles that can be assigned through the Role Catalog within User App.  Of course, this means whoever wants to assign those roles needs to be a Role Manager or Role Administrator first; like the User App admin account is by default.  Also, looking at the list above may lead you to think that if you assign someone every role that they should be able to do everything they need within the User App interfaces but you would be wrong.  And, it is also worth noting that if someone is given the administrator role they do not need the equivalent manager role.  If I am a Role Administrator I have the powers of a Role Manager and then some so it is redundant and unnecessary to specify someone for both roles.

If you have users that just need access to a specific component, like for assigning roles and resources as part of a troubleshooting exercise or special circumstances then these users can just get the Role Manager and Resource Manager roles and nothing else is needed.  With those two roles the user should have the appropriate options within their dashboard view to assign/revoke those items as needed.  If someone wanted to oversee compliance configurations then they only need the Complaince Administrator role.  But if someone needs FULL administrator rights to be able to access everything in the system like the default admin account then they need several things.

Start With The Basics

Obviously they will need each and everyone of the Administrator roles from the list above.  This means logging into the User App with an account that has rights to grant roles and then assigning all seven (7) Administrator roles to that user or group.  This can be done through the new UA screens (http://yourURL/landing) or through the classic UA screens (http://yourURL/IDMProv).

Note: Some companies may prefer to have special admin accounts created for their administrators to seperate admin rights from standard rights (a good security control) and these accounts may exist outside of the User App scope making direct assignment of any roles to the user object unavailable so alternatively, the rights/roles are assigned to a group and any members of that group inherit those rights.

As mentioned earlier, this is not enough to give users the full administrator power within the RBPM module.  With these roles assigned, the users may be able to see a lot of options but there may still be things greyed out.  For example, in the classic view (http://yourURL/IDMProv) the user may see the Administration option but clicking on it may show several tabs disabled and unselectable including the “Application Configuration” tab that allows them to flush the application cache and manage the cluster configurations.  There is also another right that needs to be granted in this tab so access to here might be nice.

In the classic view (http://yourURL/IDMProv), under the Administration section,

you will find an option on the left hand side of the screen for “User Application Administrator Assignment”.

In here, you can designate users or groups within your eDirectory (within the scope of the User Application’s configuration).  Just use the bars in the main window to select “Users”, “Groups”, or “Containers” based on your selection needs, enter part or all of the name you wish to find, click the “Go” button to filter your search, select the object(s) you wish to assign this right to, click the arrow button to add those selected objects to the “Current Assignments” field to the right, and click the “Save” button at the bottom.

If you have assigned everything up to this point, you user(s) will be able to see all of the options in the Administration page but only be able to select the “RBPM Provisioning and Security” tab while the other tabs will be greyed out and disabled (not reflected in the image below).

In order for your administrators to be able to select those other tabs and manage the settings and features within, there is one more permission that needs to be granted.  And interestingly enough, when you click the RBPM Provisioning and Security tab it defaults you to the location where this can be found; “Navigation Access Permissions”

If you change the selected item in the Navigation Area dropdown you will notice that most of the options have default trustees assigned to them (the box at the bottom of the screen).  That is, all but the Provisioning and Security option.  This is the option we need.  With no assignments here, or assignment other than our users or groups that need access, our administrators will not be able to access the Application Configuration, Page Admin, or Portlet Admin tabs of the Administration page.

To grant access to these tabs, choose your method of selection from the Delegation and Proxy Trustee dropdown menu.  Your options are User, Group, Role, or Container.  Then click the magnifying glass icon to browse your eDirectory tree (within the search scope of the User App configuration) to find and select the object(s) you wish to assign this right.  Once the selection(s) is/are made and the object(s) appear in the box, click the Save button to grant the rights.

At this point, with all of these options enabled your administrator(s) should have full access to all of the screens and configurations available in the User App UI similar to the default admin account used during the install.  However, like most applications, if the user is logged into the system when the rights are granted then he/she will need to logout and then log back in before the rights take effect.

It is also worth mentioning that giving a user these rights will allow them to perform a number of actions within the User App UI but it will not give them the ability to edit any of the underlying application configurations regarding connection to the eDirectory, application ports, URLs, etc.  All of those configurations are found in the application configuration stored on the actual application server.  To make changes to that information the user would still need login rights at the server level and rights to run the configupdate application to edit these values.