Palo Alto User-ID LDAP
Palo Alto User-ID integrates with LDAP directories to learn user-to-group mappings, then correlates those with IP addresses gathered from sources such as login events, agents, or probes. This allows the firewall to enforce security policies based on user identity instead of just IP, ensuring rules follow the authenticated user across devices and sessions.
First on the Inside Zone, we enable User Identification. This lets the firewall map IP addresses to user identities retrieved from LDAP.
Next on User Identification, hit the Gear Icon and setup the LDAP credentials
Then on Server Monitoring, add the LDAP Server Address using WMI Transport Protocol
WMI (Windows Management Instrumentation) is used to query Windows Domain Controller security logs directly, allowing the firewall to learn user login events and map usernames to IP addresses. It’s an agentless method, requiring admin credentials on the DC, and provides real-time user-to-IP mapping for User-ID.
Commit the changes and make sure the status becomes Connected
Next on Server Profiles, create a new LDAP Profile pointing to AD. This will be used to retrieve LDAP Groups and Users
Back on User Identification, create a new Group Mapping and select the desired groups to use
That should do it for the User-ID configuration, but when comitting and testing the configuration, we hit an error ‘Access Denied’ on Server Monitoring configuration
Looking over on the AD Server’s Event Viewer, we can see Palo Alto is unable to query the Domain Controller via WMI due to permission issue. I haven’t found a reliable way to mitigate this issue so we will proceed with alternative transport protocol replacing WMI
The alternative is to use WinRM-HTTP. Using WinRM-HTTP instead of WMI lets firewall query AD login events over a more modern, firewall-friendly protocol without DCOM errors. Kerberos is required because it encrypts the session and provides secure mutual authentication, so we need to create a Kerberos Profile
Next on the User Identification, we attach the Kerberos Profile here
And lastly we change the Transport Protocol from WMI to WinRM-HTTP, we also need to use FQDN instead of IP Address for the Network Address
Now the status has become connected, resolving our previous issue
We can use the retrieved User Groups in the Policy now for more granular control
And traffic from domain users are now mapped to their respective users
We can also run ‘show user ip-user-mapping all’ to see all mapped users
