User Management

This section describes the user management capabilities of your Dell SonicWALL network security appliance for locally and remotely authenticated users.

Topics:

•	Introduction to User Management

•	Viewing Status on Users > Status

•	Configuring Settings on Users > Settings

•	Configuring Local Users on Users > Local Users

•	Configuring Local Groups on Users > Local Groups

•	Configuring RADIUS Authentication

•	Configuring LDAP Integration in SonicOS

•	Configuring Single Sign-On

•	Configuring Multiple Administrator Support

Introduction to User Management

Dell SonicWALL network security appliances provide a mechanism for user-level authentication that gives users access to the LAN from remote locations on the Internet as well as a means to enforce or bypass content filtering policies for LAN users attempting to access the Internet. You can also permit only authenticated users to access VPN tunnels and send data across the encrypted connection.

The firewall authenticates all users as soon as they attempt to access network resources in a different zone (such as WAN, VPN, WLAN), which causes the network traffic to pass through the firewall. Users who log into a computer on the LAN, but perform only local tasks are not authenticated by the firewall. User-level authentication can be performed using a local user database, LDAP, RADIUS, or a combination of a local database with either LDAP or RADIUS. For networks with a large numbers of users, user authentication using LDAP or RADIUS servers can be more efficient.

SonicOS also provides Single Sign-On (SSO) capability. SSO can be used in conjunction with LDAP.

Figure 31. User management topology

Topics:

•	Using Local Users and Groups for Authentication

•	Using RADIUS for Authentication

•	Using LDAP/Active Directory/eDirectory Authentication

•	Single Sign-On Overview

•	Multiple Administrator Support Overview

Using Local Users and Groups for Authentication

The Dell SonicWALL network security appliance provides a local database for storing user and group information. You can configure the firewall to use this local database to authenticate users and control their access to the network. The local database is a good choice over LDAP or RADIUS when the number of users accessing the network is relatively small. Creating entries for dozens of users and groups takes time, although once the entries are in place they are not difficult to maintain.

The number of users supported by the local database on the firewall varies by platform:

• SM 9600 – 4000	• NSA 6600 – 2500	• TZ 600 – 250
• SM 9400 – 3200	• NSA 5600 – 2500	• TZ 500 – 250
• SM 9200 – 2500	• NSA 4600 – 1000	• TZ 400 – 150
	• NSA 3600 – 500	• TZ 300 – 150
	• NSA 2600 – 250

IMPORTANT: If you have more users than the numbers shown above for your appliance model, you must use LDAP or RADIUS for authentication.

Figure 32. User management: Using local users and groups for authentication

To apply Content Filtering Service (CFS) policies to users, the users must be members of local groups and the CFS policies are then applied to the groups. To use CFS, you cannot use LDAP or RADIUS without combining that method with local authentication. When using the combined authentication method to use CFS policies, the local group names must be an exact match with the LDAP or RADIUS group names. When using the LDAP + Local Users authentication method, you can import the groups from the LDAP server into the local database on the firewall. This greatly simplifies the creation of matching groups, to which CFS policies can then be applied.

The SonicOS user interface provides a way to create local user and group accounts. You can add users and edit the configuration for any user, including settings for the following:

•	Group membership - Users can belong to one or more local groups. By default, all users belong to the groups Everyone and Trusted Users. You can remove these group memberships for a user and can add memberships in other groups.

•	VPN access - You can configure the networks that are accessible to a VPN client started by a user. When configuring VPN access settings, you can select from a list of networks. The networks are designated by their Address Group or Address Object names.

NOTE: The VPN access configuration for users and groups affects the ability of remote clients using GVC, NetExtender, and SSL VPN Virtual Office bookmarks to access network resources. To allow GVC, NetExtender, or Virtual Office users to access a network resource, the network address objects or groups must be added to the “allow” list on the VPN Access tab.

You can also add or edit local groups. The configurable settings for groups include the following:

•	Group settings - For administrator groups, you can configure SonicOS to allow login to the management interface without activating the login status popup window.

•	Group members - Groups have members that can be local users or other local groups.

•

VPN access - VPN access for groups is configured in the same way as VPN access for users. You can configure the networks that are accessible to a VPN client started by a member of this group. When configuring VPN access settings, you can select from a list of networks. The networks are designated by their Address Group or Address Object names.

•	CFS policy - You can apply a content filtering (CFS) policy to group members. The CFS policy setting is only available if the firewall is currently licensed for Premium Content Filtering Service.

Using RADIUS for Authentication

Remote Authentication Dial In User Service (RADIUS) is a protocol used by Dell SonicWALL network security appliances to authenticate users who are attempting to access the network. The RADIUS server contains a database with user information and checks a user’s credentials using authentication schemes such as Password Authentication Protocol (PAP), Challenge-handshake authentication protocol (CHAP), Microsoft CHAP (MSCHAP), or MSCHAPv2.

Figure 33. User management: Using RADIUS for authentication

While RADIUS is very different from LDAP, primarily providing secure authentication, it can also provide numerous attributes for each entry, including a number of different ones that can be used to pass back user group memberships. RADIUS can store information for thousands of users, and is a good choice for user authentication purposes when many users need access to the network.

Using LDAP/Active Directory/eDirectory Authentication

