Enable User-ID
The user identity, as opposed to an IP address, is an integral component of an effective security infrastructure. Knowing who is using each of the applications on your network, and who may have transmitted a threat or is transferring files, can strengthen your security policy and reduce incident response times. User-ID enables you to leverage user information stored in a wide range of repositories for visibility, user- and group-based policy control, and improved logging, reporting, and forensics:
On PA-5060 and PA-7000 Series firewalls that have the multiple virtual systems capability disabled, you can base policies on up to 3,200 distinct user groups. If these platforms have multiple virtual systems, the limit is 640 groups. All other firewall platforms support up to 640 groups per virtual system or per firewall (if it doesn’t have multiple virtual systems).
Use the following workflow to configure User-ID.
Configure User-ID
Enable User-ID on the source zones that contain the users who will send requests that require user-based access controls. Enable User-ID on trusted zones only. If you enable User-ID and client probing on an external untrusted zone (such as the internet), probes could be sent outside your protected network, resulting in an information disclosure of the User-ID agent service account name, domain name, and encrypted password hash, which could allow an attacker to gain unauthorized access to protected resources. Select Network > Zones and click the Name of the zone. Select the Enable User Identification check box and click OK.
Create a Dedicated Service Account for the User-ID Agent. Create a service account with the minimum set of permissions required to support the User-ID options you enable to reduce your attack surface in the event that the service account is compromised. This is required if you plan to use the Windows-based User-ID agent or the PAN-OS integrated User-ID agent to monitor domain controllers, Exchange servers, Windows clients for user login and logout events.
Map Users to Groups. This enables the firewall to connect to your LDAP directory and retrieve Group Mapping information so that you will be able to select usernames and group names when creating policy.
Map IP Addresses to Users. As a best practice, do not enable client probing as a user mapping method on high-security networks. Client probing can generate a large amount of network traffic and can pose a security threat when misconfigured. The way you do this depends on where your users are located and what types of systems they are using, and what systems on your network are collecting login and logout events for your users. You must configure one or more User-ID agents to enable User Mapping: Configure User Mapping Using the Windows User-ID Agent. Configure User Mapping Using the PAN-OS Integrated User-ID Agent. Configure User-ID to Receive User Mappings from a Syslog Sender. Configure User Mapping for Terminal Server Users. Send User Mappings to User-ID Using the XML API.
Specify the networks to include and exclude from user mapping. As a best practice, always specify which networks to include and exclude from User-ID. This allows you to ensure that only your trusted assets are probed and that unwanted user mappings are not created unexpectedly. Configure each agent that you configured for user mapping as follows: Specify the subnetworks the Windows User-ID agent should include in or exclude from User-ID. Specify the subnetworks the PAN-OS integrated User-ID agent should include in or exclude from user mapping.
Enable user- and group-based policy enforcement. Create rules based on group rather than user whenever possible. This prevents you from having to continually update your rules (which requires a commit) whenever your user base changes. After configuring User-ID, you will be able to choose a username or group name when defining the source or destination of a security rule: Select Policies > Security and Add a new rule or click an existing rule name to edit. Select the User tab and specify which users and groups to match in the rule in one of the following ways: If you want to select specific users/groups as matching criteria, click the Add button in the Source User section to display a list of users and groups discovered by the firewall group mapping function. Select the users and/or groups to add to the rule. If you want to match any user who has or has not authenticated and you don’t need to know the specific user or group name, select known-user or unknown from the drop-down above the Source User list. Configure the rest of the rule as appropriate and then click OK to save it. For details on other fields in the security rule, see Set Up a Basic Security Policy.
Create the Security policy rules to safely enable User-ID within your trusted zones and prevent User-ID traffic from egressing your network. Follow the Best Practice Internet Gateway Security Policy to ensure that the User-ID application (paloalto-userid-agent) is only allowed in the zones where your agents (both your Windows agents and your PAN-OS integrated agents) are monitoring services and distributing mappings to firewalls. Specifically: Allow the paloalto-userid-agent application between the zones where your agents reside and the zones where the monitored servers reside (or even better, between the specific systems that host the agent and the monitored servers). Allow the paloalto-userid-agent application between the agents and the firewalls that need the user mappings and between firewalls that are redistributing user mappings and the firewalls they are redistributing the information to. Deny the paloalto-userid-agent application to any external zone, such as your internet zone.
Configure Captive Portal. Because Captive Portal authenticates users rather than relying on user mappings, it is useful for ensuring that you know exactly who is accessing your most sensitive applications and data. You can configure Captive Portal as the fall-back to identify users who have not yet been identified using another user mapping method before allowing access. As a best practice, choose Kerberos transparent authentication over NTLM authentication when configuring Captive Portal. Kerberos is a stronger, more robust authentication method than NTLM and it does not require the firewall to have an administrative account to join the domain. Select Policies > Captive Portal. Add a Name for the rule. Define the matching criteria for the rule by completing the Source, Destination, and Service/URL Category tabs as appropriate to match the traffic you want to authenticate. The matching criteria on these tabs is the same as the criteria you define when creating a Security policy rule. See Set Up a Basic Security Policy for details. Define the Action to take on traffic that matches the rule: no-captive-portal —Allow traffic to pass without presenting a Captive Portal page for authentication. web-form —Present a Captive Portal page for the user to explicitly enter authentication credentials or use client certificate authentication. browser-challenge —Transparently obtain user authentication credentials. If you select this action, you must enable Kerberos Single Sign-On (SSO) or NT LAN Manager (NTLM) authentication when you Configure Captive Portal. If Kerberos SSO authentication fails, the firewall falls back to NTLM authentication. If you didn’t configure NTLM, or NTLM authentication fails, the firewall falls back to web-form authentication. Click OK and Commit.
Configure the firewall to obtain the user IP address from the X-Forwarded-For (XFF) header. When the firewall is between the Internet and a proxy server, the IP address in the packet the firewall sees contains is for the proxy server rather than the user. To enable visibility of the user IP address instead, configure the firewall to use the XFF header for user mapping. With this option enabled, the firewall matches the IP addresses with usernames referenced in policy to enable control and visibility for the associated users and groups. For details, see Identify Users Connected through a Proxy Server. Select Device > Setup > Content-ID and edit the X-Forwarded-For Headers settings. Select the X-Forwarded-For Header in User-ID check box. Selecting the Strip-X-Forwarded-For Header check box doesn’t disable the use of XFF headers for user attribution in policy rules; the firewall zeroes out the XFF value only after using it for user attribution. Click OK to save your changes.
Verify the User-ID Configuration. After you configure user mapping and group mapping, verify that it is working properly and that you can safely enable and monitor user and group access to the applications, resources, and services.

Related Documentation