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

cancel
Showing results for 
Search instead for 
Did you mean: 

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

L2 Linker

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.

HanValk_0-1660636016659.png

Please use Advanced → Add so that these permissions are applied to ‘This namespace and subnamespaces’.

HanValk_1-1660636016665.png

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.

HanValk_1-1660657852200.png

 

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.

 

 

1 REPLY 1

Community Team Member

Hi @Han.Valk ,

 

Great stuff ! Thanks for sharing !

 

Best,

-Kiwi.

 
LIVEcommunity team member, CISSP
Cheers,
Kiwi
Don't forget to hit that Like button if a post is helpful to you!
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!