<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic [SOLVED User-ID Domain Mismatch]: Prisma Access CIE vs On-Premises NGFW Server Monitoring Overwrite in Next-Generation Firewall Discussions</title>
    <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/solved-user-id-domain-mismatch-prisma-access-cie-vs-on-premises/m-p/1256190#M6963</link>
    <description>&lt;P&gt;Hello LiveCommunity Team!&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;
&lt;P&gt;I created this post to share my experience regarding an issue involving the User-ID domain mapping issue between the &lt;STRONG&gt;Prisma Access Mobile Users GlobalProtect&lt;/STRONG&gt; conflict with the &lt;STRONG&gt;NGFW On-Premises&lt;/STRONG&gt;.&lt;BR /&gt;&lt;BR /&gt;The conflict arises when an &lt;STRONG&gt;On-Premises NGFW&lt;/STRONG&gt; and &lt;STRONG&gt;Prisma Access&lt;/STRONG&gt; &lt;STRONG&gt;MU-SPNs&lt;/STRONG&gt; use different user identity sources and domain &lt;STRONG&gt;NETBIOS&lt;/STRONG&gt; &lt;STRONG&gt;format&lt;/STRONG&gt;, leading to inconsistent security policy enforcement for remote mobile users trying to access the On-Premises local resources.&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG data-index-in-node="0" data-path-to-node="13,0,0"&gt;Prisma Access:&lt;/STRONG&gt; Configured with &lt;STRONG&gt;Cloud Identity Engine&lt;/STRONG&gt; (&lt;STRONG&gt;CIE&lt;/STRONG&gt;) integrated with &lt;STRONG&gt;Azure Entra ID&lt;/STRONG&gt;. Remote GlobalProtect users are mapped using the NetBIOS/Domain format as follows: &lt;CODE data-index-in-node="162" data-path-to-node="13,0,0"&gt;acme\username&lt;/CODE&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG data-index-in-node="0" data-path-to-node="13,1,0"&gt;On-Premises NGFW:&lt;/STRONG&gt; Configured with &lt;STRONG&gt;Agentless User-ID&lt;/STRONG&gt; (&lt;STRONG&gt;Server Monitoring&lt;/STRONG&gt;) reading logs directly via &lt;STRONG&gt;WinRM HTTP&lt;/STRONG&gt; from local &lt;STRONG&gt;Domain Controllers&lt;/STRONG&gt; (&lt;STRONG&gt;DCs&lt;/STRONG&gt;). The local Active Directory servers and NGFW uses a different NetBIOS domain name for the Agentless configuration as follows: &lt;CODE data-path-to-node="13,0,0" data-index-in-node="162"&gt;acme&lt;STRONG&gt;1&lt;/STRONG&gt;\username&lt;/CODE&gt;with a "&lt;STRONG&gt;1&lt;/STRONG&gt;".&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG data-index-in-node="0" data-path-to-node="13,2,0"&gt;User-ID Data Redistribution Agent:&lt;/STRONG&gt; The &lt;STRONG&gt;On-Premises NGFW&lt;/STRONG&gt; receives the Mobile Users User-ID mapping information from Prisma Access via an established Service Connections.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-path-to-node="14"&gt;&lt;STRONG data-index-in-node="0" data-path-to-node="14"&gt;The Domain's Problem:&lt;/STRONG&gt; When a remote user connected to &lt;STRONG&gt;Prisma Access GlobalProtect&lt;/STRONG&gt; with their assigned IP address e.g (&lt;CODE data-index-in-node="60" data-path-to-node="14"&gt;172.17.0.11/24&lt;/CODE&gt;) accesses an internal resource behind the On-Premises NGFW, the traffic triggers a &lt;STRONG&gt;Kerberos/NTLM&lt;/STRONG&gt; authentication event against the local Domain Controllers.&lt;/P&gt;
&lt;P data-path-to-node="15"&gt;&lt;BR /&gt;Then the&amp;nbsp;&lt;STRONG&gt;DCs&lt;/STRONG&gt; logs a successful login event (&lt;STRONG&gt;Event ID 4624&lt;/STRONG&gt;) for that remote IP, but associates it with the local domain format as: &lt;CODE data-index-in-node="114" data-path-to-node="15"&gt;acme&lt;STRONG&gt;1&lt;/STRONG&gt;\username&lt;/CODE&gt;. Since the &lt;STRONG&gt;On-Premises NGFW&lt;/STRONG&gt; monitors these DCs, it parses the log and overwrites the Prisma Access mapping almost immediately from the original Prisma Access format &lt;CODE data-path-to-node="13,1,0" data-index-in-node="200"&gt;acme\username&lt;/CODE&gt;. without the &lt;STRONG&gt;"1"&lt;/STRONG&gt;&amp;nbsp;&lt;CODE data-path-to-node="13,1,0" data-index-in-node="200"&gt;acme&lt;STRONG&gt;1&lt;/STRONG&gt;\username&lt;/CODE&gt;&lt;BR /&gt;&lt;BR /&gt;This causes &lt;STRONG data-index-in-node="12" data-path-to-node="16"&gt;User-ID Domain Flappings&lt;/STRONG&gt; between &lt;CODE data-index-in-node="37" data-path-to-node="16"&gt;acme\username&lt;/CODE&gt; and &lt;CODE data-index-in-node="64" data-path-to-node="16"&gt;acme&lt;STRONG&gt;1&lt;/STRONG&gt;\username&lt;/CODE&gt; (and sometimes overwriting real users with machine accounts like &lt;CODE data-index-in-node="152" data-path-to-node="16"&gt;acme1\COMPUTER-NAME$&lt;/CODE&gt;), breaking security policies that strictly rely on the cloud domain format as &lt;CODE data-path-to-node="16" data-index-in-node="64"&gt;acme\username&lt;/CODE&gt;as received initially from the redistribution agent.&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;&lt;STRONG&gt;NGFW On-Premises User-ID logs&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="DanielSRomero_0-1781243192513.png" style="width: 492px;"&gt;&lt;img src="https://live.paloaltonetworks.com/t5/image/serverpage/image-id/71721iBAAFE61B4DD14219/image-dimensions/492x64?v=v2" width="492" height="64" role="button" title="DanielSRomero_0-1781243192513.png" alt="DanielSRomero_0-1781243192513.png" /&gt;&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-path-to-node="17"&gt;&lt;STRONG data-index-in-node="0" data-path-to-node="17"&gt;The Solution:&lt;/STRONG&gt;&amp;nbsp;The most effective and non-disruptive solution was to isolate the authorities by network segments:&lt;BR /&gt;&lt;BR /&gt;On the On-Premises NGFW configure an User-ID ACL list:&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;
&lt;OL start="1" data-path-to-node="18"&gt;
&lt;LI&gt;
&lt;P data-path-to-node="18,0,0"&gt;Go to &lt;STRONG data-index-in-node="6" data-path-to-node="18,0,0"&gt;Device &amp;gt; User Identification&lt;/STRONG&gt;&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P data-path-to-node="18,1,0"&gt;Under the &lt;STRONG data-index-in-node="10" data-path-to-node="18,1,0"&gt;Include/Exclude Networks&lt;/STRONG&gt; section, click &lt;STRONG data-index-in-node="50" data-path-to-node="18,1,0"&gt;Add&lt;/STRONG&gt;.&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P data-path-to-node="18,2,0"&gt;Add the Prisma Access GlobalProtect IP pool (e.g., &lt;CODE data-index-in-node="51" data-path-to-node="18,2,0"&gt;172.17.0.0/24&lt;/CODE&gt;) and set the Type to &lt;STRONG data-index-in-node="86" data-path-to-node="18,2,0"&gt;Exclude&lt;/STRONG&gt;.&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P data-path-to-node="18,3,0"&gt;Commit and Push from Panorama.&lt;/P&gt;
&lt;/LI&gt;
&lt;/OL&gt;
&lt;P data-path-to-node="19"&gt;&lt;STRONG data-index-in-node="0" data-path-to-node="19"&gt;Note:&amp;nbsp;&lt;/STRONG&gt;Don't forget to add an &lt;STRONG&gt;Include&lt;/STRONG&gt; entry to the &lt;STRONG&gt;0.0.0.0/0&lt;/STRONG&gt; network or, if you prefer to be more specific, add the &lt;STRONG&gt;RFC 1918&lt;/STRONG&gt; or the internal IP&amp;nbsp;address space to the &lt;STRONG&gt;Include/Exclude List&lt;/STRONG&gt; on the &lt;STRONG&gt;On-Premises NGFW&lt;/STRONG&gt; that accepts the User-ID information of the other IP ranges.&lt;BR /&gt;&lt;BR /&gt;If you don't do this, &lt;STRONG&gt;the NGFW will stop mapping users&lt;/STRONG&gt; from local AD servers of all other IPS ranges.&lt;STRONG data-index-in-node="0" data-path-to-node="19"&gt;&lt;BR /&gt;&lt;BR /&gt;The Network inclusion/exclusion rules&lt;/STRONG&gt; are processed from &lt;STRONG&gt;top to bottom&lt;/STRONG&gt;, so you'll need to configure more specific IP rules at the top and general IP ranges at the bottom.&lt;STRONG data-index-in-node="0" data-path-to-node="19"&gt;&lt;BR /&gt;&lt;BR /&gt;Conclusion:&lt;/STRONG&gt; By excluding the Prisma Access VPN pool from the &lt;STRONG&gt;On-Premises NGFW&lt;/STRONG&gt; &lt;STRONG&gt;User-ID Agentless Process&lt;/STRONG&gt;, the local firewall completely ignores the Windows security logs generated by remote users authenticating against local resources using this &lt;STRONG&gt;Prisma Access GlobalProtect Client IP Pool&lt;/STRONG&gt;.&lt;BR /&gt;This ensures the User-ID table of the &lt;STRONG&gt;On-Premises NGFW&lt;/STRONG&gt; remains a with a single data source "&lt;STRONG&gt;The Prisma Access Data Redistribution Agent&lt;/STRONG&gt;" for that &lt;STRONG&gt;Prisma Access&lt;/STRONG&gt;&amp;nbsp;&lt;STRONG&gt;GlobalProtect&lt;/STRONG&gt; &lt;STRONG&gt;Client IP ranges&lt;/STRONG&gt;, stabilizing the mappings and fixing policy enforcement on the NGFW using the original Prisma Access Domain Format as "&lt;CODE data-index-in-node="64" data-path-to-node="16"&gt;acme\username&lt;/CODE&gt;" without the &lt;STRONG&gt;1&lt;/STRONG&gt;.&lt;BR /&gt;&lt;BR /&gt;Another solution could be &lt;STRONG&gt;to unify a single domain across&lt;/STRONG&gt; &lt;STRONG&gt;local AD servers&lt;/STRONG&gt; and the &lt;STRONG&gt;Azure Entra ID&lt;/STRONG&gt;; however, this process can be more difficult and time-consuming to implement correctly.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;
&lt;P&gt;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!&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;&lt;BR /&gt;Best Regards,&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Daniel Romero&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Senior Network/Security Engineer&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;PANW Partner&lt;BR /&gt;&lt;/SPAN&gt;&lt;BR /&gt;&lt;LI-PRODUCT title="NGFW" id="NGFW"&gt;&lt;/LI-PRODUCT&gt;&amp;nbsp;&lt;LI-PRODUCT title="GlobalProtect" id="GlobalProtect"&gt;&lt;/LI-PRODUCT&gt;&amp;nbsp;&lt;LI-PRODUCT title="Prisma Access" id="Prisma_Access"&gt;&lt;/LI-PRODUCT&gt;&amp;nbsp;&lt;LI-PRODUCT title="User-ID" id="User-ID"&gt;&lt;/LI-PRODUCT&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Fri, 12 Jun 2026 06:17:45 GMT</pubDate>
    <dc:creator>DanielS.Romero</dc:creator>
    <dc:date>2026-06-12T06:17:45Z</dc:date>
    <item>
      <title>[SOLVED User-ID Domain Mismatch]: Prisma Access CIE vs On-Premises NGFW Server Monitoring Overwrite</title>
      <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/solved-user-id-domain-mismatch-prisma-access-cie-vs-on-premises/m-p/1256190#M6963</link>
      <description>&lt;P&gt;Hello LiveCommunity Team!&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;
