Humps and bumps with the Palo Alto firewall integrated User-ID agent and Active Directory.

[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 currently unsupported with Windows Server 2022 domain controllers. 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:

• WMI
• HTTP with Kerberos
• HTTPS with Kerberos
• HTTPS with basic authentication

Documentation is missing important details and sometimes a bit messy.

For all deployments using the integrated User-ID agent you must add that service account you created to the following three groups that you can find in the Builtin container in Active Directory:

• Distributed COM Users
• Event Log Readers
• Remote Management Users

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

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. Nevertheless this also works in a multi-domain active directory forest.

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:

• You have to create Certificate Profile. Please do not only add the root certificate but also all intermediates.
• You must create a HTTPS listener for WinRM using this command: winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="<hostname>";CertificateThumbprint="Certificate Thumbprint"
  Note: The hostname must be the same as the common name of the certificate otherwise WinRM won’t accept the command.

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.

[kiwi]

Hi @Han.Valk ,

Great stuff ! Thanks for sharing !

Best,

-Kiwi.

[jLaCoe]

I have been trying to get this to work all week. Thanks for your testing and information. I was finally able to get the service account I created to authenticate.

[TomYoung]

Hi @Han.Valk ,

Thanks for the info!  Great stuff!  Some of that is located here -> https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClGGCA0.

MS has publicly stated that it will do away with the registry workaround in March 2023 for security reasons.  Please see this thread and the associated links -> https://live.paloaltonetworks.com/t5/general-topics/user-identification-and-winrm-on-http/m-p/481674.

Thanks,

Tom

[OtakarKlier]

Hello,

Nice article! If you still have on prem exchange, you can always utilize exchange logs instead. This is getting a lot harder since everyone is moving away from on prem and going cloud.

Cheers!

[Drshoe28]

Great article - Really helpful. Thank you! In our case it was this line in particular that resolved our issues:

Sometimes you must reset the password of the service account as well so that it is stored with AES encryption.