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 successful 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 successful 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 transparent 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 instalment 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 compatible 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