user id / winrm / ldaps setup on palo alto firewall

Palo Alto User-ID via WinRM-HTTP + Kerberos, zero to hero

1. AD service account

• Create a dedicated AD service account for User-ID (don't reuse an admin/domain admin account).
• Add it to these Builtin domain-local groups (domain-wide, applies to all DCs automatically):
  • Event Log Readers
  • Distributed COM Users
  • Remote Management Users
  • WinRMRemoteWMIUsers__
  • (Skip Server Operators unless you specifically need Session Monitoring — see step 8.)
• Confirm password doesn't contain characters known to break WMIC parsing, and note it doesn't expire unexpectedly.

2. NTP / time sync

• Confirm firewall NTP is configured and in sync with the domain (Device > Setup > Services > NTP).
• Kerberos fails silently on >5 min clock skew — check this before anything else if auth ever breaks later.

3. DNS — firewall must be able to resolve DC hostnames

• Confirm which DNS mechanism the firewall uses: direct DNS servers, or a DNS Proxy object (check Device > Setup > Services > Services tab).
• If using DNS Proxy:
  • Check domain-based rules point at valid, current DNS servers for the domain.
  • Check Static Entries — if any DC hostnames are hardcoded here, they must be added/updated for each new DC; this is easy to miss and doesn't auto-resolve via the domain rule.
• Test resolution directly: ping host <dc-fqdn> from firewall CLI.

4. Service routes — confirm traffic actually egresses correctly

• Device > Setup > Services > Service Route Configuration.
• Check UID Agent and DNS service routes — "Use default" often routes via MGT interface, which may not reach the DC subnet or may be locked down by a separate network team.
• If MGT can't reach the DC subnet, override both to the correct dataplane interface/source IP (matches whatever interface has L3 reachability to the DC subnet).
• Routing UID Agent via a dataplane interface also means it becomes visible in Monitor > Traffic and subject to a normal security policy rule — confirm a policy exists allowing firewall-originated traffic to the DC(s) on TCP/5985 (or 5986 for HTTPS).

5. WinRM on each DC

On every DC (this does not replicate between DCs — repeat per box):

winrm quickconfig
winrm set winrm/config/service/Auth @{Kerberos="true"}
winrm enumerate winrm/config/listener

• Confirm listener shows Transport = HTTP, Port = 5985, Enabled = true.
• Confirm Windows Firewall network profile is DomainAuthenticated (Get-NetConnectionProfile) — a VM occasionally comes up as Public/Private post-build, which silently blocks the built-in WinRM firewall rule.

6. WMI/DCOM local permissions — per DC, does NOT come from AD group membership

This is the step most likely to be forgotten on a rebuild, since group membership alone looks correct but isn't sufficient.

On every DC:

• CIMV2 namespace security (wmimgmt.msc → WMI Control (Local) → Properties → Security → Root/CIMV2 → Security):
  • Add service account, tick Enable Account, Remote Enable, Read Security.
  • Confirm Advanced scope is "This namespace and subnamespaces," not namespace-only.
• DCOM permissions (dcomcnfg → Component Services → Computers → My Computer → Properties → COM Security):
  • Launch and Activation Permissions > Edit Limits — add account, tick Remote Launch, Remote Activation.
  • Access Permissions > Edit Limits — add account, tick Remote Access (separate ACL, easy to skip).

No reboot needed; takes effect immediately.

7. Kerberos Server Profile on the firewall

• Device > Server Profiles > Kerberos — create a profile pointing at the domain's KDC(s).

8. Palo Alto User-ID Agent Setup

Device > User Identification > User Mapping > gear icon (Palo Alto Networks User-ID Agent Setup):

• Server Monitor Account tab: service account (domain\username format), Domain DNS Name, password, select the Kerberos Server Profile from step 7.
• Server Monitor tab: confirm Enable Session is unticked unless you specifically need it (it requires Server Operator rights and causes a generic WMI "access denied" error on every query if ticked without that privilege — this bit us during the fix).

9. Add monitored servers

• Device > User Identification > User Mapping > Server Monitoring > Add.
• Type = Microsoft Active Directory.
• Transport Protocol = WinRM-HTTP.
• Network Address = FQDN, not IP (Kerberos requires FQDN for SPN resolution).

10. Commit and verify
I found I had to fix the wmimgmt/dcomcnfg issues on all DC's before they would show as connected in the palo interface

show user server-monitor state all
tail follow yes mp-log useridd.log
show user ip-user-mapping all

All monitored servers should show Connected, with non-zero last record timestamp, and real user→IP mappings should be populating in the last command.

---

Notes for next time (DC replacement / new DC build)

Steps 3, 5, 6, and 9 are the ones that must be redone per-DC and are the most likely things to get missed on any future DC rebuild — worth keeping this as a checklist rather than relying on memory, since none of them replicate via AD.

*** Older notes try above first

Notes on how to enable WINRM + HTTPS on server side:

1. Import certificates from Palo to DC.

Export the certs from the palo alto or any CA server and import into DC.

• CA root cert goes to Computer Certificates >> Trusted Root Certification Authorities.

• Server cert goes to Computer Certificates >> Personal (This one needs to be imported to the server with Private Key – You can get it exporting the cert as pkcs12 on Palo Alto).

2. Check if WINRM is Enabled

Run the following command to verify that WINRM is configured:

• winrm quickconfig

3. Verify WINRM Listener Configuration

Check the current listener configuration:

• winrm enumerate winrm/config/listener

If only HTTP is listed and no HTTPS, you need to add an HTTPS listener.

4. Create WINRM HTTPS Listener

Use the command below to create the HTTPS listener. Replace the values with your actual hostname and certificate thumbprint:

• winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="server.local";CertificateThumbprint="0ec2b6e88d58f99...."}

