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.
- 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.
- Selectand click the Name of the zone.NetworkZones
- Select theEnable User Identificationcheck box and clickOK.
- 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.
- 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:
- Specify the networks to include and 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:
- SelectandPoliciesSecurityAdda new rule or click an existing rule name to edit.
- Select theUsertab 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 theAddbutton 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, selectknown-userorunknownfrom the drop-down above the Source User list.
- Configure the rest of the rule as appropriate and then clickOKto 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.
- 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.PoliciesCaptive Portal
- AddaNamefor the rule.
- Define the matching criteria for the rule by completing theSource,Destination, andService/URL Categorytabs 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 theActionto 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 toweb-formauthentication.
- 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.
- Selectand edit the X-Forwarded-For Headers settings.DeviceSetupContent-ID
- Select theX-Forwarded-For Header in User-IDcheck box.Selecting theStrip-X-Forwarded-For Headercheck 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.
- ClickOKto save your changes.
- 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.
Recommended For You
Recommended videos not found.