The pre-defined administrative roles configured during Authentication Manager setup have scope over the top-level security domain by default. As a result, an administrator who is assigned to a pre-defined role can modify the account of a Super Admin, because the initial Super Admin account resides in the top-level security domain as well. This is because the top-level security domain is the only security domain in the deployment when Authentication Manager is initially set up.
Before assigning a pre-defined role to an administrator, consider whether you want to maintain the default behavior, or if you want to restrict the scope of the administrators assigned these roles to a lower-level security domain that does not include Super Admins or other higher-privileged administrators. There may be situations in which you want a lower-privileged administrator to modify the account of a higher-privileged administrator.
If you do not want to use the default scope of the pre-defined administrative roles, you can avoid unintentionally granting additional privileges to an administrator by doing one of the following:
Make sure that the scope of the administrator does not include the following:
A security domain that contains the user account or token of a higher-privileged administrator.
The security domain that contains the administrator’s own token so that the administrator cannot modify his own token or other credentials to provide additional privileges to his account.
The administrator’s own security domain so that the administrator cannot modify his own account.
Create separate security domains to enforce your intended administrative scopes. For example, create one for Super Admins, one for other administrators, and one for users with no administrative role. Reduce the scope of the lower-privileged administrators to the security domains of users with no administrative role. Configure Authentication Manager according the following model:
Create a distinct security domain for Super Admins.
Place all other administrators, including those who have permission to edit users or authentication credentials, in lower-level domains.
Place all other users in another security domain.
Assign the appropriate role and scope to administrators. Make the lower-privileged administrator’s scope include only the security domain over which the administrator has authority. For example, make sure that the Help Desk administrator has scope only for the security domain of end users, and not for his own security domain or the security domain of the Super Admin. For instructions, see Change the Scope of an Administrative Role.
If you do want to allow administrators to manage the accounts of higher-privileged administrators, there are a number of ways you can configure your system to do this.
Make sure that the lower-privileged administrator does not have permission to edit the following account settings of the higher-privileged administrator, by removing permissions from the lower level account to edit authentication data of the higher level account, such as:
The credential that is required to authenticate to the Security Console, for example, the user password of a Super Admin
Assigned SecurID tokens
The ability to administer other users, including the ability to clear PINs, assign SecurID tokens and enable on-demand authentication
Note:Make sure that the administrative role assigned to the administrator does not include tasks that are not required for the administrator to perform his job. For more information, see the Help topic Edit Permissions for an Administrative Role.
If you do not use the Self-Service Console or risk-based authentication in your deployment, do the following:
Remove the Reset Password permission from the Help Desk administrator who is helping end users.
Assign the Assign Token and Reset Password permissions to an administrator other than the Help Desk administrator.
Configure Authentication Manager to require a combination of authentication credentials. If Authentication Manager requires multiple credentials, for example an on-demand tokencode and a password, at least one of which the lower-privileged administrator does not have permission to edit, the lower-privileged administrator cannot fully control the higher-privileged administrator’s authentication credentials and authenticate to the Security Console or Operations Console as the higher level administrator.