5. Enable Basic Authentication

Enable basic authentication on the DC:

• winrm set winrm/config/client/auth @{Basic="true"}

You can verify the setting with:

• winrm get winrm/config/service/Auth

Service Account Permissions

Ensure that CIMV2 namespace permissions are properly configured for the service account used by USER-ID.

Follow the Palo Alto Networks documentation, particularly Step 4 in the guide below:

https://docs.paloaltonetworks.com/pan-os/10-2/pan-os-admin/user-id/map-ip-addresses-to-users/create-a-dedicated-service-account-for-the-user-id-agent?otp=id188DF0L03YR#id188DF0L03YR

 

Older notes:

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

Generate a self signed CA on the palo

fw-ldap.domain.int

now generate a cert for the DC

DCHOST.domain.int (signed by the self signed CA we just made)

export the DC cert as pkcs12 and give password

import on the dc into local computer store

winrm quickconfig

winrm create winrm/config/Listener?Address=*+Transport=HTTPS '@{Hostname="DCHOST.domain.int";CertificateThumbprint="1x1x1x1x1x1x1x1x1x1x1x1x1x1x1"}'

winrm get winrm/config/client/Auth

Look for Basic = true

Palo FW setup

Device >User Identification >User Mapping >Palo Alto Network User-ID Agent Setup >Server Monitor Account.

It seems there are 2 parts

1 - AD user group download from AD (uses LDAP/LDAPS) so we can use in ACLs etc

2 - Server monitoring for security log to monitor logins and make user -> ip mappsing

WMI seems to be totally broken

Move to winRM + HTTP + kerberos (kerberos is still encrypited)

CIMV2 part is needed and maybe DNS proxy to resolve local addresses.

on CLI

Less mp-log useridd.log

How to Configure DNS Proxy on a Palo Alto Networks Firewall - Knowledge Base - Palo Alto Networks

Needed to add extra AD groups

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

• Distributed COM Users
• Event Log Readers
• Remote Management Users
• Server Operators
• WinRMRemoteWMIUsers__