[SOLVED User-ID Domain Mismatch]: Prisma Access CIE vs On-Premises NGFW Server Monitoring Overwrite

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

[SOLVED User-ID Domain Mismatch]: Prisma Access CIE vs On-Premises NGFW Server Monitoring Overwrite

L2 Linker

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 MU-SPNs use different user identity sources and domain NETBIOS 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 as follows: 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 name for the Agentless configuration as follows: acme1\usernamewith 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 Connections.

 

The Domain's Problem: When a remote 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, the traffic triggers a Kerberos/NTLM authentication event against the local Domain Controllers.


Then the DCs logs a successful login event (Event ID 4624) for that remote IP, but associates it with the local domain format as: acme1\username. Since the On-Premises NGFW monitors these DCs, it parses the log and overwrites the Prisma Access mapping almost immediately from the original Prisma Access format acme\username. without the "1" 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 that strictly rely on the cloud domain format as acme\usernameas received initially from the redistribution agent.


NGFW On-Premises User-ID logs

DanielSRomero_0-1781243192513.png

 

The Solution: The most effective and non-disruptive solution was to isolate the authorities by network segments:

On the On-Premises NGFW configure an 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 and Push from Panorama.

Note: Don't forget to add an 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 that accepts the User-ID information of the other IP ranges.

If you don't do this, the NGFW will stop mapping users from local AD servers of all other IPS ranges.

The Network inclusion/exclusion 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 pool from the On-Premises NGFW User-ID Agentless Process, the local firewall completely ignores the Windows security logs generated by remote users authenticating against local resources using this Prisma Access GlobalProtect Client IP Pool.
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 Prisma Access GlobalProtect Client IP ranges, stabilizing the mappings and fixing policy enforcement on the NGFW using the original Prisma Access Domain Format as "acme\username" without the 1.

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 Prisma Access User-ID 

 

0 REPLIES 0
  • 24 Views
  • 0 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!