Hello LiveCommunity Team!
I created this post to share my experience regarding an issue involving the User-ID domain mapping issue between the Prisma Access Mobile Users GlobalProtect conflict with the NGFW On-Premises.
The conflict arises when an On-Premises NGFW and Prisma Access GlobalProtect use a different user identity sources and domain NetBIOS/Domain format, leading to inconsistent security policy enforcement for Remote Mobile Users trying to access the On-Premises local resources.
Prisma Access: Configured with Cloud Identity Engine (CIE) integrated with Azure Entra ID. Remote GlobalProtect users are mapped using the NetBIOS/Domain format: acme\username
On-Premises NGFW: Configured with Agentless User-ID (Server Monitoring) reading logs directly via WinRM HTTP from local Domain Controllers (DCs). The local Active Directory servers and NGFW uses a different NetBIOS/Domain format for the Agentless configuration as follows: acme1\username with a "1".
User-ID Data Redistribution Agent: The On-Premises NGFW receives the Mobile Users User-ID mapping information from Prisma Access via an established Service Connection.
The Domain's Problem: When a Remote Mobile User connected to Prisma Access GlobalProtect with their assigned IP address e.g (172.17.0.11/24) accesses an internal resource behind the On-Premises NGFW, apparently that traffic triggers a new Kerberos/NTLM authentication event against the local Domain Controllers (DCs).
Then the DCs logs a successful login event (Event ID 4624) for that remote IP, but it associates it with the locally configured domain format as follows: acme1\username. Since the On-Premises NGFW monitors these DCs, it parses the log event and overwrites the initial Prisma Access IP mapping almost immediately after 5-10 seconds from the original Prisma Access format acme\username without the "1" to the local domain format as: acme1\username
This causes User-ID Domain Flappings between acme\username and acme1\username (and sometimes overwriting real users with machine accounts like acme1\COMPUTER-NAME$), breaking security policies matching that strictly rely on the original Prisma Access domain format as: acme\username as received initially from the redistribution agent.
NGFW On-Premises User-ID logs
The Solution: The most effective and non-disruptive solution was to isolate the data source authorities by network IP segments:
On the local NGFW, configure a user ID ACL list:
1- Go to Device > User Identification
2- Under the Include/Exclude Networks section, click Add
3- Add the Prisma Access GlobalProtect IP pool (e.g., 172.17.0.0/24) and set the Type to Exclude
4- Commit the configuration
Note: If you are using Panorama or SCM, make all these changes in the correct Template/Snippet dedicated to the local NGFW configuration avoid making a local override.
Note: Don't forget to add a lower Include entry to the 0.0.0.0/0 network or, if you prefer to be more specific, add the RFC 1918 or the internal IP address space to the Include/Exclude List on the On-Premises NGFW so the local NGFW can accepts the User-ID information of the other IP address ranges.
If you don't do this Include rule at the bottom, the NGFW will stop mapping users from local AD servers of all other IP address ranges.
The Include/Exclude Network rules are processed from top to bottom, so you'll need to configure more specific IP rules at the top and general IP ranges at the bottom.
Conclusion: By excluding the Prisma Access VPN Client IP Pool from the On-Premises NGFW User-ID Agentless Process, the local firewall completely ignores the new Windows security logs generated by Kerberos/NTLM to remote users who authenticate against local resources using the IP addresses of their Prisma Access GlobalProtect agents.
This ensures the User-ID table of the On-Premises NGFW remains a with a single data source "The Prisma Access Data Redistribution Agent" for that specific Prisma Access GlobalProtect Client IP Pool, stabilizing the mappings and fixing policy enforcement on the NGFW using the original Prisma Access Domain Format as "acme\username" without the "1", and the rest of the internal users, for example, local users or those using the local Internal Gateway of GlobalProtect, continue to be mapped as "acme1\username" seamlessly.
Another solution could be to unify a single domain across local AD servers and the Azure Entra ID; however, this process can be more difficult and time-consuming to implement correctly.
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
