Map IP Addresses to Users

User-ID provides many different methods for mapping IP addresses to usernames. Before you begin configuring user mapping, consider where your users are logging in from, what services they are accessing, and what applications and data you need to control access to. This will inform which types of agents or integrations would best allow you to identify your users.

Once you have your plan, you can begin configuring user mapping using one or more of the following methods as needed to enable user-based access and visibility to applications and resources:

• If you have users with client systems that aren’t logged in to your domain servers—for example, users running Linux clients that don’t log in to the domain—you can  Map IP Addresses to Usernames Using Authentication Portal . Using Authentication Portal in conjunction with  Authentication Policy  also ensures that all users authenticate to access your most sensitive applications and data.
• To map users as they log in to your Exchange servers, domain controllers, eDirectory servers, or Windows clients you must configure a User-ID agent:
• Configure User Mapping Using the PAN-OS Integrated User-ID Agent
• Configure User Mapping Using the Windows User-ID Agent
• If you have clients running multi-user systems in a Windows environment, such as Microsoft Terminal Server or Citrix Metaframe Presentation Server or XenApp,  Configure the Palo Alto Networks Terminal Server (TS) Agent for User Mapping . For a multi-user system that doesn’t run on Windows, you can  Retrieve User Mappings from a Terminal Server Using the PAN-OS XML API .
• To obtain user mappings from existing network services that authenticate users—such as wireless controllers, 802.1x devices, Apple Open Directory servers, proxy servers, or other Network Access Control (NAC) mechanisms— Configure User-ID to Monitor Syslog Senders for User Mapping .

While you can configure either the Windows agent or the PAN-OS integrated User-ID agent on the firewall to listen for authentication syslog messages from the network services, because only the PAN-OS integrated agent supports syslog listening over TLS, it is the preferred configuration.

• To include the username and domain in the headers for outgoing traffic so other devices in your network can identify the user and enforce user-based policy, you can  Insert Username in HTTP Headers .
• To  Share User-ID Mappings Across Virtual Systems , you can configure a virtual system as a User-ID hub.
• For other clients that you can’t map using the other methods, you can  Send User Mappings to User-ID Using the XML API .
• A large-scale network can have hundreds of information sources that firewalls query for user and group mapping and can have numerous firewalls that enforce policies based on the mapping information. You can simplify User-ID administration for such a network by aggregating the mapping information before the User-ID agents collect it. You can also reduce the resources that the firewalls and information sources use in the querying process by configuring some firewalls to redistribute the mapping information. For details, see  Deploy User-ID in a Large-Scale Network .

Create a Dedicated Service Account for the User-ID Agent

To use the Windows-based User-ID agent or the PAN-OS integrated User-ID agent to map users as they log in to your Exchange servers, domain controllers, eDirectory servers, or Windows clients, create a dedicated service account for the User-ID agent on a domain controller in each domain that the agent will monitor.

The User-ID agent maps users based on logs for security events. To ensure that the User-ID agent can successfully map users, verify that the source for your mappings generates logs for  Audit Logon ,  Audit Kerberos Authentication Service , and  Audit Kerberos Service Ticket Operations  events. At a minimum, the source must generate logs for the following events:

• Logon Success (4624)
• Authentication Ticket Granted (4768)
• Service Ticket Granted (4769)
• Ticket Granted Renewed (4770)

The required permissions for the service account depend on the user mapping methods and settings you plan to use. For example, if you are using the PAN-OS integrated User-ID agent, the service account requires Server Operator privileges to monitor user sessions. If you are using the Windows-based User-ID agent, the service account does not require Server Operator privileges to monitor user sessions. To reduce the risk of compromising the User-ID service account, always configure the account with the minimum set of permissions necessary for the agent.

• If you are installing the Windows-based User-ID agent on a supported Windows server, 

Configure a Service Account for the Windows User-ID Agent

.

• If you are using the PAN-OS integrated User-ID agent on the firewall, 

Configure a Service Account for the PAN-OS Integrated User-ID Agent

.

User-ID provides many methods for safely collecting user mapping information. Some legacy features designed for environments that only required user mapping on Windows desktops attached to the local network require privileged service accounts. If the privileged service account is compromised, this would open your network to attack. As a best practice, avoid using legacy features that require privileges that would pose a threat if compromised, such as client probing and session monitoring.

Configure a Service Account for the Windows User-ID Agent

Create a dedicated Active Directory (AD) service account for the Windows User-ID agent to access the services and hosts it will monitor to collect user mappings. You must create a service account in each domain the agent will monitor. After you enable the required permissions for the service account,  Configure User Mapping Using the Windows User-ID Agent .

The following workflow details all required privileges and provides guidance for the User-ID features that require privileges that could pose a threat so that you can decide how to best identify users without compromising your overall security posture.

1. Create an AD service account for the User-ID agent.

You must create a service account in each domain the agent will monitor.

1. Log in to the domain controller.
2. Right-click the Windows icon (

   

),  Search  for  Active Directory Users and Computers , and launch the application.

3. In the navigation pane, open the domain tree, right-click  Managed Service Accounts  and select  NewUser .
4. Enter the  First Name ,  Last Name , and  User logon name  of the user and click  Next .
5. Enter the  Password  and  Confirm Password , then click  Next  and  Finish .
1. Configure either local or group policy to allow the service account to log on as a service.

The permission to log on as a service is only needed locally on the Windows server that is the agent host.

• To assign permissions locally:
1. select  Control PanelAdministrative ToolsLocal Security Policy .
2. 
3. Select  Local PoliciesUser Rights AssignmentLog on as a service .

4. Add User or Group  to add the service account.

5. Enter the object names to select  (the service account name) in  domain\username  format and click  OK .

• To configure group policy if you are installing Windows User-ID agents on multiple servers, use the Group Policy Management Editor.
1. Select  StartGroup Policy Management<your domain>Default Domain PolicyActionEdit  for the Windows server that is the agent host.

2. Select  Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment .

3. Right-click  Log on as a service , then select  Properties .
4. Add User or Group  to add the service account username or builtin group, then click  OK  twice.

Administrators have this privilege by default.

3. ( Windows Server 2022 with User-ID Credential Detection only ) If you are using Windows Server 2022 and  credential detection , assign the following privileges to the service account:

• Replicating Directory Changes
• Replicating Directory Changes All
• Replicating Directory Changes in Filtered Set

For more information, refer to the following  documentation .

4. 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.
1. Select  Active Directory Users and Computers<your domain>BuiltinDistributed COM Users .
2. Right-click  PropertiesMembersAdd  and enter the service account name.
5. If you plan to use  WMI probing , enable the account to read the CIMV2 namespace and assign the required permissions on the client systems to be probed.

Do not enable client probing on high-security networks. Client probing can generate a large amount of network traffic and can pose a security threat when misconfigured. Instead collect user mapping information from more isolated and trusted sources, such as domain controllers and through integrations with Syslog or the XML API, which have the added benefit of allowing you to safely capture user mapping information from any device type or operating system, instead of just Windows clients.

Perform this task on each client system that the User-ID agent will probe for user mapping information:

1. Right-click the Windows icon (

   

),  Search  for  wmimgmt.msc , and launch the WMI Management Console.

2. In the console tree, right-click  WMI Control  and select  Properties .

3. Select the  Security  tab, then select  RootCIMV2 , and click the  Security  button.

4. Add  the name of the service account you created,  Check Names  to verify your entry, and click  OK .

You might have to change the  Locations  or click  Advanced  to query for account names. See the dialog help for details.

5. In the Permissions for  <Username>  section,  Allow  the  Enable Account  and  Remote Enable  permissions.

6. Click  OK  twice.
7. Use the Local Users and Groups MMC snap-in (lusrmgr.msc) to add the service account to the local Distributed Component Object Model (DCOM) Users and Remote Desktop Users groups on the system that will be probed.
5. If you want to use  Server Monitoring  to identify users, add the service account to the Event Log Reader builtin group to allow the service account to read the security log events.
1. On the domain controller or Exchange server that contains the logs you want the User-ID agent to read, or on the member server that receives events from Windows log forwarding, select  StartRun , enter  MMC .
2. Select  FileAdd/Remove Snap-inActive Directory Users and ComputersAdd , then click  OK  to run the MMC and launch the Active Directory Users and Computers snap-in.

3. Navigate to the Builtin folder for the domain, right-click the  Event Log Readers  group, and select  PropertiesMembers .

4. Add  the service account then click  Check Names  to validate that you have the proper object name.

5. Click  OK  twice to save the settings.
6. Confirm that the builtin Event Log Reader group lists the service account as a member ( Event Log ReadersPropertiesMembers ).
6. Assign account permissions to the installation folder to allow the service account to access the agent’s installation folder to read the configuration and write logs.

You only need to perform this step if the service account you configured for the User-ID agent is not a domain administrator or a local administrator on the User-ID agent server host.

1. From the Windows Explorer, navigate to  C:\Program Files(x86)\Palo Alto Networks , right-click the folder, and select  Properties .
2. On the  Security  tab, click  Edit .

3. Add  the User-ID agent service account and  Allow  permissions to  Modify ,  Read & execute ,  List folder contents ,  Read , and  Write , and then click  OK  to save the account settings.

If you do not want to configure individual permissions, you can  Allow  the  Full Control  permission instead.

8. To allow the agent to make configuration changes (for example, if you select a different logging level), give the service account permissions to the User-ID agent registry sub-tree.
1. Select  StartRun  and enter  regedt32  and navigate to the Palo Alto Networks sub-tree in  HKEY_LOCAL_MACHINE\Software\WOW6432Node\PaloAlto Networks .
2. Right-click the  Palo Alto Networks  node and select  Permissions .

3. Assign the User-ID service account  Full Control  and then click  OK  to save the setting.

9. Disable service account privileges that are not required.

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

To ensure that the User-ID account has the minimum privileges necessary, deny the following privileges on the account.

• Deny interactive logon for the User-ID service account —While the User-ID service account does need permission to read and parse Active Directory security event logs, it does not require the ability to logon to servers or domain systems interactively. You can restrict this privilege using Group Policies or by using a Managed Service account (refer to  Microsoft TechNet  for more information).
1. Select  Group Policy Management EditorDefault Domain PolicyComputer ConfigurationPoliciesWindows SettingsSecurity SettingsUser Rights Assignment .
2. For  Deny log on as a batch job ,  Deny log on locally , and  Deny log on through Remote Desktop Services , right-click  Properties .
3. Select  Define these policy settingsAdd User or Group  and add the service account name, then click  OK .

• Deny remote access for the User-ID service account —This prevents an attacker from using the account to access your network from the outside the network.
1. Select  StartRun , enter  MMC , and select  FileAdd/Remove Snap-inActive Directory Users and ComputersUsers .
2. Right-click the service account name, then select  Properties .
3. Select  Dial-in , then  Deny  the  Network Access Permission .

10. As a next step,  Configure User Mapping Using the Windows User-ID Agent .

Configure a Service Account for the PAN-OS Integrated User-ID Agent

Create a dedicated Active Directory (AD) service account for the PAN-OS Integrated User-ID agent to access the services and hosts it will monitor to collect user mappings.You must create a service account in each domain the agent will monitor. After you enable the required permissions for the service account,  Configure User Mapping Using the PAN-OS Integrated User-ID Agent .

The following workflow details all required privileges and provides guidance for the User-ID features which require privileges that could pose a threat so that you can decide how to best identify users without compromising your overall security posture.

1. Create an AD service account for the User-ID agent.

You must create a service account in each domain the agent will monitor.

1. Log in to the domain controller.
2. Right-click the Windows icon (

   

),  Search  for  Active Directory Users and Computers , and launch the application.

3. In the navigation pane, open the domain tree, right-click  Managed Service Accounts  and select  NewUser .
4. Enter the  First Name ,  Last Name , and  User logon name  of the user and click  Next .
5. Enter the  Password  and  Confirm Password , then click  Next  and  Finish .
1. If you want to use  Server Monitoring  to identify users, add the service account to the Event Log Reader builtin group to allow the service account to read the security log events.
1. On the domain controller or Exchange server that contains the logs you want the User-ID agent to read, or on the member server that receives events from Windows log forwarding, select  StartRun , enter  MMC .
2. Select  FileAdd/Remove Snap-inActive Directory Users and ComputersAdd , then click  OK  to run the MMC and launch the Active Directory Users and Computers snap-in.

