Deploy User-ID in a Large-Scale Network

A large-scale network can have hundreds of information sources that firewalls query to map IP addresses to usernames and to map usernames to user groups. You can simplify User-ID administration for such a network by aggregating the user mapping and group mapping information before the User-ID agents collect it, thereby reducing the number of required agents.

A large-scale network can also have numerous firewalls that use the mapping information to enforce policies. You can reduce the resources that the firewalls and information sources use in the querying process by configuring some firewalls to acquire mapping information through redistribution instead of direct querying. Redistribution also enables the firewalls to enforce user-based policies when users rely on local sources for authentication (such as regional directory services) but need access to remote services and applications (such as global data center applications).

If you  Configure Authentication Policy , your firewalls must also redistribute the  Authentication Timestamps  associated with user responses to authentication challenges. Firewalls use the timestamps to evaluate the timeouts for Authentication policy rules. The timeouts allow a user who successfully authenticates to later request services and applications without authenticating again within the timeout periods. Redistributing timestamps enables you to enforce consistent timeouts for each user even if the firewall that initially grants a user access is not the same firewall that later controls access for that user.

If you have configured multiple virtual systems, you can share IP address-to-username mapping information across virtual systems by selecting a virtual system as a User-ID hub.

Deploy User-ID for Numerous Mapping Information Sources

 

You can use Windows Log Forwarding and Global Catalog servers to simplify user mapping and group mapping in a large-scale network of Microsoft Active Directory (AD) domain controllers or Exchange servers. These methods simplify User-ID administration by aggregating the mapping information before the User-ID agents collect it, thereby reducing the number of required agents.

Windows Log Forwarding and Global Catalog Servers

Because each User-ID agent can monitor up to 100 servers, the firewall needs multiple User-ID agents to monitor a network with hundreds of AD domain controllers or Exchange servers. Creating and managing numerous User-ID agents involves considerable administrative overhead, especially in expanding networks where tracking new domain controllers is difficult. Windows Log Forwarding enables you to minimize the administrative overhead by reducing the number of servers to monitor and thereby reducing the number of User-ID agents to manage. When you configure Windows Log Forwarding, multiple domain controllers export their login events to a single domain member from which a User-ID agent collects the user mapping information.

You can configure Windows Log Forwarding for Windows Server versions 2012 and 2012 R2. Windows Log Forwarding is not available for non-Microsoft servers.

To collect group mapping information in a large-scale network, you can configure the firewall to query a Global Catalog server that receives account information from the domain controllers.

The following figure illustrates user mapping and group mapping for a large-scale network in which the firewall uses a Windows-based User-ID agent. See  Plan a Large-Scale User-ID Deployment  to determine if this deployment suits your network.

A diagram of a server AI-generated content may be incorrect.

Plan a Large-Scale User-ID Deployment

When deciding whether to use Windows Log Forwarding and Global Catalog servers for your User-ID implementation, consult your system administrator to determine:

Domain controllers won’t forward their entire security logs, they forward only the events that the user mapping process requires per login: four events for Windows Server 2012 and MS Exchange.

Configure Windows Log Forwarding

To configure Windows Log Forwarding, you need administrative privileges for configuring group policies on Windows servers. Configure Windows Log Forwarding on all the  Windows Event Collectors —the member servers that collect login events from domain controllers. The following is an overview of the tasks; consult your  Windows Server documentation  for the specific steps.

  1. On each Windows Event Collector, enable event collection, add the domain controllers as event sources, and configure the event collection query (subscription). The events you specify in the subscription vary by domain controller platform:

To forward events as quickly as possible,  Minimize Latency  when configuring the subscription.

User-ID agents monitor the Security log on Windows Event Collectors, not the default forwarded events location. To change the event logging path to the Security log, perform the following steps on each Windows Event Collector.

2.                   Open the Event Viewer.

3.                   Right-click the  Security  log and select  Properties .

4.                   Copy the  Log path  (default  %SystemRoot%\System32\Winevt\Logs\security.evtx ) and click  OK .

5.                   Right-click the  Forwarded Events  folder and select  Properties .

