User Management

In networking and firewalling, often policies and reporting are done with IP addresses. This is because devices are most easily identified by their IP address because every single IP packet contains an source IP address and a destination IP address.

However, often it is more convenient for administrators to set policy and review reporting data using "usernames." For example:

• I wish to allow jerry to visit a specific website where other users are not allowed to visit. I want Jerry to be able to visit this website from any device, as long as Jerry is the one using the device.
• I wish to review all of sally's network activity. I may not care which device Sally is using at any given time or if she is using multiple devices. I want to see all of her activity.
• I want to give users data quotas, and I want it to apply to the user regardless of which hosts or devices the user is using.

There are indeed many cases, where it is more convenient to use users (or groups) instead of IP address or MAC address to identify and handle network traffic appropriately. However, as stated earlier IP packets do not contain a username. The IP (Internet Protocol) header contains a source IP address and a destination IP address.

Given this, How is it possible to control traffic via username? In other words, if we see a packet from 192.168.1.100 going to 1.2.3.4 - how do we know which "user" is responsible for this packet?

The way Untangle handles this is very simple; it maintains a mapping from IP address to username. This mapping can be viewed by looking at Hosts. At any given time, Untangle knows that jerry is logged into 192.168.1.100 so anytime Untangle sees traffic from 192.168.1.100 it knows to associate this traffic with username jerry.

Hosts Mapping

To view the current username associated with any host view the Hosts table. Each host has several username-related attributes:

• Username is the username associated with this host.
• Username Source is the source of that username, which can be one of many described below.
• Username (Directory Connector) is the username according to Directory Connector
• Username (Captive Portal) is the username according to Captive Portal
• Username (Device) is the username of this host's MAC address according to Devices
• Username (OpenVPN) is the username according to OpenVPN
• Username (IPsec VPN) is the username according to IPsec VPN

Techniques

There are many techniques and approaches to set the IP to username mapping. Below are some of the common ones and the some of the advantages and drawbacks to each.

Device Username

On simple and small networks where Untangle can see the MAC address of all devices and there are no shared devices, the simplest method is to simple go into Devices and manually set a username for each device.

For smaller networks where each device is owned by a user, this is a very quick and easy way to associate usernames. After doing this any Host (IP address) that is associated with that Device (MAC Address). The host's Username (Device) will be set based on the username in the associated device.

Advantages

• Simple
• Quick

Disadvantages

• Only works on flat networks where Untangle can resolve the MAC address for all IP addresses.
• Requires the administrator to manually set the username for each device, which is painful for larger networks.

Captive Portal

Another very common approach is to install a Captive Portal on your network and force users to identify themselves before being able to use the network.

To do this, configure Captive Portal to require authentication with a username/password. The username/password can be verified against the Local Directory or an external directory through Directory Connector.

When a new host (IP address) comes onto the network or becomes active, it must authenticate with a username and password through captive portal. Captive Portal will then set the Username (Captive Portal) attribute for the lifetime of the session.

Advantages

• Simple
• Reliable and Accurate - The user identifies themselves each and every time they join the network.

Disadvantages

• Requires the use of a captive portal which can increase administrator overhead because it may confuse users, cause issues with headless devices, etc.

Directory Connector - AD Login Monitor

If the network has an Active Directory server, then Directory Connector's "Active Directory Server Login Monitor Agent" can be installed on the AD server to monitor for login events.

Each time the agent sees a authentication event, it sends the host and username information to Untangle via the Directory Connector's User Notification API.

This allows Untangle to keep track of which users are logged into which hosts based on the AD server's authentication events.

Advantages

• Simple

Disadvantages

• Only works on networks using an Active Directory server for authentication
• Only has "login" and "update" events - kerberos does not log "logout" events so users can be associated with hosts for short time even after they have logged out of the host.

Directory Connector - User Login Script

The Directory Connector documentation provides a User Notification Login Script that gets installed on all machines (usually with a Group Policy Object) that calls the User Notification API when the user logs into a host.

Advantages

• Powerful and Flexible - the script can be modified to suite each environment.

Disadvantages

• Insecure - In order to support this deployment the API must be left "open" with no secret key. A malicious user can call the API directly with false information. As such, this technique may only be appropriate in certain environments.

Director Connector - Custom Scripts

The Directory Connector User Notification API provides a simple API to set username of any given host with a simple API call.

This is the most powerful and flexible technique, as the API can be called in any variety of ways with virtually any language. You can install a custom agent or your directory server to call the API on login, or install a custom agent or your devices and hosts.

Advantages

• Powerful and Flexible - can be used in virtually any environment.

Disadvantages

• Requires the administrator to write custom agents, programs, or scripts to call the API.

FAQ

What if I have virtual environments?

Virtual machines work the same way, as long as they have a unique IP address these techniques all work the same.

What if I have virtual environments with shared addresses?

One IP address must be associated with one username, so shared addresses are not supported (including NAT). Many virtualization platforms have plugins or modifications to enforce that each user gets their own IP address.

What is Username (Source)?

The Username (Source) identifies the method used to set the Username. If there are several usernames known via different methods for a given host the source can identify which one is preferred.

What is the preference order on username sources?

The username is determined in the following order:

• Captive Portal if available
• IPsec VPN if available (only applies to remotely connecting hosts)
• OpenVPN if available (only applies to remotely connecting hosts)
• Directory Connector if available
• Device if available
• Unknown (null or blank)

How do groups work?

The first step in using groups is to use one of the above techniques to identify the users.

After than you must connect Directory Connector to the Active Directory server so that it can read the group information. This allows Untangle to build a user-to-group map and compute which groups are associated with any given username and thus any given host and any given session or packet.