Elevated privilege roles

  • Release version: Xanadu
  • Updated August 1, 2024
  • 2 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Elevated privilege roles

    Elevated privilege roles in ServiceNow require users to explicitly accept the responsibility of using the role to access its features. These roles are not granted automatically upon login; users must manually elevate their privileges. Elevated roles are temporary, lasting only for the current user session and are removed upon logout or session timeout. This mechanism enhances security by restricting immediate access to sensitive rights and capabilities.

    Show full answer Show less

    Key Features

    • Manual Elevation: Users must actively choose to elevate to a designated role, which is assigned by an administrator and marked as an elevated privilege role.
    • Session-Based Access: Elevated privileges persist only during the active session, ensuring that elevated access is not retained indefinitely.
    • Role Designation: Any role can be set as an elevated privilege role through the Role form, allowing customized control over sensitive permissions.
    • Role Hierarchy Considerations: Even if a user elevates to a role that contains another elevated role, they must separately elevate to each role to gain its privileges.
    • Admin Role Restrictions: Granting the admin role requires the granter to already have the admin role, and non-admin users cannot add users to groups containing the admin role.
    • Securityadmin Role Specifics: This elevated privilege role is automatically assigned to the default System Administrator and controls access to ACLs and High Security Settings. It must be manually elevated to be visible and usable.
    • Forcing Manual Elevation for Admins: Administrators can be required, via a system property, to manually select the elevated role they want to assume, improving accountability and security.

    Practical Implications for ServiceNow Customers

    By leveraging elevated privilege roles, ServiceNow customers can better secure sensitive administrative functions by ensuring that users consciously activate high-level permissions only when necessary. This reduces the risk of accidental or unauthorized use of powerful roles such as admin and securityadmin. Implementing manual elevation aligns with best practices for least privilege access and helps meet compliance requirements by limiting continuous access to elevated privileges.

    Customers should carefully assign elevated privilege roles to users, configure the manual elevation property for administrators as needed, and understand the role hierarchy to effectively manage access rights. This approach enhances security without compromising operational flexibility for administrators.

    Elevated privilege roles require you to manually accept the responsibility of using the role before you can access the features of the role.

    By default, you do not have elevated privilege roles upon login. You must manually elevate to the privilege of the role. An elevated privilege role lasts only for the duration of your user session. Session timeout or logout removes the role.

    You can designate any role as an elevated privilege role, and then assign that role to one or more users. Do this when you want to restrict users from having access to the rights that the role provides immediately after login. You can designate the privilege role on the Role form. See Create a role for instructions.

    To use an elevated role, you must meet these conditions:
    • The elevated role must be assigned to you.
    • You must manually elevate to a specific elevated role to get its privileges, even if you are already elevated to a second elevated role that contains the first elevated role.

      For example, if elevated role A contains elevated role B, even if you elevate to role A, you must still elevate to role B to get its privileges.

    The admin role

    To grant the admin role to a user, the granting user must also have the admin role. For example, a user with only the user_admin role cannot grant the admin role to other users.
    • Non-admin users cannot add a user to a group that contains the admin role.
    • To grant the security_admin role to a user, the granting user must also have the admin role and must elevate to the security_admin role before granting the security_admin role to other users. A user with only the admin role cannot grant the security_admin role to other users.
    • A user without the security_admin role cannot add a user to a group that contains the security_admin role.
    Warning:
    The use of elevated privilege on an admin role is not supported. Instead, require admins to manually elevate, see Force administrators to manually elevate

    The security_admin role

    In the base system, the security_admin role is the only role that has elevated privileges. This role is automatically assigned to the user who is the default System Administrator (admin) user. It provides access to ACLs and High Security Settings.

    Figure 1. Roles assigned to the System Administrator (admin) user
    The list of roles assigned to the System Administrator user
    Note:
    To see this role, you must actually elevate to the security_admin role first. If you are logged in as the System Administrator (admin) user only, you cannot see the security_admin record in the list of roles.