Lightweight Directory Access Protocol (LDAP) defines a directory services structure for storing and managing information about elements in your network, such as user accounts, user groups, hosts, and servers. Several different standards exist that use LDAP to manage user account, group, and permissions. Some are proprietary systems like Microsoft Active Directory (AD), which you can manage using LDAP, or Novell eDirectory, which provides an LDAP API for managing the user repository information. Some are open standards like SAMBA, which are implementations of the LDAP standards.

In addition to RADIUS and the local user database, SonicOS supports LDAP for user authentication, with support for numerous schemas including Microsoft Active Directory, Novell eDirectory directory services, and a fully configurable user-defined option that should allow it to interact with any schema.

Microsoft Active Directory also works with Dell SonicWALL Single Sign-On and the Dell SonicWALL SSO Agent. For more information, see Single Sign-On Overview .

LDAP Directory Services Supported in SonicOS

To integrate with the most common directory services used in company networks, SonicOS supports integration with the following LDAP schemas:

•	Microsoft Active Directory

•	RFC2798 InetOrgPerson

•	RFC2307 Network Information Service

•

Samba SMB

•	Novell eDirectory

•	User-defined schemas

SonicOS provides support for directory servers running the following protocols:

•	LDAPv2 (RFC3494)

•	LDAPv3 (RFC2251-2256, RFC3377)

•	LDAPv3 over TLS (RFC2830)

•	LDAPv3 with STARTTLS (RFC2830)

•	LDAP Referrals (RFC2251)

LDAP Terms

The following terms are useful when working with LDAP and its variants:

•	Schema – The schema is the set of rules or the structure that defines the types of data that can be stored in a directory, and how that data can be stored. Data is stored in the form of entries.

•	Active Directory (AD) – The Microsoft directory service, commonly used with Windows-based networking. Microsoft Active Directory is compatible with LDAP.

•	eDirectory – The Novell directory service, used for Novell NetWare-based networking. Novell eDirectory has an LDAP gateway that can be used for management.

•	Entry – The data that is stored in the LDAP directory. Entries are stored in attribute/value (or name/value) pairs, where the attributes are defined by object classes. A sample entry would be cn=john where cn (common name) is the attribute and john is the value.

•	Object class – Object classes define the type of entries that an LDAP directory may contain. A sample object class, as used by AD, would be user or group.

Microsoft Active Directory’s Classes can be browsed at http://msdn.microsoft.com/library/.

•

Object - In LDAP terminology, the entries in a directory are referred to as objects. For the purposes of the SonicOS implementation of the LDAP client, the critical objects are User and Group objects. Different implementations of LDAP can refer to these object classes in different fashions, for example, Active Directory refers to the user object as user and the group object as group, while RFC2798 refers to the user object as inetOrgPerson and the group object as groupOfNames.

•	Attribute - A data item stored in an object in an LDAP directory. Object can have required attributes or allowed attributes. For example, the dc attribute is a required attribute of the dcObject (domain component) object.

•

dn - A “distinguished name,” which is a globally unique name for a user or other object. It is made up of a number of components, usually starting with a common name (cn) component and ending with a domain specified as two or more domain components (dc). For example, cn=john,cn=users,dc=domain,dc=com.

•	cn – The “common name” attribute is a required component of many object classes throughout LDAP.

•	ou – The “organizational unit” attribute is a required component of most LDAP schema implementations.

•	dc – The “domain component” attribute is commonly found at the root of a distinguished name and is commonly a required attribute.

•	TLS – Transport Layer Security is the IETF standardized version of SSL (Secure Sockets Layer). TLS 1.0 is the successor to SSL 3.0. TLS 1.1 and 1.2 are later versions.

Single Sign-On Overview

Topics:

•	What Is Single Sign-On?

•	Benefits of SonicWALL SSO

•	Platforms and Supported Standards

•	How Does Single Sign-On Work?

•	How Does SSO Agent Work?

•	How Does Terminal Services Agent Work?

•	How Does Browser NTLM Authentication Work?

•	How Does RADIUS Accounting for Single-Sign-On Work?

What Is Single Sign-On?

Single Sign-On (SSO) is a transparent user-authentication mechanism that provides privileged access to multiple network resources with a single domain login to a workstation or through a Windows Terminal Services or Citrix server.

Dell SonicWALL network security appliances provide SSO functionality using the Single Sign-On Agent (SSO Agent) and SonicWALL Terminal Services Agent (TSA) to identify user activity. The SSO Agent identifies users based on workstation IP address. The TSA identifies users through a combination of server IP address, user name, and domain.

SonicWALL SSO is also available for Mac and Linux users when used with Samba. Additionally, browser NTLM authentication allows SonicWALL SSO to authenticate users who send HTTP traffic without involving the SSO Agent or Samba.

SonicWALL SSO is configured in the Users > Settings page of the SonicOS management interface. SSO is separate from the Authentication method for login settings, which can be used at the same time for authentication of VPN/L2TP client users or administrative users.

Based on data from SonicWALL SSO Agent or TSA, the firewall queries LDAP or the local database to determine group membership. Memberships are optionally checked by firewall policies to control who is given access, and can be used in selecting policies for Content Filtering and Application Control to control what they are allowed to access. User names learned via SSO are reported in logs of traffic and events from the users, and in AppFlow Monitoring.