6.                   Replace the default  Log path  ( %SystemRoot%\System32\Winevt\Logs\ForwardedEvents.evtx ) by pasting the value from the  Security  log, and then click  OK .

  1. Configure a group policy to enable Windows Remote Management (WinRM) on the domain controllers.
  2. Configure a group policy to enable Windows Event Forwarding on the domain controllers.

Configure User-ID for Numerous Mapping Information Sources

  1. Configure Windows Log Forwarding on the member servers that will collect login events.

Configure Windows Log Forwarding . This step requires administrative privileges for configuring group policies on Windows servers.

  1. Install the Windows-based User-ID agent.

Install the Windows-Based User-ID Agent  on a Windows server that can access the member servers. Make sure the system that will host the User-ID agent is a member of the same domain as the servers it will monitor.

  1. Configure the User-ID agent to collect user mapping information from the member servers.
    1. Start the Windows-based User-ID agent.
    2. Select  User IdentificationDiscovery  and perform the following steps for each member server that will receive events from domain controllers:
      1. In the Servers section, click  Add  and enter a  Name  to identify the member server.
      2. In the  Server Address  field, enter the FQDN or IP address of the member server.
      3. For the  Server Type , select  Microsoft Active Directory .
      4. Click  OK  to save the server entry.
    3. Configure the remaining User-ID agent settings (refer to  Configure the Windows-Based User-ID Agent for User Mapping ).
    4. If the User-ID sources provide usernames in multiple formats, specify the format for the  Primary Username  when you  Map Users to Groups .

The primary username is the username that identifies the user on the firewall and represents the user in reports and logs, regardless of the format that the User-ID source provides.

  1. Configure an LDAP server profile to specify how the firewall connects to the Global Catalog servers (up to four) for group mapping information.

To improve availability, use at least two Global Catalog servers for redundancy.

You can collect group mapping information only for universal groups, not local domain groups (subdomains).

    1. Select  DeviceServer ProfilesLDAP , click  Add , and enter a  Name  for the profile.
    2. In the Servers section, for each Global Catalog, click  Add  and enter the server  Name , IP address ( LDAP Server ), and  Port . For a plaintext or Start Transport Layer Security ( Start TLS ) connection, use  Port  3268. For an LDAP over SSL connection, use  Port  3269. If the connection will use Start TLS or LDAP over SSL, select the  Require SSL/TLS secured connection  check box.
    3. In the  Base DN  field, enter the Distinguished Name (DN) of the point in the Global Catalog server where the firewall will start searching for group mapping information (for example,  DC=acbdomain,DC=com ).
    4. For the  Type , select  active-directory .
  1. Configure an LDAP server profile to specify how the firewall connects to the servers (up to four) that contain domain mapping information.

User-ID uses this information to map DNS domain names to NetBIOS domain names. This mapping ensures consistent domain/username references in policy rules.

To improve availability, use at least two servers for redundancy.

The steps are the same as for the LDAP server profile you created for Global Catalogs in the previous step, except for the following fields:

  1. Create a group mapping configuration for each LDAP server profile you created.
    1. Select  DeviceUser IdentificationGroup Mapping Settings .
    2. Click  Add  and enter a  Name  to identify the group mapping configuration.
    3. Select the LDAP  Server Profile  and ensure the  Enabled  check box is selected.

If the Global Catalog and domain mapping servers reference more groups than your security rules require, configure the  Group Include List  and/or  Custom Group  list to limit the groups for which User-ID performs mapping.

    1. Click  OK  and  Commit .

Insert Username in HTTP Headers

When you configure a secondary enforcement appliance with your Palo Alto Networks firewall to enforce user-based policy, the secondary appliance may not have the IP address-to-username mapping from the firewall. Transmitting user information to downstream appliances may require deployment of additional appliances such as proxies or negatively impact the user’s experience (for example, users having to log in multiple times). By sharing the user's identity in the HTTP headers, you can enforce user-based policy without negatively impacting the user's experience or deploying additional infrastructure.

When you configure this feature, apply the URL Filtering profile to a Security policy rule, and commit your changes, the firewall:

  1. Populates the user and domain values with the format of the  primary username  in the group mapping for the source user.
  2. Encodes this information using Base64.
  3. Adds the Base64-encoded header to the payload.
  4. Routes the traffic to the downstream appliance.

