Palo Alto sells a firewall to allow or deny traffic based on network UserID. To get the UserID information an agent can be run in an isolated enclave with minimal permissions and restricted privileges. The existing documentation is somewhat minimal, here is how to do that.
Windows domains from 2008 and above have Managed Service Accounts.
These are restricted accounts which can be created for use on only one target workstation or server, and cannot be used for logon. Further they have "managed" hidden passwords of 230 digits which are automatically randomized and updated between the domain controllers and the target computer on which they run. The offical method of using them is by using active directory powershell module commands on a domain controller and on the target computer.
1. on a domain controller open a powershell, execute the cmd to create a standalone MSA
2. on a target computer, install the MSA hotfix to support password automatic updates
3. on a target computer install the RSAT remote admin tool kit, then the AD powershell module
4. on a target computer open a powershell, import the AD module, import the MSA standalone
5. add the MSA to the domain built-in "distributed COM users" security group
6. add the MSA to the domain built-in "Event log readers" security group
7. on a domain controller use wimmgmt.msc to grant the MSA, CIM allow permissions
note: membership in the [ServerOps] security group "is not required" for security log monitoring
The Palo Alto windows User-ID agent can be installed on anything from a Windows 7 workstation to a memberserver, but is very small and requires minimal resources. A small virtual machine (hyperv, vmware or virtualbox) would be appropriate.
1. Inbound Rules
2. Custom
3. All programs
4. Any port
5. Remote address: <vm hosting User-ID agent>
6. Allow traffic
7. Profiles all
8. Name: <TCP DCOM WMI CIM queries for User-ID agent>
note: its very possible "existing" (Windows Management Instrumentation) rules could be used
The User-ID agent comes as an executable installer, it must be Run As Administrator on the target computer. The actual runtime account will be changed to that of the MSA account after install.
The User-ID agent installer comes as two components; a
GUI tool, for configuration, monitoring and debugging. And a
standalone windows service to periodically fetch TCP DCOM enabled WMI queries of the
Security Log for Logon information.
The UserID agent also hosts a service to provide User ID to IP mapping results to the Palo Alto firewall as both a push and pull service. The agent can both notify enumerated firewalls, and firewalls can periodically retrieve delta and full userid to ip mapping cache results.
Step 1 after install is to click the "Setup" dialog then click [Edit]
The list of settings from the original "summary grid" are grouped into tabbed pages and stepped through one set at a time.
The first tab is for the [Authentication] or User-ID account that will be used to connect to windows domain controllers. In this case it will be "pre-populated" with the account information of the user account used to install the User-ID agent software. Backspace and erase the information and fill in the [ User name for Active Directory] : with the MSA account information.
MSA accounts are always appended with a "$" dollar sign after they are created, if you forget the "$" dollar sign and attempt to save the account information a warning will appear saying [Account Not Found].
User-ID agent "requires" the "complete" formal UPN syntax when providing the MSA account, which may appear strange when compared to many sources that give examples of using an MSA account. The
Down-Level Logon Name -
DOMAIN\UserName syntax will not work
, it will generate a complex error message when you attempt to save it. The MSA account username must be in the form:
username$@fqdn.for.domain
MSA accounts do not require "passwords", the [Password] field should be left empty (it will be automatically populated by the windows subsystems as needed. The MSA password while populated cannot be revealed and should not be a concern, it is 240 characters long and stored only on the target computer for the account and on the domain controllers which are solely responsible for its security and management.
The next tab is for choosing the methods for obtaining User-ID information.
The first method is by "monitoring" the domain controller "Security Event Logs"
[v/] Enable Security Log Monitor
Enables a TCP/DCOM/WMI query to the CIM repository on one or more active directory domain controllers to return the Logon Events, which the User-ID agent parses for matching domain\username patterns and associated IP address information.
domain\username patterns [are the "only"] patterns which will match
username without the prefixed domain name for the domain controllers being monitored will not match and will be discarded, no entries for
username:ip for plain "username" only Logon events will be recognized by the User-ID agent and will be dropped
There is
no "default domain override" as in other areas or versions of this line of products
Each installed instance of User-ID agent can only monitor the active directory domain controllers for [one] domain, in a forest with multiple domains, multiple User-ID agents must be deployed.
This is most common with wap - wireless access points, or other remote access devices like switch ports which provide some type/style of radius authentication via active directory (ex. EduRoam) - in these cases the "last" tabbed group of options will active a Syslog listening service and regex pattern matching tool specifically for capturing username and ip address information which comes from sources other than active directory security logs.
Enabling a TCP/DCOM/WMI query only requires the default permissions and privileges granted to members of the the domain built-in security groups "distributed COM users" and "Event log readers".
"distributed COM users" are granted the ability to launch and active a process on a remote network computer from the local system
"Event log readers" are granted the SDDL permissions to invoke a query which can read the Security event logs on the domain controllers
The native service on the domain controller which receives the authenticated query and actually performs the search is the WMI service on the domain controller(s), which also requires permission for the User-Id agent MSA account to perform a query against the root/CIM objects which contruct the query and serialize and deserialize the results.
That is [all] that is required to read the Security event logs for Logon events.
The next option down
[_] Enable Server Session Read
Is
"optional" and [requires] membership in the domain security group [Server Operators].
Periodically user workstations will connect to the shared domain [sysvol] on domain controllers to retrieve updated componets and changes to [domain group policies]. This is a temporary connection and does not persist, it is automatically disconnected after a period of time.
Enabling the [Server Session Read] method, instructs the User-ID agent to periodically connect to each domain controller and using WMI request a "list" of the username and ip addresses of filesharing "sessions" connected to the domain controller. These results are also added to the composite list of username to ip address information obtained from the first method.
Where conflicts arise, LIFO is applied.
Last in First Out - essentially the latest information takes precedence.
The last box contains an option to query the old Netware Directory service, if it is still in use for obtaining username to ip information. It is optional and isn't used that much anymore.
The next tab is for choosing [even more] methods for obtaining User-ID information, but not from the domain controllers, but the actual client workstations.
This requires every workstation on the domain to already be enabled for remote DCOM and WMI queries and/or to allow Netbios probing. (This is increasingly rare).
These methods have gained a bit of notoriety for propagating unauthorized software without the user or systems adminstration knowledge or authorization. They could be classified as [risky behavior] today.
A client workstation could be fully protected and not enable these methods and yet having this [Client Probing] options enabled could still pose a risk to the security of your network.
By default these methods are [enabled]
beware I would suggest you think about disabling them by default. At least until you are confident of your default firewall Ingres rulesets.. and consider the possible downsides -- really spend [a lot] of time considering the downsides.
The next tab is for setting the default timeout for expiring User-ID to IP mapping cache information. The cache does not change even when informed by a Security Log event that a user has Logged out. The username to ip mapping remains in effect until this timeout value for each entry has elapsed.
The next tab is for setting a TCP listening port for a Palo Alto firewall to contact and retrieve username to ip address mapping information
User-ID Service TCP port: 5007
And for enabling a TCP listening port for owner derived and provided scripts and program to proactively contact the User-ID agent and "upload" username to ip address information in json format for inclusion into the username to ip mapping cache.
User-ID XML API TCP Port: 5006
The check box is for confirmation of the intent to activate this "optional" upload service.
The eDirecttory tab is for obtaining username to ip mapping information from a Netware LDAP server.
The Syslog tab is for configuring a Syslog listening deamon process on windows, then parsers for general regex pattern matching for filtering username and ip address from syslog entries, or simplified regex pattern matching based on general pre and post delimeters surrounding username and ip address information in log entries.
Once these tabs are complete, clikcing Ok enabled the Commit button, which write it to a pseduo xml configuration file in the home directory for the GUI tool and service binary.
Immediately below the configuration summary is the access control list for defining networks for which firewall can call
from for u-to-p mapping information, or owner processes or scripts can submit
from using the XML API service.
The "Discovery" dialog is for manually or automatically listing (or enumerating) [all] of the active directory domain controllers (or other types of servers) against which this User-ID agent will run its methods to obtain username to ip address mapping information.
The upper grid field is for the active directory (or other) server
information. A good place to start is to click on [Add] and satisfy the
interview requirements. Click Ok to enter the results and return.
The lower grid field is for naming (nominating) the IP address ranges for which username to ip mapping will be collected. By default it accepts [any], but the first include/exclude entry here results in an implcit [denied to collect username to ip address information] unless explicitly listed as included or excluded.
This provides as way of "mapping" some user to ip traffic while excluding others, in a logical or oversubscribed LAN situation. Some traffic may be passing through your network that is of a network management or sensitive nature that you do not want to map.
to review:
setup - lower grid is for [granting] access to Firewalls and XMLAPI uploaders to User-ID agent
discovery - upper grid is for [listing] servers to contact for username to ip address information
discovery - lower grid is for [listing] subnets to include or exclude from username to ip mapping
Before a Configuaration can be [Commited] after changing over to the MSA account the User-ID will run as in windows. You must grant that MSA account [write] permission to the directory in which the configuration information file will be written.
The file path is:
C:\Program Files (x86)\Palo Alto Networks
Open file explorer in windows and navigate so that you can right click on "Palo Alto Networks" and select Properties then the Security tab.
Add the MSA account to the list of accounts with permissions for this directory, note the permissions granted to the account used to install the User-ID agent software and duplicate those for the MSA account. Inheritance should propagate the same permissions down to all the subdirectories and files so that when the Commit button is pressed the MSA account will have permission to write the new config file.
The Top of the tree [User Indentification] has an [Agent Status] box which should tell you the current status of the User-ID process once its been configured. Usually if everything is properly configured it will immediately start up and start collecting data.
However [File] menu contains and option to increase the level of debug information for troubleshooting. If you choose to use this make sure the regkey for finding the setting also grants the MSA account permission to read this registry key.
It is located at:
HKLM\SOFTWARE\Wow6432Node\Palo Alto Networks
Navigate there and right click, select Permissions and perform the same steps as before. Make sure to add the MSA account and that it has the same permissions as granted to the account used to install the Uer-ID agnet software.
When the User-ID agent begin running it will collect the first 50,000 log entries from each username ip information server source and process them into username to ip address mapping entries for the cache.
The cache is used to provide username to ip address mapping for firewalls and to store any new mappings from any source queried or received by xmlapi.
The cache is visible by navigating to the [Monitoring] node in the left Tree view
Each time a new username to ip address mapping is found, it is added to this view as a line item, checking abox and selecting [Delete] will instantly remove it from the cache.
[VM information sources] can use VMware host communications to obtain additional mapping information.
When using a domain controller for Security Log information, it is important to use a GPO to enable auditing for security events which produce Event IDs which User-ID agent will request and parse.
In general this means use gpmc.msc, create a new GPO object (this is a clumsy example, but the velocity of code change for the supporting microsoft elements makes it a moving target):
Group Policy Management \ Forest:fqdn.domain.com\-
Domains\fqdn.domain.com\Group Policy Objects
Generic Audit User Logons < Rt Click Edit
++++++
Generic Audit User Logons
- Computer Configuration
-- Polices
--- Windows Settings
---- Security Settings
-----Local Policies
------ Audit Policy
-------- Audit account logon events - success, failure
-------- Audit logon events - success, failure
-----Advanced Audit Policy Configuration
------ Account Logon
-------- Audit Credential Validation - success
-------- Audit Kerberos Authentication Service - success
-------- Audit Kerberos Service Ticket Operations - success
-------- Audit Other Account Logon Events - success
------ Logon/Logoff
-------- Audit Logoff - success, failure
-------- Audit Logon - success, failure
-------- Audit Other Logon/Logoff Events - success, failure
Then Scope for the GPO should be
==========================
[Links] > OU which contains the domain controllers
Security Filtering for the GPO should be
==============================
Computer accounts for domain controllers
When applied the GPO will have to be propagated and applied by the domain controllers which will depend on replication intervals, number of domain controllers and loading.
Turning on auditing will increase the logging load on domain controllers, explicitly enumerating the domain controllers through a Security Filter allows testing without widespread performance effecting behavior. Depending on the suer population, number, and velocity of user login and outs and dhcp renewals it may take a few minutes for User-ID mapping entries to appear in the cache.
Turning up the debug logging in User-ID agent can also provide some insight into whether the User-ID agent is experiencing any problems reading the config file, contacting domain controllers, initiating and receiving the results of WMI queries agaist the domain controller security logs.. and whether and for what reason entries are found that could be used to map a username to ip address, but were discarded for some reason.
This was a quick sheaft of notes, without the actual commands for creating an MSA account an explicit steps for bringing this to completion. They are accurate and do work. Its very possible steps can be trimmed or customized to improve performance and take many things into account.
These are simply the steps taken to enable User-ID agent in a small domain with a few thousand usernames with an MSA account.. for observation and decision making purposes.
They will be updated with more detail later.