3. Navigate to the Builtin folder for the domain, right-click the  Event Log Readers  group, and select  PropertiesMembers .

4. Add  the service account then click  Check Names  to validate that you have the proper object name.

5. Click  OK  twice to save the settings.
6. Confirm that the builtin Event Log Reader group lists the service account as a member ( Event Log ReadersPropertiesMembers ).
2. 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.
1. Select  Active Directory Users and Computers<your domain>BuiltinDistributed COM Users .
2. Right-click  PropertiesMembersAdd  and enter the service account name.
3. ( Windows Server 2022 with User-ID Credential Detection only ) If you are using Windows Server 2022 and  credential detection , assign the following privileges to the service account:

• Replicating Directory Changes
• Replicating Directory Changes All
• Replicating Directory Changes in Filtered Set

For more information, refer to the following  documentation .

5. If you plan to use  WMI probing , enable the service account to read the CIMV2 namespace on the domain controllers you want to monitor and assign the required permissions on the client systems to be probed.

Do not enable client probing on high-security networks. Client probing can generate a large amount of network traffic and can pose a security threat when misconfigured. Instead collect user mapping information from more isolated and trusted sources, such as domain controllers and through integrations with Syslog or the XML API, which have the added benefit of allowing you to safely capture user mapping information from any device type or operating system, instead of just Windows clients.

Perform this task on each client system that the User-ID agent will probe for user mapping information:

1. Right-click the Windows icon (

   

),  Search  for  wmimgmt.msc , and launch the WMI Management Console.

2. In the console tree, right-click  WMI Control  and select  Properties .

3. Select the  Security  tab, then select  RootCIMV2 , and click the  Security  button.

4. Add  the name of the service account you created,  Check Names  to verify your entry, and click  OK .

You might have to change the  Locations  or click  Advanced  to query for account names. See the dialog help for details.

5. In the Permissions for  <Username>  section,  Allow  the  Enable Account  and  Remote Enable  permissions.

6. Click  OK  twice.
7. Use the Local Users and Groups MMC snap-in (lusrmgr.msc) to add the service account to the local Distributed Component Object Model (DCOM) Users and Remote Desktop Users groups on the system that will be probed.
5. ( Not Recommended ) To allow the agent to monitor user sessions to poll Windows servers for user mapping information, assign Server Operator privileges to the service account.

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.

1. Select  Active Directory Users and Computers<your domain>BuiltinServer Operators Group .
2. Right-click  PropertiesMembersAdd  add service account name
6. Disable service account privileges that are not required.

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.

To ensure that the User-ID account has the minimum privileges necessary, deny the following privileges on the account:

• Deny interactive logon for the User-ID service account —While the User-ID service account does need permission to read and parse Active Directory security event logs, it does not require the ability to logon to servers or domain systems interactively. You can restrict this privilege using Group Policies or by using a Managed Service account (refer to  Microsoft TechNet  for more information).
1. Select  Group Policy Management EditorDefault Domain PolicyComputer ConfigurationPoliciesWindows SettingsSecurity SettingsUser Rights Assignment .
2. For  Deny log on as a batch job ,  Deny log on locally , and  Deny log on through Remote Desktop Services , right-click  Properties , then select  Define these policy settingsAdd User or Group  and add the service account name, then click  OK .

• Deny remote access for the User-ID service account —This prevents an attacker from using the account to access your network from the outside the network.
1. StartRun , enter  MMC , and select  FileAdd/Remove Snap-inActive Directory Users and ComputersUsers .
2. Right-click the service account name, then select  Properties .
3. Select  Dial-in , then  Deny  the  Network Access Permission .

8. As a next step,  Configure User Mapping Using the PAN-OS Integrated User-ID Agent .

Configure User Mapping Using the Windows User-ID Agent

 

In most cases, the majority of your network users will have logins to your monitored domain services. For these users, the Palo Alto Networks User-ID agent monitors the servers for login events and performs the IP address to username mapping. The way you configure the User-ID agent depends on the size of your environment and the location of your domain servers. As a best practice, locate your User-ID agents near the servers it will monitor (that is, the monitored servers and the Windows User-ID agent should not be across a WAN link from each other). This is because most of the traffic for user mapping occurs between the agent and the monitored server, with only a small amount of traffic—the delta of user mappings since the last update—from the agent to the firewall.

The following topics describe how to install and configure the User-ID Agent and how to configure the firewall to retrieve user mapping information from the agent:

Install the Windows-Based User-ID Agent

The following procedure shows how to install the User-ID agent on a member server in the domain and set up the service account with the required permissions. If you are upgrading, the installer will automatically remove the older version; however, it is a good idea to back up the config.xml file before running the installer.

For information about the system requirements for installing the Windows-based User-ID agent and for information on supported server OS versions, refer to the  User-ID agent release notes  and the  Palo Alto Networks Compatibility Matrix .

1. Create a dedicated Active Directory service account for the User-ID agent to access the services and hosts it will monitor to collect user mappings.

Create a Dedicated Service Account for the User-ID Agent  and grant the necessary permissions for the Windows User-ID agent.

1. Enable the service account to log on as a service by configuring either local or group policy.
1. To configure the group policy if you are installing Windows-based User-ID agents on multiple servers, select  Group Policy ManagementDefault Domain PolicyComputer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment  for the Windows server that is the agent host.
2. Right-click  Log on as a service , then select  Properties .
3. Add the service account username or builtin group (Administrators have this privilege by default).

The permission to log on as a service is only needed locally on the Windows server that is the agent host. If you are using only one User-ID agent, you can grant the permissions locally on the agent host using the following instructions.

4. To assign permissions locally, select  Control PanelAdministrative ToolsLocal Security Policy .

5. Select  Local PoliciesUser Rights AssignmentLog on as a service .

6. Add User or Group  to add the service account.

7. Enter the service account name in  domain\username  format in the  Enter the object names to select  entry field and click  OK .

To confirm the service account name is valid,  Check Names .

2. If you want to use  server monitoring  to identify users, add the service account to the Event Log Reader builtin group to enable privileges for reading the security log events.
1. On the domain controller or Exchange server that contains the logs you want the User-ID agent to read, or on the member server that receives events from Windows log forwarding, run the MMC and launch the Active Directory Users and Computers snap-in.
2. Navigate to the Builtin folder for the domain, right-click the  Event Log Reader  group and select  Add to Group  to open the properties dialog.
3. Click  Add  and enter the name of the service account that you configured the User-ID service to use and then click  Check Names  to validate that you have the proper object name.
4. Click  OK  twice to save the settings.
5. Confirm that the builtin Event Log Reader group lists the service account as a member.

3. Assign account permissions to the installation folder to allow the service account to access the agent’s installation folder to read the configuration and write logs.

You only need to perform this step if the service account you configured for the User-ID agent is not either a domain administrator or a local administrator on the User-ID agent server host.

1. From the Windows Explorer, navigate to  C:\Program Files(x86)\Palo Alto Networks  for 32-bit systems, right-click the folder, and select  Properties .
2. On the  Security  tab, click  Edit .

3. Add  the User-ID agent service account and assign it permissions to  Modify ,  Read & execute ,  List folder contents ,  Read , and  Write , and then click  OK  to save the account settings.

If you want to allow the service account to access the User-ID agent’s registry keys,  Allow  the  Full Control  permission.

4. Give the service account permissions to the User-ID Agent registry sub-tree:
1. Run  regedt32  and navigate to the Palo Alto Networks sub-tree in the following location:  HKEY_LOCAL_MACHINE\Software\Palo Alto Networks .
2. Right-click the Palo Alto Networks node and select  Permissions .
3. Assign the User-ID service account  Full Control  and then click  OK  to save the setting.
1. Decide where to install the User-ID agent.

The User-ID agent queries the Domain Controller and Exchange server logs using Microsoft Remote Procedure Calls (MSRPCs). During the initial connection, the agent transfers the most recent 50,000 events from the log to map users. On each subsequent connection, the agent transfers events with a timestamp later than the last communication with the domain controller. Therefore, always install one or more User-ID agents at each site that has servers to be monitored.

• You must install the User-ID agent on a system running one of the supported OS versions: see “Operating System (OS) Compatibility User-ID Agent” in the  Compatibility Matrix . The system must also meet the minimum requirements (see the  User-ID agent release notes ).
• Make sure the system that will host the User-ID agent is a member of the same domain as the servers it will monitor.
• As a best practice, install the User-ID agent close to the servers it will be monitoring: there is more traffic between the User-ID agent and the monitored servers than there is between the User-ID agent and the firewall, so locating the agent close to the monitored servers optimizes bandwidth usage.
• To ensure the most comprehensive mapping of users, you must monitor all domain controllers that process authentication for users you want to map. You might need to install multiple User-ID agents to efficiently monitor all of your resources.
• If you are using the User-ID agent for credential detection, you must install it on the read-only domain controller (RODC). As a best practice deploy a separate agent for this purpose. Do not use the User-ID agent installed on the RODC to map IP addresses to users. The User-ID agent installer for credential detection is named UaCredInstall64-x.x.x.msi.

3. Download the User-ID agent installer.

Install the User-ID agent version that is the same as the PAN-OS version running on the firewalls. If there is not a User-ID agent version that matches the PAN-OS version, install the latest version that is closest to the PAN-OS version.

1. Log in to the  Palo Alto Networks Customer Support Portal .
2. Select  UpdatesSoftware Updates .
3. Set  Filter By  to  User Identification Agent  and select the version of the User-ID agent you want to install from the corresponding Download column. The file name uses the following format:  UaInstall-x.x.x.msi  (where  x  represents the version number). For example, to download the 10.0 version of the User-ID agent, select  UaInstall-10.0.0-0.msi .

If you are using the User-ID agent to  prevent credential phishing , download the  UaCredInstall64-x.x.x.msi  file instead. Only download and install the  UaCredInstall64-x.x.x.msi  if you are using the User-ID for credential detection.

4. Save the file on the systems where you plan to install the agent.

4. Run the installer as an administrator.
1. Open the Windows  Start  menu, right-click the  Command Prompt  program, and select  Run as administrator .
2. From the command line, run the .msi file you downloaded. For example, if you saved the .msi file to the Desktop, enter the following:
3. C:\Users\administrator.acme>cd Desktop

C:\Users\administrator.acme\Desktop>UaInstall-6.0.0-1.msi

4. Follow the setup prompts to install the agent using the default settings. By default, the agent gets installed to  C:\Program Files(x86)\Palo Alto Networks , but you can  Browse  to a different location.
5. When the installation completes,  Close  the setup window.
4. Launch the User-ID Agent application as an administrator.

Open the Windows  Start  menu, right-click the  User-ID Agent  program, and select  Run as administrator .

You must run the User-ID Agent application as an administrator to install the application, commit configuration changes, or uninstall the application.

6. ( Optional ) Change the service account that the User-ID agent uses to log in.

By default, the agent uses the administrator account used to install the .msi file. To change the account to a restricted account:

1. Select  User IdentificationSetup  and click  Edit .
2. Select the  Authentication  tab and enter the service account name that you want the User-ID agent to use in the  User name for Active Directory  field.
3. Enter the  Password  for the specified account.
4. Commit  the changes to the User-ID agent configuration to restart the service using the service account credentials.
6. ( Optional ) Assign your own certificates for mutual authentication between the Windows User-ID agent and the firewall.
1. Obtain your certificate for the Windows User-ID agent using one of the following methods. Upload the server certificate in Privacy Enhanced Mail (PEM) format and the server certificate’s encrypted key.

• Generate a Certificate  and export it for upload to the Windows User-ID agent.
• Export a certificate from your enterprise certificate authority (CA) and the upload it to the Windows User-ID agent.

2. Add a server certificate to Windows User-ID agent.
1. On the Windows User-ID agent, select  Server Certificate  and click  Add .
2. Enter the path and name of the certificate file received from the CA or browse to the certificate file.
3. Enter the private key passphrase.
4. Click  OK  and then  Commit .
3. Upload a certificate to the firewall to validate the Windows User-ID agent’s identity.
4. Configure the certificate profile for the client device (firewall or Panorama).
1. Select  DeviceCertificate ManagementCertificate Profile .
2. Configure a Certificate Profile .