The configured inactivity timer applies with SSO but the session limit does not, though users who are logged out are automatically and transparently logged back in when they send further traffic.

Users logged into a workstation or Terminal Services/Citrix server directly, but not logged into the domain, are not authenticated unless they send HTTP traffic and browser NTML authentication is enabled (although they can optionally be authenticated for limited access). For users who are not authenticated by SonicWALL SSO, a screen will display indicating that a manual login to the appliance is required for further authentication.

Users that are identified but lack the group memberships required by the configured policy rules are redirected to the Access Barred page.

Benefits of SonicWALL SSO

SonicWALL SSO is a reliable and time-saving feature that utilizes a single login to provide access to multiple network resources based on administrator-configured group memberships and policy matching. SonicWALL SSO is transparent to end users and requires minimal administrator configuration.

By automatically determining when users have logged in or out based on workstation IP address traffic, or, for Terminal Services or Citrix, traffic from a particular user at the server IP address, SonicWALL SSO is secure and hands-free. SSO authentication is designed to operate with any external agent that can return the identity of a user at a workstation or Terminal Services/Citrix server IP address using a SonicWALL Directory Connector-compatible protocol.

SonicWALL SSO works for any service on the firewall that uses user-level authentication, including Content Filtering Service (CFS), Firewall Access Rules, group membership and inheritance, and security services (IPS, GAV, and Anti-Spyware) inclusion/exclusion lists.

Other benefits of SonicWALL SSO include:

•	Ease of use — Users only need to sign in once to gain automatic access to multiple resources.

•	Improved user experience — Windows domain credentials can be used to authenticate a user for any traffic type without logging into the appliance using a Web browser.

•	Transparency to users — Users are not required to re-enter user name and password for authentication.

•	Secure communication — Shared key encryption for data transmission protection.

•	SonicWALL SSO Agent can be installed on any Windows server on the LAN, and TSA can be installed on any terminal server.

•	Multiple SSO Agents — Up to 8 agents are supported to provide capacity for large installations

•	Multiple TSAs — Multiple terminal services agents (one per terminal server) are supported. The number depends on the model of the Dell SonicWALL network security appliance and ranges from 8 to 512.

•	Login mechanism works with any protocol, not just HTTP.

•	Browser NTLM authentication — SonicWALL SSO can authenticate users sending HTTP traffic without using the SSO Agent.

•	Mac and Linux support — With Samba 3.5 and higher, SonicWALL SSO is supported for Mac and Linux users.

•	Per-zone enforcement — SonicWALL SSO can be triggered for traffic from any zone even when not automatically initiated by firewall access rules or security services policies, providing user identification in event logging or AppFlow Monitoring.

Platforms and Supported Standards

The SSO Agent is compatible with all versions of SonicOS that support SonicWALL SSO. The TSA is supported.

The SSO feature supports LDAP and local database protocols. SonicWALL SSO supports SonicWALL Directory Connector. For all features of SonicWALL SSO to work properly, SonicOS should be used with Directory Connector 3.1.7 or higher.

To use SonicWALL SSO with Windows Terminal Services or Citrix, SonicOS 6.0 or higher is required, and SonicWALL TSA must be installed on the server.

To use SonicWALL SSO with browser NTLM authentication, SonicOS 6.0 or higher is required. The SSO Agent is not required for browser NTLM authentication.

Except when using only browser NTLM authentication, using SonicWALL SSO requires that the SSO Agent be installed on a server within your Windows domain that can reach clients and can be reached from the appliance, either directly or through a VPN path, and/or TSA be installed on any terminal servers in the domain.

The following requirements must be met in order to run the SSO Agent:

•	UDP port 2258 (by default) must be open; the firewall uses UDP port 2258 by default to communicate with SonicWALL SSO Agent; if a custom port is configured instead of 2258, then this requirement applies to the custom port

•	Windows Server, with latest service pack

•	.NET Framework 2.0

•	Net API or WMI

NOTE: Mac and Linux PCs do not support the Windows networking requests that are used by the SSO Agent, and hence require Samba 3.5 or newer to work with SonicWALL SSO. Without Samba, Mac and Linux users can still get access, but will need to log in to do so. They can be redirected to the login prompt if policy rules are set to require authentication. For more information, see AAccommodating Mac and Linux Users .

The following requirements must be met in order to run the TSA:

•	UDP port 2259 (by default) must be open on all terminal servers on which TSA is installed; the firewall uses UDP port 2259 by default to communicate with SonicWALL TSA; if a custom port is configured instead of 2259, then this requirement applies to the custom port

•	Windows Server, with latest service pack

•	Windows Terminal Services or Citrix installed on the Windows Terminal Server system(s)

How Does Single Sign-On Work?

SonicWALL SSO requires minimal administrator configuration and is transparent to the user.

SSO is triggered in the following situations:

•	If firewall access rules requiring user authentication apply to traffic that is not incoming from the WAN zone

•	When no user groups are specified in access rules, but any of the following conditions exist, SSO is triggered for all traffic on the zone (note - not just for traffic subject to these conditions):

•	CFS is enabled on the zone and multiple CFS policies are set

