Best way of doing user-ID mapping? WMI, Winrm-http? There is also Kerberos and NTLM?

[GrandRiver]

Hi, new to PA here. We just got the firewall and I'm trying to figure out what is the best way to set up User-ID mapping. I don't want to install any agents on the domain controllers and the goal is users can access Internet as long as they log into their computers with their Windows credentials, no other login required. From the User-ID screen, under server monitoring section, there are 3 options to connect to the servers: WMI, winrm-http, winrm-https. What is the best way of doing it? I tried with WMI and it seems to be able to map users but for winrm-http I keep getting access denied under status tab. Also how does kerberos and NTLM play in User-ID mapping? Do they work together with WMI/winrm-http or they are different approaches? Thanks.

[S.Cantwell]

There are quite a few steps to get UserID properly configured.

LDAP Server Profile needs to be created, so that you can query LDAP and determine what LDAP groups are to be used in Security Policies.  This is a primary feature for User.  Map your users into LDAP groups (sales, marketing finance, mgmt, IT, admin,etc), as many similar ppl have the same need/requirement to access the same resources.

Mgmt needs acess to mgmt servers using mgmt applications (marketing ppl have no reason to talk to mgmt servers for example)

You need to use the same LDAP server profile service account, in the UserID agent field.

You should have server monitoring enabled to check ever 15 secs.

You should have session monitoring every 10 secs.

You should NOT be doing client probing (unless you need to find all unknown IPs)

You should have the User Timeout session set to 1/2 of your DHCP lease time (and your scopes should be changed to 12 hours MAX)

Enable UserID under the zone you want (probably trusted, internal, etc) and then do a commit.

Under the server monitoring, you add in the LDAP and Exchange server (if mail is on premise), so that the UserID agent uses the same service account credentials to query the security logs on DC and Exchange server.

Service account should be EventLog Readers, Session Operator, and Distributed COM User as permissions on the DC.

Glad to assist you more, but wanted to ensure you have the basics.

[TomLunaENS · Accepted solution]

Hi all.  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. 

An error was encountered while processing an operation.
Error Code: 5
Error String:<f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="5" Machine="dc.mydomain.com"><f:Message>Access is denied. </f:Message></f:WSManFault>

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.

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.

Thanks!

[GrandRiver]

Thanks  and you are awesome! I just tried and it works like a charm. I hope Palo Alto can add this into their guide so other users won't have to waste time to figure out where is wrong. I don't think security wise it would be a problem as it is only used by the firewall to connect to the DCs, unless there's security bug in the software. Also make sure you give it a very strong password.

[TomLunaENS]

Thanks for responding.  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.

[vzamy]

Server monitoring status flapping between "Access denied" and "Connected" when using WinRM protocol

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000sb51CAA