palo recommended software releases updates

https://live.paloaltonetworks.com/t5/Customer-Resources/Support-PAN-OS-Software-Release-Guidance/ta-p/258304

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__ 

asa keeps booting into rommon mode

 I set the boot system to the new bin file but still booting into rommon mode

The config reg was set like this which is boot from TFTP

I set config-register 0x1 and then would need to reload

Configuration register is 0x2102 (will be 0x1 at next reload)

patching methods

We know always patch everything all the time is the best but real world constraints lead customers to take different paths. Some patching methods below

1 – Always patch to the latest release (best security)

• Pro: Latest security patches
• Con: Latest release, so largely untested, could hit new software bugs which can cause outages.

2 – Patch to the vendors suggested release (most stable)

• Pro: Usually stable as it has been deployed for some time, less software bugs as they will have been patched out overtime.
• Con: You don’t get the latest security patches which could lead to a system being compromised.

3 – Mixed method

Patching internet facing servers like firewalls/DMZ server etc to latest release but leaving LAN and other non critical systems/no internet access systems. Those systems could be left un-patched unless there is an issue or patching to suggested/stable release on a longer patching cycle.

• Pro: The most critical and most likely to be compromised systems are kept on the latest release.
• Con: Due to above, you may hit new software bugs on your most critical systems which can cause outages.
• Pro: You are not expending limited IT time on patching non critical systems.
• Con: The non critical systems are not kept on the latest release which could lead to a system being compromised from the inside. For example a compromised laptop enters the LAN and is able to leverage

Exceptions There are some exceptions like hospital equipment where we cannot patch. For example the x-ray machine won’t work with windows10. In these rare exceptions, extra security should be added. For example isolating them from your main network and removing internet access. Locking down user access to the devices etc. Adding 2FA if possible and more network visibility like syslog/SIEM/SOC. Some IT departments won’t install a patch until its at least 6 months old, their focus here is availability over security. They want their servers up and working on business tasks. That is a business risk they are willing to take. Other orgs may be more security focused.

Patching

Is a business decision that is up to the customer. There are pro's and con's with every patching strategy. I'll detail it below and you can make the decision that works best for you.

With brand new software there is the risk of new bugs/vulns that haven't been seen yet but on the pro side, you get the latest security/bug fixes/features. You will also be in the a good position if something does go wrong, TAC's can't ask you to upgrade because you are already on recent version.

• Latest release from palo: 11.2.0
• The preferred release advised by palo alto is 11.1.2.
• Your FW is running 11.0.4-h1.

The 3 main approaches we see in the wild:

1 - Try to stay on latest release

For customers concerned about security issues, they choose security over connectivity/availability. They want the latest security and software feature patches. They accept the risk there may be new bugs/issues sometimes and are ok with doing more reboots patching etc.

• Pro: Get the latest patches and features
• Con: Untested in the wild, could have new bugs vulns, more patching, more downtime, more rick etc

Some customers would wait for the first patch in a new version for example when 11.2.0 comes out, wait for the next patch in that version before upgrading for example 11.2.0-h1.

2 - Try to stay on preferred release (I would advise this for most customers)

For customers who want a balanced approach, get good security patches and good connectivity/availability.

• Pro: A recent version of the software with almost all patches and features, considered stable
• Con: Not the very latest bleeding edge software, more patching/risk than next method

3 - Stay on current version unless affected by a security issue or bug then upgrade to latest hotfix

For customers more concerned with connectivity/availability, these customers want to keep systems up and running for users with minimal interruptions, they take the risk in falling behind on security/feature/bug fixes but will handle them as they come.

• Pro: Less downtime/patching risk in regard to downtime etc
• Con: You can fall behind in patches which can make upgrading later a bigger job

Palo are a bit different from other vendors so they only support the current and last major release. This is to reduce their workload when they need to deliver security patches quickly when an issue is discovered and also to encourage customers to keep relatively up-to-date. For example when version 12 comes out version 10 will no longer be supported but 12 and 11 will.

With all that in mind let me know which option you want to go ahead with:

• 1 - Schedule upgrade to latest release
• 2 - Schedule upgrade to preferred release
• 3 - Stay on latest hotfix in the current software version

install ssl cert on manage engine ad audit plus

Purchased wildcard cert

Created internal DNS name adap.domain.com pointing to server 192.168.0.50

Convert the cert + private key + bundle to a single .pfx file with password

Most of the apps the cert was able to be installed from

admin -> general settings -> import SSL

Service Desk Plus - I had to click the 9 dots in the top left to find the "import ssl option"

For AD audit plus I needed to edit a file:

C:\Program Files\ManageEngine\ADAudit Plus\conf

Drop your .pfx file into this folder

Edit server.xml

Search for your SSL port in my case 8083

You will see a line

keystoreFile="./conf/server.keystore" keystorePass="password"

You will need to edit this 

keystoreFile="./conf/MYPFXFILE.pfx" keystorePass="MYPFXPASSWORD"

I needed to change it on two lines at the bottom of the file

Then in services on the windows server restart 

ManageEngine ADAudit Plus service

openssl - how to convert a cert file + private key + bundle/chain file into one pfx file

openssl pkcs12 -export -in wildcard-cert.crt -inkey private.key -certfile sf_bundle-g2-g1.crt -out cert-chain-pkey-bundle.pfx

Blocking top level domains

Blocking top level domains can be tricky

Geographic considerations: If your organization does not do business with certain countries or regions, it may make sense to block TLDs associated with those locations. For example, if you have no business interests in China or Russia, blocking .cn and .ru TLDs could help reduce the risk of cyberattacks from those regions. Malware comes from every country so best to conduct an exercise on what regions you do business with. There are some exceptions

.ms (used by microsoft)

.co (columbia but can block .co.uk and .com if your rule is not specific)  used by companies that can't get a .com iptel.co, adobe.co

.in (india but used by companies like logme.in, linked.in)

 .lt .jp .gr .es .pl (used by tech companies)

Business considerations: If your organization relies heavily on certain TLDs for business operations or communication with clients, it would be prudent to allow those TLDs. For example, if you frequently communicate with clients using email addresses that end in .com, it would be counterproductive to block that TLD.

Security considerations: Some TLDs are associated with higher levels of risk than others. For example, TLDs such as .cc .xyz, .top, and .loan have been associated with high levels of spam and malicious activity, so it may be wise to block those TLDs.

Brand considerations: Some TLDs are associated with well-known brands, and blocking those TLDs could inadvertently block legitimate traffic. For example, blocking .co could also block legitimate traffic to sites such as adobe.co, bbc.co, and others.

Ultimately, the decision to block or allow specific TLDs should be based on a risk assessment specific to your organization, taking into account factors such as geographic location, business needs, security risks, and brand considerations.

Do an assessment, block TLDs, review what is blocked and allow specific / needed domains.