•	IPS is enabled on the zone and there are IPS policies that require authentication

•	Anti-Spyware is enabled on the zone and there are Anti-Spyware policies that require authentication

•	Application Control policies that require authentication apply to the source zone

•	Per-zone enforcement of SSO is set for the zone

The SSO user table is also used for user and group identification needed by security services, including Content Filtering, Intrusion Prevention, Anti-Spyware, and Application Control.

SonicWALL SSO Authentication Using the SSO Agent

For users on individual Windows workstations, the SSO Agent (on the SSO workstation) handles the authentication requests from the firewall. There are six steps involved in SonicWALL SSO authentication using the SSO Agent, as illustrated in the following figure.

The SSO authentication process is initiated when user traffic passes through a firewall. For example, when a user accesses the Internet. The sent packets are temporarily blocked and saved while the firewall sends a “User Name” request and workstation IP address to the authorization agent running the SSO Agent (the SSO workstation).

The authorization agent running the SSO Agent provides the firewall with the user name currently logged into the workstation. A User IP Table entry is created for the logged in user, similarly to RADIUS and LDAP.

SonicWALL SSO Authentication Using the Terminal Services Agent

For users logged in from a Terminal Services or Citrix server, the TSA takes the place of the SSO Agent in the authentication process. The process is different in several ways:

•	The TSA runs on the same server that the user is logged into, and includes the user name and domain along with the server IP address in the initial notification to the firewall.

•

Users are identified by a user number as well as the IP address (for non-Terminal Services users, there is only one user at any IP address and so no user number is used). A non-zero user number is displayed in the SonicOS management interface using the format "x.x.x.x user n", where x.x.x.x is the server IP address and n is the user number.

•	The TSA sends a close notification to SonicOS when the user logs out, so no polling occurs.

Once a user has been identified, the firewall queries LDAP or a local database (based on administrator configuration) to find user group memberships, match the memberships against policy, and grant or restrict access to the user accordingly. Upon successful completion of the login sequence, the saved packets are sent on. If packets are received from the same source address before the sequence is completed, only the most recent packet will be saved.

User names are returned from the authorization agent running the SSO Agent in the format <domain>/<user-name>. For locally configured user groups, the user name can be configured to be the full name returned from the authorization agent running the SSO Agent (configuring the names in the firewall local user database to match) or a simple user name with the domain component stripped off (default).

For the LDAP protocol, the <domain>/<user-name> format is converted to an LDAP distinguished name by creating an LDAP search for an object of class “domain” with a “dc” (domain component) attribute that matches the domain name. If one is found, then its distinguished name will be used as the directory sub-tree to search for the user’s object. For example, if the user name is returned as “SV/bob” then a search for an object with “objectClass=domain” and “dc=SV” will be performed. If that returns an object with distinguished name “dc=sv,dc=us,dc=sonicwall,dc=com,” then a search under that directory sub-tree will be created for (in the Active Directory case) an object with “objectClass=user” and “sAMAccountName=bob”. If no domain object is found, then the search for the user object will be made from the top of the directory tree.

Once a domain object has been found, the information is saved to avoid searching for the same object. If an attempt to locate a user in a saved domain fails, the saved domain information will be deleted and another search for the domain object will be made.

User logout is handled slightly differently by SonicWALL SSO using the SSO Agent as compared to SSO with the TSA. The firewall polls the authorization agent running the SSO Agent at a configurable rate to determine when a user has logged out. Upon user logout, the authentication agent running the SSO Agent sends a User Logged Out response to the firewall, confirming that the user has been logged out and terminating the SSO session. Rather than being polled by the firewall, the TSA itself monitors the Terminal Services / Citrix server for logout events and notifies the firewall as they occur, terminating the SSO session. For both agents, configurable inactivity timers can be set, and for the SSO Agent the user name request polling rate can be configured (set a short poll time for quick detection of logouts, or a longer polling time for less overhead on the system).

SonicWALL SSO Authentication Using Browser NTLM Authentication

For users who are browsing using Mozilla-based browsers (including Internet Explorer, Firefox, Chrome and Safari) the firewall supports identifying them via NTLM (NT LAN Manager) authentication. NTLM is part of a browser authentication suite known as “Integrated Windows Security” and is supported by all Mozilla-based browsers. It allows a direct authentication request from the appliance to the browser without involving the SSO agent. NTLM is often used when a domain controller is not available, such as when the user is remotely authenticating over the Web.

NTLM Authentication is currently available for HTTP; it is not available for use with HTTPS traffic.

Browser NTLM authentication can be tried before or after the SSO agent attempts to acquire the user information. For example, if the SSO agent is tried first and fails to identify the user, then, if the traffic is HTTP, NTLM is tried.

To use this method with Linux or Mac clients as well as Windows clients, you can also enable SSO to probe the client for either NetAPI or WMI, depending on which is configured for the SSO Agent. This causes the firewall to probe for a response on the NetAPI/WMI port before requesting that the SSO Agent identify a user. If no response occurs, these devices will fail SSO immediately. For a Windows PC the probe will generally work (unless blocked by a personal firewall) and the SSO agent will be used. For a Linux/Mac PC (assuming it is not set up to run Samba server) the probe will fail, the SSO agent will be bypassed and NTLM authentication will be used when HTTP traffic is sent.