You can only assign one certificate profile for Windows User-ID agents and Terminal Server (TS) agents. Therefore, your certificate profile must include all certificate authorities that issued certificates uploaded to connected User-ID and TS agents.

5. Assign the certificate profile on the firewall.
1. Select  DeviceUser IdentificationConnection Security  and click the edit button.
2. Select the  User-ID Certificate Profile  you configured in the previous step.
3. Click  OK .
6. Commit  your changes.
7. Prevent credential phishing .

To use the Windows-based User-ID agent to detect credential submissions and  prevent credential phishing , you must install the User-ID credential service on the Windows-based User-ID agent. You can only install this add-on on a read-only domain controller (RODC).

Configure the Windows User-ID Agent for User Mapping

The Palo Alto Networks Windows User-ID agent is a Windows service that connects to servers on your network—for example, Active Directory servers, Microsoft Exchange servers, and Novell eDirectory servers—and monitors the logs for login events. The agent uses this information to map IP addresses to usernames. Palo Alto Networks firewalls connect to the User-ID agent to retrieve this user mapping information, enabling visibility into user activity by username rather than IP address and enables user- and group-based security enforcement.

For information about the server OS versions supported by the User-ID agent, refer to “Operating System (OS) Compatibility User-ID Agent” in the  User-ID Agent Release Notes .

1. Define the servers the User-ID agent will monitor to collect IP address to user mapping information.

The User-ID agent can monitor up to 100 servers, of which up to 50 can be syslog senders.

To collect all of the required mappings, the User-ID agent must connect to all servers that your users log in to in order to monitor the security log files on all servers that contain login events.

1. Open the Windows  Start  menu and select  User-ID Agent .
2. Select  User IdentificationDiscovery .
3. In the  Servers  section of the screen, click  Add .
4. Enter a  Name  and  Server Address  for the server to be monitored. The network address can be a FQDN or an IP address.
5. Select the  Server Type  ( Microsoft Active Directory ,  Microsoft Exchange ,  Novell eDirectory , or  Syslog Sender ) and then click  OK  to save the server entry. Repeat this step for each server to be monitored.
6. ( Optional ) To enable the Windows User-ID agent to automatically discover domain controllers on your network using DNS lookups, click  Auto Discover . If you have new domain controllers that you want the Windows User-ID agent to discover, click  Auto Discover  each time you want to discover the new domain controllers.

Auto-discovery locates domain controllers in the local domain only; you must manually add Exchange servers, eDirectory servers, and syslog senders.

7. ( Optional ) To tune the frequency at which the firewall polls configured servers for mapping information, select  User IdentificationSetup  and  Edit  the Setup section. On the  Server Monitor  tab, modify the value in the  Server Log Monitor Frequency (seconds)  field. Increase the value in this field to 5 seconds in environments with older Domain Controllers or high-latency links.

Ensure that the  Enable Server Session Read  setting is not selected. This setting requires that the User-ID agent have an Active Directory account with Server Operator privileges so that it can read all user sessions. Instead, use a syslog or XML API integration to monitor sources that capture login and logout events for all device types and operating systems (instead of just Windows), such as wireless controllers and Network Access Controllers (NACs).

8. Click  OK  to save the settings.
1. Specify the subnetworks the Windows User-ID agent should include in or exclude from User-ID.

By default, the User-ID maps all users accessing the servers you are monitoring.

As a best practice, always specify which networks to include and exclude from User-ID to ensure that the agent is only communicating with internal resources and to prevent unauthorized users from being mapped. You should only enable User-ID on the subnetworks where users internal to your organization are logging in.

1. Select  User IdentificationDiscovery .
2. Add  an entry to the Include/Exclude list of configured networks and enter a  Name  for the entry and enter the IP address range of the subnetwork in as the  Network Address .
3. Select whether to include or exclude the network:
• Include specified network —Select this option if you want to limit user mapping to users logged in to the specified subnetwork only. For example, if you include 10.0.0.0/8, the agent maps the users on that subnetwork and excludes all others. If you want the agent to map users in other subnetworks, you must repeat these steps to add additional networks to the list.
• Exclude specified network —Select this option only if you want the agent to exclude a subset of the subnetworks you added for inclusion. For example, if you include 10.0.0.0/8 and exclude 10.2.50.0/22, the agent will map users 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.

4. Click  OK .
2. ( Optional ) If you configured the agent to connect to a Novell eDirectory server, you must specify how the agent should search the directory.
1. Select  User IdentificationSetup  and click  Edit  in the Setup section of the window.
2. Select the  eDirectory  tab and then complete the following fields:
• Search Base —The starting point or root context for agent queries, for example:  dc=domain1,dc=example, dc=com .
• Bind Distinguished Name —The account to use to bind to the directory, for example:  cn=admin,ou=IT, dc=domain1, dc=example, dc=com .
• Bind Password —The bind account password. The agent saves the encrypted password in the configuration file.
• Search Filter —The search query for user entries (default is  objectClass=Person ).
• Server Domain Prefix —A prefix to uniquely identify the user. This is only required if there are overlapping name spaces, such as different users with the same name from two different directories.
• Use SSL —Select the check box to use SSL for eDirectory binding.
• Verify Server Certificate —Select the check box to verify the eDirectory server certificate when using SSL.
3. ( Strongly recommended ) Disable client probing.

Palo Alto Networks strongly recommends disabling client probing on high-security networks. Client probing can pose a security threat if not correctly configured. For more information, see  client probing .

1. On the  Client Probing  tab, deselect the  Enable WMI Probing  check box if it is enabled.

Palo Alto Network strongly recommends that you collect user mapping information from isolated and trusted sources, such as domain controllers or integrations with  Syslog  or the  XML API , to safely capture user mapping information from any device type or operating system.

If you must enable client probing, select the  Enable WMI Probing  check box and on the  Client Probing  tab. Then add a remote administration exception to the Windows firewall for each probed client to ensure the Windows firewall will allow client probing. Each probed client PC must allow port 139 in the Windows firewall and must also have file and printer sharing services enabled.

5. Save the configuration.

Click  OK  to save the User-ID agent setup settings and then click  Commit  to restart the User-ID agent and load the new settings.

6. ( Optional ) Define the set of users for which you do not need to provide IP address-to-username mappings, such as kiosk accounts.

Save the  ignore-user  list as a text document on the agent host using the title  ignore_user_list  and use the .txt file extension to save it to the User-ID Agent folder on the domain server where the agent is installed.

List the user accounts to ignore; there is no limit to the number of accounts you can add to the list. Each user account name must be on a separate line. For example:

SPAdmin

SPInstall

TFSReport

You can use an asterisk as a wildcard character to match multiple usernames, but only as the last character in the entry. For example,  corpdomain\it-admin*  would match all administrators in the  corpdomain  domain whose usernames start with the string  it‑admin . You can also use the  ignore-user  list to identify users whom you want to force to authenticate using Authentication Portal.

After adding entries to the Ignore User list, you must stop and restart the connection to the service.

7. Configure the firewall to connect to the User-ID agent.

The firewall can connect to only one Windows-based User-ID agent that is using the User-ID credential service add-on to detect corporate credential submissions. See  Configure Credential Detection with the Windows User-ID Agent  for more details on how to use this service.

Complete the following steps on each firewall you want to connect to the User-ID agent to receive user mappings:

1. Select  DeviceData RedistributionAgents  and click  Add .
2. Enter a  Name  for the agent.
3. Add an Agent Using  the  Host and Port .
4. Enter the IP address of the Windows  Host  on which the User-ID Agent is installed.
5. Enter the  Port  number (1-65535) on which the agent will listen for user mapping requests. This value must match the value configured on the User-ID agent. By default, the port is set to 5007 on the firewall and on newer versions of the User-ID agent. However, some older User-ID agent versions use port 2010 as the default.
6. Select  IP User Mappings  as the  Data type .
7. Make sure that the configuration is  Enabled , then click  OK .
8. Commit  the changes.
9. Verify that the  Connected status  displays as connected (a green light).
7. Verify that the User-ID agent is successfully mapping IP addresses to usernames and that the firewalls can connect to the agent.
1. Launch the User-ID agent and select  User Identification .
2. Verify that the agent status shows  Agent is running . If the Agent is not running, click  Start .
3. To verify that the User-ID agent can connect to monitored servers, make sure the Status for each Server is  Connected .
4. To verify that the firewalls can connect to the User-ID agent, make sure the Status for each of the Connected Devices is  Connected .
5. To verify that the User-ID agent is mapping IP addresses to usernames, select  Monitoring  and make sure that the mapping table is populated. You can also  Search  for specific users, or  Delete  user mappings from the list.

Configure User Mapping Using the PAN-OS Integrated User-ID Agent

The following procedure describes how to configure the PAN-OS® integrated User-ID™ agent on the firewall for IP address-to-username mapping. The integrated User-ID agent performs the same tasks as the Windows-based agent.

1. Create an Active Directory service account for the User-ID agent to access the services and hosts that the firewall will monitor for collecting user mapping information.

Create a Dedicated Service Account for the User-ID Agent .

2. Define the servers that the firewall will monitor to collect user mapping information.

Within the total maximum of 100 monitored servers per firewall, you can define no more than 50 syslog senders for any single virtual system.

To collect all the required mappings, the firewall must connect to all servers that your users log in to so that the firewall can monitor the Security log files on all servers that contain login events.

1. Select  DeviceUser IdentificationUser Mapping .
2. Add  a server (Server Monitoring section).
3. Enter a  Name  to identify the server.
4. Select the  Type  of server.
• Microsoft Active Directory
• Microsoft Exchange
• Novell eDirectory
• Syslog Sender
5. ( Microsoft Active Directory and Microsoft Exchange only ) Select the  Transport Protocol  you want to use to monitor security logs and session information on the server.
• WMI —The firewall and the monitored servers use Windows Management Instrumentation ( WMI ) to communicate.
• WinRM-HTTP —The firewall and the monitored servers use Kerberos for mutual authentication and the monitored server encrypts the communication with the firewall using a negotiated Kerberos session key.
• WinRM-HTTPS —The firewall and the monitored servers use HTTPS to communicate and use basic authentication or Kerberos for mutual authentication.

If you select a Windows Remote Management (WinRM) option, you must  Configure Server Monitoring Using WinRM .

6. ( Microsoft Active Directory, Microsoft Exchange, and Novell eDirectory only ) Enter the  Network Address  of the server.

If you are using  WinRM with Kerberos , you must enter a fully qualified domain name (FDQN). If you want to use  WinRM with basic authentication  or use  WMI  to monitor the server, you can enter an IP address or FQDN.

To monitor servers using WMI, specify an IP address, the service account name (if all server monitoring is in the same domain), or a fully qualified domain name (FQDN). If you specify an FQDN, use the down-level logon name in the (DLN)\sAMAccountName format instead of the FQDN\sAMAccountName format. For example, use  example\user.services  not  example.com\user.services . If you specify an FQDN, the firewall will attempt to authenticate using Kerberos, which does not support WMI.

7. ( Syslog Sender only ) If you select  Syslog Sender  as the server  Type ,  Configure the PAN-OS Integrated User-ID Agent as a Syslog Listener .
8. ( Novell eDirectory only ) Make sure the  Server Profile  you select is  Enabled  and click  OK .
9. (Optional) Configure the firewall to automatically  Discover  domain controllers on your network using DNS lookups.

The auto-discovery feature is for domain controllers only; you must manually add any Exchange servers or eDirectory servers you want to monitor.

3. (Optional) Specify the frequency at which the firewall polls Windows servers for mapping information. This is the interval between the end of the last query and the start of the next query.

If the domain controller is processing many requests, delays between queries may exceed the specified value.

1. Edit  the  Palo Alto Networks User ID Agent Setup .
2. Select the  Server Monitor  tab and specify the  Server Log Monitor Frequency  in seconds (range is 1 to 3,600; default is 2). In environments with older domain controllers or high-latency links, set this frequency to a minimum of five seconds.

