DOTW: What is the Best Way to Configure User-ID Mapping?

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



This Discussion of the Week is all about how to configure User-ID mapping, using WinRM-http, and Kerberos.


User-ID is one of the most popular topics in our discussion forums, and this discussion started by user @GrandRiver is no different. 





@GrandRiver states that they are new to Palo Alto Networks firewalls, and need assistance on getting User-ID working with WMI, WinRM-http, or WinRM-HTTPS. They also need to see how Kerberos or NTLM play into User-ID.


There were some very good responses on that discussion! One was by one of Cyber Elite experts, @SteveCantwell, who was able to respond to the discussion with some great basic information about LDAP and configuring User-ID. 


User @TomLunaENS was able to chime in with a very good response. Tom explains what has worked for him, as he is running in a Windows domain with Server 2019 DC's. 


"I set up the firewall to use the PAN-OS Integrated User-ID agent using Kerberos and WinRM-http using the TechDoc for guidance, and was also running into the "Access Denied" error (HTTP 500: s:Senderw:AccessDeniedAccess is denied. Access is denied.). After some troubleshooting on the server, I determined that the service account was authenticating successfully using Kerberos, but was failing when submitting the WQL query to pull the user/IP data. "


This is the error that he was getting:

An error was encountered while processing an operation.
Error Code: 5
Error String:<f:WSManFault xmlns:f="" Code="5" Machine=""><f:Message>Access is denied. </f:Message></f:WSManFault>


Tom continued in his response letting everyone know that his solution was a simple one:


"In the end, I figured out that the service account needs to belong to the 'Remote Management Users' group in AD to allow WinRM connections from the firewall to query WMI.  This is because the service account (as configured per the TechDoc) is not an administrator on the domain, and by default PowerShell Remoting requires admin privileges."


Tom fished up with letting people know a warning, because "There could be negative security implications to granting the service account this level of access. I have not looked into this issue yet, but additional restrictions may be needed to ensure that this account can't be abused."


Later on in the discussion, Tom responded again, but with another warning:


"The security implications would pertain to the potentially increased attack surface in case the service account was compromised.  The PaloAlto documentation has some steps to remove unneeded privileges from the account (always a good idea).  I just wanted to make clear that adding the user to the additional group may open the server to additional attack vectors which I have not attempted to investigate."


The upshot? Use Kerberos and WinRM-http and ensure that the service account belongs to the 'Remote Management Users' group in AD to allow WinRM connections from the firewall to query WMI.


Thanks again @TomLunaENS for a great response to the discussion, your help is always appreciated.


Along with the above recommendation on getting User-ID up and running, if you needed any more resources when it comes to User-ID, then I would recommend checking out a great Getting Started article that Reaper created called GETTING STARTED: USER-ID.


There is also some great documentation that we have on our TechPubs site when it comes to Enable User-ID or TechPubs also has information on how to configure Prisma Access: Configure User-ID for Remote Network Deployments.


I hope this helps you a little when it comes to configuring User-ID!



Thanks for taking time to read my blog.
If you enjoyed this, please hit the Like (thumb up) button, don't forget to subscribe to the LIVEcommunity Blog area.


As always, we welcome all comments and feedback in the comments section below.


Stay Secure,
Joe Delio
End of line


  • 324 Subscriptions
Register or Sign-in