Guardium administrators perform various administration and maintenance tasks from the administrator portal. Any user assigned the admin role is referred to as a Guardium administrator. This is distinct from the admin user account, which is described in detail below.
Refer to the Contents panel to the left for a list of tasks usually performed by Guardium administrators.
The Guardium admin role (i.e., any user account with the role admin) has privileges that are not explicitly assigned to that role. For example, when a user with the admin role displays a list of privacy set definitions, all privacy sets defined on the Guardium system display, and the user with the admin role can view, modify, or delete any of those definitions.
When a user without the admin role accesses the list of privacy sets, that user will see only those privacy sets that he or she owns (i.e. created), and all privacy sets that have been assigned a security role that is also assigned to that user.
Use of the diag cli command requires an additional password, which can be the password of any user with the admin role.
If automatic account lockout is enabled (a feature that locks a user account after a specified number of login failures), the admin user account may become locked after a number of failed login attempts. If that happens, use the unlock admin CLI command to unlock it.
The admin user has additional privileges that are not granted to the admin role, as follows:
Access to all users' to-do lists
Owner of imported definitions
Access management functions
The To-do List is a workflow automation feature that controls the distribution of audit process results to users. The admin user has special privileges and responsibilities in this area. If a user account is disabled, all audit process results for that user will be re-assigned to the admin user automatically. If a user is unavailable for any other reason, audit process results may be "stalled" in that user's to-do list, i.e., awaiting sign-off before being released to the next results receiver. The admin user can open any user's to-do list, and take any actions available to that user. When the admin user performs any actions on another user's to-do list, that fact is noted in the audit process activity log (e.g., "User admin signed results on behalf of user x").
When definitions are exported, all roles are removed, and the owner is changed to the admin user. This is the only way to control how the definition will be used on the importing system.
By default, the Customize Pane for the admin user lists the Access Management tab, but that tab does not appear in the layout, and no access management functions can be performed. In smaller installations where access management and system administration are not separate functions, you can grant access management privileges to the admin user by logging in as the access manager (accessmgr), and assigning the accessmgr role to the admin user. The next time the admin user logs in, the Access Manager tab (and all functionality) will be available. This is possible for the admin user only (and not for other users having the admin role).
If you have assigned the accessmgr role to the admin user, and you are logged in as the admin user, and you remove accessmgr from your set of roles, the Access Management tab will disappear, but the its menu will remain, with the message "You do not have access to these portlets." Click on any other tab, and the menu and message will disappear.