NTLM cannot identify the user until they browse with HTTP, so any traffic sent before that will be treated as unidentified. The default CFS policy will be applied, and any rule requiring authenticated users will not let the traffic pass.

If NTLM is configured to be used before the SSO agent, then if HTTP traffic is received first, the user will be authenticated with NTLM. If non-HTTP traffic is received first, the SSO agent will be used for authentication.

How Does SSO Agent Work?

The SSO Agent can be installed on any workstation with a Windows domain that can communicate with clients and the firewall directly using the IP address or using a path, such as VPN. For installation instructions for the SSO Agent, refer to Installing the SonicWALL SSO Agent .

Multiple SSO agents are supported to accommodate large installations with thousands of users. You can configure up to eight SSO agents, each running on a dedicated, high-performance PC in your network. Note that one SSO agent on a fast PC can support up to 2500 users.

The SSO Agent only communicates with clients and the firewall. The SSO Agent uses a shared key for encryption of messages between the SSO Agent and the firewall.

NOTE: The shared key is generated in the SSO Agent and the key entered in the firewall during SSO configuration must match the SSO Agent-generated key exactly.

The firewall queries the SSO Agent over the default port 2258. The SSO Agent then communicates between the client and the firewall to determine the client’s user ID. The SSO Agent is polled, at a rate that is configurable by the administrator, by the firewall to continually confirm a user’s login status.

Logging

The SSO Agent sends log event messages to the Windows Event Log based on administrator-selected logging levels.

The firewall also logs SSO Agent-specific events in its event log. The following is a list of SSO Agent-specific log event messages from the firewall:

•	User login denied - not allowed by policy rule – The user has been identified and does not belong to any user groups allowed by the policy blocking the user’s traffic.

•	User login denied - not found locally – The user has not been found locally, and Allow only users listed locally is selected in the firewall.

•	User login denied - SSO Agent agent timeout – Attempts to contact the SSO Agent have timed out.

•	User login denied - SSO Agent configuration error – The SSO Agent is not properly configured to allow access for this user.

•	User login denied - SSO Agent communication problem – There is a problem communicating with the workstation running the SSO Agent.

•	User login denied - SSO Agent agent name resolution failed – The SSO Agent is unable to resolve the user name.

•	SSO Agent returned user name too long – The user name is too long.

•	SSO Agent returned domain name too long – The domain name is too long.

NOTE: The notes field of log messages specific to the SSO Agent will contain the text <domain/user-name>, authentication by SSO Agent.

How Does Terminal Services Agent Work?

The TSA can be installed on any Windows Server machine with Terminal Services or Citrix installed. The server must belong to a Windows domain that can communicate with the firewall directly using the IP address or using a path, such as VPN.

For installation instructions for the TSA, refer to Installing the SonicWALL Terminal Services Agent .

See the following sections for information about the TSA:

•	Multiple TSA Support

•	Encryption of TSA Messages and Use of Session IDs

•	Connections to Local Subnets

•	Non-Domain User Traffic from the Terminal Server

•	Non-User Traffic from the Terminal Server

Multiple TSA Support

To accommodate large installations with thousands of users, firewalls are configurable for operation with multiple terminal services agents (one per terminal server). The number of agents supported depends on the model, as shown in Table 82.

 

Table 82. Terminal services agents supported per model

Dell SonicWALL Network Security Appliance	TS Agents Supported
SM 9600	512
SM 9400	512
SM 9200	512
NSA 6600	256
NSA 5600	128
NSA 4600	64
NSA 3600	16
NSA 2600	8
TZ 600	4
TZ 500	4
TZ 400	4
TZ 300	4

For all Dell SonicWALL network security appliances, a maximum of 32 IP addresses is supported per terminal server, where the server may have multiple NICs (network interface controllers). There is no limit on users per terminal server.

Encryption of TSA Messages and Use of Session IDs

The TSA uses a shared key for encryption of messages between the TSA and the firewall when the user name and domain are contained in the message. The first open notification for a user is always encrypted, because the TSA includes the user name and domain.

NOTE: The shared key is created in the TSA, and the key entered in the firewall during SSO configuration must match the TSA key exactly.

The TSA includes a user session ID in all notifications rather than including the user name and domain every time. This is efficient, secure, and allows the TSA to re-synchronize with Terminal Services users after the agent restarts.

Connections to Local Subnets

The TSA dynamically learns network topology based on information returned from the appliance and, once learned, it will not send notifications to the appliance for subsequent user connections that do not go through the appliance. As there is no mechanism for the TSA to “unlearn” these local destinations, the TSA should be restarted if a subnet is moved between interfaces on the appliance.

Non-Domain User Traffic from the Terminal Server

The firewall has the Allow limited access for non-domain users setting for optionally giving limited access to non-domain users (users logged into their local machine and not into the domain), and this works for terminal services users as it does for other SSO users.

If your network includes non-Windows devices or Windows computers with personal firewalls running, check the box next to Probe user for and select the radio button for either NetAPI or WMI depending on which is configured for the SSO Agent. This causes the firewall to probe for a response on the NetAPI/WMI port before requesting that the SSO Agent identify a user. If no response occurs, these devices will fail SSO immediately. Such devices do not respond to, or may block, the Windows networking messages used by the SSO Agent to identify a user.

