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.
UTM has these objects that can play a role during traffic filtering:
IP Address Objects
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.
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.
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:
Web Proxy supports both transparent identification and prompted login.
These methods provide transparent user identification
These methods provide prompted user identification:
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.
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 becomes usable, and possibly desirable, in these VPN client configurations:
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:
Stated differently, the only usable methods are:
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.
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.