Create a Dedicated Service Account for the User-ID Agent

To use either 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 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. If you are using the Windows-based User-ID agent, the service account does not require Server Operator privileges. 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 to function properly.
User-ID provides many methods for safely collecting user mapping information. Some legacy features, which were designed for environments that only required mapping of users 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, such as client probing, NTLM authentication, and session monitoring, that require privileges that would pose a threat if compromised. 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 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 ( Windows_icon.png ), 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.
  2. Add the account to the Builtin groups that have privileges for accessing the services and hosts the User-ID agent will monitor.
    1. Right-click the service account you just added and Add to a group.
    2. Enter the object names to select as follows to assign the account to groups. Separate each entry with a semicolon.
      • Event Log Readers or a custom group that has privileges for reading Security log events. These privileges are required if the User-ID agent will collect mapping information by monitoring Security logs.
      • (PAN-OS integrated agent only) Distributed COM Users group, which has privileges for launching, activating, and using Distributed Component Object Model (DCOM) objects.
      • (PAN-OS integrated agent only - Not recommended) Server Operators group, which has privileges for opening sessions. The agent only requires these privileges if you plan to configure it to refresh existing mapping information by monitoring user sessions.
        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.
      • (PAN-OS integrated agent only) If you plan to configure NTLM authentication for Captive Portal, the firewall where you’ve configured the agent will need to join the domain. To enable this, enter the name of a group that has administrative privileges to join the domain, write to the validated service principal name, and create a computer object within the computers organization unit (ou=computers).
        The PAN-OS integrated agent requires privileged operations to join the domain, which poses a security threat if the account is compromised. Consider configuring Kerberos single sign-on (SSO) or SAML SSO authentication for Captive Portal instead of NTLM. Kerberos and SAML are stronger, more secure authentication methods and do not require the firewall to join the domain.
        For a firewall with multiple virtual systems, only vsys1 can join the domain because of AD restrictions on virtual systems running on the same host.
    3. Check Names to validate your entries and click OK twice.
  3. 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 ( Windows_icon.png ), Search for wmimgmt.msc, and launch the WMI Management Console.
    2. In the console tree, right-click WMI Control and select Properties.
    3. Select Security, select RootCIMV2, and click Security.
    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.
  4. Turn off account privileges that are not necessary.
    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).
    • 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.
  5. Next steps...

Related Documentation