Configure Your Prisma Access Deployment to Retrieve Group Mapping

After you configure User-ID mapping in Prisma Access, you need to be able to retrieve the current IP address-to-username and username-to-user group information for mobile users and users at remote networks. To allow the Panorama that manages your deployment to retrieve group mapping information, you must add one or more next-generation firewalls to your deployment and then designate the firewall as a Master Device . You then create policies in Panorama and enforce the policies using the list of user groups that Panorama retrieved from the Master Device.

Panorama cannot retrieve group mapping information in Prisma Access deployments without next-generation firewalls, because Prisma Access does not have any devices in its device groups that you can specify as a Master Device . If you have a standalone Prisma Access deployment, you can still implement User-ID mapping in policies by using long-form Distinguished Name (DN) entries.

• Retrieve Group Mappings Using a Master Device
• Configure an on-premises or VM-Series Firewall as a Master Device
• Implement User-ID in Security Policies For a Standalone Prisma Access Deployment

Retrieve Group Mappings Using a Master Device

To allow Panorama to collect group mappings, you need to add a device group, then designate one or more next-generation firewalls as a Master Device . You can configure either an on-premises firewall or a VM-series firewall as a master device.

Diagram: Group Mapping Retrieval via Master Device

flowchart TD
    subgraph Corporate_Network ["Corporate Network"]
        LDAP["LDAP Server
Global Catalog"]
        UIDAgent["User-ID Agent
(Optional)"]
    end

    subgraph OnPrem_or_VM_Firewall ["On-Prem/VM-Series Firewall"]
        MasterFW[(Master Device Firewall)]
    end

    subgraph Panorama_Mgmt ["Panorama Management"]
        Pano["Panorama"]
        MasterDG["Master Device Group
(References MasterFW)"]
        ChildDG["Prisma Access Device Group
(e.g., Mobile_Users,
Child of MasterDG)"]
    end

    LDAP -- Group Info --> MasterFW
    UIDAgent -- User Mappings --> MasterFW
    MasterFW -- "1 Pushes Group Mappings
to its Device Group" --> MasterDG
    Pano -- "2 Retrieves Group Info
from Master DG" --> MasterDG
    Pano -- "3 Uses Group Info for Policies
(Applied to Child DGs like Prisma Access)" --> ChildDG

    style MasterFW fill:#cde,stroke:#333,stroke-width:2px
    style Pano fill:#ffc,stroke:#333

• To allow Panorama to collect group mapping information from mobile users , create a device group that specifies the on-premises or VM-series firewall as the Master Device and specify this device group as a Parent Device Group of the Mobile_User_Device_Group device group.
• To allow Panorama to collect group mapping information from users connected to remote networks , create a device group that specifies the on-premises or VM-series firewall as the Master Device and specify this device group as a Parent Device Group of the Remote_Network_Device_Group device group.
• To allow Panorama to collect group mapping information from users or resources available through a service connection , create a device group that specifies the on-premises or VM-series firewall as the Master Device and specify this device group as a Parent Device Group of the Service_Conn_Device_Group device group.

Auto-population of users and groups is only applicable to the parent device group that is associated with the master device. Auto-Population of users/groups is not applicable to the child device groups (the Mobile_User_Device_Group , Remote_Network_Device_Group , or Service_Conn_Device_Group , device groups). See Configure an on-premises or VM-Series Firewall as a Master Device for details.

The Master Devices can serve as the termination point of a remote network connection or service connection, but this connection method is not required for the process to work, as shown in the following example. The following figure shows a User-ID deployment where the administrator has configured an on-premises device as a Master Device . Callouts in the figure show the process.

1. A next-generation on-premises or VM-series firewall that the administrator has configured as a Master Device retrieves the latest User-ID information from the LDAP server and User-ID agent in the data center.
2. Panorama gets the list of usernames, user group names, and group mapping information from the Master Device.

Configure an on-premises or VM-Series Firewall as a Master Device

Use the following procedure to configure an on-premises or VM-series firewall as a Master Device.

Diagram: Master Device Configuration Steps

flowchart TD
    A[Start: Configure Master Device] --> B[Navigate to Panorama > Managed Devices > Device Groups]
    B --> C["Add/Edit Parent Device Group e.g. Master-DG-Service"]
    C --> D[Add On-Prem/VM Firewall to 'Devices' list]
    D --> E[Select the Firewall as Master Device]
    E --> F[Check 'Store user and groups' option]
    F --> G[Save Parent Device Group]
    G --> H["Navigate to Cloud Services > Config > Mobile Users, Remote Networks, Service Setup"]
    H --> I[Edit Settings - Gear Icon]
    I --> J["Select the created Parent Device Group in Parent Device Group dropdown"]
    J --> K[Save Prisma Access Settings]
    K --> L[Commit Changes to Panorama & Master Device]
    L --> M[End: Configuration Complete]

    style F fill:#ccf,stroke:#333
    style J fill:#ccf,stroke:#333

1. Create device groups for mobile users, remote networks, and service connection device groups as required, and specify the on-premises device as the Master Device .
   1. Select Panorama > Managed Devices > Device Groups .
   2. Add a new device group.
   3. Enter a Name for the device group.
   4. Leave the Parent Device Group as Shared .
   5. In the Devices area, select the Name of the on-premises or VM-Series device that you want to set as the Master Device .
   6. Select Store user and groups from Master Device if Reporting and Filtering on Groups is enabled in Panorama Settings .

      This option allows Panorama to locally store usernames, user group names, and group mapping information that it receives from the Master Device.

   7. Click OK .

   The following screenshot creates a Master Device to be used for the service connection.

   
2. Associate the device groups you created for your Prisma Access mobile user, remote network, or service connection deployment.
   • To associate the device group with a mobile user deployment, select Panorama > Cloud Services > Configuration > Mobile Users and edit the settings by clicking the gear icon in the Settings area and associate the device group you created for the service connection with the Parent Device Group .
   • To associate the device group with a remote network connection, select Panorama > Cloud Services > Configuration > Remote Networks and edit the settings by clicking the gear icon in the Settings area and associate the device group you created for the remote network connection with the Parent Device Group .
   • To associate the device group with a service connection, select Panorama > Cloud Services > Configuration > Service Setup and edit the settings by clicking the gear icon in the Settings area and associate the device group you created for the service connection with the Parent Device Group .
3. After you create a parent device group, Prisma Access automatically populates group mapping for the device group that is associated with the master device only. For the previous examples, the auto-population would occur only in the User-ID DG Mobile Users , User-ID DG Remote Connection , and User-ID DG Service Connection device groups, and would not populate to the Mobile_User_Device_Group, Remote_Network_Device_Group, or Service_Conn_Device_Group device groups, respectively.
4. Click OK .

Implement User-ID in Security Policies For a Standalone Prisma Access Deployment

In a standalone Prisma Access deployment without a Master Device, you can use group-based policy using long-form DN entries in Panorama. Prisma Access uses the DN entries to evaluate the User-ID-based policies you have configured in Panorama.

For example, given a User named Bob Alice who works in IT for Organization Hooli in the United States, a matching security policy may have ou=IT Staff,O=Hooli,C=US if the policy is to be applied to all IT staff, or CN=Bob Alice,ou=IT Staff,O=Hooli,C=US if the policy is only to be applied to Bob Alice.

Redistribute User-ID Information Between Prisma Access and On-Premises Firewalls

After you configure User-ID, you consistently enforce user-based policy for all mobile users and users at remote network locations by configuring User-ID redistribution to redistribute the User-ID mapping from Prisma Access to all next-generation firewalls that secure access to network resources.

Use one the following methods to redistribute User-ID mapping to mobile users and users in remote networks from an on-premises next-generation firewall and vice versa, depending on the direction in which you want to redistribute the User-IDs:

• Redistribute User-ID Information From Prisma Access to an On-Premise Firewall
• Redistribute User-ID Information From an On-Premises Firewall to Prisma Access

Redistribute User-ID Information From Prisma Access to an On-Premise Firewall

In cases where mobile users need to access a resource on a remote network location or HQ/data center and the resource is secured by an on-premises next-generation firewall with user-based policies, you must redistribute User-ID mappings from the Prisma Access mobile users and users at remote networks to the on-premises firewall. When the user connects to Prisma Access, it collects this user-to-IP address mapping and stores it.

The following figure shows two mobile users that have an existing IP address-to-username mapping in Prisma Access. Prisma Access then redistributes this mapping by way of a service connection to the on-premises firewall that secures the HQ/data center.

Diagram: Redistribution Flow - Prisma Access TO On-Prem

sequenceDiagram
    participant MU as Mobile User
    participant PA as Prisma Access (Service Connection)
    participant OnPremFW as On-Prem Firewall (HQ/Data Center)
    participant Resource as Protected Resource

    MU ->> PA: Connects & Authenticates
    PA ->> PA: Collects/Stores IP-User Mapping for MU
    Note over PA OnPremFW: Prisma Access acts as Redistribution Agent

    PA ->> OnPremFW: Redistribute IP-User Mapping (via Service Conn)
    OnPremFW -->> PA: Ack
    OnPremFW ->> OnPremFW: Stores received mapping

    Note over MU PA OnPremFW: Later, Mobile User accesses resource

    MU ->> PA: Traffic to Resource
    PA ->> OnPremFW: Forwards Traffic (via Service Conn)
    OnPremFW ->> OnPremFW: Lookup mapping for MU's IP
    OnPremFW ->> Resource: Allow traffic based on User Policy
    Resource -->> OnPremFW: Response
    OnPremFW -->> PA: Response
    PA -->> MU: Response

To redistribute User-ID mappings from Prisma Access to an on-premises firewall, complete the following steps.

1. Configure Prisma Access as a User-ID agent that redistributes user mapping information.
   1. In the Panorama that manages Prisma Access, select Device > User Identification > User Mapping > Palo Alto Networks User-ID Agent Setup (for Panorama 9.1.x Appliances) or Device > Data Redistribution > Collector Settings (for Panorama 10.x appliances).

   Make sure that you have selected the Service_Conn_Template in the Templates drop-down at the top of the page. The User-ID agent in Prisma Access receives its User-ID mapping from the domain controller in the data center by way of the service connection.

   2. Click the gear icon to edit the settings.
   3. Select Redistribution (Panorama 9.1.x Appliances only).
   4. Provide a User-ID Collector Name and a User-ID Collector Pre-Shared Key to identify Prisma Access as a User-ID agent.
   5. Click OK to save your changes.
   
2. Configure the on-premises firewall to collect the User-ID mapping from Prisma Access.
   1. From the on-premises firewall, select Panorama > User Identification > User-ID Agents (for 9.1. x Panorama appliances) or Panorama > Data Redistribution > Agents (for Panorama 10. x appliances).
   2. Add a User-ID Agent and give it a Name .
   3. Select Host and Port .
   4. Enter the User-ID Agent Address from Prisma Access in the Host field.
   5. Enter the User-ID Collector Name and User-ID Collector Pre-Shared Key for the Prisma Access collector you created in Step 1.
   6. Click OK .
   7. Repeat these steps for each service connection.
   

Redistribute User-ID Information From an On-Premises Firewall to Prisma Access

In cases where users are at a branch location or HQ that is secured by an on-premises next-generation firewall with user-based policies, and they need to access resources at another branch location that you have secured with Prisma Access, you must redistribute User-ID mappings from the on-premises firewall to Prisma Access.

The following figure shows an HQ/Data center with an on-premises next-generation firewall with existing IP address-to-username mapping. Prisma Access connects to the firewall with a service connection, and the on-premises firewall redistributes the mapping to Prisma Access.

Diagram: Redistribution Flow - On-Prem TO Prisma Access

sequenceDiagram
    participant HQUser as HQ/Branch User
    participant OnPremFW as On-Prem Firewall (HQ/Branch)
    participant PA as Prisma Access (Service Connection)
    participant CloudResource as Protected Cloud/Branch Resource

    HQUser ->> OnPremFW: Connects & Authenticates (or traffic hits)
    OnPremFW ->> OnPremFW: Collects/Stores IP-User Mapping for HQUser
    Note over OnPremFW PA: On-Prem Firewall acts as Redistribution Agent

    OnPremFW ->> PA: Redistribute IP-User Mapping (via Service Conn)
    PA -->> OnPremFW: Ack
    PA ->> PA: Stores received mapping

    Note over HQUser OnPremFW PA: Later, HQ User accesses cloud/branch resource

    HQUser ->> OnPremFW: Traffic to Cloud Resource
    OnPremFW ->> PA: Forwards Traffic (via Service Conn)
    PA ->> PA: Lookup mapping for HQUser's IP
    PA ->> CloudResource: Allow traffic based on User Policy
    CloudResource -->> PA: Response
    PA -->> OnPremFW: Response
    OnPremFW -->> HQUser: Response

To redistribute User-ID mappings from an on-premises firewall to Prisma Access, complete the following steps.

1. Configure the on-premises firewall to redistribute User-ID information to Prisma Access.
   1. From the on-premises firewall, select Device > User Identification > User Mapping > Palo Alto Networks User-ID Agent Setup (for Panorama 9.1.x Appliances) or Device > Data Redistribution > Collector Settings (for Panorama 10.x appliances).
   2. Click the gear icon to edit the settings.
   3. Select Redistribution (9.1.x devices only).
   4. Provide a User-ID Collector Name and a User-ID Collector Pre-Shared Key to identify the on-premises firewall as a User-ID agent.
   5. Click OK to save your changes.
2. Configure Prisma Access to collect the User-ID mapping from the on-premises firewall.
   1. From the Panorama that manages Prisma Access, select Panorama > User Identification > User-ID Agents (for 9.1. x Panorama appliances) or Panorama > Data Redistribution > Agents (for Panorama 10. x appliances).

   Make sure that you have selected the Remote_Network_Template or Service_Conn_Template (depending on how Prisma Access connects) in the Templates drop-down at the top of the page.

   2. Add a User-ID Agent and give it a Name .
   3. Select Host and Port .
   4. Enter the IP address of the MGT interface or service route that the on-premises firewall uses to send user mappings in the Host field.

      For the MGT interface, you can enter a hostname instead of the IP address.

   5. Enter the User-ID Collector Name and User-ID Collector Pre-Shared Key , using the values for the collector you created for the on-premises firewall in Step 1.
   6. Click OK .

Simplified Explanation: Prisma Access User-ID Concepts & Scaling

Imagine you have two main goals:

1. Use User Groups in Prisma Access Policies: You want to create security rules in Prisma Access like "Allow the 'Engineers' group to access the code server," instead of just using IP addresses.
2. Make Sure User Info is Consistent: If a user logs in from home (via Prisma Access) or from the office (via a regular firewall), you want all your firewalls to know who that user is so policies work everywhere.

Here's a simplified explanation of the document, including how these concepts scale:

Part 1: Getting User Group Names into Panorama for Prisma Access

• The Problem: Prisma Access itself doesn't directly talk to your company's user groups (LDAP/AD). Panorama needs this list to let you build group-based policies for Prisma Access.
• The Solution: The "Master Device"
  • A "Master Device" is a helper firewall (on-prem or VM) added to Panorama.
  • Important: This Master Device firewall is placed into its own separate Device Group in Panorama (e.g., Master-Firewall-DG ). It's not placed directly into the Prisma Access Device Groups.
  • This Master Device *can* talk to your company's user group list (LDAP) and gets the full list.
  • Inside the settings for the Master-Firewall-DG , you mark the firewall as the "Master Device" and tell Panorama to store the groups learned from it.
  • Panorama queries the Master Device in this group and stores the list.

Diagram: Master Device Group Info Flow

        flowchart TD
            LDAP[("LDAP/AD
Source of Groups")] -- "1. Reads Groups" --> MasterFW[(Master Device
Firewall)]
            subgraph PanoMgmt ["Panorama"]
                 MasterDG["Master Device Group
(Contains MasterFW)"]
                 PanoApp[Panorama Application]
                 ChildDG["Prisma Access DG
(Parent = MasterDG)"]
                 PolicyEditor["Policy Editor"]
            end
            MasterFW -- "2. Populates DG" --> MasterDG
            PanoApp -- "3. Retrieves
Group List" --> MasterDG
            PanoApp -- "4. Stores List" --> PanoDB[(Panorama
Group Cache)]
            PolicyEditor -- "5. Uses Cached
Group List" --> PanoDB
            PolicyEditor -- "6. Creates Policy
for Child DG" --> ChildDG

            style MasterFW fill:#cde,stroke:#333,stroke-width:2px
            style PanoApp fill:#ffc,stroke:#333

        

• Linking it Together (Parent/Child Device Groups): How Prisma Access "Knows"
  • You edit your Prisma Access Device Groups (e.g., Mobile_User_Device_Group ).

  The Key Connection: Parent Device Group Setting

  This is how Panorama (and indirectly, Prisma Access policies) knows which group list to use: Inside the settings for the *Prisma Access* Device Group (e.g., Mobile_User_Device_Group ), you configure the "Parent Device Group" option.

  You set this "Parent Device Group" to be the specific Device Group you created earlier that contains the Master Device (e.g., you set the Parent of Mobile_User_Device_Group to be Master-Firewall-DG ).

  This explicitly tells Panorama: "When you are creating or applying policies for this Prisma Access group (the 'Child'), the list of available user groups you should use is the one being supplied by the Master Device located within that specific Parent Device Group ( Master-Firewall-DG )."
  • Visibility Note: You'll only *see* the actual list of groups populated under the Master-Firewall-DG in Panorama, not directly under the Prisma Access child groups. But the *Parent/Child link* is what makes those groups available and usable when you build policies targeting the Prisma Access child groups.
• What if I DON'T have an extra firewall (Standalone Prisma Access)?
  • You use manual long-form DN entries (e.g., ou=Engineers,... ) directly in policies. Less convenient.

• Scaling Group Retrieval (Hundreds of Firewalls / Regions)

  • Problem: Relying on one Master Device can be a bottleneck or single point of failure. Different regions might need different views of groups.
  • Solution: Multiple Master Devices/Groups:
    • You can have *multiple* Master Devices, perhaps one per region or major AD site.
    • Each Master Device lives in its *own* dedicated Master Device Group (e.g., Master-DG-EMEA , Master-DG-APAC ).
    • Panorama can retrieve group lists from *all* these Master DGs.
    • You then assign the *appropriate* Parent Master DG to the relevant Prisma Access or on-prem Device Groups based on region or function. This distributes the LDAP load and allows regional group scope.

Diagram: Scaling Group Retrieval with Multiple Masters

            graph TD
                subgraph Panorama_Mgmt ["Panorama"]
                    MasterDG_A["Master DG A
(Master FW A)"]
                    MasterDG_B["Master DG B
(Master FW B)"]
                    PanoApp[Panorama Application]
                    PrismaDG_A["Prisma Access DG A
(Parent=MasterDG_A)"]
                    PrismaDG_B["Prisma Access DG B
(Parent=MasterDG_B)"]
                end

                LDAP_A[LDAP Region A] --> MasterDG_A
                LDAP_B[LDAP Region B] --> MasterDG_B

                PanoApp --> MasterDG_A
                PanoApp --> MasterDG_B

                PanoApp --> PrismaDG_A
                PanoApp --> PrismaDG_B

                style PanoApp fill:#ffc,stroke:#333
                style PrismaDG_A fill:#eef,stroke:#333
                style PrismaDG_B fill:#efe,stroke:#333
         

Part 2: Sharing Who is Logged In (User-ID Redistribution)

• The Problem: Users move between Prisma Access and office networks. Firewalls in *both* places need the current IP address = Username mapping to apply policies correctly.
• The Basic Solution: Redistribution
  • One system (Prisma Access or On-Prem FW) sends its learned mappings to the other system that needs them.

• Scaling Redistribution (Hundreds of Firewalls / Service Connections)

  • Problem: Configuring direct redistribution between hundreds of firewalls (Prisma Access <-> On-Prem, On-Prem <-> On-Prem) creates an unmanageable "mesh". It doesn't scale.
  • Solution: Panorama as the Central Redistribution Hub:
    • This is the **recommended and most scalable method**, especially involving Prisma Access.
    • Instead of firewalls talking directly to each other, **all systems send their mappings TO Panorama** (or dedicated Log Collectors managed by Panorama).
    • **All systems query Panorama** (or Log Collectors) when they need a mapping they haven't learned locally.

Diagram: Scaled Redistribution via Panorama Hub

  sequenceDiagram
    participant PA as Prisma Access
    participant OPFW1 as On-Prem FW 1
    participant OPFW2 as On-Prem FW 2
    participant PanoHub as Panorama / Log Collector Hub
    participant UserA
    participant UserB

    UserA ->> PA: Logs In (Mobile User)
    PA ->> PA: Learns Mapping (IP_A = UserA)
    PA ->> PanoHub: Send Mapping (IP_A = UserA)

    UserB ->> OPFW1: Logs In (Office User)
    OPFW1 ->> OPFW1: Learns Mapping (IP_B = UserB)
    OPFW1 ->> PanoHub: Send Mapping (IP_B = UserB)

    Note over PA OPFW2 PanoHub: Later, traffic requires mapping lookup

    PA ->> PanoHub: Query Mapping for IP_B?
    PanoHub -->> PA: Provide Mapping (IP_B = UserB)

    OPFW2 ->> PanoHub: Query Mapping for IP_A?
    PanoHub -->> OPFW2: Provide Mapping (IP_A = UserA)

        

• Configuration (Hub Model):
  • **On-Prem Firewalls:** Configure them to send mappings TO Panorama/Log Collectors AND query Panorama/Log Collectors for unknown mappings.
  • **Prisma Access (via Templates):** Configure the Service Connection and potentially other templates to send mappings TO Panorama/Log Collectors AND query Panorama/Log Collectors for unknown mappings.
• Benefits:** Greatly simplifies configuration (each device only talks to the central hub), reduces load on individual firewalls, provides a central point for troubleshooting.
• Service Connections:** Redistribution data typically flows over existing Service Connections or management paths to Panorama/Log Collectors. You don't usually need extra tunnels *just* for redistribution when using the Panorama hub method.

Scenario 1: Mobile User (Prisma Access) accessing Office Resource (On-Prem Firewall)

1. Mobile User Connects & Mapping Learned:
   • User mobile_user connects via GlobalProtect, gets IP 10.100.1.5 .
   • Prisma Access authenticates them and now knows: 10.100.1.5 = mobile_user .
2. The Need to Share:
   • mobile_user tries to access office server 192.168.1.50 .
   • The On-Prem Firewall protecting that server needs to know who 10.100.1.5 is to apply user-based rules.
3. How Prisma Access Shares (via Service Connection & *Ideally* Panorama Hub):
   • Sharing happens over the secure Service Connection tunnel or management paths.
   • **Scalable Method:** Prisma Access sends its mapping (`10.100.1.5 = mobile_user`) TO the central Panorama/Log Collector hub.
   • **Less Scalable (Direct):** Configure specific Prisma Access nodes (via Service Connection template) to act as a direct sender TO the specific On-Prem FW.
4. Configure Prisma Access as Sender (via Panorama Template for *Direct* Method):
   • Log into **Panorama**.
   • Navigate to the User-ID/Data Redistribution settings for the Service Connection Template :
     • Pano 10.x: Device > Data Redistribution > Collector Settings
     • Pano 9.1.x: Device > User Identification > User Mapping > ... > Redistribution tab
   • Configure Prisma Access to act as a sender (Collector Name/PSK).
5. Configure On-Prem Firewall as Receiver:
   • Log into the **On-Prem Firewall**.
   • Navigate to User-ID Agent/Data Redistribution Agent settings.
   • Add Prisma Access (for *Direct* method) or Panorama/Log Collector (for *Hub* method) as the source:
     • Host (Direct): Enter the specific User-ID Agent Address IP found in Panorama > Cloud Services > Status > Network Details for the Service Connection.
     • Host (Hub): Enter the IP of Panorama or the Log Collector.
     • Enter matching Collector Name/PSK.
6. Result:
   • The On-Prem Firewall gets the mapping (either directly or via the hub).
   • When traffic from 10.100.1.5 arrives, the On-Prem Firewall knows it's mobile_user and applies the correct policies.

Scenario 2: Office User (On-Prem Firewall) accessing Cloud Resource (Prisma Access)

• Who learns mapping first? The Office Firewall.
• Who needs the mapping? Prisma Access.
• How (Scalable Method - Panorama Hub):
  1. On-Prem FW Learns & Sends to Hub: On-Prem FW learns 192.168.1.100 = jdoe and sends it TO Panorama/Log Collector.
  2. Prisma Access Queries Hub: When traffic from 192.168.1.100 reaches Prisma Access, it queries Panorama/Log Collector for the mapping.
  3. Prisma Access Uses Info: Receives 192.168.1.100 = jdoe from the hub, looks up groups (via Master Device link), and applies policy.
• How (Less Scalable - Direct):
  1. On-Prem FW Learns & Sends Directly: On-Prem FW learns mapping. Configure it as a "sender" (Collector Name/PSK).
  2. Configure Prisma Access to LISTEN Directly: In the relevant Prisma Access Template (Service Conn or Remote Network), add the On-Prem FW's IP as a User-ID Agent/Source, using the matching Collector Name/PSK.
  3. Sharing Happens Directly: On-Prem FW sends mapping over the tunnel to Prisma Access.
  4. Prisma Access Uses Info:** When traffic arrives, Prisma Access uses the mapping it received directly.

---

In Simple Terms (with Scaling):

• Use a Master Device (or multiple for scale/regions, each in its own Device Group ) so Panorama can learn user group names . Make the appropriate Master Device Group the Parent of your Prisma Access/On-Prem Device Groups so they inherit the group list for policy creation.
• Use Redistribution via Panorama as a Central Hub to share the live " IP address = Username " information efficiently between Prisma Access and hundreds of office firewalls, ensuring consistent policy enforcement everywhere.