Ensure that the  Enable Session  option is not enabled. This option requires that the User-ID agent have an Active Directory account with Server Operator privileges so that it can read all user sessions. Instead, use a Syslog or XML API integration to monitor sources that capture login and logout events for all device types and operating systems (instead of just Windows), such as wireless controllers and network access control (NAC) devices.

3. Click  OK  to save your changes.
3. Specify the subnetworks that the PAN-OS integrated User-ID agent should include in or exclude from user mapping.

By default, the User-ID maps all users accessing the servers you are monitoring.

As a best practice, always specify which networks to include and, optionally, which networks to exclude from User-ID to ensure that the agent is communicating only with internal resources and to prevent unauthorized users from being mapped. You should enable user mapping only on the subnetworks where users internal to your organization are logging in.

1. Select  DeviceUser IdentificationUser Mapping .
2. Add  an entry to the  Include/Exclude Networks  and enter a  Name  for the entry. Ensure that the entry is  Enabled .
3. Enter the  Network Address  and then select whether to include or exclude it:
• Include —Select this option to limit user mapping to only users logged in to the specified subnetwork. For example, if you include 10.0.0.0/8, the agent maps the users on that subnetwork and excludes all others. If you want the agent to map users in other subnetworks, you must repeat these steps to add additional networks to the list.
• Exclude —Select this option to configure the agent to exclude a subset of the subnetworks you added for inclusion. For example, if you include 10.0.0.0/8 and exclude 10.2.50.0/22, the agent will map users 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.

4. Click  OK .
4. Set the domain credentials for the account that the firewall will use to access Windows resources. This is required for monitoring Exchange servers and domain controllers as well as for WMI probing.
1. Edit  the  Palo Alto Networks User-ID Agent Setup .
2. Select the  Server Monitor Account  tab and enter the  User Name  and  Password  for the  service account  that the User-ID agent will use to probe the clients and monitor servers. Enter the username using the  domain\username  syntax.
3. If you are using WinRM to monitor servers, configure the firewall to authenticate with the server you are monitoring.
• If you want to use  WinRM with basic authentication , enable WinRM on the server, configure basic authentication, and specify the service account  Domain’s DNS Name .
• If you want to use  WinRM with Kerberos ,  Configure a Kerberos server profile  if you have not already done so and then select the  Kerberos Server Profile .
5. ( Optional, not recommended ) Configure WMI probing.

Do not enable WMI probing on high-security networks. Client probing can generate a large amount of network traffic and can pose a security threat when misconfigured.

1. On the  Client Probing  tab,  Enable Probing .
2. ( Optional ) Specify the  Probe Interval  to define the interval (in minutes) between the end of the last probe request and the start of the next request.

If necessary, increase the value to ensure the User-ID agent has sufficient time to probe all the learned IP addresses (range is 1 to 1440; default is 20).

If the request load is high, the observed delay between requests might significantly exceed the specified interval.

3. Click  OK .
4. Make sure the Windows firewall will allow client probing by adding a remote administration exception to the Windows firewall for each probed client.
6. ( Optional ) Define the set of user accounts that don’t require IP address-to-username mappings, such as kiosk accounts.

Define the ignore user list on the firewall that is the User-ID agent, not the client. If you define the ignore user list on the client firewall, the users in the list are still mapped during redistribution.

On the  Ignore User List  tab,  Add  each username you want to exclude from user mapping. You can also use the ignore user list to identify the users you want to force to use Authentication Portal to authenticate. You can use an asterisk as a wildcard character to match multiple usernames but only as the last character in the entry. For example,  corpdomain\it-admin*  would match all administrators in the  corpdomain  domain whose usernames start with the string  it‑admin . You can add up to 5,000 entries to exclude from user mapping.

8. Activate your configuration changes.

Click  OK  and  Commit .

9. Verify the configuration.
1. Access the firewall CLI .
2. Enter the following operational command:

> show user server-monitor state all

3. On the  DeviceUser IdentificationUser Mapping  tab in the web interface, verify that the Status of each server you configured for server monitoring is  Connected .

Configure Server Monitoring Using WinRM

You can  configure the PAN-OS integrated User-ID agent  to monitor servers using Windows Remote Management (WinRM). Using the WinRM protocol improves speed, efficiency, and security when monitoring server events to map user events to IP addresses. The PAN-OS integrated User-ID agent supports the WinRM protocol on Windows Server 2012 Active Directory and Microsoft Exchange Server 2012 or later versions of both.

There are three ways to configure server monitoring using WinRM:

• Configure WinRM over HTTPS with Basic Authentication

—The firewall authenticates to the monitored server using the username and password of the service account for the User-ID agent and the firewall authenticates the monitored server using the User-ID certificate profile.

• Configure WinRM over HTTP with Kerberos

—The firewall and the monitored servers use Kerberos for mutual authentication and the monitored server encrypts the communication with the firewall using a negotiated Kerberos session key.

• Configure WinRM over HTTPS with Kerberos

—The firewall and the monitored server use HTTPS to communicate and use Kerberos for mutual authentication.

Configure WinRM over HTTPS with Basic Authentication

When you configure WinRM to use HTTPS with basic authentication, the firewall transfers the credentials for the service account in a secure tunnel using SSL.

1. Configure the  service account  with Remote Management User and CIMV2 privileges for the server you want to monitor.
2. On the Windows server you are monitoring, obtain the thumbprint from the certificate for the Windows server to use with WinRM and enable WinRM.

Ensure that you use an account with administrator privileges to configure WinRM on the server you want to monitor. As a best practice for security, this account should not be the same account as the service account in Step 1.

1. Verify the certificate is installed in the Local Computer certificate store ( Certificates (Local Computer)PersonalCertificates ).

If you do not see the Local Computer certificate store, launch the Microsoft Management Console ( StartRunMMC ) and add the Certificates snap-in ( FileAdd/Remove Snap-inCertificatesAddComputer accountNextFinish ).

2. Open the certificate and select  GeneralDetailsShow: <All> .
3. Select the  Thumbprint  and copy it.
4. To enable the firewall to connect to the Windows server using WinRM, enter the following command:  winrm quickconfig .
5. Enter  y  to confirm the changes and then confirm the output displays  WinRM service started .

If WinRM is enabled, the output displays  WinRM service is already running on this machine.  You will be prompted to confirm any additional required configuration changes.

6. To verify that WinRM is communicating using HTTPS, enter the following command:  winrm enumerate winrm/config/listener  and confirm that the output displays  Transport = HTTPS .

By default, WinRM/HTTPS uses port 5986.

7. From the Windows server command prompt, enter the following command:  winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=”<hostname>";CertificateThumbprint=”Certificate Thumbprint"} , where hostname is the hostname of the Windows server and Certificate Thumbprint is the value you copied from the certificate.

Use the command prompt (not Powershell) and remove any spaces in the Certificate Thumbprint to ensure that WinRM can validate the certificate.

8. From the Windows server command prompt, enter the following command:

c:\> winrm set winrm/config/client/auth @{Basic="true"}

9. Enter the following command:  winrm get winrm/config/service/Auth  and confirm that  Basic = true .
2. Enable Basic Authentication between the PAN-OS integrated User-ID agent and the monitored servers.
1. Select  DeviceUser IdentificationUser MappingPalo Alto Networks User-ID Agent SetupServer Monitor Account .
2. In  domain\username  format, enter the  User Name  for the service account that the User-ID agent will use to monitor servers.
3. Enter the  Domain’s DNS Name  of the server monitor account.

4. Enter the  Password  and  Confirm Password  for the service account.
5. Click  OK
3. Configure  server monitoring  for the PAN-OS integrated User-ID agent.
1. Select the Microsoft server  Type  ( Microsoft Active Directory  or  Microsoft Exchange ).
2. Select  Win-RM-HTTPS  as the  Transport Protocol  to use Windows Remote Management (WinRM) over HTTPS to monitor the server security logs and session information.

3. Enter the IP address or FQDN  Network Address  of the server.
4. To enable the PAN-OS integrated User-ID agent to communicate with the monitored servers using WinRM-HTTPS, verify that you successfully imported the root certificate for the service certificates that the Windows server uses for WinRM on to the firewall and associate the certificate with the User-ID Certificate Profile.
1. Select  DeviceUser IdentificationConnection Security .
2. Click  Edit .
3. Select the Windows server certificate to use for the  User-ID Certificate Profile .

4. Click  OK .
5. Commit  your changes.
6. Verify that the status of each monitored server is Connected ( DeviceUser IdentificationUser Mapping ).

Configure WinRM over HTTP with Kerberos

When you configure WinRM over HTTP with Kerberos, the firewall and the monitored servers use Kerberos for mutual authentication and the monitored server encrypts the communication with the firewall using a negotiated Kerberos session key.

WinRM with Kerberos supports the aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 ciphers. If the server you want to monitor uses RC4, you must download the Windows  update  and  disable  RC4 for Kerberos in the registry settings of the server you want to monitor.

1. Configure the  service account  with Remote Management User and CIMV2 privileges for the server you want to monitor.
2. Confirm that WinRM is enabled on the Windows server you are monitoring.

Ensure that you use an account with administrator privileges to configure WinRM on the server you want to monitor. As a best practice for security, this account should not be the same account as the service account in Step 1.

1. To enable the firewall to connect to the Windows server using WinRM, enter the following command:  winrm quickconfig .
2. Enter  y  to confirm the changes and then confirm the output displays  WinRM service started .

If WinRM is enabled, the output displays  WinRM service is already running on this machine.  You will be prompted to confirm any additional required configuration changes.

3. To verify that WinRM is communicating using HTTP, enter the following command:  winrm enumerate winrm/config/listener  and confirm that the output displays  Transport = HTTP .

By default, WinRM/HTTP uses port 5985.

4. Enter the following command:  winrm get winrm/config/service/Auth  and confirm that  Kerberos = true .
2. Enable the PAN-OS integrated User-ID agent and the monitored servers to authenticate using Kerberos.
1. If you did not do so during the  initial configuration , configure date and time (NTP) settings to ensure successful Kerberos negotiation.
2. Configure a Kerberos server profile  on the firewall to authenticate with the server to monitor the security logs and session information.
3. Select  DeviceUser IdentificationUser MappingPalo Alto Networks User-ID Agent SetupServer Monitor Account .
4. In  domain\username  format, enter the  User Name  for the service account that the User-ID agent will use to monitor servers.
5. Enter the  Domain’s DNS Name  of the server monitor account.

Kerberos uses the domain name to locate the service account.

6. Enter the  Password  and  Confirm Password  for the service account.
7. Select the  Kerberos Server Profile  you configured in Step 3.2.

8. Click  OK .
3. Configure  server monitoring  for the PAN-OS integrated User-ID agent.
1. Configure the Microsoft server type ( Microsoft Active Directory  or  Microsoft Exchange ).
2. Select  WinRM-HTTP  as the  Transport Protocol  to use Windows Remote Management (WinRM) over HTTP to monitor the server security logs and session information.

3. Enter the FQDN  Network Address  of the server.

If you are using Kerberos, the network address must be a fully qualified domain name (FDQN).

5. Commit  your changes.
6. Verify that the status of each monitored server is Connected ( DeviceUser IdentificationUser Mapping ).

Configure WinRM over HTTPS with Kerberos

When you configure WinRM over HTTPS with Kerberos, the firewall and the monitored server use HTTPS to communicate and use Kerberos for mutual authentication.

WinRM with Kerberos supports the aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 ciphers. If the server you want to monitor uses RC4, you must download the Windows  update  and  disable  RC4 for Kerberos in the registry settings of the server you want to monitor.

1. Configure the  service account  with Remote Management User and CIMV2 privileges for the server you want to monitor.
2. On the Windows server you are monitoring, obtain the thumbprint from the certificate for the Windows server to use with WinRM and enable WinRM.

Ensure that you use an account with administrator privileges to configure WinRM on the server you want to monitor. As a best practice for security, this account should not be the same account as the service account in Step 1.

1. Verify the certificate is installed in the Local Computer certificate store ( Certificates (Local Computer)PersonalCertificates ).

If you do not see the Local Computer certificate store, launch the Microsoft Management Console ( StartRunMMC ) and add the Certificates snap-in ( FileAdd/Remove Snap-inCertificatesAddComputer accountNextFinish ).