Non-User Traffic from the Terminal Server

Non-user connections are opened from the Terminal Server for Windows updates and anti-virus updates. The TSA can identify a connection from a logged-in service as being a non-user connection, and indicates this in the notification to the appliance.

To control handling of these non-user connections, an Allow Terminal Server non-user traffic to bypass user authentication in access rules checkbox is available in the TSA configuration on the appliance. When selected, these connections are allowed. If this checkbox is not selected, then the services are treated as local users and can be given access by selecting the Allow limited access for non-domain users setting and creating user accounts on the appliance with the corresponding service names.

How Does Browser NTLM Authentication Work?

Topics:

•	NTLM Authentication of Domain Users

•	NTLM Authentication of Non-Domain Users

•	Credentials for NTLM Authentication in the Browser

NTLM Authentication of Domain Users

For domain users, the NTLM response is authenticated via the MSCHAP mechanism in RADIUS. RADIUS must be enabled on the appliance.

The following settings on the Users tab of the SSO configuration apply when configuring NTLM authentication:

•	Allow only users listed locally

•	Simple user names in local database

•	Mechanism for setting user group memberships (LDAP or local)

•	User group memberships can be set locally by duplicating LDAP user names (set in the LDAP configuration and applicable when the user group membership mechanism is LDAP)

•	Polling rate

NTLM Authentication of Non-Domain Users

With NTLM, non-domain users could be users who are logged into their PC rather than into the domain , or could be users who were prompted to enter a user name and password and entered something other than their domain credentials. In both cases, NTLM allows for distinguishing these from domain users.

If the user name matches a local user account on the firewall, then the NTLM response is validated locally against the password of that account. If successful, the user is logged in and given privileges based on that account. User group memberships are set from the local account, not from LDAP, and (since the password has been validated locally) will include membership of the Trusted Users group.

If the user name does not match a local user account, the user will not be logged in. The Allow limited access for non-domain users option does not apply for users authenticated via NTLM.

Credentials for NTLM Authentication in the Browser

For NTLM authentication, the browser either uses the domain credentials (if the user is logged into the domain), thus providing full single-sign-on functionality, or prompts the user to enter a name and password for the website being accessed (the firewall in this case). Different factors affect the browser’s ability to use the domain credentials when the user is logged into the domain. These factors depend on the type of browser being used:

•

Internet Explorer – Internet Explorer (9.0 or above) uses the user’s domain credentials and authenticates transparently if the website that it is logging into the firewall (the Dell SonicWALL appliance) is in the local intranet, according to the Security tab in its Internet Options. This requires adding the firewall to the list of websites in the Local Intranet zone in the Internet Options.

This can be done via the domain’s group policy in the Site to Zone Assignment List under Computer Configuration, Administrative Templates, Windows Components, Internet Explorer, Internet Control Panel, Security Page.

•	Google Chrome – Chrome behaves the same as Internet Explorer, including requiring that the firewall is added to the list of websites in the Local Intranet zone in the Internet Options.

•	Firefox – Firefox uses the user’s domain credentials and authenticates transparently if the website that it is logging into the firewall is listed in the network.automatic-ntlm-auth.trusted-uris entry in its configuration (accessed by entering about:config in the Firefox address bar).

•	Safari – Although Safari does support NTLM, it does not currently support fully transparent logon using the user’s domain credentials.

NOTE: Safari does not operate on Windows platforms.

•

Browsers on Non-PC Platforms – Non-PC platforms, such as Linux and Mac, can access resources in a Windows domain through Samba, but do not have the concept of “logging the PC into the domain” as Windows PCs do. Hence, browsers on these platforms do not have access to the user’s domain credentials and cannot use them for NTLM.

When a user is not logged into the domain or the browser cannot use their domain credentials, it will prompt for a name and password to be entered, or will use cached credentials if the user has previously opted to have it save them.

In all cases, should authentication fail when using the user’s domain credentials (which could be because the user does not have the privileges necessary to get access) then the browser will prompt the user to enter a name and password. This allows the user to enter credentials different from the domain credentials to get access.

NOTE: When NTLM is enabled for Single Sign-On enforcement, an HTTP/HTTPS access rule with Trusted Users as Users Allowed must be added to the LAN to WAN rules in the Firewall > Access Rules page. This rule will trigger an NTLM authentication request to the user. Without the access rule, other configurations such as restrictive Content Filter policies might block the user from Internet access and prevent the authentication request.

How Does RADIUS Accounting for Single-Sign-On Work?

RADIUS Accounting is specified by RFC 2866 as a mechanism for a network access server (NAS) to send user login session accounting messages to an accounting server. These messages are sent at user login and logoff. Optionally, they can also be sent periodically during the user’s session.

When a customer uses a third-party network access appliance to perform user authentication (typically for remote or wireless access) and the appliance supports RADIUS accounting, a Dell SonicWALL appliance can act as the RADIUS Accounting Server, and can use RADIUS Accounting messages sent from the customer's network access server for single sign-on (SSO) in the network.

