This article is based on a discussion, Humps and bumps with the Palo Alto firewall integrated User-ID agent and Active Directory, posted by @Han.Valk.
Introduction
The User-ID agent links an IP-address to a user account. It enables identifying your users so that they show up in the logs and you can use them in rules. One can choose between the integrated agent or install the Windows edition. Problem with the Windows variant is that it is unsupported with Windows Server 2022 domain controllers at the moment of this writing. Therefore, in this article I will concentrate on the integrated edition.
Using the integrated User-ID agent, one can choose from several combinations of transport protocols and authentication mechanisms:
Documentation is missing important details and sometimes a bit messy.
For all deployments using the integrated User-ID agent you must add the service account you created to the following three groups that you can find in the Builtin container in Active Directory:
I’ve done some experimenting with different combinations of these three groups and found you need all of them to not only see a Connected status in Server Monitoring, but also to get useful data. A Connected status doesn’t say everything.
If you have a multi-domain forest, you’d be better off creating a universal group in the root domain, assuming that’s where your service account lives. Make the service account a member of this group and add the universal group to the three groups mentioned above.
One thing the documentation isn’t telling you is that you not only need to give the service account ‘Enable Account’ and ‘Remote Enable’ WMI permissions on the CIMV2 branch but also on everything below it.
Please use Advanced → Add so that these permissions are applied to ‘This namespace and subnamespaces’.
Repeat this for every domain controller you want to monitor.
Another important point is that your service account must support Kerberos AES 128 or 256 bit encryption. Sometimes you must reset the password of the service account as well so that it is stored with AES encryption.
WMI
Because of DCOM hardening changes that Microsoft is rolling out, WMI does not work until you deploy the RequireIntegrityActivationAuthenticationLevel registry value and set it to zero. However, this setting currently has no effect in Windows Server 2022. With Windows Server 2022 your system log will fill with event id 10036 errors regardless what value you use for RequireIntegrityActivationAuthenticationLevel.
@palo Alto Networks: Can you please anticipate on the coming DCOM hardening so we can use WMI with DCOM hardening enabled?
@Microsoft: Can you please fix RequireIntegrityActivationAuthenticationLevel on Windows Server 2022?
HTTP with Kerberos
This works great in a flat active directory forest, but… What if you have a multi-domain Active Directory forest with child domains and lots of domain controllers? Will this work?
You can only add 4 domain controllers to a Kerberos Server Profile and you can only configure one Kerberos Server Profile to the User-ID Agent Setup.
One other thing, with Kerberos you must configure a domain and use FQDNs. Thus, the firewall must be able to resolve this domain and those domain controllers.
HTTPS with Kerberos
A few things to keep in mind in addition to that what is written above about HTTP with Kerberos:
HTTPS with basic authentication
Everything that I wrote above about HTTPS with Kerberos is also true for HTTPS with basic authentication. When using HTTPS with basic authentication instead of an FQDN you can also use the IP-address of the domain controllers you add to Server Monitoring. So, the firewall doesn’t need the ability to resolve the domain controllers.
One important note: I would not recommend using the HTTPS with basic authentication option since it will enlarge the attack surface of your domain controllers. It will make them vulnerable to password spray attacks.
