Disclaimer: This information is posted as-is and the content should be referenced at your own risk

UTM offers a variety of user authentication methods, each with different strengths and weaknesses.  This document attempts to consolidate all of those capabilities into one reference to help administrators implement them successfully.

Concepts

Objects used for User-dependent functions

UTM has these objects that can play a role during traffic filtering:

User Objects

• Local User created manually
• Local User linked to a Remotely-Authenticated User
• Remotely Authenticated User (not linked to any Local User)

IP Address Objects

• IP address linked to an Active Directory User login (STAS User Network Object)

Technologies used for matching a network packet to a user

To perform any user-dependent traffic filtering, UTM must identify both user logon and user logoff events.   It relies on several methods to achieve this result.

• Direct Session Logon/Logoff: The user logs onto UTM in response to a login prompt, establishing a session with UTM. UTM identifies the logoff when the session is closed.
• NTLM-enabled browsing: The user logs onto Active Directory on a Windows PC and uses a browser that passes NTLM information.   UTM matches that NTLM information to a configured back-end server, and associates that user with a single web request/response transaction.
• IP Address mapping: The user authenticates by a supported method and is associated with an IP address. UTM assumes all traffic from that IP address can be considered traffic for that user, until it detects a logout.   A maximum session timer can be used for the situation where the logout event is missed.   Multiple users on the same device are not supported.

How are these different user types and identification methods applied?

Contexts which prompt for User Login but do not require a UTM User Object

The following operations will prompt for a login, but do not require permanent tracking of user attributes, so UTM will accept any of the three user types:  Local, Local linked to Remote, or Remote.

• WAF with Authentication, but without One-Time Passwords
• Web Proxy Browser authentication
• Web Proxy Basic authentication

Contexts which prompt for User Login and require UTM User Object

The following operations utilize user attributes maintained by UTM, so either a UTM Local User or a Local User linked to a Remote User is required.   All of these functions will require the user to log into the User Portal as a preliminary.   The User Portal will accept an initial Remote Authentication User and then create a Linked Local User automatically.  The functions in this category include:

• User Portal
• WebAdmin
• WAF with authentication and OTP
• VPN Clients

Context which conditionally require a User Login

Web Proxy supports both transparent identification and prompted login.

These methods provide transparent user identification

• NTLM Matching: When the Filter Profile authentication method specifies AD SSO or LDAP SSO to Active Directory, NTLM matching is attempted. The browser passes NTLM information in the web request, and UTM uses it to match a user in a configured back-end Active Directory authentication system. If the packet lacks NTLM data, or the NTLM lookup fails, then the packet is handled as an Unauthenticated User. Traffic which can supply this information includes HTTP, and HTTPS with decrypt-and-scan enabled, with either Standard Mode or Transparent Mode web proxy. It can also applies to Standard Mode Web Proxy with FTP traffic, when the browser is IE or Firefox.   Chrome seems unable to pass the NTLM information when the protocol is FTP.
• IP Matching to Prior NTLM Match:   If HTTPS traffic is not configured for decrypt-and-scan, then the NTLM information is hidden from UTM in the encrypted packet.   As a workaround, UTM assumes that the HTTPS packet is for the same user as the most recent HTTP packet received from the same IP address. If the packet was not recently preceded by an HTTP packet, then the packet is handled as an Unauthenticated User.
• IP Matching to E-Directory user: UTM will match a packet to a user based on the source iP address matching an active E-Directory logon session. If no session is available, the packet is handled as an Unauthenticated User
• IP Matching to STAS user: If a STAS User Network Object is enabled for the source IP Address, indicating an active STAS logon, then the packet will be associated with the STAT user. If no session is identified, the packet is handled as an Unauthenticated User
• SAA will match a packet to a user based on the source IP address matching a client with a valid logon to the SAA application. If no session is available, the packet is handled as an Unauthenticated User

These methods provide prompted user identification:

• Browser authentication Filter Profile: A special browser window prompts for login.   The user remains authenticated until the authentication window is closed.
• Basic authentication Filter Profile:   The user is prompted by the browser, and the user remains authenticated for that browser session only.

Contexts that never prompt for User Login

These firewall operations are examining individual packets at wire speed, so there is no opportunity for a login prompt.   If the appropriate conditions are created in advance, the firewall rules will be activated.

• Firewall rules based on a UTM User Object apply during a VPN Client session. Consequently, it is only intended for external PCs.
• Firewall rules based on a STAS User Network Object apply during a logon session to an Active Directory account on a Windows PC. Consequently, it is only intended for use with internal PCs.