If you want to include the username and domain only when the user accesses specific domains, configure a domain list and the firewall inserts the header only when a domain in the list matches the Host header of the HTTP request.

To share user information with downstream appliances, you must first  enable  User-ID and configure  group mapping .

To include the username and domain in the header, the firewall requires the IP address-to-username mapping for the user. If the user isn't mapped, the firewall inserts  unknown  in Base64 encoding for both the domain and username in the header.

To include the username and domain in headers for HTTPS traffic, you must first create a  Decryption profile  to decrypt HTTPS traffic.

This feature supports forward-proxy decryption traffic.

  1. Create  or edit a URL Filtering profile.

The firewall does not insert headers if the action for the URL Filtering profile is  block  for the domain.

  1. Create or edit an  HTTP header insertion entry  using predefined types.

You can define up to five headers for each profile.

  1. Select  Dynamic Fields  as the header  Type .
  2. Add  the  Domains  where you want insert headers. When the user accesses a domain in the list, the firewall inserts the specified header.
  3. Add  a new  Header  or select  X-Authenticated-User  to edit it.
  4. Select a header  Value  format (either  ($domain)\($user)  or  WinNT://($domain)/($user) ) or enter your own format using the  ($domain)  and  ($user)  dynamic tokens (for example,  ($user)@($domain)  for UserPrincipalName).

Do not use the same dynamic token (either  ($user)  or  ($domain) ) more than once per value.

Each value can be up to 512 characters. The firewall populates the  ($user)  and  ($domain)  dynamic tokens using the primary username in the group mapping profile. For example:

  1. ( Optional ) Select  Log  to enable logging for the header insertion.
  2. Apply the URL Filtering profile to the Security policy rule for HTTP or HTTPS traffic.
  3. Select  OK  twice to confirm the HTTP header configuration.
  4. Commit  your changes.
  5. Verify the firewall includes the username and domain in the HTTP headers.

Redistribute Data and Authentication Timestamps

 

In a large-scale network, instead of configuring all your firewalls to directly query the mapping information sources, you can streamline resource usage by configuring some firewalls to collect mapping information through redistribution.

You can redistribute user mapping information collected through any method except Terminal Server (TS) agents. You cannot redistribute  Group Mapping  or  HIP match  information.

If you use Panorama to manage firewalls and aggregate firewall logs, you can use Panorama to  manage User-ID redistribution . Leveraging Panorama is a simpler solution than creating extra connections between firewalls to redistribute User-ID information.

If you  Configure Authentication Policy , your firewalls must also redistribute the  Authentication Timestamps  that are generated when users authenticate to access applications and services. Firewalls use the timestamps to evaluate the timeouts for Authentication policy rules. The timeouts allow a user who successfully authenticates to later request services and applications without authenticating again within the timeout periods. Redistributing timestamps enables you to enforce consistent timeouts across all the firewalls in your network.

Firewalls share data and authentication timestamps as part of the same redistribution flow; you don’t have to configure redistribution for each information type separately.

Firewall Deployment for Data Redistribution

In a large-scale network, instead of configuring all your firewalls to directly query the data sources, you can streamline resource usage by configuring some firewalls to collect data through redistribution. Data redistribution also provides granularity, allowing you to redistribute only the types of information you specify to only the devices you select. You can also filter the IP user mappings or IP tag mappings using subnets and ranges to ensure the firewalls collect only the mappings they need to enforce policy.

Data redistribution can be unidirectional (the agent provides data to the client) or bidirectional, where both the agent and the client can simultaneously send and receive data.

To redistribute the data, you can use the following architecture types:

To redistribute data between firewalls, use a hub and spoke architecture as a best practice. In this configuration, a hub firewall collects the data from sources such as Windows User-ID agents, Syslog Servers, Domain Controllers, or other firewalls. Configure the redistribution client firewalls to collect the data from the hub firewall.

For example, a hub (consisting of a pair of VM-50s for resiliency) could connect to the User-ID sources for the user mappings. The hub would then be able to redistribute the user mappings when the client firewalls that use the user mappings to enforce policy connect to the hub to receive data.

If you have firewalls deployed in multiple regions and want to distribute the data to the firewalls in all of these regions so that you can enforce policy consistently regardless of where the user logs in, you can use a multi-hub and spoke architecture for multiple regions.

Start by configuring a firewall in each region to collect data from the sources. This firewall acts as a local hub for redistribution. This firewall collects the data from all sources in that region so that it can redistribute it to the client firewalls. Next, configure the client firewalls to connect to the redistribution hubs for their region and all other regions so that the client firewalls have all data from all hubs.

As a best practice, enable bidirectional redistribution within a region if the firewalls need to both send and receive data. For example, if a firewall is acting as a GlobalProtect gateway for remote users and as a branch firewall for local users, the firewall must send the user mappings it collects for remote users to the hub firewall as well as receive the user mappings of the local users from the hub firewall.

To redistribute data, you can also use a hierarchical architecture. For example, to redistribute data such as User-ID information, organize the redistribution sequence in layers, where each layer has one or more firewalls. In the bottom layer, PAN-OS integrated User-ID agents running on firewalls and Windows-based User-ID agents running on Windows servers map IP addresses to usernames. Each higher layer has firewalls that receive the mapping information and authentication timestamps from up to 100 redistribution points in the layer beneath it. The top-layer firewalls aggregate the mappings and timestamps from all layers. This deployment provides the option to configure policies for all users in top-layer firewalls and region- or function-specific policies for a subset of users in the corresponding domains served by lower-layer firewalls.

In this scenario, three layers of firewalls redistribute mappings and timestamps from local offices to regional offices and then to a global data center. The data center firewall that aggregates all the information shares it with other data center firewalls so that they can all enforce policy and generate reports for users across your entire network. Only the bottom layer firewalls use User-ID agents to query the directory servers.

The information sources that the User-ID agents query do not count towards the maximum of ten  hops  in the sequence. However, Windows-based User-ID agents that forward mapping information to firewalls do count. Also in this example, the top layer has two hops: the first to aggregate information in one data center firewall and the second to share the information with other data center firewalls.

Configure Data Redistribution

Before you configure data redistribution:

Data redistribution consists of:

Perform the following steps on the firewalls in the data redistribution sequence.

  1. On a redistribution client firewall, configure a firewall, Panorama, or Windows User-ID agent as a data redistribution agent.
    1. Select  DeviceData RedistributionAgents .
    2. Add  a redistribution agent and enter a  Name .
    3. Confirm that the agent is  Enabled .
  2. Add the agent using its  Serial Number  or its  Host and Port .
  1. Select one or more  Data Type  for the agent to redistribute.
  1. ( Multiple virtual systems only ) Configure a virtual system as a collector that can redistribute data.

Skip this step if the firewall receives but does not redistribute data.

You can redistribute information among virtual systems on different firewalls or on the same firewall. In both cases, each virtual system counts as one hop in the redistribution sequence.

    1. Select  DeviceData RedistributionCollector Settings .
    2. Edit the  Data Redistribution Agent Setup .
    3. Enter a  Collector Name  and  Pre-Shared Key  to identify this firewall or virtual system as a User-ID agent.
    4. Click  OK  to save your changes.
  1. ( Optional but recommended ) Configure which networks you want to include in data redistribution and which networks you want to exclude from data redistribution.

You can include or exclude networks and subnetworks when redistributing either IP address-to-tag mappings or IP address-to-username mappings.

As a best practice, always specify which networks to include and exclude to ensure that the agent is only communicating with internal resources.

    1. Select  DeviceData RedistributionInclude/Exclude Networks .
    2. Add  an entry and enter a  Name .
    3. Confirm that the entry is  Enabled .
    4. Select whether you want to  Include  or  Exclude  the entry.
    5. Enter the  Network Address  for the entry.
    6. Click  OK .
  1. Configure the service route that the firewall uses to query other firewalls for User-ID information.

Skip this step if the firewall only receives user mapping information from Windows-based User-ID agents or directly from the information sources (such as directory servers) instead of from other firewalls.

    1. Select  DeviceSetupServices .
    2. ( Firewalls with multiple virtual systems only ) Select  Global  (for a firewall-wide service route) or  Virtual Systems  (for a virtual system-specific service route), and then  configure the service route .
    3. Click  Service Route Configuration , select  Customize , and select  IPv4  or  IPv6  based on your network protocols. Configure the service route for both protocols if your network uses both.
    4. Select  UID Agent  and then select the  Source Interface  and  Source Address .
    5. Click  OK  twice to save the service route.
  1. Enable the firewall to respond when other firewalls query it for data to redistribute.

Skip this step if the firewall receives but does not redistribute data.

Configure an Interface Management Profile  with the  User-ID  service enabled and assign the profile to a firewall interface.

  1. ( Optional but recommended ) Use a custom certificate from your enterprise PKI to establish a unique chain of trust from the redistribution client to the redistribution agent.
    1. On the redistribution client firewall, create a custom  SSL certificate profile  to use for outgoing connections.
    2. Select  DeviceSetupManagementSecure Communication Settings .
    3. Edit  the settings.
    4. Select the  Customize Secure Server Communication  option.
    5. Select the  Certificate Profile  you created in Substep 1.
    6. Click  OK .
    7. Customize Communication  for  Data Redistribution .
    8. Commit  your changes.
    9. Enter the following CLI command to confirm the certificate profile ( SSL config)  uses  Custom certificates :  show redistribution agent state <agent-name>  (where <agent-name> is the name of the redistribution agent or User-ID agent.
  2. ( Optional but recommended ) Use a custom certificate from your enterprise PKI to establish a unique chain of trust from the redistribution agent to the redistribution client.
    1. On the redistribution agent firewall, create a custom  SSL/TLS service profile  for the firewall to use for incoming connections.
    2. Select  DeviceSetupManagementSecure Communication Settings .
    3. Edit  the settings.
    4. Select the  Customize Secure Server Communication  option.
    5. Select the  SSL/TLS Service Profile  you created in Step 1.
    6. Click  OK .
    7. Commit  your changes.
    8. Enter the following CLI command to confirm the certificate profile ( SSL config)  uses  Custom certificates :  show redistribution service status .
  3. Verify the agents correctly redistribute data to the clients.
    1. View the agent statistics ( DeviceData RedistributionAgents ) and select  Status  to view a summary of the activity for the redistribution agent, such as the number of mappings that the client firewall has received.
    2. Confirm that the  Connected  status is  yes .
    3. On the agent,  access the CLI  and enter the following CLI command to check the status of the redistribution:  show redistribution service status .
    4. On the agent, enter the following CLI command to view the redistribution clients:  show redistribution service client all .
    5. On the client, enter the following CLI command to check the status of the redistribution:  show redistribution service client all .
    6. Confirm the  Source Name  in the User-ID logs ( MonitorLogsUser-ID ) to verify that the firewall receives the mappings from the redistribution agents.
    7. On the client, view the IP-Tag log ( MonitorLogsIP-Tag ) to confirm that the client firewall receives data.
    8. On the client, enter the following CLI command and verify that the source the firewall receives the mappings  From  is  REDIST :  show user ip-user-mapping all .
  4. ( Optional ) To troubleshoot data redistribution, enable the traceroute option.

When you enable the traceroute option, the firewall that receives the data appends its IP address to the  <route>  field, which is a list of all firewall IP addresses that the data has traversed. This option requires that all PAN-OS devices in the redistribution route use PAN-OS version 10.0. If a PAN-OS device in the redistribution route uses PAN-OS 9.1.x or earlier versions, the traceroute information terminates at that device.

    1. On the redistribution agent where the source originates, enter the following CLI command:  debug user-id test cp-login traceroute yes ip-address <ip-address> user <username>  (where  <ip-address>  is the IP address of the IP address-to-username mapping you want to verify and  <username>  is the username of the IP address-to-username mapping you want to verify.
    2. On a client of the firewall where you configured the traceroute, verify the firewall redistributes the data by entering the following CLI command:  show user ip-user-mapping all .

The firewall displays the timestamp for the creation of the mapping ( SeqNumber ) and whether the user has GlobalProtect ( GP User ).

admin > show user ip-user-mapping-mp ip 192.0.2.0

 

IP address:      192.0.2.0 (vsys1)

User:                                    jimdoe

From:                                  REDIST

Timeout:                           889s

Created:                            11s ago

Origin:                                198.51.100.0

SeqNumber:                   15895329682-67831262

GP User:                            No

Local HIP:                         No

Route Node 0:               198.51.100.0 (vsys1)

Route Node 1:               198.51.100.1 (vsys1)

Share User-ID Mappings Across Virtual Systems

To simplify User-ID™ source configuration when you have multiple virtual systems, configure the User-ID sources on a single  virtual system  to share IP address-to-username mappings and username-to-group mappings with all other virtual systems on the firewall.

Configuring a single virtual system as a  User-ID hub  simplifies user mapping by eliminating the need to configure the sources on multiple virtual systems, especially if traffic will pass through multiple virtual systems based on the resources the user is trying to access (for example, in an academic networking environment where a student will be accessing different departments whose traffic is managed by different virtual systems).

To map the user or group, the firewall uses the mapping table on the local virtual system and applies the policy for that user or group. If the firewall does not find the mapping for a user or group on the virtual system where that user’s traffic originated, the firewall queries the hub to fetch the IP address-to-username information for that user or group mapping information for that group. If the firewall locates the mapping on both the User-ID hub and the local virtual system, the firewall uses the mapping it learns locally. If the mapping on the local firewall differs from the mapping on the virtual system hub, the firewall uses the local mapping.

After you configure the User-ID hub, the virtual system can use the mapping table on the User-ID hub when it needs to identify a user for user-based policy enforcement or to display the username in a log or report but the source is not available locally. When you select a hub, the firewall retains the mappings on other virtual systems so we recommend consolidating the User-ID sources on the hub. However, if you don’t want to share mappings from a specific source, you can configure an individual virtual system to perform user or group mapping.

  1. Assign the  virtual system  as a User-ID hub.
    1. Select  DeviceVirtual Systems  and then select the virtual system where you consolidated your User-ID sources.
    2. On the  Resource  tab,  Make this vsys a User-ID data hub  and click  Yes  to confirm. Then click  OK .

A screenshot of a computer AI-generated content may be incorrect.

  1. Click  Yes  to confirm.

A screenshot of a computer AI-generated content may be incorrect.

  1. Select the  Mapping Type  that you want to share then click  OK .

A screenshot of a computer AI-generated content may be incorrect.

You must select at least one mapping type.

  1. Consolidate your User-ID sources and migrate them to the virtual system that you want to use as a User-ID hub.

This consolidates the User-ID configuration for operational simplicity. By configuring the hub to monitor servers and connect to agents that were previously monitored by other virtual systems, the hub collects the user mapping information instead of having each virtual system collect it independently. If you don’t want to share mappings from specific virtual systems, configure those mappings on a virtual system that will not be used as the hub.

Use the same format for the Primary Username across virtual systems and firewalls.

    1. Remove any sources that are unnecessary or outdated.
    2. Identify all configurations for your  Windows-based  or  integrated  agents and any sources that send user mappings using the  XML API  and copy them to the virtual system you want to use as a User-ID hub.

On the hub, you can configure any User-ID source that is currently configured on a virtual system. However, IP address-and-port-to-username mapping information from Terminal Server agents are not shared between the User-ID hub and the connected virtual systems.

    1. Specify the subnetworks that User-ID should  include in or exclude from  mapping.
    2. Define  the  Ignore User List .
    3. On all other virtual systems, remove any sources that are on the User-ID hub.
  1. Commit  the changes to enable the User-ID hub and begin collecting mappings for the consolidated sources.
  2. Confirm the User-ID hub is mapping the users and groups.
    1. Use the  show user ip-user-mapping all  command to show the IP address-to-username mappings and which virtual system provides the mappings.
    2. Use the  show user user-id-agent statistics  command to show which virtual system is serving as the User-ID hub.
    3. Confirm the hub is sharing the group mappings by using the following CLI commands:
      • show user group-mapping statistics
      • show user group-mapping state all
      • show user group list
      • show user group name <group-name>