>
    Configure an Admin Role Profile
    Focus
    Download PDF
    Focus
    1. Home
    2. Next-Generation Firewall
    3. Firewall Administration
    4. Manage Firewall Administrators
    5. Configure an Admin Role Profile
    Download PDF
    Next-Generation Firewall

    Configure an Admin Role Profile

    Table of Contents

    Configure an Admin Role Profile

    Configure admin role profiles in PAN-OS to define access permissions and administrative privileges for firewall administrators.
    Where Can I Use This?What Do I Need?
    NGFW (Managed by PAN-OS or Panorama)
    • No prerequisites needed
    Admin Role profiles enable you to define granular administrative access privileges to ensure protection for sensitive company information and privacy for end users.
    Follow the principle of least privilege access to create Admin Role profiles that enable administrators to access only the areas of the management interface that they need to access to perform their jobs and follow Administrative Access Best Practices.
    You can create an Admin Role profile, specify that the role applies to Virtual System, and then select Web UI, for example, and choose the part of the configuration that the administrator can control within a virtual system. Click OK to save the Admin Role Profile. Then select DeviceAdministrators, name the role, select Role Based, enter the name of the Admin Role Profile, and select the virtual system that the administrator can control. The MGT interface doesn't give full access to the firewall; access is controlled by the Admin Role.
    If the Admin Role Profile is based on Virtual System, that administrator won't have control over a virtual router. Only a subset of the Network options are available in a Virtual System role, and virtual router isn't one of the included options. If you want virtual router available in an Admin Role Profile, the role must be Device, not Virtual System. (You can define a superuser Administrator to have both Virtual System and Virtual Router access.)
    You can create a second Admin Role Profile, specify that the role applies to Device, and then select portions under Network, such as Virtual Routers. Name the Admin Role Profile, and then apply it to a different administrator.
    You might have different departments that have different functions. Based on the login, the administrator gets the right to control the objects enabled in the Admin Role Profile.
    In summary, you can't define a Virtual System Admin Role profile that includes routing (Virtual Router). You can create two accounts to have these separate roles and assign them to two different users. An Administrator account can have only one Admin Role profile.
    The MGT interface can have role-based access; it doesn't strictly provide full access to the device. The login account (Admin Role) is what gives a user rights or limited access to the objects, not the MGT interface.
    1. Select DeviceAdmin Roles and click Add.
    2. Enter a Name to identify the role.
    3. For the scope of the Role, select Device or Virtual System.
    4. In the Web UI and REST API tabs, click the icon for each functional area to toggle it to the desired setting: Enable, Read Only or Disable. For the XML API tab select, Enable or Disable. For details on the Web UI options, see Web Interface Access Privileges.
    5. Select the Command Line tab and select a CLI access option. The Role scope controls the available options:
      • Device role:
        • None—CLI access is not permitted (default).
        • superuser—Full access. Can define new administrator accounts and virtual systems. Only a superuser can create administrator users with superuser privileges.
        • superreader—Full read-only access.
        • deviceadmin—Full access to all settings except defining new accounts or virtual systems.
        • devicereader—Read-only access to all settings except password profiles (no access) and administrator accounts (only the logged in account is visible).
      • Virtual System role:
        • None—Access is not permitted (default).
        • vsysadmin—Access to specific virtual systems to create and manage specific aspects of virtual systems. Does not enable access to firewall-level or network-level functions including static and dynamic routing, interface IP addresses, IPSec tunnels, VLANs, virtual wires, virtual routers, GRE tunnels, DCHP, DNS Proxy, QoS, LLDP, or network profiles.
        • vsysreader—Read-only access to specific virtual systems to specific aspects of virtual systems. Does not enable access to firewall-level or network-level functions including static and dynamic routing, interface IP addresses, IPSec tunnels, VLANs, virtual wires, virtual routers, GRE tunnels, DCHP, DNS Proxy, QoS, LLDP, or network profiles.
    6. Click OK to save the profile.
    7. Assign the role to an administrator. See Configure a Firewall Administrator Account.

    Example Admin Role Profile Construction

    This example shows an Admin Role profile for a Security Operations Center (SOC) manager who needs access to investigate potential issues. The SOC Manager needs read access to many areas of the firewall, but generally doesn’t need write access. The example covers all four of the Admin Role Profile’s tabs and each step describes why the profile enables or disables a particular area of access to the SOC manager.
    This is an example profile for a fictional SOC manager. Configure Admin Role profiles for your administrators based on the functions they manage and the access required to do their job. Do not enable unnecessary access. Create separate profiles for each administrative group that shares the same duties and for administrators who have unique duties. Each administrator should have the exact level of access required to perform their duties and no access beyond that.
    1. Configure Web UI access permissions. Each snip of the Web UI screen shows a different area of Web UI permissions. Permissions are listed by firewall tab, in the order you see the tabs in the Web UI, followed by permissions for other actions.
      The Dashboard, ACC, and MonitorLogs areas of the firewall don’t contain configuration elements—all of the objects are informational (you can only toggle them between enable and disable because they are already read only). Because the SOC Manager needs to investigate potential issues, the SOC Manager needs access to the information on these tabs.
      The profile name and description make it easy to understand the profile’s objective. This snip doesn’t show all of the Logs permissions, but all of them are enabled for this profile.
      The next snip shows permissions for more informational objects on the Monitor tab. The SOC Manager uses these tools to investigate potential issues and therefore requires access.
      The next two snips show permissions for PDF Reports, Custom Reports, and predefined reports on the Monitor tab. While the SOC Manager needs access to PDF reports to gather information, in this example, the SOC Manager does not need to configure reports, so access is set to read-only (summary reports are not configurable). However, the SOC Manager needs to manage custom reports to investigate specific potential issues, so full access permissions are granted for all custom reports (including those not shown in the snip). Finally the SOC Manager requires access to predefined reports for investigating potential issues.
      Because the SOC Manager is an investigator and not an administrator who configures the firewall, permissions for the Policies tab are read-only, with the exception of resetting the rule hit count. Resetting the rule hit count is not one of the SOC Manager’s duties (and changing the hit count could adversely affect or confuse other administrators), so access is disabled. Read access enables the SOC Manager to investigate the construction of a policy that the SOC Manager suspects may have caused an issue.
      Permissions for the Objects tab are also read-only for the same reason—the SOC Manager’s job doesn’t require configuration, so no configuration permissions are assigned. For areas that aren’t included in the SOC Manager’s duties, access is disabled. In this example, the SOC Manager has read-only access to investigate objects configurations for all objects except URL Filtering, SD-WAN Link Management and Schedules, which are under the control of different administrators in this example.
      For Network tab permissions, the scenario is similar: the SOC Manager doesn’t need to configure any of the objects, but may need information to investigate issues, so read-only access is assigned to the areas that the SOC Manager may need to investigate. In this example, access is disabled for QoS, LLDP, Network Profiles, or SD-WAN Interface profiles because these items are not part of the SOC Manager’s duties.
      In this example, the SOC Manager needs no access to the Device tab capabilities for investigative purposes, so all Device tab permissions are blocked. In addition, investigation doesn’t require commit actions or access to any of the remaining actions, so those permissions are also blocked.
    2. Configure XML API access permissions.
      The following snip shows that all XML API permissions are disabled for the SOC Manager because the SOC Manager doesn’t access the firewall using XML API commands.
    3. Configure Command Line (CLI) access permissions.
      CLI access permissions are read-only for the SOC Manager because the SOC Manager needs access to logs and other monitoring tools and also needs to be able to see certain configurations in order to investigate potential issues. However, the SOC Manager doesn’t configure the firewall, so no configuration permissions are assigned. The access level is set to devicereader instead of to superreader because the SOC Manager doesn’t need access to password profiles or to other administrative accounts.
    4. Configure REST API access permissions.
      The SOC Manager doesn’t access the firewall using REST API commands, so all REST API access is disabled.

    © 2025 Palo Alto Networks, Inc. All rights reserved.