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.
Network > Zones
and click the Name of the zone.
Enable User Identification
check box and click
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
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
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:
Policies > Security
a new rule or click an existing rule name to edit.
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
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
from the drop-down above the Source User list.
Configure the rest of the rule as appropriate and then click
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.
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.
Policies > Captive Portal.
for the rule.
Define the matching criteria for the rule by completing the
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
to take on traffic that matches the rule:
—Allow traffic to pass without presenting a Captive Portal page for authentication.
—Present a Captive Portal page for the user to explicitly enter authentication credentials or use client certificate authentication.
—Transparently obtain user authentication credentials. If you select this action, you must enable
Kerberos Single Sign-On (SSO)
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
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.
Device > Setup > Content-ID
and edit the X-Forwarded-For Headers settings.
X-Forwarded-For Header in User-ID
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.
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.