Limitations and other Design Considerations

Multi-User Devices

Multi-User Devices are inherently incompatible with solutions based on matching an IP Address to a User.   This obviously includes Microsoft Terminal Services and Citrix XenApp, but it is also for a Windows 7 or later PC that allows a Switch User function.  XenApp has an option to assign a unique virtual IP address to each session.  With this option enabled, ip-to-user mapping is still valid, and should not be affected by other users on the same server.   These authentication methods are vulnerable to problems when users share a device:  E-Directory, STAS,  SAA, HTTPS without decrypt-and-scan, and Browser Authentication.  

This can be a concern if web logs are queried to evaluate a user for compliance with Acceptable Use Policy.  These technologies permit the user to claim a defense that the user information in the logs may be inaccurate because of a user context change or logout that was missed by UTM.  The only web authentication methods that provide perfect user attribution are AD/LDAP SSO (with HTTPS decrypt-and-scan enabled) and Basic Authentication.   Basic Authentication has limited acceptability because of the frequency with which the user may have to resupply his credentials.

XG Firewall provides STAC, a tool intended for installation on Terminal Server or XenApp.  It is used on multi-user servers, to provide session-level tracking on these platforms.   It has not yet been ported to UTM.

Because STAS (and STAC) are only documented to work with Active Directory, and because AD/LDAP SSO will provide superior user attribution, it seems wise to use SSO for web proxy even in a STAS environment.

An exception to this recommendation applies to Active Directory environments that include non-Windows devices running SAMBA to provide Active Directory integration.   Web Browsers on SAMBA devices cannot be expected to pass NTLM information, so an AD SSO Filter Profile will consider a SAMBA user to be unauthenticated, while a STAS Filter Profile will consider the same user to be authenticated.

Web Proxy usage with VPN clients

Web Proxy becomes usable, and possibly desirable, in these VPN client configurations:

1. Any VPN client session with full tunneling enforced (Allowed Networks = Any). In full tunnel mode, any attempt to use Internet websites will flow through UTM, so web proxy is desirable. If the remote device was configured to use a Standard Mode Proxy when the VPN Client is off, the full tunnel will prevent contacting that proxy.   After a delay, the proxy connection attempt will time out, at which point the device will attempt to connect directly. If no proxy configuration was applied, it will also attempt to connect directly.   So for either situation, a UTM Transparent Mode filter action is needed for the VPN IP Pool.
2. Any VPN client session with UTM configured as its Standard Mode proxy. If the remote device has UTM configured as its standard proxy, and a Filter Profile allows a Standard Mode connection from the VPN IP address, then the Standard Mode connection will succeed.   This is possible with either split-tunnel or full-tunnel VPN sessions. Since this seems unlikely to be useful, it is recommended that any Standard Mode Filter Actions be configured to not grant access to any VPN IP Pool address.
3. Any VPN client session to a DMZ security zone. For any VPN client with traffic entering the Web Proxy for a local web server, care must be taken to determine whether the security policy of the organization requires the VPN client to connect through a WAF or should be allowed to connect directly. If direct connection is not permitted, then the Filter Action needs a block rule for the disallowed IP addresses. If Standard Mode is enabled for the VPN IP Pool, then you must also block the associated DNS names because Standard Mode resolves DNS names at the UTM rather than the client.

Authenticating VPN Client users to the Web Proxy

If any VPN Client web traffic is routed through the web proxy, the authentication options are limited.   The VPN Client user is not passed through to the web proxy, so another method is needed.   All of these methods are crippled:

• AD/LDAP SSO and STAS require a local Active Directory login, so they are not usable.
• E-Directory requires a local Novell login, so it is also unusable.
• SAA finds UTM using an ARP request for 1.2.3.4, which will only be answered if UTM is connected to the same LAN, so it is also not usable.

Stated differently, the only usable methods are:

• Browser Authentication
• Basic Authentication
• None

Configure a Filter Profile for the VPN Pool addresses, with one of the above authentication methods, and give it precedence over any Filter Profile that includes the VPN Pool in a larger range.

Summary

UTM supports a wide variety of authentication methods, and supports a wide variety of traffic filtering.   This creates complexity, because different use cases require different strategies for matching packets to the appropriate user.   The system administrator needs to understand his configuration options, so that the security policy of his organization can be implemented correctly and successfully.