What more can my firewall do? Identify users!
Let's take a closer look at the options available to identify users by their username and what can be done with that information. We'll go over the configuration of the User-ID client and compare this to clientless deployment, set up captive portal, and prepare group mapping for use in security policies.
Windows Preparation
Before you can get started, download the User Identification Agent. It can be found on the Support Portal under Software Updates. After the installer is downloaded, we recommend installing it on your Active Directory server, but this is not strictly required if you prefer using a different server. Due to UAC (User Access Control) settings on Windows servers, we recommend running the installer as administrator. Open a command prompt with the 'run as administrator' option, navigate to the folder containing the installer file, and execue the installer from the command line.
After the install process completes, open the User-ID Agent from the start menu and go to Setup. Click edit to start configuring the User-ID Agent.
The first thing you'll need to configure is the username the service will be running as. Make sure the account is granted at least the following privileges (incorrect/incomplete permissions could lead to "Start service failed with error 1069" error message) please follow this article for a step by step setup of the user privileges: How to Install User-ID Agent and Prevent 'Start service failed with error 1069'
- Event Log Readers (audit and manage security log in Windows 2003)
- Server operator (to run as a service)
- DCOM Users (for WMI probing)
If this is a little confusing, set the account as administrator for now and at the end of this article, I've added several more links to relevant articles that can help you to better understand and plan out User-ID agent deployments.
The agent picks up on logon_success and auth_ticket_granted/renew events as listed in the admin guide
- Windows Server 2003—The event IDs for the required events are 672 (Authentication Ticket Granted), 673 (Service Ticket Granted), and 674 (Ticket Granted Renewed).
- Windows Server 2008/2012 (including R2) or MS Exchange—The event IDs for the required events are 4768 (Authentication Ticket Granted), 4769 (Service Ticket Granted), 4770 (Ticket Granted Renewed), and 4624 (Logon Success).
Lastly, on the ActiveDirectory preparation list, make sure succesful auditing is enabled, so login events are captured in the AD logs:
User-ID Agent configuration
Now let's configure the UID Agent. If you have no dedicated user yet, set the user to Administrator, which can be changed later, when you're confortable with the setup and have some time to read through further recommendations. The first tab of the configuration will have you set the username.
The Next tab will have the frequency of log reads. This will set how frequently the agent is going to poll the event log and look for succesful login events to add the source IP and its associated user account to the user-ip list. In most cases, the 1-second default setting is recommended.
Server sessions can be enabled to monitor client's connections to the server. This could come in useful when most clients have a drive mapping on the AD that can be used to verify if a user account is still logged in and connected to its share.
The Client Probing tab lets you control if and how client machines are periodically probed to see if an account is still logged on. These probes will be able to remove a user-ip mapping in case a machine is logged on to a local account or suddenly removed from the network. Some planning is required however, as the destination machines do need to support these probes. A failed probe due to a firewall policy, or if the client does not authorize wmi to the User-ID Agent account, will result in the user-ip mapping to be removed as well. If you are not sure if your clients will be able to support probing, disable both probes for now.
The Cache tab allows for a timeout to be set on entries in the user-ip mapping. Especially if probing is disabled this valuable as it allows you to remove 'stale' user-ip mappings. If an ActiveDirectory succesful log event is detected, the timeout is refreshed.
In a fairly static office environment, It could be safe to have this timeout set to 600+ minutes, as the default kerberos user ticket lifetime is 10 hours. In a very dynamic environment with many users sharing workstations, it may be more beneficial to set the timeout to a shorter period.
The Agent Service Tab allows you to change the default port the service is listening on for incoming firewall connections.
We'll leave the eDirectory and syslog tabs for now, go ahead and click ok. You will see a summary of the configuration you just created and the Access Control List which you can set to limit which IP addresses or subnets can connect to the User-ID Agent. Go ahead and commit the new User-ID Agent configuration.
Quickly make sure the service is running by going back to the main page of the agent:
If the Agent has not been started, you can manually start it from here.
Next, we will configure the ActiveDirectory servers the agent is going to connect to, to gather information on user activity. Open the Discovery page and hit the Auto Discover, this will populate the list of available servers by using the local machine information. Additional servers can be added manually. In case a server is multi-homed excess entries can be removed if necessary.
The Include/Exclude list allows you to control which subnets should or should not be monitored for user login events.
The Monitoring page should now start filling up with new user-ip mapping. When the User-ID Agent is first started it will go through the last 50.000 log entries of the ActiveDirectory and will then monitor every second for new entries. Depending on the time of day and the chattiness of the eventlog on your server, it could take a while before the list is populated with a reliable database of active IP addresses (take this into account when deploying security policies).
Now the agent has been prepared, open the firewall GUI. In the Device tab, in User Identification, a clientless deployment can be configured using the same parameters we used in the User-ID Agent. This could be very useful in a smaller environment or when access to the ActiveDirectory does not allow installing a piece of software. We don't recommend using the clientless deployment in a large environment as this could cause a lot of overhead.
To connect to the installed User-ID Agent, we need to skip to the next tab and add a new User-ID Agent.
Assign a name to the agent to easily identify it, set its IP and the port we configured in the 'Agent Service' tab of the agent's configuration. Collector should only be used if a different firewall is used as a collection point and this firewall needs to collect information from that firewall. In case Captive portal is configured to support NTLM authentication in the browser at least one agent needs to be set up to act as a proxy. Enable this option now as I'll show you how to set NTLM once we configure Captive Portal.
Commit this configuration and wait for the 'Connected' light to come up green.
The Next step is to enable User Identification for the zones that require UserID. Enabling this for the internet-facing zone is not adviseable unless the User Identification ACL is set to only perform UserID for a specific subnet in that zone. If this is not set, the firewall will query the User-ID Agent for information on every IP address that connects to the firewall's external interface.
Head on over to the Network tab and open the Zones, open the trust zone and enable the User Identification.
Commit the configuration after all required zones have been enabled. After the commit is completed, traffic logs will start showing user information:
Captive Portal
For any users that cannot be picked up via the conventional way of Active Directory event logs, a captive portal system can be set up where a browsing session is intercepted and the user's browser queried through NTLM for credential information, or a web-form presented to the user to input username and password.
As the users may be redirected to a portal page requesting authentication, an optimal user experience is to have a certificate in-place that is trusted throughout the organization, so if a Certificate Authority is available to create a server certificate, this will allow the browser to not pop up an error message when the user is redirected. If no local CA is available, a self-signed certificate can be generated and manually imported onto the clients to improve user experience.
Head over to the Device tab and generate a new self-signed certificate or import an organization certificate. I created my certificate as a Certificate Authority, but this is not strictly necessary. As common name I set the IP address of my interface as I will be using this as the redirect IP, but if you have an internal DNS server, you could set an FQDN like captiveportal.mycompany.com and use that in the redirect.
Next, you need to create an SSL/TLS Service Profile to be able to use this certificate as the captive portal server certificate. Choose which minimum and maximum version of TLS you would like the portal to support:
One more step before we can configure Captive Portal is to enable authentication. Go to the LDAP server profiles and create a new LDAP profile for the Active Directory server.
Then create an Authentication Profile. Make sure to set the login attributes appropriately for your environment. For Active Directory, this will usually be 'sAMAccountName'.
In the Advanced tab, you can limit the group of users allowed to authenticate, but for now, we're going to set this to 'All'.
Next, configure the Captive Portal.
You're going to enable redirect mode, as that will redirect the user to a landing page on the firewall's interface. This will allow the certificate created in the previous step to present the user with a proper browser experience. If transparant mode is left enabled, the firewall will impersonate the original destination URL, invoking an HTTP 401 authentication request. However, due to the in-line nature of this authentication, the client will not be presented with a proper certificate and will always get a certificate error.
- Set the SSL/TLS Service Profile to the captive portal certificate.
- Set the authentication profile to the ldap Authentication Profile.
- Set the redirect host to the interface IP of the firewall. As mentioned earlier, this could be an FQDN resolving to the IP and set as Common Name in the certificate.
For the redirect to work, the interface needs to have Response Pages enabled. These can be enabled through an Interface Management profile. In the Layer3 installment of the Getting started series, we covered adding an Interface Management profile to allow ping--we can edit that profile to also allow Response Pages:
The last step is to create Captive Portal policies. Create one policy where the action is set to browser-challenge and create a second one below that uses action web-form. The browser challenge policy will try to poll the browser for NTLM cmpatible authentication. If this fails, the second policy will present the user with a web form to fill in username and password.
Group mapping
Since you've already created an LDAP profile, one extra step will allow for group information to be collected from the Active Directory. This group information can then be used to create security policy that will allow or deny users based on their user account and group membership.
On the Device tab in User Identification, go to Group Mapping Settings and create a new profile. Set the Server Profile to the LDAP profile and set the User Domain to the NetBios domain.
The Update Interval is 3600 seconds (60 minutes) by default. If your users change between groups regularly, it could be beneficial to decrease this interval. In the Group Include list, you can choose specifically which groups to retrieve onto the firewall:
After you select the groups you're going to use, commit the config. After the commit is completed, these groups will become available in the security policy user fields.
Now you can build security policies based on user groups:
CLI commands
Several CLI commands can come in handy to verify all users are identified correctly and the group information is accurate:
- show user group name <groupname> to show members of a certain group
> show user group name "cn=domain users,cn=users,dc=example,dc=com" short name: example.com\domain users source type: ldap source: groupmapping [1 ] example.com\administrator [2 ] example.com\astark [3 ] example.com\bstark [4 ] example.com\cgrimes [5 ] example.com\dtargaryen [6 ] example.com\jlannister [7 ] example.com\jsnow [8 ] example.com\lgrimes [9 ] example.com\rgrimes [10 ] example.com\tlannister [11 ] example.com\varys
- show user group-mapping state all to see the status of the group mapping profile ad the time before a refresh/last refresh
> show user group-mapping state all Group Mapping(vsys1, type: active-directory): groupmapping Bind DN : administrator@example.com Base : DC=example,DC=com Group Filter: (None) User Filter: (None) Servers : configured 1 servers 10.192.16.98(389) Last Action Time: 3418 secs ago(took 0 secs) Next Action Time: In 182 secs Number of Groups: 3 cn=it staff,cn=users,dc=example,dc=com cn=human resources,cn=users,dc=example,dc=com cn=domain users,cn=users,dc=example,dc=com
- show user ip-user-mapping all to see all the currently identified active users and how they were identified
> show user ip-user-mapping all IP Vsys From User IdleTimeout(s) MaxTimeout(s) --------------- ------ ------- -------------------------------- -------------- ------------- 10.0.0.188 vsys1 UIA example\rgrimes 1304 1304 10.0.0.29 vsys1 CP example\administrator 561 2593 Total: 2 users > show user ip-user-mapping all type AD Active Directory CP Captive Portal EDIR eDirectory GP Global Protect SSO SSO SYSLOG Syslog UIA User-ID Agent UNKNOWN Unknown XMLAPI XML API
Check out the User-ID CLI cheat sheet for more useful CLI commands.
Other helpful information about planning UID deployments:
A full list of the event ID's read by the agent can be found in the admin guide
I hope you liked this article. Please feel free to leave comments in the section below.
Please also check out the previous episodes at Getting Started: the series.
___________________________________________________________________________________________________________
___________________________________________________________________________________________________________
Steps
To configure Agentless User-ID, first create the service account, then modify and verify security settings.
Configure the following on the Active Directory (AD) Server and the Palo Alto Networks device:
- Create the service account in AD, which is utilized on the device. Be sure the user is part of the following groups:
- Distributed COM Users
- Event Log Readers
- Server Operators
Note: Domain Admin privileges are not required for the User-ID service account to function properly, see Best Practices for Securing User-ID Deployments for more information.
In Windows 2003, the service account must be given the “Audit and manage security log” user right through a group policy. Making the account a member of the Domain Administrators group provides rights for all operations. The built-in group named “Event Log Readers” is not available in Windows 2003. - The device uses WMI Authentication and the user must modify the CIMV2 security properties on the AD server that connects to the device.
- Run 'wmimgmt.msc' on the command prompt to open the console and select these properties:
- From the Security tab on WMI Control Properties:
1.) Select the CIMV2 folder.
2.) Click Security,
3.) Click Add and then select the service account from Step 1.
4.) In this case, it is userid@pantac.lab.
5.) For this account, check both Allow for Enable Account and Remote Enable:
6.) Click Apply,
7.) Then click OK. - Back in the Palo Alto WebGUI, Select Device > User Identification > User Mapping, then click the edit sproket in the upper right corner to complete the Palo Alto Networks User-ID Agent Setup.
- Be sure to configure with the domain\username format for username under WMI Authentication tab along with valid credentials for that user.
- Enable the Server Monitor options and enable the security log/enable session accordingly.
Client probing is enabled by default, so disable if desired. - If the domain is configured during Setup in the General Settings/Domain field, the user can elect to discover servers with which to connect. If not, manually add a server to the device:
- Confirm connectivity through the WebGUI or the CLI:
> show user server-monitor statistics Directory Servers: Name TYPE Host Vsys Status ----------------------------------------------------------------------------- pantacad2003.pantac.lab AD pantacad2003.pantac.lab vsys1 Connected
- Confirm that ip-user-mapping is working.
> show user ip-user-mapping all IP Vsys From User IdleTimeout(s) MaxTimeout(s)--------------- ------ ------- -------------------------------- -------------- ----------192.168.28.15 vsys1 AD pantac\tom 2576 2541192.168.29.106 vsys1 AD pantac\userid 2660 2624192.168.29.110 vsys1 AD pantac\userid 2675 2638Total: 3 users
- Ensure Enable User Identification is enabled on the zones where identifiable traffic will be initiated. Select the zone in Network > Zone.
No comments:
Post a Comment