When a remote user connects through a third-party appliance, the third-party appliance sends an accounting message to the Dell SonicWALL appliance (configured as a RADIUS accounting server). The Dell SonicWALL appliance adds the user to its internal database of logged in users based on the information in the accounting message.

When the user logs out, the third-party appliance sends another accounting message to the Dell SonicWALL appliance. The Dell SonicWALL appliance then logs the user out.

NOTE: When a network access server (NAS) sends RADIUS accounting messages, it does not require the user to be authenticated by RADIUS. The NAS can send RADIUS accounting messages even when the third-party appliance is using LDAP, its local database, or any other mechanism to authenticate users.

RADIUS accounting messages are not encrypted. RADIUS accounting is inherently secure against spoofing because it uses a request authenticator and a shared secret. RADIUS accounting requires that a list of the network access servers (NASs), that can send RADIUS Accounting messages, be configured on the appliance. This configuration supplies the IP address and shared secret for each NAS.

Topics:

•	RADIUS Accounting Messages

•	Dell SonicWALL Compatibility with Third Party Network Appliances

•	Proxy Forwarding

•	Non-Domain Users

•	IPv6 Considerations

RADIUS Accounting Messages

RADIUS accounting uses two types of accounting messages:

•	Accounting-Request

•	Accounting-Response

An Accounting-Request can send one of three request types specified by the Status-Type attribute:

•	Start—sent when a user logs in.

•	Stop—sent when a user logs out.

•	Interim-Update—sent periodically during a user login session.

Accounting messages follow the RADIUS standard specified by RFC 2866. Each message contains a list of attributes and an authenticator that is validated by a shared secret.

The following attributes, that are relevant to SSO, are sent in Accounting-Requests:

•	Status-Type—The type of accounting request (Start, Stop, or Interim-Update).

•	User-Name—The user’s login name. The format is not specified by the RFC and can be a simple login name or a string with various values such as login name, domain, or distinguished name (DN).

•	Framed-IP-Address—The user's IP address. If NAT is used, this must be the user’s internal IP address.

•	Calling-Station-Id—A string representation of the user's IP address, used by some appliances such as Aventail.

•	Proxy-State—A pass-though state used for forwarding requests to another RADIUS accounting server.

Dell SonicWALL Compatibility with Third Party Network Appliances

For Dell SonicWALL appliances to be compatible with third party network appliances for SSO via RADIUS Accounting, the third party appliance must be able to do the following:

•	Support RADIUS Accounting.

•	Send both Start and Stop messages. Sending Interim-Update messages is not required.

•	Send the user’s IP address in either the Framed-IP-Address or Calling-Station-Id attribute in both Start and Stop messages.

NOTE: In the case of a remote access server using NAT to translate a user’s external public IP address, the attribute must provide the internal IP address that is used on the internal network, and it must be a unique IP address for the user. If both attributes are being used, the Framed-IP-Address attribute must use the internal IP address, and the Calling-Station-Id attribute should use the external IP address.

The user’s login name should be sent in the User-Name attribute of Start messages and Interim-Update messages. The user’s login name can also be sent in the User-Name attribute of Stop messages, but is not required. The User-Name attribute must contain the user’s account name and may include the domain also, or it must contain the user’s distinguished name (DN).

Proxy Forwarding

A Dell SonicWALL appliance acting as a RADIUS accounting server can proxy-forward requests to up to four other RADIUS accounting servers for each network access server (NAS). Each RADIUS accounting server is separately configurable for each NAS.

To avoid the need to re-enter the configuration details for each NAS, SonicOS allows you to select the forwarding for each NAS from a list of configured servers.

The proxy forwarding configuration for each NAS client includes timeouts and retries. How to forward requests to two or more servers can be configured by selecting the following options:

•	try the next server on a timeout

•	forward each request to all the servers

Non-Domain Users

Users reported to a RADIUS accounting server are determined to be local (non-domain) users in the following cases:

•	The user name was sent without a domain, and it is not configured to look up domains for the server via LDAP.

•	The user name was sent without a domain, and it is configured to look up domains for the server via LDAP, but the user name was not found.

•	The user name was sent with a domain, but the domain was not found in the LDAP database.

•	The user name was sent with a domain, but the user name was not found in the LDAP database.

A non-domain user authenticated by RADIUS accounting is subject to the same constraints as one authenticated by the other SSO mechanisms, and the following restrictions apply:

•	The user will only be logged in if “Allow limited access for non-domain users” is set.

•	The user will not be made a member of the Trusted Users group.

IPv6 Considerations

In RADIUS accounting, these attributes are used to contain the user's IPv6 address:

•	Framed-Interface-Id / Framed-IPv6-Prefix

•	Framed-IPv6-Address

Currently, all these IPv6 attributes are ignored.

Some devices pass the IPv6 address as text in the Calling-Station-ID attribute.

The Calling-Station-ID is also ignored if it does not contain a valid IPv4 address.

RADIUS accounting messages that contain an IPv6 address attribute and no IPv4 address attribute are forwarded to the proxy server. If no proxy server is configured, IPv6 attributes discarded.

RADIUS Accounting Server Port