&lt;P&gt;I created this post to share my experience regarding an issue involving the User-ID domain mapping issue between the &lt;STRONG&gt;Prisma Access Mobile Users GlobalProtect&lt;/STRONG&gt; conflict with the &lt;STRONG&gt;NGFW On-Premises&lt;/STRONG&gt;.&lt;BR /&gt;&lt;BR /&gt;The conflict arises when an &lt;STRONG&gt;On-Premises NGFW&lt;/STRONG&gt; and &lt;STRONG&gt;Prisma Access&lt;/STRONG&gt; &lt;STRONG&gt;MU-SPNs&lt;/STRONG&gt; use different user identity sources and domain &lt;STRONG&gt;NETBIOS&lt;/STRONG&gt; &lt;STRONG&gt;format&lt;/STRONG&gt;, leading to inconsistent security policy enforcement for remote mobile users trying to access the On-Premises local resources.&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG data-index-in-node="0" data-path-to-node="13,0,0"&gt;Prisma Access:&lt;/STRONG&gt; Configured with &lt;STRONG&gt;Cloud Identity Engine&lt;/STRONG&gt; (&lt;STRONG&gt;CIE&lt;/STRONG&gt;) integrated with &lt;STRONG&gt;Azure Entra ID&lt;/STRONG&gt;. Remote GlobalProtect users are mapped using the NetBIOS/Domain format as follows: &lt;CODE data-index-in-node="162" data-path-to-node="13,0,0"&gt;acme\username&lt;/CODE&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG data-index-in-node="0" data-path-to-node="13,1,0"&gt;On-Premises NGFW:&lt;/STRONG&gt; Configured with &lt;STRONG&gt;Agentless User-ID&lt;/STRONG&gt; (&lt;STRONG&gt;Server Monitoring&lt;/STRONG&gt;) reading logs directly via &lt;STRONG&gt;WinRM HTTP&lt;/STRONG&gt; from local &lt;STRONG&gt;Domain Controllers&lt;/STRONG&gt; (&lt;STRONG&gt;DCs&lt;/STRONG&gt;). The local Active Directory servers and NGFW uses a different NetBIOS domain name for the Agentless configuration as follows: &lt;CODE data-path-to-node="13,0,0" data-index-in-node="162"&gt;acme&lt;STRONG&gt;1&lt;/STRONG&gt;\username&lt;/CODE&gt;with a "&lt;STRONG&gt;1&lt;/STRONG&gt;".&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG data-index-in-node="0" data-path-to-node="13,2,0"&gt;User-ID Data Redistribution Agent:&lt;/STRONG&gt; The &lt;STRONG&gt;On-Premises NGFW&lt;/STRONG&gt; receives the Mobile Users User-ID mapping information from Prisma Access via an established Service Connections.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-path-to-node="14"&gt;&lt;STRONG data-index-in-node="0" data-path-to-node="14"&gt;The Domain's Problem:&lt;/STRONG&gt; When a remote user connected to &lt;STRONG&gt;Prisma Access GlobalProtect&lt;/STRONG&gt; with their assigned IP address e.g (&lt;CODE data-index-in-node="60" data-path-to-node="14"&gt;172.17.0.11/24&lt;/CODE&gt;) accesses an internal resource behind the On-Premises NGFW, the traffic triggers a &lt;STRONG&gt;Kerberos/NTLM&lt;/STRONG&gt; authentication event against the local Domain Controllers.&lt;/P&gt;
&lt;P data-path-to-node="15"&gt;&lt;BR /&gt;Then the&amp;nbsp;&lt;STRONG&gt;DCs&lt;/STRONG&gt; logs a successful login event (&lt;STRONG&gt;Event ID 4624&lt;/STRONG&gt;) for that remote IP, but associates it with the local domain format as: &lt;CODE data-index-in-node="114" data-path-to-node="15"&gt;acme&lt;STRONG&gt;1&lt;/STRONG&gt;\username&lt;/CODE&gt;. Since the &lt;STRONG&gt;On-Premises NGFW&lt;/STRONG&gt; monitors these DCs, it parses the log and overwrites the Prisma Access mapping almost immediately from the original Prisma Access format &lt;CODE data-path-to-node="13,1,0" data-index-in-node="200"&gt;acme\username&lt;/CODE&gt;. without the &lt;STRONG&gt;"1"&lt;/STRONG&gt;&amp;nbsp;&lt;CODE data-path-to-node="13,1,0" data-index-in-node="200"&gt;acme&lt;STRONG&gt;1&lt;/STRONG&gt;\username&lt;/CODE&gt;&lt;BR /&gt;&lt;BR /&gt;This causes &lt;STRONG data-index-in-node="12" data-path-to-node="16"&gt;User-ID Domain Flappings&lt;/STRONG&gt; between &lt;CODE data-index-in-node="37" data-path-to-node="16"&gt;acme\username&lt;/CODE&gt; and &lt;CODE data-index-in-node="64" data-path-to-node="16"&gt;acme&lt;STRONG&gt;1&lt;/STRONG&gt;\username&lt;/CODE&gt; (and sometimes overwriting real users with machine accounts like &lt;CODE data-index-in-node="152" data-path-to-node="16"&gt;acme1\COMPUTER-NAME$&lt;/CODE&gt;), breaking security policies that strictly rely on the cloud domain format as &lt;CODE data-path-to-node="16" data-index-in-node="64"&gt;acme\username&lt;/CODE&gt;as received initially from the redistribution agent.&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;&lt;STRONG&gt;NGFW On-Premises User-ID logs&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="DanielSRomero_0-1781243192513.png" style="width: 492px;"&gt;&lt;img src="https://live.paloaltonetworks.com/t5/image/serverpage/image-id/71721iBAAFE61B4DD14219/image-dimensions/492x64?v=v2" width="492" height="64" role="button" title="DanielSRomero_0-1781243192513.png" alt="DanielSRomero_0-1781243192513.png" /&gt;&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P data-path-to-node="17"&gt;&lt;STRONG data-index-in-node="0" data-path-to-node="17"&gt;The Solution:&lt;/STRONG&gt;&amp;nbsp;The most effective and non-disruptive solution was to isolate the authorities by network segments:&lt;BR /&gt;&lt;BR /&gt;On the On-Premises NGFW configure an User-ID ACL list:&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;
&lt;OL start="1" data-path-to-node="18"&gt;
&lt;LI&gt;
&lt;P data-path-to-node="18,0,0"&gt;Go to &lt;STRONG data-index-in-node="6" data-path-to-node="18,0,0"&gt;Device &amp;gt; User Identification&lt;/STRONG&gt;&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P data-path-to-node="18,1,0"&gt;Under the &lt;STRONG data-index-in-node="10" data-path-to-node="18,1,0"&gt;Include/Exclude Networks&lt;/STRONG&gt; section, click &lt;STRONG data-index-in-node="50" data-path-to-node="18,1,0"&gt;Add&lt;/STRONG&gt;.&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P data-path-to-node="18,2,0"&gt;Add the Prisma Access GlobalProtect IP pool (e.g., &lt;CODE data-index-in-node="51" data-path-to-node="18,2,0"&gt;172.17.0.0/24&lt;/CODE&gt;) and set the Type to &lt;STRONG data-index-in-node="86" data-path-to-node="18,2,0"&gt;Exclude&lt;/STRONG&gt;.&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;
&lt;P data-path-to-node="18,3,0"&gt;Commit and Push from Panorama.&lt;/P&gt;
&lt;/LI&gt;
&lt;/OL&gt;
&lt;P data-path-to-node="19"&gt;&lt;STRONG data-index-in-node="0" data-path-to-node="19"&gt;Note:&amp;nbsp;&lt;/STRONG&gt;Don't forget to add an &lt;STRONG&gt;Include&lt;/STRONG&gt; entry to the &lt;STRONG&gt;0.0.0.0/0&lt;/STRONG&gt; network or, if you prefer to be more specific, add the &lt;STRONG&gt;RFC 1918&lt;/STRONG&gt; or the internal IP&amp;nbsp;address space to the &lt;STRONG&gt;Include/Exclude List&lt;/STRONG&gt; on the &lt;STRONG&gt;On-Premises NGFW&lt;/STRONG&gt; that accepts the User-ID information of the other IP ranges.&lt;BR /&gt;&lt;BR /&gt;If you don't do this, &lt;STRONG&gt;the NGFW will stop mapping users&lt;/STRONG&gt; from local AD servers of all other IPS ranges.&lt;STRONG data-index-in-node="0" data-path-to-node="19"&gt;&lt;BR /&gt;&lt;BR /&gt;The Network inclusion/exclusion rules&lt;/STRONG&gt; are processed from &lt;STRONG&gt;top to bottom&lt;/STRONG&gt;, so you'll need to configure more specific IP rules at the top and general IP ranges at the bottom.&lt;STRONG data-index-in-node="0" data-path-to-node="19"&gt;&lt;BR /&gt;&lt;BR /&gt;Conclusion:&lt;/STRONG&gt; By excluding the Prisma Access VPN pool from the &lt;STRONG&gt;On-Premises NGFW&lt;/STRONG&gt; &lt;STRONG&gt;User-ID Agentless Process&lt;/STRONG&gt;, the local firewall completely ignores the Windows security logs generated by remote users authenticating against local resources using this &lt;STRONG&gt;Prisma Access GlobalProtect Client IP Pool&lt;/STRONG&gt;.&lt;BR /&gt;This ensures the User-ID table of the &lt;STRONG&gt;On-Premises NGFW&lt;/STRONG&gt; remains a with a single data source "&lt;STRONG&gt;The Prisma Access Data Redistribution Agent&lt;/STRONG&gt;" for that &lt;STRONG&gt;Prisma Access&lt;/STRONG&gt;&amp;nbsp;&lt;STRONG&gt;GlobalProtect&lt;/STRONG&gt; &lt;STRONG&gt;Client IP ranges&lt;/STRONG&gt;, stabilizing the mappings and fixing policy enforcement on the NGFW using the original Prisma Access Domain Format as "&lt;CODE data-index-in-node="64" data-path-to-node="16"&gt;acme\username&lt;/CODE&gt;" without the &lt;STRONG&gt;1&lt;/STRONG&gt;.&lt;BR /&gt;&lt;BR /&gt;Another solution could be &lt;STRONG&gt;to unify a single domain across&lt;/STRONG&gt; &lt;STRONG&gt;local AD servers&lt;/STRONG&gt; and the &lt;STRONG&gt;Azure Entra ID&lt;/STRONG&gt;; however, this process can be more difficult and time-consuming to implement correctly.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;
&lt;P&gt;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!&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;&lt;BR /&gt;Best Regards,&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Daniel Romero&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Senior Network/Security Engineer&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;PANW Partner&lt;BR /&gt;&lt;/SPAN&gt;&lt;BR /&gt;&lt;LI-PRODUCT title="NGFW" id="NGFW"&gt;&lt;/LI-PRODUCT&gt;&amp;nbsp;&lt;LI-PRODUCT title="GlobalProtect" id="GlobalProtect"&gt;&lt;/LI-PRODUCT&gt;&amp;nbsp;&lt;LI-PRODUCT title="Prisma Access" id="Prisma_Access"&gt;&lt;/LI-PRODUCT&gt;&amp;nbsp;&lt;LI-PRODUCT title="User-ID" id="User-ID"&gt;&lt;/LI-PRODUCT&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 12 Jun 2026 06:17:45 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/next-generation-firewall/solved-user-id-domain-mismatch-prisma-access-cie-vs-on-premises/m-p/1256190#M6963</guid>
      <dc:creator>DanielS.Romero</dc:creator>
      <dc:date>2026-06-12T06:17:45Z</dc:date>
    </item>
  </channel>
</rss>