2. Open the certificate and select  GeneralDetailsShow: <All> .
3. Select the  Thumbprint  and copy it.
4. To enable the firewall to connect to the Windows server using WinRM, enter the following command:  winrm quickconfig .
5. Enter  y  to confirm the changes and then confirm the output displays  WinRM service started .

If WinRM is enabled, the output displays  WinRM service is already running on this machine.  You will be prompted to confirm any additional required configuration changes.

6. To verify that WinRM is communicating using HTTPS, enter the following command:  winrm enumerate winrm/config/listener . Then confirm that the output displays  Transport = HTTPS .

By default, WinRM/HTTPS uses 5986.

7. From the Windows server command prompt, enter the following command:  winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=”<hostname>";CertificateThumbprint=”Certificate Thumbprint"} , where hostname is the hostname of the Windows server and Certificate Thumbprint is the value you copied from the certificate.

Use the command prompt (not Powershell) and remove any spaces in the Certificate Thumbprint to ensure that WinRM can validate the certificate.

8. Enter the following command:  winrm get winrm/config/service/Auth  and confirm that  Basic = false  and  Kerberos= true .
2. Enable the PAN-OS integrated User-ID agent and the monitored servers to authenticate using Kerberos.
1. If you did not do so during the  initial configuration , configure date and time (NTP) settings to ensure successful Kerberos negotiation.
2. Configure a Kerberos server profile  on the firewall to authenticate with the server to monitor the security logs and session information.
3. Select  DeviceUser IdentificationUser MappingPalo Alto Networks User-ID Agent SetupServer Monitor Account .
4. In  domain\username  format, enter the  User Name  for the service account that the User-ID agent will use to monitor servers.
5. Enter the  Domain’s DNS Name  of the server monitor account.

Kerberos uses the domain name to locate the service account.

6. Enter the  Password  and  Confirm Password  for the service account.
7. Select the  Kerberos Server Profile  you created in Step 3.2.

8. Click  OK .
3. Configure  server monitoring  for the PAN-OS integrated User-ID agent.
1. Configure the Microsoft server type ( Microsoft Active Directory  or  Microsoft Exchange ).
2. Select  Win-RM-HTTPS  as the  Transport Protocol  to use Windows Remote Management (WinRM) over HTTPS to monitor the server security logs and session information.

3. Enter the FQDN  Network Address  of the server.

If you are using Kerberos, the network address must be a fully qualified domain name (FDQN).

5. To enable the PAN-OS integrated User-ID agent to communicate with the monitored servers using WinRM-HTTPS, verify that you successfully imported the root certificate for the service certificates that the Windows server uses for WinRM on to the firewall and associate the certificate with the User-ID Certificate Profile.

The firewall uses the same certificate to authenticate with all monitored servers.

1. Select  DeviceUser IdentificationConnection Security .
2. Click  Edit .
3. Select the Windows server certificate to use for the  User-ID Certificate Profile .

4. Click  OK .
5. Commit  your changes.
5. Verify that the status of each monitored server is Connected ( DeviceUser IdentificationUser Mapping ).

Configure User-ID to Monitor Syslog Senders for User Mapping

 

To obtain IP address-to-username mappings from existing network services that authenticate users, you can configure the PAN-OS integrated User-ID agent or Windows-based User-ID agent to parse  Syslog  messages from those services. To keep user mappings up to date, you can also configure the User-ID agent to parse syslog messages for logout events so that the firewall automatically deletes outdated mappings.

Configure the PAN-OS Integrated User-ID Agent as a Syslog Listener

 

To configure the PAN-OS Integrated User-ID agent to create new user mappings and remove outdated mappings through syslog monitoring, start by defining Syslog Parse profiles. The User-ID agent uses the profiles to find login and logout events in syslog messages. In environments where  syslog senders  (the network services that authenticate users) deliver syslog messages in different formats, configure a profile for each syslog format. Syslog messages must meet certain criteria for a User-ID agent to parse them (see  Syslog ). This procedure uses examples with the following formats:

• Login events — [Tue Jul 5 13:15:04 2016 CDT] Administratorauthentication success User:johndoe1 Source:192.168.3.212
• Logout events — [Tue Jul 5 13:18:05 2016CDT] User logout successful User:johndoe1 Source:192.168.3.212

After configuring the Syslog Parse profiles, you specify syslog senders for the User-ID agent to monitor.

1. Determine whether there is a predefined Syslog Parse profile for your particular syslog senders.

Palo Alto Networks provides several predefined profiles through Application content updates. The predefined profiles are global to the firewall, whereas custom profiles apply to a single virtual system only.

Any new Syslog Parse profiles in a given content release is documented in the corresponding release note along with the specific regex used to define the filter.

1. Install the latest Applications or Applications and Threats update:
1. Select  DeviceDynamic Updates  and  Check Now .
2. Download  and  Install  any new update.
2. Determine which predefined Syslog Parse profiles are available:
1. Select  DeviceUser IdentificationUser Mapping  and click  Add  in the Server Monitoring section.
2. Set the  Type  to  Syslog Sender  and click  Add  in the Filter section. If the Syslog Parse profile you need is available, skip the steps for defining custom profiles.
1. Define custom Syslog Parse profiles to create and delete user mappings.

Each profile filters syslog messages to identify either login events (to create user mappings) or logout events (to delete mappings), but no single profile can do both.

1. Review the syslog messages that the syslog sender generates to identify the syntax for login and logout events. This enables you to define the matching patterns when creating Syslog Parse profiles.

While reviewing syslog messages, also determine whether they include the domain name. If they don’t, and your user mappings require domain names, enter the  Default Domain Name  when defining the syslog senders that the User-ID agent monitors (later in this procedure).

2. Select  DeviceUser IdentificationUser Mapping  and edit the Palo Alto Networks User-ID Agent Setup.
3. Select  Syslog Filters  and  Add  a Syslog Parse profile.
4. Enter a name to identify the  Syslog Parse Profile .
5. Select the  Type  of parsing to find login or logout events in syslog messages:

• Regex Identifier —Regular expressions.
• Field Identifier —Text strings.

The following steps describe how to configure these parsing types.

3. ( Regex Identifier parsing only ) Define the regex matching patterns.

If the syslog message contains a standalone space or tab as a delimiter, use  \s  for a space and  \t  for a tab.

1. Enter the  Event Regex  for the type of events you want to find:

• Login events —For the example message, the regex  (authentication\ success){1}  extracts the first  {1}  instance of the string  authenticationsuccess .
• Logout events —For the example message, the regex  (logout\ successful){1}  extracts the first  {1}  instance of the string  logoutsuccessful .

The backslash (\) before the space is a standard regex escape character that instructs the regex engine not to treat the space as a special character.

2. Enter the  Username Regex  to identify the start of the username.

In the example message, the regex  User:([a-zA-Z0-9\\\._]+)  matches the string  User:johndoe1  and identifies  johndoe1  as the username.

3. Enter the  Address Regex  to identify the IP address portion of syslog messages.

In the example message, the regular expression  Source:([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})  matches the IPv4 address  Source:192.168.3.212 .

The following is an example of a completed Syslog Parse profile that uses regex to identify login events:

4. Click  OK  twice to save the profile.
3. ( Field Identifier parsing only ) Define string matching patterns.
1. Enter an  Event String  to identify the type of events you want to find.

• Login events —For the example message, the string  authentication success  identifies login events.
• Logout events —For the example message, the string  logoutsuccessful  identifies logout events.

2. Enter a  Username Prefix  to identify the start of the username field in syslog messages. The field does not support regex expressions such as \s (for a space) or \t (for a tab).

In the example messages,  User:  identifies the start of the username field.

3. Enter the  Username Delimiter  that indicates the end of the username field in syslog messages. Use  \s  to indicate a standalone space (as in the sample message) and  \t  to indicate a tab.
4. Enter an  Address Prefix  to identify the start of the IP address field in syslog messages. The field does not support regex expressions such as \s (for a space) or \t (for a tab).

In the example messages,  Source:  identifies the start of the address field.

5. Enter the  Address Delimiter  that indicates the end of the IP address field in syslog messages.

For example, enter  \n  to indicate the delimiter is a line break.

The following is an example of a completed Syslog Parse profile that uses string matching to identify login events:

6. Click  OK  twice to save the profile.
4. Specify the syslog senders that the firewall monitors.

Within the total maximum of 100 monitored servers per firewall, you can define no more than 50 syslog senders for any single virtual system.

The firewall discards any syslog messages received from senders that are not on this list.

1. Select  DeviceUser IdentificationUser Mapping  and  Add  an entry to the Server Monitoring list.
2. Enter a  Name  to identify the sender.
3. Make sure the sender profile is  Enabled  (default is enabled).
4. Set the  Type  to  Syslog Sender .
5. Enter the  Network Address  (IP address) of the syslog sender.
6. Select  SSL  (default) or  UDP  as the  Connection Type .

To select the TLS certificate that the firewall uses to receive syslog messages, select  DeviceUser IdentificationUser MappingPalo Alto Networks User-ID Agent Setup .  Edit  the settings and select  Server Monitor , then select the  Syslog Service Profile  that contains the TLS certificate you want to the firewall to use to receive syslog messages.

The PAN-OS integrated User-ID agent accepts syslogs over SSL and UDP only. However, you must use caution when using UDP to receive syslog messages because it is an unreliable protocol and as such there is no way to verify that a message was sent from a trusted syslog sender. Although you can restrict syslog messages to specific source IP addresses, an attacker can still spoof the IP address, potentially allowing the injection of unauthorized syslog messages into the firewall.

Always use SSL to listen for syslog messages because the traffic is encrypted (UDP sends the traffic in cleartext). If you must use UDP, make sure that the syslog sender and client are both on a dedicated, secure network to prevent untrusted hosts from sending UDP traffic to the firewall.

A syslog sender using SSL to connect will show a Status of Connected only when there is an active SSL connection. Syslog senders using UDP will not show a Status value.

7. For each syslog format that the sender supports,  Add  a Syslog Parse profile to the Filter list. Select the  Event Type  that each profile is configured to identify:  login  (default) or  logout .
8. ( Optional ) If the syslog messages don’t contain domain information and your user mappings require domain names, enter a  Default Domain Name  to append to the mappings.
9. Click  OK  to save the settings.
5. Enable syslog listener services  on the interface that the firewall uses to collect user mappings.
1. Select  NetworkNetwork ProfilesInterface Mgmt  and edit an existing Interface Management profile or  Add  a new profile.
2. Select  User-ID Syslog Listener-SSL  or  User-ID Syslog Listener-UDP  or both, based on the protocols you defined for the syslog senders in the Server Monitoring list.

The listening ports (514 for UDP and 6514 for SSL) are not configurable; they are enabled through the management service only.

3. Click  OK  to save the interface management profile.

Even after enabling the User-ID Syslog Listener service on the interface, the interface only accepts syslog connections from senders that have a corresponding entry in the User-ID monitored servers configuration. The firewall discards connections or messages from senders that are not on the list.

4. Assign the Interface Management profile to the interface that the firewall uses to collect user mappings:
1. Select  NetworkInterfaces  and edit the interface.
2. Select  AdvancedOther info , select the Interface  Management Profile  you just added, and click  OK .
5. Commit  your changes.
6. Verify that the firewall adds and deletes user mappings when users log in and out.

You can  use CLI commands  to see additional information about syslog senders, syslog messages, and user mappings.

1. Log in to a client system for which a monitored syslog sender generates login and logout event messages.
2. Log in to the firewall CLI .
3. Verify that the firewall mapped the login username to the client IP address:
4. > show user ip-user-mapping ip <ip-address>
5. IP address:    192.0.2.1 (vsys1)
6. User:          localdomain\username

From:          SYSLOG

7. Log out of the client system.
8. Verify that the firewall deleted the user mapping:
9. > show user ip-user-mapping ip <ip-address>

No matched record

Configure the Windows User-ID Agent as a Syslog Listener

To configure the Windows-based User-ID agent to create new user mappings and remove outdated mappings through syslog monitoring, start by defining Syslog Parse profiles. The User-ID agent uses the profiles to find login and logout events in syslog messages. In environments where  syslog senders  (the network services that authenticate users) deliver syslog messages in different formats, configure a profile for each syslog format. Syslog messages must meet certain criteria for a User-ID agent to parse them (see  Syslog ). This procedure uses examples with the following formats:

• Login events— [Tue Jul 5 13:15:04 2016 CDT] Administrator authentication success User:johndoe1 Source:192.168.3.212
• Logout events— [Tue Jul 5 13:18:05 2016 CDT] User logout successful User:johndoe1 Source:192.168.3.212

After configuring the Syslog Parse profiles, you specify the syslog senders that the User-ID agent monitors.

The Windows User-ID agent accepts syslogs over TCP and UDP only. However, you must use caution when using UDP to receive syslog messages because it is an unreliable protocol and as such there is no way to verify that a message was sent from a trusted syslog sender. Although you can restrict syslog messages to specific source IP addresses, an attacker can still spoof the IP address, potentially allowing the injection of unauthorized syslog messages into the firewall. As a best practice, use TCP instead of UDP. In either case, make sure that the syslog sender and client are both on a dedicated, secure VLAN to prevent untrusted hosts from sending syslogs to the User-ID agent.

1. Deploy the Windows-based User-ID agents if you haven’t already.
1. Install the Windows-Based User-ID Agent .
2. Configure the firewall to connect to the User-ID agent.
2. Define custom Syslog Parse profiles to create and delete user mappings.

Each profile filters syslog messages to identify either login events (to create user mappings) or logout events (to delete mappings), but no single profile can do both.

1. Review the syslog messages that the syslog sender generates to identify the syntax for login and logout events. This enables you to define the matching patterns when creating Syslog Parse profiles.

While reviewing syslog messages, also determine whether they include the domain name. If they don’t, and your user mappings require domain names, enter the  Default Domain Name  when defining the syslog senders that the User-ID agent monitors (later in this procedure).

2. Open the Windows  Start  menu and select  User-ID Agent .
3. Select  User IdentificationSetup  and  Edit  the Setup.
4. Select  Syslog ,  Enable Syslog Service , and  Add  a Syslog Parse profile.
5. Enter a  Profile Name  and  Description .
6. Select the  Type  of parsing to find login and logout events in syslog messages:
• Regex —Regular expressions.
• Field —Text strings.

The following steps describe how to configure these parsing types.

3. ( Regex parsing only ) Define the regex matching patterns.

If the syslog message contains a standalone space or tab as a delimiter, use  \s  for a space and  \t  for a tab.

1. Enter the  Event Regex  for the type of events you want to find:
• Login events —For the example message, the regex  (authentication\ success){1}  extracts the first  {1}  instance of the string  authentication success .
• Logout events —For the example message, the regex  (logout\ successful){1}  extracts the first  {1}  instance of the string  logout successful .

The backslash before the space is a standard regex escape character that instructs the regex engine not to treat the space as a special character.

2. Enter the  Username Regex  to identify the start of the username.

In the example message, the regex  User:([a-zA-Z0-9\\\._]+)  matches the string  User:johndoe1  and identifies  johndoe1  as the username.

3. Enter the  Address Regex  to identify the IP address portion of syslog messages.

In the example message, the regular expression  Source:([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})  matches the IPv4 address  Source:192.168.3.212 .

The following is an example of a completed Syslog Parse profile that uses regex to identify login events:

4. Click  OK  twice to save the profile.
3. ( Field Identifier parsing only ) Define string matching patterns.
1. Enter an  Event String  to identify the type of events you want to find.
• Login events —For the example message, the string  authentication success  identifies login events.
• Logout events —For the example message, the string  logout successful  identifies logout events.
2. Enter a  Username Prefix  to identify the start of the username field in syslog messages. The field does not support regex expressions such as \s (for a space) or \t (for a tab).

In the example messages,  User:  identifies the start of the username field.

3. Enter the  Username Delimiter  that indicates the end of the username field in syslog messages. Use  \s  to indicate a standalone space (as in the sample message) and  \t  to indicate a tab.
4. Enter an  Address Prefix  to identify the start of the IP address field in syslog messages. The field does not support regex expressions such as \s (for a space) or \t (for a tab).

In the example messages,  Source:  identifies the start of the address field.

5. Enter the  Address Delimiter  that indicates the end of the IP address field in syslog messages.

For example, enter  \n  to indicate the delimiter is a line break.

The following is an example of a completed Syslog Parse profile that uses string matching to identify login events:

6. Click  OK  twice to save the profile.
4. Specify the syslog senders that the User-ID agent monitors.

Within the total maximum of 100 servers of all types that the User-ID agent can monitor, up to 50 can be syslog senders.

The User-ID agent discards any syslog messages received from senders that are not on this list.

1. Select  User IdentificationDiscovery  and  Add  an entry to the Servers list.
2. Enter a  Name  to identify the sender.
3. Enter the  Server Address  of the syslog sender (IP address or FQDN).
4. Set the  Server Type  to  Syslog Sender .
5. ( Optional ) If you want to override the current domain in the username of your syslog message or prepend the domain to the username if your syslog message doesn’t contain a domain, enter a  Default Domain Name .
6. For each syslog format that the sender supports,  Add  a Syslog Parse profile to the Filter list. Select the  Event Type  that you configured each profile to identify— login  (default) or  logout —and then click  OK .
7. Click  OK  to save the settings.
8. Commit  your changes to the User-ID agent configuration.
5. Verify that the User-ID agent adds and deletes user mappings when users log in and out.

You can  use CLI commands  to see additional information about syslog senders, syslog messages, and user mappings.

1. Log in to a client system for which a monitored syslog sender generates login and logout event messages.
2. Verify that the User-ID agent mapped the login username to the client IP address:

1.                   In the User-ID agent, select  Monitoring .

2.                   Enter the username or IP address in the filter field,  Search , and verify that the list displays the mapping.

3. Verify that the firewall received the user mapping from the User-ID agent:

1.                   Log in to the firewall CLI .

2.                   Run the following command:

> show user ip-user-mapping ip <ip-address>

If the firewall received the user mapping, the output resembles the following:

IP address:    192.0.2.1 (vsys1)

User:          localdomain\username

From:          SYSLOG

4. Log out of the client system.
5. Verify that the User-ID agent removed the user mapping:

1.                   In the User-ID agent, select  Monitoring .

2.                   Enter the username or IP address in the filter field,  Search , and verify that the list does not display the mapping.

6. Verify that the firewall deleted the user mapping:

1.                   Access the firewall CLI.

2.                   Run the following command:

> show user ip-user-mapping ip <ip-address>

If the firewall deleted the user mapping, the output displays:

No matched record

Map IP Addresses to Usernames Using Authentication Portal

When a user initiates web traffic (HTTP or HTTPS) that matches an  Authentication Policy  rule, the firewall prompts the user to authenticate through Authentication Portal. This ensures that you know exactly who is accessing your most sensitive applications and data. Based on user information collected during authentication, the firewall creates a new IP address-to-username mapping or updates the existing mapping for that user. This method of user mapping is useful in environments where the firewall cannot learn mappings through other methods such as monitoring servers. For example, you might have users who are not logged in to your monitored domain servers, such as users on Linux clients.

Authentication Portal Authentication Methods

 

Authentication Portal uses the following methods to authenticate users whose web requests match  Authentication Policy  rules:

Authentication Method	Description
Kerberos SSO	The firewall uses  Kerberos  single sign-on (SSO) to transparently obtain user credentials from the browser. To use this method, your network requires a Kerberos infrastructure, including a key distribution center (KDC) with an authentication server and ticket granting service. The firewall must have a Kerberos account. If Kerberos SSO authentication fails, the firewall falls back to web form or client certificate authentication, depending on your Authentication policy and Authentication Portal configuration.
Web Form	The firewall redirects web requests to a web form for authentication. For this method, you can configure Authentication policy to use  Multi-Factor Authentication  (MFA),  SAML ,  Kerberos ,  TACACS+ ,  RADIUS , or  LDAP  authentication. Although users have to manually enter their login credentials, this method works with all browsers and operating systems.
Client Certificate Authentication	The firewall prompts the browser to present a valid client certificate to authenticate the user. To use this method, you must provision client certificates on each user system and install the trusted certificate authority (CA) certificate used to issue those certificates on the firewall.

Authentication Portal Modes

The Authentication Portal mode defines how the firewall captures web requests for authentication:

Mode	Description
Transparent	The firewall intercepts the browser traffic per the Authentication policy rule and impersonates the original destination URL, issuing an HTTP 401 to invoke authentication. However, because the firewall does not have the real certificate for the destination URL, the browser displays a certificate error to users attempting to access a secure site. Therefore, use this mode only when absolutely necessary, such as in Layer 2 or virtual wire deployments.
Redirect	The firewall intercepts unknown HTTP or HTTPS sessions and redirects them to a Layer 3 interface on the firewall using an HTTP 302 redirect to perform authentication. This is the preferred mode because it provides a better end-user experience (no certificate errors). However, it does require additional Layer 3 configuration. Another benefit of the Redirect mode is that it provides for the use of session cookies, which enable the user to continue browsing to authenticated sites without requiring re-mapping each time the timeouts expire. This is especially useful for users who roam from one IP address to another (for example, from the corporate LAN to the wireless network) because they won’t need to re-authenticate when the IP address changes as long as the session stays open. If you use Kerberos SSO, you must use Redirect mode because the browser will provide credentials only to trusted sites. Redirect mode is also required if you use  Multi-Factor Authentication  to authenticate Authentication Portal users.

Configure Authentication Portal

The following procedure shows how to set up Authentication Portal authentication by configuring the PAN-OS integrated User-ID agent to redirect web requests that match an  Authentication Policy  rule to a firewall interface (redirect host).

SSL Inbound Inspection  does not support Authentication Portal redirect. To use Authentication Portal redirect and decryption, you must use  SSL Forward Proxy .

Based on their sensitivity, the applications that users access through Authentication Portal require different authentication methods and settings. To accommodate all authentication requirements, you can use default and custom authentication enforcement objects. Each object associates an Authentication rule with an authentication profile and an Authentication Portal authentication method.

• Default authentication enforcement objects —Use the default objects if you want to associate multiple Authentication rules with the same global authentication profile. You must  configure this authentication profile  before configuring Authentication Portal, and then assign it in the Authentication Portal Settings. For Authentication rules that require  Multi-Factor Authentication  (MFA), you cannot use default authentication enforcement objects.
• Custom authentication enforcement objects —Use a custom object for each Authentication rule that requires an authentication profile that differs from the global profile. Custom objects are mandatory for Authentication rules that require MFA. To use custom objects, create authentication profiles and assign them to the objects after configuring Authentication Portal—when you  Configure Authentication Policy .

Keep in mind that authentication profiles are necessary only if users authenticate through a Authentication Portal  Web Form  or  Kerberos SSO . Alternatively, or in addition to these methods, the following procedure also describes how to implement  Client Certificate Authentication .

If you use Authentication Portal without the other User-ID functions (user mapping and group mapping), you don’t need to configure a User-ID agent.

1. Configure the interfaces that the firewall will use for incoming web requests, authenticating users, and communicating with directory servers to map usernames to IP addresses.

When the firewall connects to authentication servers or User-ID agents, it uses the management interface by default. As a best practice, isolate your management network by configuring service  routes  to connect to the authentication servers or User-ID agents.

1. ( MGT interface only ) Select  DeviceSetupInterfaces , edit the  Management  interface, select  User-ID , and click  OK .
2. ( Non-MGT interface only )  Assign an Interface Management Profile  to the Layer 3 interface that the firewall will use for incoming web requests and communication with directory servers. You must enable  Response Pages  and  User-ID  in the Interface Management profile.
3. ( Non-MGT interface only )  Configure a service route  for the interface that the firewall will use to authenticate users. If the firewall has more than one virtual system (vsys), the service route can be global or vsys-specific. The services must include  LDAP  and potentially the following:
• Kerberos ,  RADIUS ,  TACACS+ , or  Multi-Factor Authentication —Configure a service route for any authentication services that you use.
• UID Agent —Configure this service only if you  Enable User- and Group-Based Policy .
4. ( Redirect mode only ) Create a DNS address (A) record that maps the IP address on the Layer 3 interface to the redirect host. If you will use Kerberos SSO, you must also add a DNS pointer (PTR) record that performs the same mapping.