RADIUS accounting normally uses UDP port 1646 or 1813. UDP port 1813 is the IANA-specified port. UDP port 1646 is an older unofficial standard port. The Dell SonicWALL appliance listens on port 1812 by default. Other port numbers can be configured for the RADIUS accounting port, but the appliance can only listen on only one port. So, if you are using multiple network access servers (NASs), they must all be configured to communicate on the same port number.

Multiple Administrator Support Overview

This section provides an introduction to the Multiple Administrators Support feature.

Topics:

•	What is Multiple Administrators Support?

•

Benefits

•	How Does Multiple Administrators Support Work?

What is Multiple Administrators Support?

The original version of SonicOS supported only a single administrator to log on to a firewall with full administrative privileges. Additional users can be granted “limited administrator” access, but only one administrator can have full access to modify all areas of the SonicOS GUI at one time.

SonicOS provides support for multiple concurrent administrators. This feature allows for multiple users to log-in with full administrator privileges. In addition to using the default admin user name, additional administrator user names can be created.

Because of the potential for conflicts caused by multiple administrators making configuration changes at the same time, only one administrator is allowed to make configuration changes. The additional administrators are given full access to the GUI, but they cannot make configuration changes.

Benefits

Multiple Administrators Support provides the following benefits:

•	Improved productivity - Allowing multiple administrators to access a firewall simultaneously eliminates “auto logout,” a situation that occurs when two administrators require access to the appliance at the same time and one is automatically forced out of the system.

•	Reduced configuration risk – The new read-only mode allows users to view the current configuration and status of a firewall without the risk of making unintentional changes to the configuration.

How Does Multiple Administrators Support Work?

The following sections describe how the Multiple Administrators Support feature works:

•	Configuration Modes

•	User Groups

•	Priority for Preempting Administrators

•	GMS and Multiple Administrator Support

Configuration Modes

To allow multiple concurrent administrators, while also preventing potential conflicts caused by multiple administrators making configuration changes at the same time, the following configuration modes have been defined:

•	Configuration mode - Administrator has full privileges to edit the configuration. If no administrator is already logged into the appliance, this is the default behavior for administrators with full and limited administrator privileges (but not read-only administrators).

NOTE: Administrators with full configuration privilege can also log in using the Command Line Interface (CLI).

•	Read-only mode - Administrator cannot make any changes to the configuration, but can view the browse the entire management UI and perform monitoring actions.

Only administrators that are members of the SonicWALL Read-Only Admins user group are given read-only access, and it is the only configuration mode they can access.

•	Non-configuration mode - Administrator can view the same information as members of the read-only group and they can also initiate management actions that do not have the potential to cause configuration conflicts.

Only administrators that are members of the SonicWALL Administrators user group can access non-configuration mode. This mode can be entered when another administrator is already in configuration mode and the new administrator chooses not to preempt the existing administrator. By default, when an administrator is preempted out of configuration mode, he or she is converted to non-configuration mode. On the System > Administration page, this behavior can be modified so that the original administrator is logged out.

The following table provides a summary of the access rights available to the configuration modes. Access rights for limited administrators are included also, but note that this table does not include all functions available to limited administrators.

 

Table 83. Access rights available to configuration modes

Function	Full admin in config mode	Full admin in non‑config mode	Read-only administrator	Limited administrator
Import certificates	X
Generate certificate signing requests	X
Export certificates	X
Export appliance settings	X	X	X
Download TSR	X	X	X
Use other diagnostics	X	X		X
Configure network	X			X
Flush ARP cache	X	X		X
Setup DHCP Server	X
Renegotiate VPN tunnels	X	X
Log users off	X	X		X guest users only
Unlock locked-out users	X	X
Clear log	X	X		X
Filter logs	X	X	X	X
Export log	X	X	X	X
Email log	X	X		X
Configure log categories	X	X		X
Configure log settings	X			X
Generate log reports	X	X		X
Browse the full UI	X	X	X
Generate log reports	X	X		X

User Groups

The Multiple Administrators Support feature supports two new default user groups:

•	SonicWALL Administrators - Members of this group have full administrator access to edit the configuration.

•	SonicWALL Read-Only Admins - Members of this group have read-only access to view the full management interface, but they cannot edit the configuration and they cannot switch to full configuration mode.

It is not recommended to include users in more than one of these user groups. However, if you do so, the following behavior applies:

•	If members of the SonicWALL Administrators user group are also included in the Limited Administrators or SonicWALL Read-Only Admins user groups, the members will have full administrator rights.

•	If members of the Limited Administrators user group are included in the SonicWALL Read-Only Admins user group, the members will have limited administrator rights.

Priority for Preempting Administrators

The following rules govern the priority levels that the various classes of administrators have for preempting administrators that are already logged into the appliance:

1	The admin user and SonicWALL Global Management System (GMS) both have the highest priority and can preempt any users.

2	A user that is a member of the SonicWALL Administrators user group can preempt any users except for the admin and SonicWALL GMS.

3	A user that is a member of the Limited Administrators user group can only preempt other members of the Limited Administrators group.

GMS and Multiple Administrator Support

When using SonicWALL GMS to manage a firewall, GMS frequently logs in to the appliance (for such activities as ensuring that GMS management IPSec tunnels have been created correctly). These frequent GMS log-ins can make local administration of the appliance difficult because the local administrator can be preempted by GMS.