Hello LiveCommunity Team!
I created this post to share my experience regarding the User-ID Hub for multi-vsys environments involving some User-ID incomplete table for a specific vsys:
I have an NGFW with multiple vsys, and in each vsys I have configured a unique Data Redistribution Appointing to dedicated User-ID Agents and Panorama/NGFWs, local Agentless Server Monitoring, and Group Mappings configuration; however, I have the problem that some users and groups are not mapped to the other vsys, causing security, NAT, Decryption rules to not match according to the user ID information of every vsys.
As a solution, I configure the default base vsys1 as the User-ID Hub and centralize the User-ID and Group Mapping settings in the Hub.
User-ID Hub Conclusions
- The User-ID Hub "Master" will redistribute the User-ID information "IP-to-User and Group Mapping" to the "Slaves" or non-hub vsys but the "Slaves" or non-hub vsys doesn't will share natively their User-ID information to the User-ID Hub or to others "Slaves" non-hub vsys. This mechanism simplifies User-ID source configuration by allowing you to consolidate User-ID sources on a single virtual system the User-ID Hub "Master" vsys. The purpose is to ensure all virtual systems have consistent IP-user mappings from a central vsys.
Workaround for Non-Hub to Hub Redistribution: If there is a requirement for IP-user mappings learned by a non-hub virtual system to be available on the User-ID Hub, a workaround involves configuring the non-hub virtual system to act as a client to Panorama or another NGFW. In this scenario, Panorama or the other NGFW would then learn the IP-user mappings and Group Mapping from the non-hub virtual system and subsequently redistribute them to the Hub virtual system. The redistribution path would be: non-hub vsys > Panorama/Other NGFW > hub vsys
- If custom Service Routes are not configured per vsys on each vsys, they will all use the Global Service Route to route their messages to external services such as (DNS, EDL, LDAP, SAML, UIA, etc.). Therefore, in this scenario, use a single central User-ID Hub with a Central User-ID configuration to the same sources on it, for example (UIA, User-ID Agentless, Data Redistribution, Group Mapping), since all this user ID information will be shared with the "Slave" or non-hub vsys.
- Consolidate your User-ID sources and migrate them from non-hub vsys to the designated User-ID hub virtual system, removing unnecessary, dupplicated or outdated sources from other non-hub virtual systems. This setup ensures that if a non-hub virtual system needs to identify a user for policy enforcement or logging and doesn't find the mapping locally, it will query the User-ID Hub for the necessary information.
- IP address and Port-to-username mapping information learned from Terminal Server Agents (TSA) is not shared between the User-ID Hub and the non-hub virtual systems.
Possible workaround for Central Hub TSA Redistribution (Needs to be tested): A workaround involves configuring the User-ID Hub virtual system to act as a server to Panorama or another NGFW. In this scenario, Panorama or the other NGFW would then learn the IP-user-and-Port mappings and Group Mapping from the User-ID Hub virtual system and subsequently redistribute them to the non-hub virtual system. The redistribution path would be: central hub vsys > Panorama/Other NGFW > non-hub vsys
- The current vsys User-ID information cache will remain active on every Hub and non-hub vsys until there's a new user Logon process that maps the user on the User-ID Hub vsys. If you change to a central User-ID hub the User-ID configurations (UIA, Agentless, Group Mapping) needs to wait the caché timeout from every non-hub vsys to expire to start learning User-ID information from the central User-ID Hub. If you needs a faster convergence between the User-ID Hub and non-hub vsys, make a clear for the user-id information on the specific vsys CLI so the User-ID Hub information then can be distributed to the other vsys.
- Cheat Sheet CLI vsys User-ID information:
| PAN-OS CLI Command |
Function Description / Use Case |
| show system info | match vsys |
Displays basic system properties filtered by the 'vsys' keyword. Crucial for verifying whether the Multi-VSYS capability is enabled on the device and checking the total number of configured virtual systems. |
| show session meter |
Displays the maximum concurrent session capacity supported by the current physical hardware or VM model alongside real-time consumption metrics. Helps engineers verify if the firewall is nearing its operational limit. |
| set system setting target-vsys vsys1 |
Switches the operational context of the current CLI session to a specific virtual system (in this case, 'vsys1'). It allows execution of verification and troubleshooting commands scoped entirely to that target VSYS. |
| show user user-id-agent statistics |
Provides comprehensive statistical metrics regarding connections with external User-ID agents. Displays messaging counters, connection health status, and continuous log event parsing rates. |
| show user user-ids all |
Displays the complete database of active user identities learned by the firewall. Helpful for confirming that specific user strings are known to the plane and available for security policy matching. |
| show user ip-user-mapping all |
Displays the firewall's active IP-to-User mapping table. It provides granular visibility into the source IP address, assigned username, discovery method (Agent, AD, Syslog, etc.), remaining Time-to-Live (TTL), and domain. |
| show user group list |
Lists all directory groups that have been successfully retrieved and parsed by the firewall from configured directory sources (such as Active Directory or LDAP servers). Helps verify proper group synchronization. |
| show user group-mapping state all |
Shows the health and operational status of all configured Group Mapping profiles. Verifies whether active LDAP/AD communication channels are running normally and timestamps the most recent directory synchronization. |
| show user group-mapping statistics |
Provides performance statistics concerning the group mapping process, including total numbers of synchronized groups, user-per-group distributions, and corresponding sub-process memory footprints. |
| set system setting target-vsys none |
Reverts the current CLI operational context back to the global default non-vsys mode. Clears the specific VSYS scope so the engineer can run system-wide visibility commands that span across the entire hardware appliance. |
Thank you for your time, and I hope this information is helpful in your daily cybersecurity work. I would greatly appreciate your support by liking or accepting this as a useful post; it would help me a lot in becoming a CyberElite!
Best Regards,
Daniel Romero
Senior Network/Security Engineer
PANW Partner
NGFW GlobalProtect User-ID Prisma Access Panorama Strata Cloud Manager