If your network doesn’t support access to the directory servers from any firewall interface, you must  Configure User Mapping Using the Windows User-ID Agent .

2. Make sure Domain Name System (DNS) is configured to resolve your domain controller addresses.

To verify proper resolution, ping the server FQDN. For example:

admin@PA-220> ping host dc1.acme.com

3. Configure clients to trust Authentication Portal certificates.

Required for redirect mode—to transparently redirect users without displaying certificate errors. You can generate a self-signed certificate or import a certificate that an external certificate authority (CA) signed.

To use a self-signed certificate, create a root CA certificate and use it to sign the certificate you will use for Authentication Portal:

1. Select  DeviceCertificate ManagementCertificatesDevice Certificates .
2. Create a Self-Signed Root CA Certificate  or import a CA certificate (see  Import a Certificate and Private Key ).
3. Generate a Certificate  to use for Authentication Portal. Be sure to configure the following fields:
• Common Name —Enter the DNS name of the intranet host for the Layer 3 interface.
• Signed By —Select the CA certificate you just created or imported.
• Certificate Attributes—Click  Add , for the  Type  select  IP  and, for the  Value , enter the IP address of the Layer 3 interface to which the firewall will redirect requests.
4. Configure an SSL/TLS Service Profile . Assign the Authentication Portal certificate you just created to the profile.

If you don’t assign an SSL/TLS Service Profile, the firewall uses TLS 1.2 by default. To use a different TLS version, configure an SSL/TLS Service Profile for the TLS version you want to use.

5. Configure clients to trust the certificate:

1.                   Export the CA certificate  you created or imported.

2.                   Import the certificate as a trusted root CA into all client browsers, either by manually configuring the browser or by adding the certificate to the trusted roots in an Active Directory (AD) Group Policy Object (GPO).

4. ( Optional ) Configure  Client Certificate Authentication .

You don’t need an authentication profile or sequence for client certificate authentication. If you configure both an authentication profile/sequence and certificate authentication, users must authenticate using both.

1. Use a root CA certificate to generate a client certificate for each user who will authenticate through Authentication Portal. The CA in this case is usually your enterprise CA, not the firewall.
2. Export the CA certificate  in PEM format to a system that the firewall can access.
3. Import the CA certificate onto the firewall: see  Import a Certificate and Private Key . After the import, click the imported certificate, select  Trusted Root CA , and click  OK .
4. Configure a Certificate Profile .
• In the  Username Field  drop-down, select the certificate field that contains the user identity information.
• In the  CA Certificates  list, click  Add  and select the CA certificate you just imported.
4. ( Optional ) Configure Authentication Portal for the Apple Captive Network Assistant.

This step is only required if you are using Authentication Portal with the Apple Captive Network Assistant (CNA). To use Authentication Portal with CNA, perform the following steps.

1. Verify you have specified an FQDN for the redirect host (not just an IP address).
2. Select an  SSL/TLS service profile  that uses a publicly-signed certificate for the specified FQDN.
3. Enter the following command to adjust the number of requests supported for Authentication Portal:  set deviceconfig setting ctd cap-portal-ask-requests <threshold-value>

By default, the firewall has a rate limit threshold for Authentication Portal that limits the number of requests to one request every two seconds. The CNA sends multiple requests that can exceed this limit, which can result in a TCP reset and an error from the CNA. The recommended threshold value is 5 (default is one). This value will allow up to 5 requests every two seconds. Based on your environment, you may need to configure a different value. If the current value is not sufficient to handle the number of requests, increase the value.

6. Configure the Authentication Portal settings.
1. Select  DeviceUser IdentificationAuthentication Portal Settings  and edit the settings.
2. Enable Authentication Portal  (default is enabled).
3. Specify the  Timer , which is the maximum time in minutes that the firewall retains an IP address-to-username mapping for a user after that user authenticates through Authentication Portal (default is 60; range is 1 to 1,440). After the  Timer  expires, the firewall removes the mapping and any associated  Authentication Timestamps  used to evaluate the  Timeout  in Authentication policy rules.

When evaluating the Authentication Portal  Timer  and the  Timeout  value in each Authentication policy rule, the firewall prompts the user to re-authenticate for whichever setting expires first. Upon re-authenticating, the firewall resets the time count for the Authentication Portal  Timer  and records new authentication timestamps for the user. Therefore, to enable different  Timeout  periods for different Authentication rules, set the Authentication Portal  Timer  to a value the same as or higher than any rule  Timeout .

4. Select the  SSL/TLS Service Profile  you created for redirect requests over TLS. See  Configure an SSL/TLS Service Profile .
5. Select the  Mode  (in this example,  Redirect ).
6. ( Redirect mode only ) Specify the  Redirect Host , which is the intranet hostname (a hostname with no period in its name) that resolves to the IP address of the Layer 3 interface on the firewall to which web requests are redirected.

If users authenticate through  Kerberos  single sign-on (SSO), the  Redirect Host  must be the same as the hostname specified in the Kerberos keytab.

7. Select the fall back authentication method to use:
• To use client certificate authentication, select the  Certificate Profile  you created.
• To use global settings for interactive or SSO authentication, select the  Authentication Profile  you configured.
• To use Authentication policy rule-specific settings for interactive or SSO authentication, assign authentication profiles to authentication enforcement objects when you  Configure Authentication Policy .
8. Click  OK  and  Commit  the Authentication Portal configuration.
6. Next steps...

The firewall does not display the Authentication Portal web form to users until you  Configure Authentication Policy  rules that trigger authentication when users request services or applications.

Configure User Mapping for Terminal Server Users

 

Individual terminal server users appear to have the same IP address and therefore an IP address-to-username mapping is not sufficient to identify a specific user. To identify specific users on Windows-based terminal servers, the Palo Alto Networks Terminal Server agent (TS agent) allocates a port range to each user. The TS agent then notifies every connected firewall about the allocated port range, which allows the firewall to create an IP address-port-user mapping table and enable user- and group-based security policy enforcement. For non-Windows terminal servers, configure the PAN-OS XML API to extract user mapping information. The following values apply for both methods:

• Default port range: 1025 to 65534
• Per user block size: 200
• Maximum number of multi-user systems: 2,500

For information about the terminal servers supported by the TS agent and the number of TS agents supported on each firewall model, refer to the  Palo Alto Networks Compatibility Matrix  and the  Product Comparison Tool .

Configure the Palo Alto Networks Terminal Server (TS) Agent for User Mapping

Use the following procedure to install and configure the TS agent on the terminal server. To map all your users, you must install the TS agent on all terminal servers to which your users log in.

If you are using TS agent 7.0 or a later version, disable any Sophos antivirus software on the TS agent host. Otherwise, the antivirus software overwrites the source ports that the TS agent allocates.

For information about default values, ranges, and other specifications, refer to  Configure User Mapping for Terminal Server Users . For information about the terminal servers supported by the TS agent and the number of TS agents supported on each firewall model, refer to the  Palo Alto Networks Compatibility Matrix .

1. Download the TS agent installer.
1. Log in to the  Palo Alto Networks Customer Support Portal .
2. Select  UpdatesSoftware Updates .
3. Set  Filter By  to  Terminal Services Agent  and select the version of the agent you want to install from the corresponding Download column. For example, to download TS agent 9.0, select  TaInstall-9.0.msi .
4. Save the  TaInstall.x64-x.x.x-xx.msi  or  TaInstall-x.x.x-xx.msi  file on the systems where you plan to install the agent; be sure to select the appropriate version based on whether the Windows system is running a 32-bit or a 64-bit OS.

2. Run the installer as an administrator.
1. Open the Windows  Start  menu, right-click the  Command Prompt  program, and  Run as administrator .
2. From the command line, run the .msi file you downloaded. For example, if you saved the TaInstall-9.0.msi file to the Desktop, then enter the following:
3. C:\Users\administrator.acme>cd Desktop

C:\Users\administrator.acme\Desktop>TaInstall-9.0.0-1.msi

4. Follow the setup prompts to install the agent using the default settings. The setup installs the agent in  C:\ProgramFiles\Palo Alto Networks\Terminal Server Agent .

To ensure correct port allocation, you must use the default Terminal Server agent installation folder location.

5. When the installation completes,  Close  the setup dialog.

If you are upgrading to a TS agent version that has a newer driver than the existing installation, the installation wizard prompts you to reboot the system after you upgrade.

3. Define the range of ports for the TS agent to allocate to end users.

The  System Source Port Allocation Range  and  System Reserved Source Ports  specify the range of ports that are allocated to non-user sessions. Make sure the values in these fields do not overlap with the ports you designate for user traffic. These values can be changed only by editing the corresponding Windows registry settings. The TS agent does not allocate ports for network traffic emitted by session 0.

1. Open the Windows  Start  menu and select  Terminal Server Agent  to launch the Terminal Server agent application.
2. Configure  (side menu) the agent.
3. Enter the  Source Port Allocation Range  (default is 20,000-39,999). This is the full range of port numbers that the TS agent will allocate for user mapping. The port range you specify cannot overlap the  System Source Port Allocation Range .
4. ( Optional ) If there are ports or port ranges within the source port allocation that you do not want the TS agent to allocate to user sessions, specify them as  Reserved Source Ports . To include multiple ranges, use commas with no spaces (for example:  2000-3000,3500,4000-5000 ).
5. Specify the number of ports to allocate to each individual user upon login to the terminal server ( Port Allocation Start Size Per User ); default is 200.
6. Specify the  Port Allocation Maximum Size Per User , which is the maximum number of ports the Terminal Server agent can allocate to an individual user.
7. Specify whether to continue processing traffic from the user if the user runs out of allocated ports. The  Fail port binding when available ports are used up  option is enabled by default, which indicates that the application will fail to send traffic when all ports are used. To enable users to continue using applications when they run out of ports, disable (clear) this option, but if you do, this traffic may not be identified with User-ID.
8. If the terminal server stops responding when you attempt to shut it down, enable the  Detach agent driver at shutdown  option.
3. ( Optional ) Assign your own certificates for mutual authentication between the TS agent and the firewall.
1. Obtain your certificate for the TS agent from your enterprise PKI or generate one on your firewall. The private key of the server certificate must be encrypted and the certificate must be uploaded in PEM file format. Perform one of the following tasks to upload a certificate:
• Generate a Certificate  and export it.
• Export a certificate from your enterprise certificate authority (CA).
2. Add a server certificate to the TS agent.

1.                   On the TS agent, select  Server Certificate  and  Add  a new certificate.

2.                   Enter the path and name of the certificate file received from the CA or browse to the certificate file.

3.                   Enter the private key password.

4.                   Click  OK .

5.                   Commit  your changes.

The TS agent uses a self-signed certificate on port 5009 with following information:Issuer: CN=Terminal Server Agent, OU=Engineering, O=Palo Alto Networks, L=Santa Clara, S=California, C=USSubject: CN=Terminal Server Agent, OU=Engineering, O=Palo Alto Networks, L=Santa Clara, S=California, C=US

3. Configure and assign the certificate profile for the firewall.

1.                   Select  DeviceCertificate ManagementCertificate Profile  to  Configure a Certificate Profile .

You can assign only one certificate profile for Windows User-ID agents and TS agents. Therefore, your certificate profile must include all certificate authorities that issued certificates uploaded to connected Windows User-ID and TS agents.

2.                   Select  DeviceUser IdentificationConnection Security .

3.                   Edit (

   

) and select the certificate profile you configured in the previous step as the  User-ID Certificate Profile .

4.                   Click  OK .

5.                   Commit  your changes.

5. Configure the firewall to connect to the Terminal Server agent.

Complete the following steps on each firewall you want to connect to the Terminal Server agent to receive user mappings:

1. Select  DeviceUser IdentificationTerminal Server Agents  and  Add  a new TS agent.
2. Enter a  Name  for the Terminal Server agent.
3. Enter the hostname or IP address of the Windows  Host  on which the Terminal Server agent is installed.

The hostname or IP address must resolve to a static IP address. If you change the existing hostname, the TS agent resets when you commit the changes to resolve the new hostname. If the hostname resolves to multiple IP addresses, the TS agent uses the first address in the list.

4. ( Optional ) Enter the hostname or IP address for any  Alternative IP Addresses  that can appear as the source IP address for the outgoing traffic.

