Useful User-ID information.

Palo Doc Here.

Setup

The service account needs to belong to the 'Remote Management Users' group in AD to allow WinRM connections from the firewall to query WMI. This is because the service account is not an administrator on the domain, and by default PowerShell Remoting requires admin privileges.

The service account requires the following domain permissions per forest.

• Domain Users - This is true for both Agent and Agentless configurations.
• Event Log Readers - If you want to use server monitoring to identify users. This is true for both Agent and Agentless configurations.
• Distributed COM Users - If you want to use WMI to collect user data, assign DCOM privileges to the service account so that it can use WMI queries on monitored servers. This may be needed when configuring agentless User-ID. I had one instance where I didn't configure Distributed COM permission for the service account and one domain controller allowed connections while its twin did not. No idea why.
• Server Operators - (Not recommended) To allow the agent (not integrated agent) to monitor user sessions to poll Windows servers for user mapping information, assign Server Operator privileges to the service account. This is not best practice because this group also has privileges for shutting down and restarting servers, only assign the account to this group if monitoring user sessions is very important.

(Bear in mind that agentless configuration using WMI will cause CPU spikes. E.G. in the lab, agentless caused the DC to spike to 40% CPU every couple of seconds).

I have found that if you want to use the integrated PANOS agent, you only need a simple user account that is a member of “Domain Users” and “Event Log Readers” (see the next section of this document.

However, the caveat is that for each Domain Controller/Exchange server that you want to monitor, you have to add CIMv2 permissions on that server to the service user account.

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/user-id/map-ip-addresses-to-users/create-a-dedicated-service-account-for-the-user-id-agent.html# Palo Alto Networks' documentation is not complete.

1. On the Windows Server start menu, search for wmimgmt.msc, and launch the WMI Management Console. (Alternatively, launch mmc and add the WMI Management Snap In).
2. In the console tree, right-click WMI Control and select Properties.
3. Select Security tab.
4. Expand Root
5. Select the CIMV2 folder that is under Root.
6. Click the Security button at the bottom right of the window.
7. Add the User-ID service account and give it the following permissions
8. - Enable Account
9. - Remote Enable
10. Click OK to close the permission window.
11. Expand CIMV2 (Palo documentation says you need this but I've not seen this as actually required in the real world)
12. Select the Security sub folder (Palo documentation says you need this but I've not seen this as actually required in the real world)
13. Click the Security button at the bottom right of the window. (Palo documentation says you need this but I've not seen this as actually required in the real world)
14. Add the User-ID service account and give it the following permissions (Palo documentation says you need this but I've not seen this as actually required in the real world)
15. - Enable Account (Palo documentation says you need this but I've not seen this as actually required in the real world)
16. - Remote Enable (Palo documentation says you need this but I've not seen this as actually required in the real world)
17. Click OK to close the permission window. (Palo documentation says you need this but I've not seen this as actually required in the real world)
18. Click OK to close the properties window.

The firewall should now be able to connect to the domain controller for UserID information.

Don't forget that you will only want to scan User subnets and ignore service accounts.

User ID Timeout should be set to the half-life of DHCP or the Kerberos ticket lifetime.

Run the following on a domain controller:

dsquery user -name administrator

C:\Users\Admin>nltest /dclist:example.local
Get list of DCs in domain 'example.local' from '\\dc1.example.local'.
      dc1.example.local        [DS] Site: Default-First-Site-Name
      dc2.example.local        [DS] Site: Default-First-Site-Name
      dc3.example.local [PDC]  [DS] Site: Default-First-Site-Name
The command completed successfully

To list all combinations of username listed on the firewall.

show user user-attributes user domain\user

Regex for Cisco ISE

              <entry name="Cisco-ISE-Regex">
                <regex-identifier>
                  <event-regex>([A-Za-z0-9].*CISE_Passed_Authentications.*Framed-IP-Address=.*)|([A-Za-z0-9].*CISE_RADIUS_Accounting.*Framed-IP-Address=.*)</event-regex>
                  <username-regex>User-Name=([a-zA-Z0-9\@\-\\/\\\._]+)|UserName=([a-zA-Z0-9\@\-\\/\\\._]+)</username-regex>
                  <address-regex>Framed-IP-Address=([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})</address-regex>
                </regex-identifier>
              </entry>

The ignore user file is called ignore_user_list.txt and is placed in the Palo Alto Networks programs folder (C:\Program Files(x86)\Palo Alto Networks).

If you are using the User-ID agent installed on a server, you will need to make sure that the service account has permissions to access the installation folder of the Agent (to read configuration and write logs) and the registry (to update configurations such as logging levels).

• C:\Program Files(x86)\Palo Alto Networks
• 32-bit systems—HKEY_LOCAL_MACHINE\Software\Palo Alto Networks
• 64-bit systems—HKEY_LOCAL_MACHINE\Software\WOW6432Node\PaloAlto Networks

By ensuring that the User-ID service account has the minimum set of account privileges, you can reduce the attack surface should the account be compromised.

# Select ''Group Policy Management Editor -> Default Domain Policy -> Computer Configuration -> Policies -> Windows Settings -> Security Settings -> User Rights Assignment''.
# For ''Deny log on as a batch job'', ''Deny log on locally'', and ''Deny log on through Remote Desktop Services'', right-click ''Properties''.
# Select Define these policy settings->Add User or Group and add the service account name, then click OK.

# Select ''Start -> Run'', enter ''MMC'', and select ''File -> Add/Remove Snap-in -> Active Directory Users and Computers -> Users''.
# Right-click the service account name, then select Properties.
# Select Dial-in, then ''Deny the Network Access Permission''.

(Reference) If probing is enabled, the agent will probe each learned IP address periodically (every 20 minutes by default, but this is configurable) to verify that the same user is still logged in. In addition, when the firewall encounters an IP address for which it has no user mapping, it will send the address to the agent for an immediate probe. (This will be sent to the agent regardless of whether the agent is on a dedicated server or on the firewall. Additionally, only IP addresses that come from networks that are in Zones that have been marked for User-ID will be probed.)

Enable WMI probing for public IPv4 addresses if desired. (Public IPv4 addresses are those outside the scope of RFC 1918 and RFC 3927). By default, in PAN-OS 7.1 and later, WMI probing excludes client systems with public IPv4 addresses.

If you include any subnetworks in the Include/Exclude Networks list, the firewall implicitly excludes all subnetworks that are not in the list. Therefore, if you add subnetworks for public IPv4 addresses, you must also add all the other subnetworks that WMI probing should include.

When monitoring Microsoft Exchange servers, you need to ensure that they are Exchange CAS servers (Client Access Server).

(From the built in documentation)By default, if you don’t add any subnetworks to the list, the User-ID agent performs discovery for user identification sources in all subnetworks except when using WMI probing for client systems that have public IPv4 addresses.

The User-ID agent applies an implicit exclude all rule to the list. For example, if you add subnetwork 10.0.0.0/8 with the Include option, the User-ID agent excludes all other subnetworks even if you don’t add them to the list. Add entries with the Exclude option only if you want the User-ID agent to exclude a subset of the subnetworks you explicitly included. For example, if you add 10.0.0.0/8 with the Include option and add 10.2.50.0/22 with the Exclude option, the User-ID agent will perform discovery on all the subnetworks of 10.0.0.0/8 except 10.2.50.0/22, and will exclude all subnetworks outside of 10.0.0.0/8. If you add Exclude profiles without adding any Include profiles, the User-ID agent excludes all subnetworks, not just the ones you added.

By default, the User-ID agent evaluates the subnetworks in the order you add them, from top-first to bottom-last.

In PAN-OS 7.0 and earlier releases, client probing that uses Windows Management Instrumentation (WMI) includes all public and private IPv4 and IPv6 addresses by default. However, after you upgrade to PAN-OS 7.1, the default for WMI probing is to exclude public IPv4 addresses. (Public IPv4 addresses are those outside the scope of RFC 1918 and RFC 3927). To use WMI probing for public IPv4 addresses after the upgrade, you must add their subnetworks to the User-ID agent Include Networks list.

After you upgrade, all Palo Alto Networks DNS signatures are enabled by default. The default action for the DNS Signatures is sinkhole, and the sinkhole IP address is a Palo Alto Networks server (71.15.192.112). This IP address is not static and can change because it is pushed using Palo Alto Networks content updates.

After you upgrade to 7.1, all Palo Alto Networks DNS signatures are enabled by default. The default action for the DNS Signatures is sinkhole, and the sinkhole IP address is a Palo Alto Networks server (71.15.192.112). This IP address is not static and can change because it is pushed using Palo Alto Networks content updates.

When you upgrade to PAN-OS 7.1, the ARP table capacity automatically increases on 3000 and 5000 series firewalls. To avoid a mismatch when upgrading a pair of HA firewalls, you should upgrade both HA peers within a short period of time. You should also clear the ARP cache ( clear arp ) on both HA peers before you upgrade.

The first thing is that AD based User-ID is often the easiest type to setup but is not the best in terms of reliability/accuracy as it is a passive monitor. Active monitors are better (e.g. GlobalProtect). An easy example to give to customers is someone plugging into the wired LAN in the morning (which will generate a User-ID mapping) and then moving to wireless. The user will have a new IP but no login event will be generated.

Windows Server Monitoring “Enable Security Log” is enabled by default but “Enable Session” is disabled by default. This is because the “Enable Security Log” requires that your User-ID service account has the “Server Operators” privilege. The privilege is quite powerful and some customers may not want to enable the User-ID service account with this much authority. Consequently, “Enable Session” is, by a large, a safe option to tick as part of best practice (assuming the customer will give the service account the required privilege).

A benefit that you get from using “Enable Session” is that all Windows clients that are members of the domain will 'phone home' every 90 minutes (+/- 30 minutes) to get the latest group policy. Part of this process involves mounting a file share from the domain controller. This will give the User-ID agent a fresh IP-User mapping. This also means that domain connected Windows clients that move from one network to another (e.g. wireless to wired) will get a fresh IP-User mapping within that time period.

A possible reason for not using “Enable Session” is if the client has multiple domains in a single forest and does not want to use one agent per domain (e.g. they want to use one agent per forest). The session tables on the agent will only contain the user name and not the domain. It would be recommended to use one agent per domain.

While it is technically possible to use one agent per forest, since a username in two separate domains in a single forest may be members of very different security groups, it is a bad idea to base security policy restrictions by group membership when you are unable to determine the domain (e.g. using one agent per forest).

The default timeout for “Enable User Identification Timeout” is 45 minutes. It is not known who came up with this number or why. Expiring User-ID after 45 minutes can lead to problems in environments where users are not authenticating to the domain controllers a lot. Extending this time to at least 120 minutes allows the group policy check to refresh the User-ID mapping before expiry.

Kerberos ticket granting ticket interval. By default, the interval is 10 hours +/- 30 minutes. Consequently, the maximum 'safe' timeout for User-ID is 630 minutes as a domain connected Windows client will authenticate again within that time window.

There is a possibility that someone with authenticate, get an IP-user mapping and then leave the office. Someone else can then access the network, configure their machine with the same IP and be granted the same network access as the original user until the User-ID mapping expires. The solution to this problem is to implement IP source control with another product (i.e. Palo does not provide this functionality).

PAN-OS 8.0 and the latest User-ID agent can understand logout events from syslog sources and API. However, it cannot detect logout events from Active Directory. The reason for this is because Active Directory logout events do not contain a username, just a session ID. To register the logout with the User-ID agent, you would have to lookup the session ID against the login events going back several hours. It is my understanding that Palo do not intended to implement this kind of functionality.

In larger environments there can be a frequent turn over of domain controllers. This is a problem for User-ID as you need to ensure you are monitoring every domain controller. You can do this by ensuring that that the firewall team maintain good communication with the Active Directory team. However, another way of ensuring all domain controllers are monitored is to use Windows Event Forwarding. You configure Windows Event Forwarding in group policy. This ensures that all new domain controllers will forward their logs as specified in the group policy. You the install the User-ID agent on the server that is receiving all the logs from all the domain controllers and just monitor the local loopback IP. A caveat is that the User-ID agent only looks at 'Security logs'. Forwarded logs go to 'Forwarded Logs' and will consequently evade the watchful eye of the User-ID agent. The fix is to use group policy to force the forwarded events destination to match the destination of the security logs.

There are four events that the User-ID agent cares about: 4624, 4768, 4769, 4770. There are another three or four for Windows 2003 and earlier but they are not really used anymore.

The Windows User-ID agent uses RPC to connect to the domain controllers. It asks for a delta of all the security events that have happened since its last query. The problem with this is that the returned results includes all security logs - not just the four types that the agent is interested in. The causes larger bandwidth use but uses less CPU on the domain controller.

The agent that is build into PANOS uses DCOM to connect to the domain controllers and WMI to query them. It asks for a delta of the four types of logs that it is interested in since its last query. This reduces network bandwidth but can increase CPU use on the domain controller as the domain controller has to use regex to filter out the unwanted event logs.

Using Windows Event Forwarding can be the best of both worlds as it keeps the bandwidth use between the Forwarding server and the Agent low while also doing the required regex rather than letting the domain controller do it.

It should be reiterated that WMI and Netbios probing are legacy features that were implemented years ago when companies ran Windows XP on 98% of all networked devices and the security by default was really bad and allowed WMI probing. It is suggested that suggested that small customers with a single domain might still get some use out of it but that this feature may not be around for much longer (this was not an official statement of roadmap - not even an unofficial statement, just a casual remark). NetBIOS is similar to WMI probing but actually worse (if you want to compare the two).

Retrieving groups for use in security policy is easy for single domains. For multiple domains in a forest, it gets more complicated. Prior to PAN-OS 8.0, PAN-OS had a limitation of 640 group mappings per appliance. In PAN-OS 8.0, this was raised to either 1,000 or 10,000 group mappings per appliance (depending on the model).

It is best practice, when setting a customer up with PAN, to set at least one group mapping up (e.g. for Palo Admin access). This ensures they don't setup a group mapping to map all groups in the domain (which can increase CPU and Bandwidth use). It is also possible, in companies that have separate firewall teams and Active Directory teams, that the AD team may try and tidy up groups by moving them around the domain structure. This causes a problem because Palo firewalls lookup group membership based on the full path of the group (e.g. cn=palogroup,ou=securitygroup,dn=example,dn=local) rather than just the group name (e.g. example\palogroup). A best practice way around this is to have the AD team create a branch in AD that the firewall admins can use for group enumeration (e.g. ou=palogroupmappings,dn=example,dn=local). The firewall admins then have groups created in this branch and add the target groups as members.

For example, rather than mapping cn=VPNusers,ou=somthing,ou=anything,dn=example,dn=local, you would create cn=palovpnusers,ou=palogroupmappings,dn=example,dn=local and then make VPNusers a member of palovpnusers. The AD team can then move the VPNusers group to anywhere they want within AD and it will still be accessible via palogroupmappings.

There are two ways of approaching group mappings when there are multiple domains within a forest.

1. If they want to use groups from specific domains, they will need to have a group mapping per domain and put each group into the security policy rule.
2. If they have a group within the forest that contains users from multiple domains, the group will be a 'universal' group and they will have to monitor the Global Catalog (https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/user-id/map-users-to-groups.html)

More specifically, in Windows Active Directory there are three types of groups: universal, domain local, domain global.

When you connect to the LDAP port of an AD server, we can see all three types of groups. The groups can contain users from multiple domains within the forest.

The way the mapping connector works, when we connect to the LDAP port, while we can see all the groups, we can only see the users that are local to the domain we have connected to. To see all the users in that group, you need to connect to the global catalogue server in AD. This only contains universal groups but we can see all users form all domains within the forest in those groups.

You can use method 1 or method 2 but do not use both. When you connect to a global catalogue server and a local LDAP server at the same time, you start to see crazyness with regards to group mapping and who is a member of a given group.

Where possible (especially on a single domain), use just one group mapping object to get all the group mappings you need.

For terminal services User-ID, the default port range is 20,000-39,000. This is because Palo have noticed that these ports are very rarely used by services. Check with the customer but it is fine to take the starting port down low. E.G. you might make a few exceptions but take it down to 10,000-39,000. The terminal services User-ID agent will tell you what the OS reserved ports are (usually they start at 49152). These ranges can be changed in the Windows registry.

The default port allocation batch of 200 is a good default. If you increase it higher, you will run out of ports more quickly. If you set it any lower, then users will request more blocks more frequently and this all has to be communicated to all the firewalls that monitor the TS agent. Increased network chatter isn't a good thing if it can be avoided. On a similar note, the volumetric issue of redistributing port information is why Palo do not allow TS agent User-ID to be redistributed. It is not on the roadmap but there team are pondering it.

For User-ID redistribution, Palo have noticed that customers with very old infrastructures who have done AD for years and years tend to have AD servers at each site (back in the day, WAN links were slow). New companies tend to centralise their AD servers as WAN links are fast enough to support it.

PAN-OS 8.0 New user-ID features. Consume logout events (syslog & API only) Process logs up to 20 regexs from a single syslog server (previously only one regex could be used. Matching is top down so put the most frequently used regex at the top. SAML enabled SSO capability on GlobalProtect, Captive Portal and Managemnt-UI

On previous version of PAN-OS, you could see the logs for User-ID using the following command. In PAN-OS 8.0, this is now visible in the GUI. show log user ID

Be aware that PAN-OS has a limit of 100 User-ID agents per appliance. This means that if you have 110 virtual systems, at least 10 will not be able to do UserID.

User-ID - 100 User-ID agents per firewall is a limitation. This is per platform. This means if you have a Palo with 256 Virtual systems, you will not be able to have User-ID agent on all of them, maximum of 1 agent per VSYSs for 100 VSYSs but then you have 150 without User-ID.

In 7.0, you need a full mesh for UserID redistribution. This causes two problems. Firstly, you can hit the User-ID agent limit (e.g if you have more than 100 sites) and secondly you get a lot of network chatter.

7.1 allows for a hub and spoke model where a single firewall (e.g. VM-100) could collect all the User-ID mappings and redistribute to all machines. You can then add a second spoke if you hit the 100 user agent limit. Additionally, the majority of User-ID mappings being sent through the mesh will be duplicates and will be discarded. This wastes bandwidth and CPU.

8.0 allows for a hub and spoke model but now allows a Panorama appliance to act as the hub.

Be aware that some old versions of 7.1 have a bug (now patched) that allows a runaway loop of User-ID redistribution in a full mesh broadcast.

The nice thing about using Panorama is that all the firewalls already have a route to it for Panorama communication.

Question) can you configure more than 100 useragents on Panorama? This means you need two panorama firewalls to gather logs from 200 firewalls.

Two points of latency, the time between the local firewall polling the local AD server. e.g. firewall will query User-ID agent every two seconds for mappings. This means you have about a four second delay between logging into AD and it reaching Panorama.

Every hop you add to the redistribution will add up to 2 seconds of delay.

When using a syslog server, it is important to discuss existing delays between source and syslog server and syslog server and Palo. E.g. if customer is putting everything into spunk - it goes to forwarder and then on to an indexer and then off to process and then to Palo device. This adds a delay between login and Palo learning about User-ID mapping.

For SAML, Palo is only a service provider. There is, apparently, no reason for a firewall to be a SAML identity provider (IDP). If a customer has a very old version of PulseSecure VPN, they may have an appliance that is a SAML IDP as well as SAML service provider. However, all modern systems are just service providers as companies like Duo or Ping give you SAML IDP as part of their offering. Most SAML IDP providers will create a self-signed certificate per customer and provide that to the customer. Pay attention to clock skew as this is important in SAML. Ensure firewall has correct time as this is very important with SAML

CLI is not supported for SAML (e.g. can't us SAML to SSH in - you only use SAML when logging into GUI) - can't be part of authentication sequence - no an identity provider

When you enable SAML on Palo firewall, you will see “Single Sign-on” button the logon screen. Specify username and click continue, if you do not specify a username, the default SAML provider will be used.

To use the credential theft feature, you will need a URL Filtering subscription.

Passwords are checked ever five minutes by User-ID credential agent.