The hostname or IP address must resolve to a static IP address. You can enter up to 8 IP addresses or hostnames.

5. Enter the  Port  number on which the agent will listen for user mapping requests. This value must match the value configured on the Terminal Server agent. By default, the port is set to 5009 on the firewall and on the agent. If you change it on the firewall, you must also change the  Listening Port  on the Terminal Server agent  Configure  dialog to the same port.
6. Make sure that the configuration is  Enabled  and then click  OK .
7. Commit  your changes.
8. Verify that the  Connected  status displays as connected (a green light).
5. Verify that the Terminal Server agent is successfully mapping IP addresses to usernames and that the firewalls can connect to the agent.
1. Open the Windows  Start  menu and select  Terminal Server Agent .
2. Verify that the firewalls can connect by making sure the  Connection Status  of each firewall in the Connection List is  Connected .
3. Verify that the Terminal Server agent is successfully mapping port ranges to usernames ( Monitor  in the side menu) and confirm that the mapping table is populated.
6. ( Windows 2012 R2 servers only ) Disable Enhanced Protected Mode in Microsoft Internet Explorer for each user who uses that browser.

This task is not necessary for other browsers, such as Google Chrome or Mozilla Firefox.

To disable Enhanced Protected Mode for all users, use  Local Security Policy .

Perform these steps on the Windows Server:

1. Start Internet Explorer.
2. Select  SettingsInternet optionsAdvanced  and scroll to the Security section.
3. Disable (clear) the  Enable Enhanced Protected Mode  option.
4. Click  OK .

In Internet Explorer, Palo Alto Networks recommends that you do not disable Protected Mode, which differs from Enhanced Protected Mode.

Retrieve User Mappings from a Terminal Server Using the PAN-OS XML API

The PAN-OS XML API uses standard HTTP requests to send and receive data. API calls can be made directly from command line utilities such as cURL or using any scripting or application framework that supports RESTful services.

To enable a non-Windows terminal server to send user mapping information directly to the firewall, create scripts that extract the user login and logout events and use them for input to the PAN-OS XML API request format. Then define the mechanisms for submitting the XML API request(s) to the firewall using cURL or wget and providing the firewall’s API key for secure communication. Creating user mappings from multi-user systems such as terminal servers requires use of the following API messages:

• <multiusersystem> —Sets up the configuration for an XML API Multi-user System on the firewall. This message allows for definition of the terminal server IP address (this will be the source address for all users on that terminal server). In addition, the  <multiusersystem>  setup message specifies the range of source port numbers to allocate for user mapping and the number of ports to allocate to each individual user upon login (called the  block size ). If you want to use the default source port allocation range (1025-65534) and block size (200), you do not need to send a  <multiusersystem>  setup event to the firewall. Instead, the firewall will automatically generate the XML API Multi-user System configuration with the default settings upon receipt of the first user login event message.
• <blockstart> —Used with the  <login>  and  <logout>  messages to indicate the starting source port number allocated to the user. The firewall then uses the block size to determine the actual range of port numbers to map to the IP address and username in the login message. For example, if the  <blockstart>  value is 13200 and the block size configured for the multi-user system is 300, the actual source port range allocated to the user is 13200 through 13499. Each connection initiated by the user should use a unique source port number within the allocated range, enabling the firewall to identify the user based on its IP address-port-user mappings for enforcement of user- and group-based security rules. When a user exhausts all the ports allocated, the terminal server must send a new  <login>  message allocating a new port range for the user so that the firewall can update the IP address-port-user mapping. In addition, a single username can have multiple blocks of ports mapped simultaneously. When the firewall receives a  <logout>  message that includes a  <blockstart>  parameter, it removes the corresponding IP address-port-user mapping from its mapping table. When the firewall receives a  <logout>  message with a username and IP address, but no  <blockstart> , it removes the user from its table. And, if the firewall receives a  <logout>  message with an IP address only, it removes the multi-user system and all mappings associated with it.

The XML files that the terminal server sends to the firewall can contain multiple message types and the messages do not need to be in any particular order within the file. However, upon receiving an XML file that contains multiple message types, the firewall will process them in the following order: multiusersystem requests first, followed by logins, then logouts.

The following workflow provides an example of how to use the PAN-OS XML API to send user mappings from a non-Windows terminal server to the firewall.

1. Generate the API key that will be used to authenticate the API communication between the firewall and the terminal server. To generate the key you must provide login credentials for an administrative account; the API is available to all administrators (including role-based administrators with XML API privileges enabled).

Any special characters in the password must be URL/ percent-encoded.

From a browser, log in to the firewall. Then, to generate the API key for the firewall, open a new browser window and enter the following URL:

https://<Firewall-IPaddress>/api/?type=keygen&user=<username>&password=<password>

Where  <Firewall-IPaddress>  is the IP address or FQDN of the firewall and  <username>  and  <password>  are the credentials for the administrative user account on the firewall. For example:

https://10.1.2.5/api/?type=keygen&user=admin&password=admin

The firewall responds with a message containing the key, for example:

<response status="success">

   <result>

      <key>k7J335J6hI7nBxIqyfa62sZugWx7ot%2BgzEA9UOnlZRg=</key>

   </result>

</response>

2. ( Optional ) Generate a setup message that the terminal server will send to specify the port range and block size of ports per user that your Terminal Server agent uses.

If the Terminal Server agent does not send a setup message, the firewall will automatically create a Terminal Server agent configuration using the following default settings upon receipt of the first login message:

• Default port range: 1025 to 65534
• Per user block size: 200
• Maximum number of multi-user systems: 1,000

The following shows a sample setup message:

<uid-message>

                                <payload>

<multiusersystem>

<entry ip="10.1.1.23" startport="20000"          endport="39999" blocksize="100/">

</multiusersystem>

</payload>

<type>update</type>

<version>1.0</version>

</uid-message>

where  entry ip  specifies the IP address assigned to terminal server users,  startport  and  endport  specify the port range to use when assigning ports to individual users, and  blocksize  specifies the number of ports to assign to each user. The maximum blocksize is 4000 and each multi-user system can allocate a maximum of 1000 blocks.

If you define a custom blocksize and or port range, keep in mind that you must configure the values such that every port in the range gets allocated and that there are no gaps or unused ports. For example, if you set the port range to 1000–1499, you could set the block size to 100, but not to 200. This is because if you set it to 200, there would be unused ports at the end of the range.

3. Create a script that will extract the login events and create the XML input file to send to the firewall.

Make sure the script enforces assignment of port number ranges at fixed boundaries with no port overlaps. For example, if the port range is 1000–1999 and the block size is 200, acceptable blockstart values would be 1000, 1200, 1400, 1600, or 1800. Blockstart values of 1001, 1300, or 1850 would be unacceptable because some of the port numbers in the range would be left unused.

The login event payload that the terminal server sends to the firewall can contain multiple login events.

The following shows the input file format for a PAN-OS XML login event:

<uid-message>

<payload>

<login>

<entry name="acme\jjaso" ip="10.1.1.23" blockstart="20000">

<entry name="acme\jparker" ip="10.1.1.23" blockstart="20100">

<entry name="acme\ccrisp" ip="10.1.1.23" blockstart="21000">

</login>

</payload>

<type>update</type>

<version>1.0</version>

</uid-message>

The firewall uses this information to populate its user mapping table. Based on the mappings extracted from the example above, if the firewall received a packet with a source address and port of 10.1.1.23:20101, it would map the request to user jparker for policy enforcement.

Each multi-user system can allocate a maximum of 1,000 port blocks.

4. Create a script that will extract the logout events and create the XML input file to send to the firewall.

Upon receipt of a  logout  event message with a  blockstart  parameter, the firewall removes the corresponding IP address-port-user mapping. If the  logout  message contains a username and IP address, but no  blockstart  parameter, the firewall removes all mappings for the user. If the  logout  message contains an IP address only, the firewall removes the multi-user system and all associated mappings.

The following shows the input file format for a PAN-OS XML logout event:

<uid-message>

<payload>

<logout>

<entry name="acme\jjaso" ip="10.1.1.23" blockstart="20000">

<entry name="acme\ccrisp" ip="10.1.1.23">

<entry ip="10.2.5.4">

</logout>

</payload>

<type>update</type>

<version>1.0</version>

</uid-message>

You can also clear the multiuser system entry from the firewall using the following CLI command:  clear xml-api multiusersystem

5. Make sure that the scripts you create include a way to dynamically enforce that the port block range allocated using the XML API matches the actual source port assigned to the user on the terminal server and that the mapping is removed when the user logs out or the port allocation changes.

One way to do this would be to use netfilter NAT rules to hide user sessions behind the specific port ranges allocated via the XML API based on the uid. For example, to ensure that a user with the user ID jjaso is mapped to a source network address translation (SNAT) value of 10.1.1.23:20000-20099, the script you create should include the following:

[root@ts1 ~]# iptables -t nat -A POSTROUTING -m owner --uid-owner jjaso -p tcp -j SNAT --to-source 10.1.1.23:20000-20099

Similarly, the scripts you create should also ensure that the IP table routing configuration dynamically removes the SNAT mapping when the user logs out or the port allocation changes:

[root@ts1 ~]# iptables -t nat -D POSTROUTING 1

6. Define how to package the XML input files containing the setup, login, and logout events into wget or cURL messages for transmission to the firewall.

To apply the files to the firewall using wget:

> wget --post file <filename> “https://<Firewall-IPaddress>/api/?type=user-id&key=<key>&file-name=<input_filename.xml>&client=wget&vsys=<VSYS_name>”

For example, the syntax for sending an input file named login.xml to the firewall at 10.2.5.11 using key  k7J335J6hI7nBxIqyfa62sZugWx7ot%2BgzEA9UOnlZRg  using wget would look as follows:

> wget --post file login.xml “https://10.2.5.11/api/?type=user-id&key=k7J335J6hI7nBxIqyfa62sZugWx7ot%2BgzEA9UOnlZRg&file-name=login.xml&client=wget&vsys=vsys1”

To apply the file to the firewall using cURL:

> curl --form file=@<filename> https://<Firewall-IPaddress>/api/?type=user-id&key=<key>&vsys=<VSYS_name>

For example, the syntax for sending an input file named login.xml to the firewall at 10.2.5.11 using key  k7J335J6hI7nBxIqyfa62sZugWx7ot%2BgzEA9UOnlZRg  using cURL would look as follows:

> curl --form file@login.xml “https://10.2.5.11/api/?type=user-id&key=k7J335J6hI7nBxIqyfa62sZugWx7ot%2BgzEA9UOnlZRg&vsys=vsys1”

7. Verify that the firewall is successfully receiving login events from the terminal servers.

Verify the configuration by opening an SSH connection to the firewall and then running the following CLI commands:

To verify if the terminal server is connecting to the firewall over XML:

admin@PA-5250> show user xml-api multiusersystem

Host            Vsys    Users   Blocks

----------------------------------------

10.5.204.43   vsys1      5         2

To verify that the firewall is receiving mappings from a terminal server over XML:

admin@PA-5250> show user ip-port-user-mapping all

 

Global max host index 1, host hash count 1

 

XML API Multi-user System 10.5.204.43

Vsys 1, Flag 3

Port range: 20000 - 39999

Port size: start 200; max 2000

Block count 100, port count 20000

20000-20199: acme\administrator

 

Total host: 1

Send User Mappings to User-ID Using the XML API

 

User-ID provides many out-of-the box methods for obtaining user mapping information. However, you might have applications or devices that capture user information but cannot natively integrate with User-ID. For example, you might have a custom, internally developed application or a device that no standard user mapping method supports. In such cases, you can use the PAN-OS XML API to create custom scripts that send the information to the PAN-OS integrated User-ID agent or directly to the firewall. The PAN-OS XML API uses standard HTTP requests to send and receive data. API calls can be made directly from command line utilities such as cURL or using any scripting or application framework that supports POST and GET requests.

To enable an external system to send user mapping information to the PAN-OS integrated User-ID agent, create scripts that extract user login and logout events and use the events as input to the PAN-OS XML API request. Then define the mechanisms for submitting the XML API requests to the firewall (using cURL, for example) and use the API key of the firewall for secure communication. For more details, refer to the  PAN-OS XML API Usage Guide .