en-US
search-icon

SonicOS 6.2 Admin Guide

User Management

Managing Users and Authentication Settings

User Management

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

Topics:  

About User Management

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. See User management topology.

User management topology

Topics:  

Using Local Users and Groups for Authentication

The 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 is shown in Maximum number of supported users by platform. The maximum overall user limit is equal to the maximum number of SSO users and the maximum number of native users is equal to the maximum number of SSO users. The maximum web users is the maximum combined user logins from he web and the GVC, SSL-VP, and L2TP clients.

Maximum number of supported users by platform

Platform

SSO users

Web users

Web server threads

Platform

SSO users

Web users

Web server threads

SM 9800

110,000

12.000

30

TZ600

500

500

8

SM 9600

100,000

5,000

30

TZ500/TZ500W

500

500

8

SM 9400

90,000

5,000

30

TZ400/TZ400W

500

150

8

SM 9200

80,000

5,000

20

TZ300/TZ300W

500

150

8

NSA 6600

70,000

5,000

20

 

 

 

 

NSA 5600

60,000

3,000

16

 

 

 

 

NSA 4600

50,000

2,000

10

SOHO W

250

150

8

NSA 3600

40,000

1,500

8

 

 

 

 

NSA 2600

30,000

1,000

8

 

 

 

 

* 
IMPORTANT: To achieve the maximum efficiency in handling these numbers, SonicWall recommends:
For wireless users, use RADIUS Accounting as much as possible.
Use SSO Agent version 4 or higher; do not use any SSO Agent older than version 3.6.10.
Use the SSO Agent in DC logs mode with LogWatcher wherever possible.
If NetAPI or WMI is needed to identify non-domain users, then do it in separate agents.
Where possible, set exclusions to prevent anything that cannot be identified by SSO from triggering it.

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 networking protocol that provides centralized authentication, authorization, and accounting. 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.

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 SonicWall Single Sign-On and the SonicWall SSO Agent. For more information, see Single Sign-On Overview.

Topics:  
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.1 and 1.2 are supported.

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 User Group Mirroring

LDAP User Group Mirroring provides automatic duplication of LDAP User Group configurations from an LDAP server to a SonicWall Security Appliance. Administrators can manage LDAP User Groups exclusively on the LDAP server and do not need to manually duplicate configurations on the SonicWall Security Appliance. User group configurations are periodically read from the LDAP server and copied to the SonicWall Security Appliance.

LDAP User Group names that are copied to the Security Appliance include the domain name in the format: name@domain.com. This ensures that user group names from various domains are unique.

The following features and restrictions apply to mirrored LDAP User Groups:

You can delete LDAP User Groups only on the LDAP server. They cannot delete the mirrored LDAP User Groups on the SonicWall Security Appliance. When a user group is deleted on the LDAP server, its mirrored group on the SonicWall Security Appliance is also automatically deleted.
You can edit LDAP User Group names (and their comment boxes) only on the LDAP server. They cannot edit the mirrored LDAP User Group name or its comment box on the SonicWall Security Appliance. The comment box displays “Mirrored from LDAP” on the SonicWall Security Appliance.
You can add users as members to an LDAP User Group on the SonicWall Security Appliance.
You cannot add groups to other groups on the SonicWall Security Appliance. Default user groups can only be configured on the LDAP server.
You can configure things such as VPNs, SSL VPNs, CFS policies, and ISP policies for LDAP User Groups on the SonicWall Security Appliance, when they are configurable under configuration pages such as Firewall > Access Rules or Firewall > App Rules.
* 
NOTE: LDAP User Groups are not deleted if they are configured in any Access Rules, App Rules, or policies.
When you disable LDAP User Group Mirroring, the mirrored user groups on the SonicWall Security Appliance are not deleted. They are changed so that they can be deleted manually by an administrator. Local mirrored user groups can be re-enabled if they have not been deleted manually.
When the system creates a mirrored group on the SonicWall Security Appliance, and the name of the mirrored group matches the name of an already existing, user-created (non-mirrored) local group, the local group is not replaced. The local group memberships are updated to reflect the group ne stings that are configured on the LDAP server.
If the system finds a user group on the LDAP server with a name that is the same as one of the default user groups on the SonicWall Security Appliance, no mirrored user group is created on the SonicWall Security Appliance. The memberships in the default user group are updated to reflect the group nestings that are configured on the LDAP server.
For groups created before SonicOS 6.2, if a local user group exists on the SonicWall Security Appliance with a simple name only (no domain) and that name matches the name of a user group on the LDAP server (which includes a domain), a new local user group is created on the SonicWall Security Appliance and is given the same domain as the corresponding user group on the LDAP server. The original local user group is retained with no domain. Users of the original group are given memberships in the LDAP group, the new local mirrored group, and the original local group (with no domain).
Integrating LDAP into the SonicWall Appliance

Integrating your firewall with an LDAP directory service requires configuring your LDAP server for certificate management, installing the correct certificate on your firewall, and configuring the firewall to use the information from the LDAP Server. For an introduction to LDAP, see Using LDAP/Active Directory/eDirectory Authentication.

Topics:  
Preparing Your LDAP Server for Integration

Before beginning your LDAP configuration, you should prepare your LDAP server and your SonicWall for LDAP over TLS support. This requires:

Installing a server certificate on your LDAP server.
Installing a CA (Certificate Authority) certificate for the issuing CA on your firewall.

The following procedures describe how to perform these tasks in an Active Directory environment.

Configuring the CA on the Active Directory Server
To configure the CA on the Active Directory server:
* 
TIP: Skip the first five steps if Certificate Services are already installed.
1
Navigate to Start > Settings > Control Panel > Add/Remove Programs
2
Select Add/Remove Windows Components
3
Select Certificate Services
4
Select Enterprise Root CA when prompted.
5
Enter the requested information. For information about certificates on Windows systems, see http://support.microsoft.com/kb/931125.
6
Launch the Domain Security Policy application: Navigate to Start > Run and run the command: dompol.msc.
7
Open Security Settings > Public Key Policies.
8
Right click Automatic Certificate Request Settings.
9
Select New > Automatic Certificate Request.
10
Step through the wizard, and select Domain Controller from the list.
Exporting the CA Certificate from the Active Directory Server
To export the CA certificate from the AD server:
1
Launch the Certification Authority application: Start > Run > certsrv.msc.
2
Right click on the CA you created, and select properties.
3
On the General tab, click the View Certificate button.
4
On the Details tab, select Copy to File.
5
Step through the wizard, and select the Base-64 Encoded X.509 (.cer) format.
6
Specify a path and filename to which to save the certificate.
Importing the CA Certificate in to SonicOS
To import the CA certificate in to SonicOS:
1
Browse to System > CA Certificates.
2
Select Add new CA certificate. Browse to and select the certificate file you just exported.
3
Click the Import certificate button.
LDAP Group Membership by Organizational Unit

The LDAP Group Membership by Organizational Unit feature provides the ability to set LDAP rules and policies for users located in certain Organizational Units (OUs) on the LDAP server.

When a user logs in, if user groups are set to grant memberships by LDAP location, the user is made a member of any groups that match its LDAP location.

You can set any local group, including default local groups (except for the Everyone group and the Trusted Users group) as a group with members that are set by their location in the LDAP directory tree.

When a user is a member of any local groups that are configured for LDAP location:

The location of those local groups in the LDAP tree is learned.
The location of the user’s local groups is checked against all other local groups. If any other groups have the same LDAP location as that of the user’s membership groups, the user is automatically set as a member of those groups for that login session.

When a user attempts to log in, whether with success or failure, the user’s distinguished name is logged in the event log. This helps with troubleshooting if a user fails to get memberships to the expected groups.

Single Sign-On Overview

Topics:  
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.

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 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 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 Accommodating 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. NTLM 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 fail SSO immediately. For a:

Windows PC, the probe generally works (unless blocked by a personal firewall) and the SSO agent is used.
Linux/Mac PC (assuming it is not set up to run Samba server), the probe fails, the SSO agent is bypassed, and NTLM authentication is 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 or server with a Windows domain that can communicate with clients and the firewall directly using the IP address or using a path, such as VPN. It is recommended, however, that the SSO Agent be installed on separate, standalone workstations or servers. 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: When using NetAPI or WMI, one SSO Agent can support up to approximately 2500 users, depending on the performance level of the hardware that it is running on, how it is configured on the firewall, and other network-dependent factors. Depending on similar factors, when configured to read from domain controller security logs, one SSO Agent can support a much larger number of users identified via that mechanism, potentially up to 50,000+ 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.

Topics: :
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 Terminal services agents supported per model.

 

Terminal services agents supported per model

SonicWall Network Security Appliance

TS Agents Supported

SonicWall Network Security Appliance

TS Agents Supported

SonicWall Network Security Appliance

TS Agents Supported

SM 9800

512

NSA 6600

256

TZ600

4

SM 9600

512

NSA 5600

128

TZ500/TZ500 W

4

SM 9400

512

NSA 4600

64

TZ400/TZ400 W

4

SM 9200

512

NSA 3600

16

TZ300/TZ300 W

4

 

 

NSA 2600

8

SOHO W

4

For all 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

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 dialog 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 (9.0 or above) – Uses the user’s domain credentials and authenticates transparently if the website that it is logging into the firewall (the 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 – 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 – 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 an external or third-party network access appliance to perform user authentication (typically for remote or wireless access) and the appliance supports RADIUS accounting, a 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.

* 
NOTE: A SonicWall SMA 1000 Series appliance running SMA 11.4 or higher can be configured as an external RADIUS Accounting client, with the SonicWall firewall as the RADIUS Accounting server.

When a remote user connects through a SonicWall SMA or third-party appliance, the SMA or third-party appliance sends an accounting message to the SonicWall appliance (configured as a RADIUS accounting server). The 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 SonicWall SMA or third-party appliance sends another accounting message to the SonicWall appliance. The 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

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 SMA.
Proxy-State—A pass-though state used for forwarding requests to another RADIUS accounting server.
SonicWall Compatibility with Third Party Network Appliances

For 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 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 1813 or 1646. UDP port 1813 is the IANA-specified port. UDP port 1646 is an older unofficial standard port. The SonicWall appliance listens on port 1813 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?

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

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; see the SonicOS 6.2 CLI Reference Guide).
Read-only mode - Administrator cannot make any changes to the configuration, but can view 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.

Access rights available to configuration modes 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.

 

Access rights available to configuration modes

Function

Full admin in config mode

Full admin in nonconfig 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.
If members of the SonicWall Read-Only Admins user group are later included in another administrative group, the If this read-only admin group is used with other administrative groups option in the SonicWall Read-Only Admins group configuration determines whether the members are still restricted to read-only access or have the full administration capabilities set by their other group.
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.

Installing the Single Sign-On Agent and/or Terminal Services Agent

Configuring SSO is a process that includes installing and configuring the SonicWall SSO Agent and/or the SonicWall Terminal Services Agent (TSA), and configuring a firewall running SonicOS to use the SSO Agent or TSA. For an introduction to SonicWall SSO, see Single Sign-On Overview.

The following sections describe how to install SSO agent and/or TSA; for configuring SonicOS for SSO and TSA, see Single Sign-On Overview; for configuring SonicOS to use the SSO agent, see Configuring SonicOS to Use the SonicWall SSO Agent; for advanced LDAP configuration, see Advanced LDAP Configuration.

Installing the SonicWall SSO Agent

The SonicWall SSO Agent is part of the SonicWall Directory Connector. The SonicWall SSO Agent must be installed on at least one, and up to eight, workstations or servers in the Windows domain that have access to the Active Directory server using VPN or IP. It is recommended that these workstations or servers be separate, standalone workstations or servers. The SonicWall SSO Agent must have access to your firewall.

To install the SonicWall SSO Agent, see the procedure in the SonicWall Directory Services Connector Administration Guide. You can download this guide from mysonicwall.com.

Installing the SonicWall Terminal Services Agent

Install the SonicWall TSA on one or more terminal servers on your network within the Windows domain. The SonicWall TSA must have access to your SonicWall security appliance, and the appliance must have access to the TSA. If you have a software firewall running on the terminal server, you may need to open up the UDP port number for incoming messages from the appliance.

SonicWall TSA is available for download without charge from MySonicWall.

To install the SonicWall TSA:
1
On a Windows Terminal Server system, download one of the following installation programs, depending on your computer:
SonicWall TSAInstaller32.msi (32 bit, version 3.0.28.1001 or higher)
SonicWall TSAInstaller64.msi (64 bit, version 3.0.28.1001 or higher)

You can find these on http://www.mysonicwall.com.

2
Double-click the installation program to begin installation.
3
On the Welcome page, click Next to continue.
4
The License Agreement displays. Select I agree and click Next to continue.
5
On the Select Installation Folder window, select the destination folder. To use the default folder, C:\Program Files\SonicWall\SonicWall Terminal Services Agent\, click Next. To specify a custom location, click Browse, select the folder, and click Next.

6
On the Confirm Installation window, click Next to start the installation.

7
Wait while the SonicWall Terminal Services Agent installs. The progress bar indicates the status.
8
When installation is complete, click Close to exit the installer.
9
You must restart your system before starting the SonicWall Terminal Services Agent. To restart immediately, click Yes in the dialog box. To restart later, click No.

Configuring the SonicWall SSO Agent

The SonicWall SSO Agent communicates with workstations using NetAPI or WMI, which both provide information about users that are logged into a workstation, including domain users, local users, and Windows services. WMI is pre-installed on Windows Server 2003, Windows XP, Windows ME, and Windows 2000. For other Windows versions, visit www.microsoft.com to download WMI. Verify that WMI or NetAPI is installed prior to configuring the SonicWall SSO Agent.

The .NET Framework 2.0 must installed prior to configuring the SonicWall SSO Agent. The .NET Framework can be downloaded from Microsoft at www.microsoft.com.

To configure the communication properties of the SonicWall SSO Agent:
1
Launch the SonicWall Configuration Tool by double-clicking the desktop shortcut or by navigating to Start > All Programs > SonicWall > SonicWall Directory Connector > SonicWall Configuration Tool.

* 
NOTE: If the IP address for a default firewall was not configured, or if it was configured incorrectly, a pop up will display. Click Yes to use the default IP address (192.168.168.168) or click No to use the current configuration.

If you clicked Yes, the message Successfully restored the old configuration will display. Click OK.

If you clicked No, or if you clicked Yes but the default configuration is incorrect, the message SonicWall SSO Agent service is not running. Please check the configuration and start the service. will display. Click OK.

If the message SonicWall SSO Agent service is not running. Please check the configuration and start the service displays, the SSO Agent service is disabled by default. To enable the service, expand the SonicWall Directory Connector Configuration Tool in the left navigation panel by clicking the + icon, highlight the SonicWall SSO Agent underneath it, and click the Start icon.

2
In the left-hand navigation panel, expand the SonicWall Directory Connector Configuration Tool by clicking the + icon. Right click the SonicWall SSO Agent and select Properties.

3
From the Logging Level drop-down menu, select the level of events to be logged in the Windows Event Log. The default logging level is 1. Select one of the following levels:
Logging Level 0 - Only critical events are logged.
Logging Level 1 - Critical and significantly severe events are logged.
Logging Level 2 - All requests from the appliance are logged, using the debug level of severity.
* 
NOTE: When Logging Level 2 is selected, the SSO Agent service will terminate if the Windows event log reaches its maximum capacity.

4
In the Refresh Time field, enter the frequency, in seconds, that the SSO Agent will refresh user log in status. The default is 60 seconds.

5
From the Query Source drop-down menu, select the protocol that the SSO Agent will use to communicate with workstations, either NETAPI or WMI.

* 
NOTE: NetAPI will provide faster, though possibly slightly less accurate, performance. WMI will provide slower, though possibly more accurate, performance. With NetAPI, Windows reports the last login to the workstation whether or not the user is still logged in. This means that after a user logs out from his computer, the appliance will still show the user as logged in when NetAPI is used. If another user logs onto the same computer, then at that point the previous user is logged out from the SonicWall.

WMI is pre-installed on Windows Server 2003, Windows XP, Windows Me, and Windows 2000. Both NetAPI and WMI can be manually downloaded and installed. NetAPI and WMI provide information about users that are logged into a workstation, including domain users, local users, and Windows services.

6
In the Configuration File field, enter the path for the configuration file. The default path is C:\Program Files\SonicWall\DCON\SSO\CIAConfig.xml.

7
Click Accept.
8
Click OK.
Adding a SonicWall Network Security Appliance

Use these instructions to manually add a firewall if you did not add one during installation, or to add additional firewalls.

To add a firewall:
1
Launch the SonicWall SSO Agent Configurator.

2
Expand the SonicWall Directory Connector and SonicWall SSO Agent trees in the left column by clicking the + button.
3
Right click SonicWall Appliance and select Add.

4
Enter the appliance IP address for your SonicWall network security appliance in the Appliance IP field.
5
Enter the port for the same appliance in the Appliance Port field. The default port is 2258. Give your appliance a friendly name in the Friendly Name field.
6
Enter a shared key in the Shared Key field or click Generate Key to generate a shared key.
7
When you are finished, click OK.

Your appliance displays in the left-hand navigation panel under the SonicWall Appliance tree.

Editing Appliances in SonicWall SSO Agent

You can edit all settings on firewalls previously added in SonicWall SSO Agent, including IP address, port number, friendly name, and shared key. To edit a firewall in SonicWall SSO Agent, select the appliance from the left-hand navigation panel and click the Edit icon above the left-hand navigation panel. You can also click the Edit tab at the bottom of the right-hand window.

Deleting Appliances in SonicWall SSO Agent

To delete a firewall you previously added in SonicWall SSO Agent, select the appliance from the left-hand navigation panel and click the Delete icon above the left-hand navigation panel.

Modifying Services in SonicWall SSO Agent

You can start, stop, and pause SonicWall SSO Agent services to firewalls.

To pause services for an appliance, select the appliance from the left-hand navigation panel and click the Pause icon.

To stop services for an appliance, select the appliance from the left-hand navigation panel and click the Stop icon.

To resume services, click the Start icon.

* 
NOTE: You may be prompted to restart services after making configuration changes to a firewall in the SonicWall SSO Agent. To restart services, press the stop button then press the start button.

Configuring the SonicWall Terminal Services Agent

After installing the SonicWall TSA and restarting your Windows Server system, you can double-click the SonicWall TSA desktop icon created by the installer to launch it for configuration, to generate a trouble shooting report (TSR), or to see the status and version information.

Topics:  
Adding a SonicWall Network Security Appliance to SonicWall TSA Settings

Perform the following steps to add a SonicWall network security appliance to the SonicWall TSA:

1
Double-click the SonicWall TSA desktop icon. The SonicWall Terminal Services Agent window displays.

2
On the Settings tab, type the IP address of the firewall into the Appliance IP field.
3
Type the communication port into the Appliance Port field. The default port is 2259, but a custom port can be used instead. This port must be open on the Windows Server system.
4
Type the encryption key into the Shared Secret field. Select the Show Secret checkbox to view the characters and verify correctness. The same shared secret must be configured on the firewall.
5
In the Timeout drop-down list, select the number of seconds that the agent will wait for a reply from the appliance before retrying the notification. The range is 5 to 10 seconds, and the default is 5 seconds.
6
In the Retries drop-down list, select the number of times the agent will retry sending a notification to the appliance when it does not receive a reply. The range is 3 to 10 retries, and the default is 5.
7
To enable full details in log messages, select the Enable Verbose Log checkbox. Do this only to provide extra, detailed information in a trouble shooting report. Avoid leaving this enabled at other times because it may impact performance.
8
Click Apply. A dialog box indicates that the SonicWall TSA service has restarted with the new settings.

Creating a SonicWall TSA Trouble Shooting Report

You can create a trouble shooting report (TSR) containing all current log messages and information about the agent, driver, and system settings to examine or to send to SonicWall Technical Support for assistance.

To create a TSR for the SonicWall TSA:
1
Double-click the SonicWall TSA desktop icon. The SonicWall Terminal Services Agent window displays.
2
Click the Reports tab.

3
To generate the TSR and:
Automatically email it to SonicWall Technical Support, click Send.
Examine it in your default text editor, click View.
Save it as a text file, click Save As.
4
When finished, click Close.
Viewing SonicWall TSA Status and Version
To display the current status of the SonicWall TSA service on your Windows Server system, or to view the version number of the SonicWall TSA:
1
Double-click the SonicWall TSA desktop icon. The SonicWall Terminal Services Agent window displays.
2
Click the About tab.

3
Click Close.

Single Sign-On Advanced Features

Topics:  
Overview

When a user first tries to send traffic through a SonicWall that is using SSO, the appliance sends a “who is this” request to SonicWall SSO Agent. The agent queries the user’s PC via Windows networking, and returns the user name to the firewall. If the user name matches any criteria set in the policies, then the user is considered as “logged on” by the SonicWall. When users are logged into the SonicWall using SSO, the SSO feature also provides detection of logouts. To detect logouts, the appliance repeatedly polls the agent to check if each user is still logged in. This polling, along with the initial identification requests, could potentially result in a large loading on the SonicWall SSO Agent application and the PC on which it is running, especially when very large numbers of users are connecting.

The SonicWall SSO feature utilizes a rate-limiting mechanism to prevent the appliance from swamping the agent with these user requests. Both automatic calculations and a configurable setting on the appliance govern how this rate-limiting operates. The SonicWall SSO feature automatically calculates the maximum number of user requests contained in each message to the agent that can be processed in the poll period, based on recent polling response times. Also, the timeout on a multi-user request is automatically set to be long enough to reduce the likelihood of an occasional long timeout during polling. The configurable setting controls the number of requests to send to the agent at a time, and can be tuned to optimize SSO performance and prevent potential problems. This section provides a guide to choosing suitable settings.

The potential for problems resulting from overloading the agent can be reduced by running the agent on a dedicated high-performance PC, and possibly also by using multiple agents on separate PCs, in which case the load will be shared between them. The latter option also provides redundancy in case one of the agent PCs fails. The agent should run on a Windows Server PC (some older workstations could be used but changes in later Windows 2000/XP/Vista workstation releases and in service packs for the older versions added a TCP connection rate limiting feature that interferes with operation of the SSO agent).

About the Advanced Settings

The Maximum requests to send at a time setting is available on the Advanced tab of the SSO agent configuration.

This setting controls the maximum number of requests that can be sent from the appliance to the agent at the same time. The agent processes multiple requests concurrently, spawning a separate thread in the PC to handle each. Sending too many requests at a time can overload the PC on which the agent is running. If the number of requests to send exceeds the maximum, then some are placed on an internal “ring buffer” queue (see Using the Single Sign-On Statistics in the TSR and Viewing SSO Mouseover Statistics and Tooltips). Requests waiting on the ring buffer for too long could lead to slow response times in SSO authentication.

This setting works in conjunction with the automatically calculated number of user requests per message to the agent when polling to check the status of logged in users. The number of user requests per message is calculated based on recent polling response times. SonicOS adjusts this number as high as possible to minimize the number of messages that need to be sent, which reduces the load on the agent and helps reduce network traffic between the appliance and the agent. However, the number is kept low enough to allow the agent to process all of the user requests in the message within the poll period. This avoids potential problems such as timeouts and failures to quickly detect logged out users.

Viewing SSO Mouseover Statistics and Tooltips

The SSO Configuration page provides mouseover statistics about each agent, and mouseover tooltips for many fields. On the Settings tab, a green LED-style icon next to an agent indicates that the agent is up and running. A red LED icon indicates that the agent is down.

To view the statistics for a particular agent, hover your mouse pointer over the Statistics icon to the right of the SSO agent. This also works for individual TSAs on the Terminal Services tab.

To view the statistics for all SSO activity on the appliance, hover your mouse pointer over the Statistics icon at the bottom of the table, in the same row as the Add button.

To close the statistics display, click close.

To clear all the displayed values, click Click to reset.

To view the tooltips available for many fields in the SSO configuration screens, hover your mouse pointer over the triangular icon to the right of the field. The tooltip will display until you move your mouse pointer away.

Using the Single Sign-On Statistics in the TSR

A rich set of SSO performance and error statistics is included in the trouble shooting report (TSR). These can be used to gauge how well SSO is performing in your installation. Download the TSR on the System > Diagnostics page and search for the title, SSO operation statistics. The following are the counters to look at in particular:

1
Under SSO ring buffer statistics, look at Ring buffer overflows and Maximum time spent on ring. If the latter approaches or exceeds the polling rate, or if any ring buffer overflows are shown, then requests are not being sent to the agent quickly enough. Also, if the Current requests waiting on ring is constantly increasing, that would indicate the same. This means that the Maximum requests to send at a time value should be increased to send requests faster. However, that will increase the load on the agent, and if the agent cannot handle the additional load, then problems will result, in which case it may be necessary to consider moving the agent to a more powerful PC or adding additional agents.
2
Under SSO operation statistics, look at Failed user id attempts with time outs and Failed user id attempts with other errors. These should be zero or close to it – significant failures shown here indicate a problem with the agent, possibly because it cannot keep up with the number of user authentications being attempted.
3
Also under SSO operation statistics, look at the Total users polled in periodic polling, User polling failures with time outs, and User polling failures with other errors. Seeing some timeouts and errors here is acceptable and probably to be expected, and occasional polling failures will not cause problems. However, the error rate should be low (an error rate of about 0.1% or less should be acceptable). Again, a high failure rate here would indicate a problem with the agent, as above.
4
Under SSO agent statistics, look at the Avg user ID request time and Avg poll per-user resp time. These should be in the region of a few seconds or less – something longer indicates possible problems on the network. Note, however, that errors caused by attempting to authenticate traffic from non-Windows PCs via SSO (which can take a significantly long time) can skew the Avg user ID request time value, so if this is high but Avg poll per-user resp time looks correct, that would indicate the agent is probably experiencing large numbers of errors, likely due to attempting to authenticate non-Windows devices – see Step 6.
5
If using multiple agents, then also under SSO agent statistics look at the error and timeout rates reported for the different agents, and also their response times. Significant differences between agents could indicate a problem specific to one agent that could be addressed by upgrading or changing settings for that agent in particular.
6
Traffic from devices other than PCs can trigger SSO identification attempts and that can cause errors and/or timeouts to get reported in these statistics. This can be avoided by configuring an address object group with the IP addresses of such devices, and doing one or both of the following:
If using Content Filtering, select that address object with the Bypass the Single Sign On process for traffic from setting on the Enforcement tab of the SSO configuration dialog.
If access rules are set to allow only authenticated users, set separate rules for that address object with Users Allowed set to All.

To identify the IP addresses concerned, look in the TSR and search for “IP addresses held from SSO attempts”. This lists SSO failures in the preceding period set by the Hold time after failure setting.

* 
NOTE: If any of the listed IP addresses are for are Mac/Linux PCs, see Accommodating Mac and Linux Users.

To limit the rate of errors due to this you can also extend the Hold time after failure setting on the Users tab.

Examining the Agent

If the above statistics indicate a possible problem with the agent, a good next step would be to run Windows Task Manager on the PC on which the agent is running and look at the CPU usage on the Performance tab, plus the CPU usage by the “CIAService.exe” process on the Processes tab. If the latter is using a large percentage of the CPU time and the CPU usage is spiking close to 100%, this is an indication that the agent is getting overloaded. To try to reduce the loading you can decrease the Maximum requests to send at a time setting; see Using the Single Sign-On Statistics in the TSR above, Step 1.

Remedies

If the settings cannot be balanced to avoid overloading the agent’s PC while still being able to send requests to the agent fast enough, then one of the following actions should be taken:

Consider reducing the polling rate configured on the Users tab by increasing the poll time. This will reduce the load on the agent, at the cost of detecting logouts less quickly. Note that in an environment with shared PCs, it is probably best to keep the poll interval as short as possible to avoid problems that could result from not detecting logouts when different users use the same PC, such as the initial traffic from the second user of a PC possibly being logged as sent by the previous user.
Move the agent to a higher-performance, dedicated PC.
Configure an additional agent or agents.

Configuring Firewall Access Rules

Enabling SonicWall SSO affects policies on the Firewall > Access Rules page of the SonicOS management interface. Rules set under Firewall > Access Rules are checked against the user group memberships returned from a SSO LDAP query, and are applied automatically.

Topics:  
Automatically Generated Rules for SonicWall SSO

When a SonicWall SSO agent or TSA is configured in the SonicOS management interface, a Firewall access rule and corresponding NAT policy are created to allow the replies from the agent into the LAN. These rules use either a SonicWall SSO Agents or SonicWall Terminal Services Agents address group object, which has a member address object for each configured agent. The member address objects are automatically added to and deleted from the group object as agents are added or deleted. The member address objects are also updated automatically as an agent’s IP address changes, including when an IP address is resolved via DNS (where an agent is given by DNS name).

If SonicWall SSO agents or TSAs are configured in different zones, the Firewall access rule and NAT policy are added to each applicable zone. The same SonicWall SSO Agents or SonicWall Terminal Services Agents address group is used in each zone.

* 
NOTE: Do not enable Guest Services in the same zone where SonicWall SSO is being used. Enabling Guest Services will disable SSO in that zone, causing users who have authenticated via SSO to lose access. Create a separate zone for Guest Services.
Accommodating Mac and Linux Users

Mac and Linux systems do not support the Windows networking requests that are used by the SonicWall SSO agent, but can use Samba 3.5 or newer to work with SonicWall SSO.

Using SSO on Mac and Linux With Samba

For Windows users, SonicWall SSO is used by a firewall to automatically authenticate users in a Windows domain. It allows the users to get access through the appliance with correct filtering and policy compliance without the need to identify themselves via any additional login process after their Windows domain login.

Samba is a software package used by Linux/Unix or Mac machines to give their users access to resources in a Windows domain (via Samba’s smbclient utility) and/or to give Windows domain users access to resources on the Linux or Mac machine (via a Samba server).

A user working on a Linux PC or Mac with Samba in a Windows domain can be identified by SonicWall SSO, but it requires proper configuration of the Linux/Mac machine, the SSO Agent, and possibly some reconfiguration of the appliance. For example, the following configuration is necessary:

To use SonicWall SSO with Linux/Mac users, the SonicWall SSO Agent must be configured to use NetAPI rather than WMI to get the user login information from the user's machine.
For Samba to receive and respond to the requests from the SonicWall SSO Agent, it must be set up as a member of the domain and the Samba server must be running and properly configured to use domain authentication.

These and other configuration details are described in the Using Single Sign-on with Samba technote.

SonicWall SSO is supported by Samba 3.5 or newer.

* 
NOTE: If multiple users log into a Linux PC, access to traffic from that PC is granted based on the most recent login.
Using SSO on Mac and Linux Without Samba

Without Samba, Mac and Linux users can still get access, but will need to log in to the firewall to do so. This can cause the following problems:

Traffic from Mac or Linux systems might keep triggering SSO identification attempts unless the user logs in. This could potentially be a performance overhead to the SSO system if there are a large number of such systems, although the effect would be somewhat mitigated by the “hold after failure” timeout.
If per-user Content Filtering (CFS) policies are used without policy rules with user level authentication, the default CFS policy will be applied to users of Mac and Linux systems unless they manually log in first.
If policy rules are set requiring user level authentication, Web browser connections from users of Mac and Linux systems will be redirected to the login page after the SSO failure, but the failure may initiate a timeout that would cause a delay for the user.

To avoid these problems, the Don't invoke Single Sign On to Authenticate Users checkbox is available when configuring Firewall access rules by clicking Add on the Firewall > Access Rules page. This checkbox is visible only when SonicWall SSO is enabled. If this checkbox is selected, SSO is not attempted for traffic that matches the rule, and unauthenticated HTTP connections that match it are directed straight to the login page. Typically, the Source drop-down menu would be set to an address object containing the IP addresses of Mac and Linux systems.

In the case of CFS, a rule with this checkbox enabled can be added “in front of” CFS so that HTTP sessions from Mac and Linux systems are automatically redirected to log in, avoiding the need for these users to log in manually.

* 
NOTE: Do not select the Don't invoke Single Sign On to Authenticate Users option for use with devices that are allowed to bypass the user authentication process entirely. Any devices that may be affected by an access rule when this option is enabled must be capable of logging in manually. A separate access rule should be added for such devices, with Users Allowed set to All.
Allowing ICMP Pings from a Terminal Server

In Windows, outgoing ICMP pings from users on the Terminal Server are not sent via a socket and so are not seen by the TSA, and hence the appliance will receive no notifications for them. Therefore, if firewall rules are using user level authentication and pings are to be allowed through, you must create separate access rules to allow them from “All”.

About Firewall Access Rules

Firewall access rules provide the administrator with the ability to control user access. Rules set under Firewall > Access Rules are checked against the user group memberships returned from a SSO LDAP query, and are applied automatically. Access rules are network management tools that allow you to define inbound and outbound access policy, configure user authentication, and enable remote management of the firewall. The SonicOS Firewall > Access Rules page provides a sortable access rule management interface.

* 
NOTE: More specific policy rules should be given higher priority than general policy rules. The general specificity hierarchy is source, destination, service. User identification elements, for example, user name and corresponding group permissions, are not included in defining the specificity of a policy rule.

By default, the firewall’s stateful packet inspection allows all communication from the LAN to the Internet, and blocks all traffic to the LAN from the Internet.

Additional network access rules can be defined to extend or override the default access rules. For example, access rules can be created that block certain types of traffic such as IRC from the LAN to the WAN, or allow certain types of traffic, such as Lotus Notes database synchronization, from specific hosts on the Internet to specific hosts on the LAN, or restrict use of certain protocols such as Telnet to authorized users on the LAN.

* 
CAUTION: The ability to define network access rules is a powerful tool. Using custom access rules can disable firewall protection or block all access to the Internet. Use caution when creating or deleting network access rules.

For detailed information about access rules, see Firewall > Access Rules.

Managing SonicOS with HTTP Login from a Terminal Server

The firewall normally grants access through policies based on authentication credentials supplied via HTTP login for one user at an IP address. For users on a terminal server, this method of authenticating one user per IP address is not possible. However, HTTP login is still allowed from a terminal server only for the purpose of administration of the appliance, subject to the following limitations and requirements:

Internet access from the terminal server is controlled from the TSA, and HTTP login does not override that — a user on a terminal server is not granted any access through the appliance based on credentials supplied via HTTP login.
HTTP login from a terminal server is allowed only for the built-in admin account and other user accounts with administrator privileges. An attempt to log in with a non-administrative account will fail with the error, Not allowed from this location.
On successful HTTP login, an administrative user is taken straight to the management interface. The small User Login Status page is not displayed.
The administrative user account used for HTTP login from the terminal server does not need to be the same user account that was used for login to the terminal server. It is shown on the appliance as an entirely separate login session.
Only one user at a time can manage the appliance from a given terminal server. If two users attempt to do so simultaneously, the most recently logged in user takes precedence, and the other user will see the error, This is not the browser most recently used to log in.
On a failure to identify a user due to communication problems with the TSA, an HTTP browser session is not redirected to the Web login page (as happens on a failure in the SSO case). Instead, it goes to a new page with the message, The destination that you were trying to reach is temporarily unavailable due to network problems.

Viewing and Managing SSO User Sessions

This section provides information to help you manage SSO on your firewall. See the following sections:

Logging Out SSO Users

The Users > Status page displays Active User Sessions on the firewall. The table lists User Name, IP Address, Session Time, Time Remaining, Inactivity Remaining, Settings, and Logout. For users authenticated using SonicWall SSO Agent, the message Auth. by SSO Agent will display. To logout a user, click the Delete icon next to the user’s entry.

* 
NOTE: Changes in a user’s settings, configured under Users > Settings, will not be reflected during that user’s current session; you must manually log the user out for changes to take effect. The user will be transparently logged in again, with the changes reflected.
Configuring Additional SSO User Settings

The Users > Settings page provides configuration options for user session settings, global user settings, and acceptable use policy settings, in addition to SSO and other user login settings.

The Enable login session limit and corresponding Login session limit (minutes) settings under User Session Settings apply to users logged in using SSO. SSO users are logged out according to session limit settings, but will be automatically and transparently logged back in when they send further traffic.

* 
NOTE: Do not set the login session limit interval too low. This could potentially cause performance problems, especially for deployments with many users.

Changes applied in the Users > Settings page during an active SSO session are not reflected during that session.

* 
TIP: You must log the user out for changes to take effect. The user will immediately and automatically be logged in again, with the changes made.
Viewing SSO and LDAP Messages with Packet Monitor

The Packet Monitor feature available on System > Packet Monitor provides two checkboxes to enable capture of decrypted messages to and from the SSO agent, and decrypted LDAP over TLS (LDAPS) messages.

Capturing SSO Messages
To capture decrypted messages to or from the SSO authentication agent:
1
Click the Configuration button in the System > Packet Monitor page
2
Click the Advanced Monitor Filter tab
3
Select the Monitor intermediate Packets checkbox.
4
Select the Monitor intermediate decrypted Single Sign On agent messages checkbox.

5
Click OK.

The packets are marked with (sso) in the ingress/egress interface field. They have dummy Ethernet, TCP, and IP headers, so some values in these fields may not be correct.

This enables decrypted SSO packets to be fed to the packet monitor, but any monitor filters are still applied to them.

Captured SSO messages are displayed fully decoded on the System > Packet Monitor page.

Capturing LDAP Over TLS Messages
To capture decrypted LDAP over TLS (LDAPS) packets:
1
Click the Configuration button in the System > Packet Monitor page.
2
Click the Advanced Monitor Filter tab.
3
Select the Monitor intermediate Packets checkbox.
4
Select the Monitor intermediate decrypted LDAP over TLS packets checkbox.

5
Click OK.

The packets are marked with (ldp) in the ingress/egress interface field. They have dummy Ethernet, TCP, and IP headers, so some values in these fields may not be correct. The LDAP server port is set to 389 so that an external capture analysis program (such as Wireshark) will know to decode these packets as LDAP. Passwords in captured LDAP bind requests are obfuscated. The LDAP messages are not decoded in the Packet Monitor display, but the capture can be exported and displayed in WireShark to view them decoded.

This enables decrypted LDAPS packets to be fed to the packet monitor, but any monitor filters are still applied to them.

* 
NOTE: LDAPS capture only works for connections from the firewall’s LDAP client, and does not display LDAP over TLS connections from an external LDAP client that pass through the firewall.

Configuring Multiple Administrator Support

Topics:  

Configuring Additional Administrator User Profiles

1
While logged in as admin, navigate to the Users > Local Users page.
2
Click the Add User button. The Add User dialog displays.

3
Enter a Name and Password for the user.
4
Click on the Groups tab.

5
Select the appropriate group to give user Administrator privileges:
Limited Administrators - The user has limited administrator configuration privileges.
SonicWall Administrators - The user has full administrator configuration privileges.
SonicWall Read-Only Admins - The user can view the entire management interface, but cannot make any changes to the configuration.
6
Click the right arrow button.\
7
Click OK.
8
To configure the multiple administrator feature such that administrators are logged out when they are preempted, navigate to the System > Administration page.
9
In the Multiple Administrators section, select the Log out radio button for the On preemption by another administrator option.
10
Click Accept.

Configuring Administrators Locally when Using LDAP or RADIUS

When using RADIUS or LDAP authentication, if you want to ensure that some or all administrative users will always be able to manage the appliance, even if the RADIUS or LDAP server becomes unreachable, then you can use the RADIUS + Local Users or LDAP + Local Users option and configure the accounts for those particular users locally.

For users authenticated by RADIUS or LDAP, create user groups named SonicWall Administrators and/or SonicWall Read-Only Admins on the RADIUS or LDAP server (or its back-end) and assign the relevant users to those groups.

* 
NOTE: For RADIUS, you will probably need special configuration of the RADIUS server to return the user group information.
To configure administrators when using LDAP or RADIUS:
1
Navigate to the Users > Settings page.

2
Select either the RADIUS + Local Users or LDAP + Local Users authentication method.
3
Click the Configure button.
4
For RADIUS, click on the RADIUS Users tab and select the Local configuration only radio button and ensure that the Memberships can be set locally by duplicating RADIUS user names checkbox is checked.
5
For LDAP, click on the LDAP Users tab and select the User group membership can be set locally by duplicating LDAP user names checkbox.
6
Then create local user accounts with the user names of the administrative users (note no passwords need be set here) and add them to the relevant administrator user groups.

Preempting Administrators

When an administrator attempts to log in while another administrator is logged in, the following message is displayed. The message displays the current administrator’s user name, IP address, phone number (if it can be retrieved from LDAP), and whether the administrator is logged in using the GUI or CLI.

This window gives you three options:

Continue - Preempts the current administrator. The current administrator is dropped to non-config mode and you are given full administrator access.
Non-config - You are logged into the appliance in non-config mode. The current administrator’s session is not disturbed.
Cancel - Returns to the authentication screen.

Activating Configuration Mode

When logging in as a user with administrator rights (that is, not the admin user), the User Login Status popup window is displayed.

To go to the SonicWall user interface, click the Manage button. You will be prompted to enter your password again. This is a safeguard to protect against unauthorized access when administrators are away from their computers and do not log out of their session.

Disabling the User Login Status Popup

You can disable the User Login Status popup window if you prefer to allow certain users to log in solely for the purpose of managing the appliance, rather than for privileged access through the appliance. To disable the popup window, select the Members go straight to the management UI on web login checkbox when adding or editing the local group.

If you want some user accounts to be administrative only, while other users need to log in for privileged access through the appliance, but also with the ability to administer it (that is, some go straight to the management interface on login, while others get the User Login Status popup dialog with a Manage button), this can be achieved as follows:

1
Create a local group with the Members go straight to the management UI on web login checkbox selected.
2
Add the group to the relevant administrative group, but do not select this checkbox in the administrative group.
3
Add those user accounts that are to be administrative-only to the new user group. The User Login Status popup window is disabled for these users.
4
Add the user accounts that are to have privileged and administrative access directly to the top-level administrative group.
To switch from non-config mode to full configuration mode,:
1
Navigate to the System > Administration page.

2
In the Web Management Settings section, click on the Configuration mode button. If there is not currently an administrator in configuration mode, you will automatically be entered into configuration mode.
3
If another administrator is in configuration mode, the following message displays.

4
Click the Continue button to enter configuration mode. The current administrator is converted to read-only mode and you are given full administrator access.

Verifying Multiple Administrators Support Configuration

User accounts with administrator and read-only administrators can be viewed on the Users > Local Groups page.

Administrators can determine which configuration mode they are in by looking at either the top right corner of the management interface or at the status bar of their browser.

To display the status bar in Firefox and Internet Explorer, click on the View menu and enable status bar. By default, Internet Explorer 7.0 and Firefox 2.0 do not allow Web pages to display text in the status bar. To allow status bar messages in Internet Explorer, go to Tools > Internet Options, select the Security tab, click on the Custom Level button, scroll to the bottom of the list, and select Enable for Allow Status Bar Updates Via Script.

To allow status bar messages in Firefox, go to Tools > Options, select the Content tab, click the Advanced button, and select the checkbox for Change Status Bar Text in the pop-up window that displays.

When the administrator is in full configuration mode, no message is displayed in the top right corner and the status bar displays Done.

When the administrator is in read-only mode, the top right corner of the interface displays Read-Only Mode.

The status bar displays Read-only mode - no changes can be made.

When the administrator is in non-config mode, the top right of the interface displays Non-Config Mode. Clicking on this text links to the System > Administration page where you can enter full configuration mode.

The status bar displays Non-config mode - configuration changes not allowed.

Viewing Multiple Administrator Related Log Messages

Log messages are generated for the following events:

A GUI or CLI user begins configuration mode (including when an admin logs in).
A GUI or CLI user ends configuration mode (including when an admin logs out).
A GUI user begins management in non-config mode (including when an admin logs in and when a user in configuration mode is preempted and dropped back to read-only mode).
A GUI user begins management in read-only mode.

A GUI user terminates either of the above management sessions (including when an admin logs out).

Viewing Users Status

Users > Status

 

The Users > Status page displays the Active User Sessions on the firewall.

The Active User Sessions section lists the User Name, IP Address, Session Time, Time Remaining, Inactivity Remaining, Settings, and Logout.

To log a user out do one of the following:

Click the Logout icon in the Logout column for that user.
Click the checkbox for each user you wish to log out, then click the Logout Selected Users button.
Select the Include inactive users checkbox to display SSO-authenticated users who have been aged-out due to inactivity and put into the inactive state to conserve system resources, rather than being logged out. These users are shown in grey text.
Display a pop-up window showing the privileges of a user by hovering the mouse over the Comment icon for that user in the Settings column.

 

Display a table of User Counts statistics by clicking on the Statistics icon.
Search for users by specifying one or more full or partial user names, domains, IP addresses, and/or types of user in the filter field, then click the Filter button. The basic syntax for combining strings is “a,b” to include users that match either a or b, and “a;b” to include users that match both a and b. To exclude a user, use an exclamation point (bang: !). The filter can contain:
Simple strings: bob     192.1.1.1     mydomain
More complex syntax:
name=bob     domain=mydomain     ip=192.1.1.1     type=config mode
user-num=1
name=bob,john,sue     ip=192.1.1.1,192.1.1.2 ip=192.1.1.0/24     type=sso,web
name=bob;ip=192.1.1.1     type=sso;netapi type=sso;
from logs on domain controller 192.1.1.10
!name=bob     !ip=192.1.1.1

IPv6 addresses are supported, but currently only for full matching:

ip-2012::1     !ip=2012::1
combinations of those described above.
Select the Show unauthenticated users checkbox to display information about users who have attempted to send traffic through this appliance, but could not be identified or authenticated. The Unauthenticated Users table lists the IP Address, Reason, User Name if Known, and Time of Last Access.

 

Configuring Authentication Settings

Users > Settings

On this page, you can configure the authentication method required, global user settings, and an acceptable user policy that is displayed to users when logging onto your network.

Topics:  

Configuring Authentication and Login Settings

Configuration instructions for the settings on this page are provided in the following sections:

* 
NOTE: When you have finished configuring the Users > Settings page, click the Accept button at the top of the page.

User Authentication Settings

To configure user authentication settings:
1
From the User Authentication method drop-down menu, select the type of user account management your network uses:
Local Users to configure users in the local database in the firewall using the Users > Local Users and Users > Local Groups pages.

For information about using the local database for authentication, see Using Local Users and Groups for Authentication.

For detailed configuration instructions, see the following sections:

RADIUS if you have more than 1,000 users or want to add an extra layer of security for authenticating the user to the firewall. If you select RADIUS for user authentication, users must log into the firewall using HTTPS in order to encrypt the password sent to the firewall. If a user attempts to log into the firewall using HTTP, the browser is automatically redirected to HTTPS.

RADIUS may be required in addition to LDAP in a number of cases:

LDAP does not usually support CHAP/MS-CHAP authentication (Microsoft Active Directory and Novell eDirectory do not), so the SonicWall authenticates CHAP/MS-CHAP via RADIUS if that is the case and RADIUS is configured.
If NTLM is used for SSO, it can only be authenticated via RADIUS in MS-CHAP mode.
RADIUS may be required for CHAP/MS-CHAP with L2TP servers or with VPN or SSL VPN clients, including NetExtender and Portal, or if it may be required for NTLM.
* 
NOTE: LDAP is generally still used for non-CHAP authentications when RADIUS is used for CHAP.

For information about using a RADIUS database for authentication, see Using RADIUS for Authentication.

For detailed configuration instructions, see Configuring RADIUS Authentication.

RADIUS + Local Users if you want to use both RADIUS and the firewall local user database for authentication.
LDAP if you use a Lightweight Directory Access Protocol (LDAP) server, Microsoft Active Directory (AD) server, or Novell eDirectory to maintain all your user account data.

For information about using an LDAP database for authentication, see Using LDAP/Active Directory/eDirectory Authentication.

For detailed configuration instructions, see Integrating LDAP into the SonicWall Appliance.

LDAP + Local Users if you want to use both LDAP and the firewall local user database for authentication.
2
For Single-sign-on method, select one of the following:
* 
NOTE: Do not select any of these options if you are not using Single Sign-On to authenticate users.
SonicWall SSO Agent if you are using Active Directory for authentication and the SSO Agent is installed on a computer in the same domain. For detailed SSO configuration instructions, see Single Sign-On Overview.
Terminal Services Agent if you are using Terminal Services and the Terminal Services Agent (TSA) is installed on a terminal server in the same domain.
Browser NTLM authentication only if you want to authenticate Web users without using the SSO Agent or TSA. Users are identified as soon as they send HTTP traffic. NTLM requires RADIUS to be configured (in addition to LDAP, if using LDAP), for access to MSCHAP authentication. If LDAP is selected above, a separate Configure button for RADIUS appears here when NTLM is selected.
RADIUS Accounting if you want a network access server (NAS) to send user login session accounting messages to an accounting server.
3
Select Case-sensitive user names to enable matching based on capitalization of user account names.
4
Select Enforce login uniqueness to prevent the same user name from being used to log into the network from more than one location at a time. This setting applies to both local users and RADIUS/LDAP users, but it does not apply to the default administrator with the username, admin. This setting is not selected by default.
5
To make users log in after changing their passwords, select the Force relogin after password change checkbox. This setting is not selected by default.
6
To display user login information since the last log in, select the Display user login info since last login checkbox. This checkbox is not selected by default.

If this option is enabled, user login information—including last successful login timestamp, number of all user successful login attempts, unsuccessful login attempts, and administrator privilege changes—are displayed in the System Messages section of System > Status.

7
Configure the following One-Time Password options:
One-time password Email format – Select either Plain text or HTML.
One Time Password Format – Select Characters (default), Characters+Numbers, or Numbers from the drop-down menu.
* 
TIP: The format selection along with the two values for password length result in a password strength of Poor, Good, or Excellent. The strongest passwords have long lengths and either Characters or Characters+Numbers format; The weakest password strength is the Numbers format regardless of length.
At One Time Password Length, enter the minimum length in the first field and the maximum length in the second field. The minimum and maximum must be within the range of 4 to 14, with a default value of 10 for each field. The minimum length cannot be greater than the maximum length.

User Web Login Settings

 

To configure user web login settings:
1
In the Show user authentication page for (minutes) field, enter the number of minutes that users have to log in with their username and password before the login page times out. If it times out, a message displays informing them what they must do before attempting to log in again. The default time is 1 minute.

While the login authentication page is displayed, it uses system resources. By setting a limit on how long a login can take before the login page is closed, you free up those resources.

2
From the Redirect the browser to this appliance via radio buttons, select one of the following options to determine how a user’s browser is initially redirected to the SonicWall appliance’s Web server:
The interface IP address – Select this to redirect the browser to the IP address of the appliance Web server interface. This option is selected by default.
Its domain name from a reverse DNS lookup of the interface IP address – Enables the Show Cache button which, when clicked, displays the appliance Web server’s Interface, IP Address, DNS Name, and TTL (in seconds). This option is not selected by default.

Click the Show Cache button to verify the domain name (DNS name) being used for redirecting the user’s browser. Click close to close the display.

Its configured domain name – Select to enable redirecting to a domain name configured on the System > Administration page.
* 
NOTE: This option is available only if a domain name has been specified on the System > Administration page. Otherwise, this option is dimmed.
The name from the administration certificate – Select to enable redirecting to a configured domain name with a properly signed certificate. Redirecting to the name from this administration certificate is allowed when an imported certificate has been selected for HTTPS web management on that page.
* 
NOTE: This option is available only if a certificate has been imported for HTTPS management in the Web Management Settings section of the System > Administration page. See Web Management Settings.
* 
TIP: If you are using imported administration certificates, use this option. If you are not going to use an administration certificate, select the Its configured domain name option.

To do HTTPS management without the browser displaying invalid-certificate warnings, you need to import a certificate properly signed by a certification authority (administration certificate) rather than use the internally generated self-signed one. This certificate must be generated for the appliance and its host domain name. A properly signed certificate is the best way to obtain an appliance’s domain name.

If you use an administration certificate, then to avoid certificate warnings, the browser needs to redirect to that domain name rather than to the IP address. For example, if you browse the internet and are redirected to log in at https://gateway.sonicwall.com/auth.html, the administration certificate on the appliance says that the appliance really is gateway.sonicall.com, so the browser displays the login page. If you are redirected to https://10.0.02/auth.html, however, even though the certificate says it is gateway.sonicall.com, the browser has no way to tell if that is correct, so it displays a certificate warning instead.

3
To limit redirections to the login page enter the number of times in the Limit redirecting users to times per minute per user field. The default value is 10 times.

Limiting redirections prevents possibly overloading the SonicWall appliances’ web server by limiting redirections to the login page should HTTP/HTTPS connections that would otherwise get redirected there be repeatedly opened at a high rate from some unauthorized users.

a
To further limit redirects of the same page, select the Don’t redirect repeated gets of the same page checkbox. This option is selected by default.
4
Select Redirect users from HTTPS to HTTP on completion of login if you want users to be connected to the network through your firewall via HTTP after logging in via HTTPS. If you have a large number of users logging in via HTTPS, you may want to redirect them to HTTP, because HTTPS consumes more system resources than HTTP. This option is selected by default. If you deselect this option, you will see a warning dialog.
5
Select Allow HTTP login with RADIUS CHAP mode to have a CHAP challenge be issued when a RADIUS user attempts to log in using HTTP. This allows for a secure connection without using HTTPS. Be sure to check that the RADIUS server supports this option. This option is not selected by default.
* 
NOTE: If you log in using this method, you are restricted in the management operations you can perform because some operations require the appliance to know the administrator's password; with CHAP authentication by a remote authentication server, the appliance does not know the password.

If this setting is checked, therefore, any users who are members of administrative user groups may need to manually log in via HTTPS if logging in for administration. This restriction does not apply to the built-in admin account.

* 
NOTE: When using LDAP, this mechanism can normally be used by setting the Authentication method for login to RADIUS and then selecting LDAP as the mechanism for setting user group memberships in the RADIUS configuration.
6
To display a banner containing a policy when the user logs in and that the user must accept to log in, select the Start With Policy Banner Before Login Window checkbox.
a
To see a sample banner, click Example Template. The Policy banner content field is populated.

* 
TIP: The banner can include HTML formatting.
b
Make changes to the sample banner or enter new coding.
c
To see what the banner looks like, click Preview. The PolicyBanner dialog displays.

User Session Settings

To configure settings that apply to all users who are authenticated through the firewall:
1
Specify the length of time for inactivity after which users are logged out of the firewall in the Inactivity timeout (minutes) field. The default is 15 minutes.
2
From the Don’t allow traffic from these services to prevent user logout on inactivity drop-down menu, select the service or service group option to be prevented from logging out inactive users. This option saves system overhead and possible delays re-identifying aged-out authenticated users by making them inactive instead of logging them out. Inactive users do not use up system resources and can be displayed on the Users > Status page. The default is None.
3
For the following For logging of connections on which the user is not identified options, select the type of logging, Log no user name or Log user name, to be done, and optionally, the log user name:
If SSO fails to identify the user: Log user name Unknown SSO failed (default)
For connections that bypass SSO: Log user name SSO Bypass (default)
* 
NOTE: This option also can be set in the SSO Bypass section of the Enforcement tab of the SSO Authentication Configuration dialog.
For connections originating externally: Log no user name (default); if Log user name is selected, the default user name is Unknown (external)
For other unidentified connects: Log no user name (default); if Log user name is selected, the default user name is Unknown
4
Specify how to handle a user’s connections that remain after the user logs out from the SonicWall appliance with the Actions for remaining user connections on logout options.
 

Type of logout

Action

For connections requiring user authentication 1

For other connections 2

On logout due to inactivity

Leave them alive (default)

Terminate them

Terminate after… minutes

Leave them alive (default)

Terminate them

Terminate after… minutes

On active/reported logout

Leave them alive

Terminate them (default)

Terminate after… minutes

Leave them alive

Terminate them

Terminate after… 15 minutes (default)


1
Applies for connections via access rules that allow only specific users.

2
Applies for other connections that do not have a specific user authentication requirement.

You can set different actions for:

Inactivity logout, where the user may or may not still be logged into the domain/computer
Users actively logging themselves out or being reported to the SonicWall appliance as being logged out (the latter normally means that the user has logged out from the domain/user)

User Session Settings for SSO Authenticated Users

To specify how inactive SSO-authenticated users are handled:
1
To put a user identified to the SonicWall appliance via an SSO mechanism, but no traffic has yet been received from the user, into an inactive state so they do not use resources, select the On being notified of a login make the user initially inactive until they send traffic checkbox. The users remain in an inactive state until traffic is received. This option is selected by default.

Some SSO mechanisms do not give any way for the SonicWall appliance to actively re-identify a user, and if users identified by such a mechanism do not send traffic, they remain in the inactive state until the appliance eventually receives a logout notification for the user. For other users who can be re-identified, if they stay inactive and do not send traffic, they are aged-out and removed after a period that can be set in Step 3.

2
If an SSO-identified user who has been actively logged in is timed out due to inactivity, then users who cannot be re-identified are returned to an inactive state. To have users who would otherwise be logged out on inactivity to be returned to an inactive state, select the On inactivity timeout make all user inactive instead of logged out checkbox. Doing this avoids overhead and possible delays re-identifying the users when they become active again. This setting is selected by default.
3
For inactive users who are subject to getting aged out, you can set the time, in minutes, after which they are aged-out and removed if they stay inactive and do not send traffic by selecting the Age out inactive users after (minutes) checkbox and specifying the timeout in the field. This setting is selected by default, and the minimum timeout value is 10 minutes, the maximum is 10000 minutes, and the default is 60 minutes.
* 
NOTE: As the reason for keeping inactive user separate from active users is to minimize the resources used to manage them, the age-out timer runs once every 10 minutes. It may, therefore, take up to 10 minutes longer to remove inactive users from active status.

User Session Settings for Web Login

To configure user session settings for web login:
1
Enable login session limit for web logins: Limit the time a user is logged into the firewall via web login by selecting the checkbox and typing the amount of time, in minutes, in the Login session limit (minutes) field. This setting is selected by default The default value is 30 minutes.
2
Show user login status window — For users logging in via web login, displays a status window with a Log Out button during the user’s session. The user can click the Log Out button to log out of their session.
* 
NOTE: The window must be kept open throughout the user’s session as closing it logs the user out.
* 
IMPORTANT: If this option is not enabled, the status window is not displayed and users may not be able to log out. In this case, a login session limit must be set to ensure that they do eventually get logged out.

The User Login Status window displays the number of minutes the user has left in the login session. The user can set the remaining time to a smaller number of minutes by entering the number and clicking the Update button.

When this option is enabled, a mechanism that monitors heartbeats sent from that window also can be enabled to detect and log out users who disconnect without logging out.

If the user is a member of the SonicWall Administrators or Limited Administrators user group, the User Login Status window has a Manage button the user can click to automatically log into the firewall’s management interface. See Disabling the User Login Status Popup for information about disabling the User Login Status window for administrative users. See Configuring Local Groupsfor group configuration procedures.

User's login status window sends heartbeat every (seconds) Sets the frequency of the heartbeat signal used to detect whether the user still has a valid connection. The minimum heartbeat frequency is 10 seconds, the maximum is 65530 seconds, and the default is 120 seconds.
3
Enable disconnected user detection — Causes the firewall to detect when a user’s connection is no longer valid and ends the session. This setting is selected by default.
Timeout on heartbeat from user's login status window (minutes) — Sets the time needed without a reply from the heartbeat before ending the user session. The minimum delay before ending the user session is 1 minute, the maximum is 65535 minutes, and the default is 10 minutes.
4
Optionally, select to have the user’s login status window display in the same window rather than a popup window by selecting Open user’s login status window in the same window rather than in a popup checkbox.

Other Global User Settings

The specified HTTP URLs bypass users authentication access rules. In this section, you define a list of URLs users can connect to without authenticating.

To add a URL to the list:
1
Click Add below the URL list. The Add URL dialog displays.

2
In the Enter URL field, enter the top-level URL you are adding, for example, www.sonicwall.com. All sub directories of that URL are included, such as www.sonicwall.com/us/Support.html.

3
Click on OK to add the URL to the list. A message displays.

4
Click Accept.

Acceptable Use Policy

An acceptable use policy (AUP) is a policy that users must agree to follow in order to access a network or the Internet. It is common practice for many businesses and educational facilities to require that employees or students agree to an acceptable use policy before accessing the network or Internet through the firewall.

The Acceptable Use Policy section allows you to create the AUP message window for users. You can use HTML formatting in the body of your message. Clicking the Example Template button creates a preformatted HTML template for your AUP window; see Example Template.

Display on login from - Select the network interface(s) you want to display the Acceptable Use Policy page when users login. You can choose Trusted Zones (default), WAN Zone, Public Zones (default), Wireless Zones, and VPN Zone in any combination.
Window size (pixels) - Allows you to specify the size of the AUP window, in pixels.
Checking the Enable scroll bars on the window allows the user to scroll through the AUP window contents. Specify both:
Width: Minimum size is 400 pixels, maximum size is 1280 pixels, and the default is 460 pixels.
Height: Minimum size is 200 pixels, maximum size is 1024 pixels, and he default is 310 pixels.
Enable scroll bars on window - Turns on the scroll bars if your content will exceed the display size of the window. This setting is enabled by default.
Acceptable use policy page content - Enter your Acceptable Use Policy text in this field. You can include HTML formatting. The page that is displayed to the user includes an I Accept button and Cancel button for user confirmation.

Topics:  
Example Template

Click the Example Template button to populate the content with the default AUP template, which you can modify:

<font face=arial size=3>
<center><b><i>Welcome to the SonicWall</center></b></i>
<font size=2>
 
<table width="100%" border="1">
<tr><td>
<font size=2>
<br><br><br>
<center>Enter your usage policy terms here.
<br><br><br>
</td></tr>
</table>
 
Click "I Accept" only if you wish to accept these terms and continue,
or otherwise select "Cancel".
Preview Message

Click the Preview button to display your AUP message as it will appear for the user.

Customize Login Pages

SonicOS provides the ability to customize the text of the login authentication pages that are presented to users. Administrators can translate the login-related pages with their own wording and apply the changes so that they take effect without rebooting.

Although the entire SonicOS interface is available in different languages, sometimes the administrator does not want to change the entire UI language to a specific local language.

However, if the firewall requires authentication before users can access other networks, or enables external access services (for example, VPN, SSL-VPN), those login related pages usually should be localized to make them more usable for typical users.

The Customize Login Page feature provides the following functionality:

Keeps the style of original login by default
Customizes login related pages
Uses the default login related pages as templates
Saves customized pages into system preferences
Allows preview of changes before saving to preferences
Presents customized login-related pages to typical users

The following login-related pages can be customized:

Admin Preempt
Login Authentication
Logged Out
Login Full
Login Disallowed
Login Lockout
Login Status
Guest Login Status
Policy Access Barred
Policy Access Down
Policy Access Unavailable
Policy Login Redirect
Policy SSO Probe Failure
User Password Update
User Login Message
To customize one of these pages:
1
On the Users > Settings page, scroll down to the Customize Login Pages section.
2
Select the page to be customized from the Select Login Page drop-down menu.
3
Scroll to the bottom of the page and click Default to load the default content for the page.
4
Edit the content of the page.
* 
NOTE: The "var strXXX =" lines in the template pages are customized JavaScript Strings. You can change them into your preferring wording. Modifications should follow the JavaScript syntax. You can also edit the wording in the HTML section.
5
Click Preview to preview how the customized page will look.
6
When you are finished editing the page, click Accept.

Leave the Login page content field blank and apply the change to revert to the default page to users.

* 
CAUTION: Be careful to verify the HTML of your custom login page before deploying it, because HTML errors may cause the login page to not function properly. An alternative login page is always available for the administrator, in case a customized login page has any issues. To access the alternate login page, manually input the URL: https://(device_ip)/defauth.html directly into the address line of browser (case sensitive). The default login page without any customization is then displayed, allowing you to login as normal and reset your customized login related pages.

Configuring RADIUS Authentication

* 
NOTE: For configuring RADIUS for SonicPoints, see SonicPoints and RADIUS Accounting and

For an introduction to RADIUS authentication in SonicOS, see Using RADIUS for Authentication. If you selected RADIUS or RADIUS + Local Users from the Authentication method for login drop-down menu on the Users > Settings page, the Configure RADIUS button becomes available.

A separate Configure button for RADIUS is also available if you selected Browser NTLM authentication only from the Single-sign-on method choices. The configuration process is the same.

Topics:  

Configuring RADIUS Settings

To configure RADIUS settings:
1
Navigate to the Users > Settings page.
2
Click Configure RADIUS to set up your RADIUS server settings in SonicOS. The RADIUS Configuration dialog displays.

3
Under Global RADIUS Settings, type in a value for the RADIUS Server Timeout (seconds). The allowable range is 1-60 seconds with a default value of 5.
4
In the Retries field, enter the number of times SonicOS will attempt to contact the RADIUS server. If the RADIUS server does not respond within the specified number of retries, the connection is dropped. This field can range between 0 and 10, with a default setting of 3 RADIUS server retries.
5
In the RADIUS Servers section, designate the primary RADIUS server. In the Primary Server section, type the host name or IP address of the RADIUS server in the Name or IP Address field.
6
Type the RADIUS server administrative password or “shared secret” in the Shared Secret field. The alphanumeric Shared Secret can range from 1 to 31 characters in length. The shared secret is case sensitive.
7
Type the Port Number for the RADIUS server to use for communication with SonicOS. The default is 1812.
8
Optionally, select Send Through VPN tunnel. This option is not selected by default.
9
Optionally, to enforce MS-CHAPv2 RADIUS authentication, select Force PAP to MSCHAPv2. This option is not selected by default.
10
In the Secondary Server section, optionally type the host name or IP address of the secondary RADIUS server in the Name or IP Address field.
11
An optional secondary RADIUS server can be defined if a backup RADIUS server exists on the network. If you have a secondary RADIUS server, repeat Step 5 through Step 9.
12
Either click
OK if you have finished configuring the RADIUS server.
Apply, to continue configuring RADIUS users (see RADIUS Users Tab) and/or testing the settings (see RADIUS Client Test).

RADIUS Users Tab

On the RADIUS Users tab you can specify what types of local or LDAP information to use in combination with RADIUS authentication. You can also define the default user group for RADIUS users.

To configure the RADIUS user settings:
1
Click the RADIUS Users tab.

2
Select Allow only users listed locally if only the users listed in the SonicOS database are authenticated using RADIUS.
3
Select the Mechanism used for setting user group memberships for RADIUS users option:
* 
NOTE: If the Use SonicWall vendor-specific attribute on Radius server or Use RADIUS Filter-ID attribute on RADIUS server options are selected, the RADIUS server must be properly configured to return these attributes to the SonicWall appliance when a user is authenticated. The RADIUS server should return aero (0) or more instances of the selected attribute, each giving the name of a user group to which the user belongs.

For details of the vendor-specific attribute settings, see the tech note, SonicOS Enhanced: Using User Level Authentication, and the SonicOS Enhanced RADIUS Dictionary file, SonicWall.dct. Both are available at https://support.sonicwall.com/.

Use SonicWall vendor-specific attribute on RADIUS server – To apply a configured vendor-specific attribute from the RADIUS server. The attribute must provide the user group to which the user belongs. The preferred vendor-specific RADIUS attribute is SonicWall-User-Group. SonicWall-User-Privilege also works for certain user groups, but it is supported primarily for backwards compatibility and is not governed by the Mechanism for setting user group memberships for RADIUS users setting; that is, it is still effective even if something other than the Use SonicWall vendor-specific attribute on RADIUS server is selected.
Use RADIUS Filter-ID attribute on RADIUS server – To apply a configured Filter-ID attribute from the RADIUS server. The attribute must provide the user group to which the user belongs.
Use LDAP to retrieve user group information (default) – To obtain the user group from the LDAP server. You can click the Configure button to set up LDAP if you have not already configured it or if you need to make a change. For information about configuring LDAP, see Configuring the SonicWall Appliance for LDAP.
Local configuration only – If you do not plan to retrieve user group information from RADIUS or LDAP.
Memberships can be set locally by duplicating RADIUS user names – For a shortcut for managing RADIUS user groups. When you create users with the same name locally on the security appliance and manage their group memberships, the memberships in the RADIUS database automatically change to mirror your local changes.
4
If you have previously configured User Groups in SonicOS, select the group from the Default user group to which all RADIUS users belong drop-down menu. To create a new user group, see Creating a New User Group for RADIUS Users.
5
Either click
OK if you have finished configuring the RADIUS server.
Apply, to continue configuring RADIUS users and/or testing the settings.
Creating a New User Group for RADIUS Users

In the RADIUS User Settings dialog, you can create a new group by choosing Create a new user group... from the Default user group to which all RADIUS users belong drop-down menu. The Add Group dialog displays. For the procedure for creating a new user group, see Creating or Editing a Local Group.

RADIUS with LDAP for User Groups

When RADIUS is used for user authentication, there is an option on the RADIUS Users tab in the RADIUS Configuration dialog to allow LDAP to be selected as the mechanism for setting user group memberships for RADIUS users:

When Use LDAP to retrieve user group information is selected, after authenticating a user via RADIUS, his/her user group membership information will be looked up via LDAP in the directory on the LDAP/AD server.

* 
NOTE: If this mechanism is not selected, and one-time password is enabled, a RADIUS user will be receive a one-time password fail message when attempting to login through SSL VPN.

Clicking the Configure button launches the LDAP Configuration dialog. For more information on configuring LDAP settings, see Preparing Your LDAP Server for Integration.

* 
NOTE: In this case LDAP is not dealing with user passwords and the information that it reads from the directory is normally unrestricted, so operation without TLS could be selected, ignoring the warnings, if TLS is not available (for example, if certificate services are not installed with Active Directory). However, it must be ensured that security is not compromised by SonicOS doing a clear-text login to the LDAP server – for example, create a user account with read-only access to the directory dedicated for SonicOS use. Do not use the administrator account in this case.

RADIUS Client Test

In the RADIUS Configuration dialog, you can test your RADIUS Client user name, password and other settings by typing in a valid user name and password and selecting one of the authentication choices for Test. Performing the test applies any changes you have made.

To test your RADIUS settings:
1
Click the Test tab.

2
In the User field, type a valid RADIUS login name.
3
In the Password field, type the password.
4
For Test, select one of the following:
Password authentication: Select this to use the password for authentication.
CHAP: Select this to use the Challenge Handshake Authentication Protocol. After initial verification, CHAP periodically verifies the identity of the client by using a three-way handshake.
MSCHAP: Select this to use the Microsoft implementation of CHAP. MSCHAP works for all Windows versions before Windows Vista.
MSCHAPv2: Select this to use the Microsoft version 2 implementation of CHAP. MSCHAPv2 works for Windows 2000 and later versions of Windows.
5
Click the Test button. If the validation is successful, the Status messages changes to Success. If the validation fails, the Status message changes to Failure.
6
To complete the RADIUS configuration, click OK.

After SonicOS has been configured, a VPN Security Association requiring RADIUS authentication prompts incoming VPN clients to enter a User Name and Password into a dialog.

Configuring the SonicWall Appliance for LDAP

To manage your LDAP integration:
1
Navigate to the Users > Settings page.
2
In the User Authentication method drop-down menu, select either LDAP or LDAP + Local Users.
3
Click Configure LDAP.
4
If you are connected to your firewall via HTTP rather than HTTPS, a message displays warning you of the sensitive nature of the information stored in directory services and offering to change your connection to HTTPS. If you have HTTPS management enabled for the interface to which you are connected (recommended), click Yes. The LDAP Configuration dialog displays.

 

Topics:  

Settings Tab

To configure the LDAP server settings:
1
Configure the following fields:
Name or IP Address – The FQDN or the IP address of the LDAP server against which you wish to authenticate. If using a name, be certain that it can be resolved by your DNS server. Also, if using TLS with the ‘Require valid certificate from server’ option, the name provided here must match the name to which the server certificate was issued (i.e. the CN) or the TLS exchange will fail.
Port Number – The default LDAP over TLS port number is TCP 636. The default LDAP (unencrypted) port number is TCP 389. If you are using a custom listening port on your LDAP server, specify it here.
Server timeout – The amount of time, in seconds, that SonicOS will wait for a response from the LDAP server before timing out. The range is 1 to 99999, with a default of 10 seconds.
Overall operation timeout – The amount of time, in minutes, to spend on any automatic operation. Some operations, such as directory configuration or importing user groups, can take several minutes, especially when multiple LDAP servers are in use.
Select one of the following radio buttons:
Anonymous Login – Some LDAP servers allow for the tree to be accessed anonymously. If your server supports this (Active Directory generally does not), then you may select this option.
Give login name/location in tree – Select this option to build the distinguished name (dn) that is used to bind to the LDAP server from the Login user name and User tree for login to server fields according to the following rules:
The first name component begins cn=
The ‘location in tree’ components all use ou= (apart from certain Active Directory built-ins that begin with cn=)
The domain components all use dc=
If the User tree for login to server field is given as a dn, you can also select this option if the bind dn conforms to the first bullet above, but not to the second and/or the third bullet.
Give bind distinguished name – Select this option if the bind dn does not conform to the first bullet above (if the first name component does not begin with cn=). This option can always be selected if the dn is known. You must provide the bind dn explicitly if the bind dn does not conform to the first bullet above.
Login user name – Specify a user name that has rights to log in to the LDAP directory. The login name will automatically be presented to the LDAP server in full ‘dn’ notation. This can be any account with LDAP read privileges (essentially any user account); Administrative privileges are not required.
* 
NOTE: This is the user’s name, not their login ID (for example, John Smith rather than jsmith).
Login password – The password for the user account specified above.
Protocol version – Select either LDAPv3 or LDAPv2. Most modern implementations of LDAP, including Active Directory, employ LDAPv3.
Use TLS (SSL) – Use Transport Layer Security (SSL) to log in to the LDAP server. It is strongly recommended that TLS be used to protected the username and password information that will be sent across the network. Most modern implementations of LDAP server, including Active Directory, support TLS. Deselecting this default setting will display an alert that you must accept to proceed.
Send LDAP ‘Start TLS’ Request – Some LDAP server implementations support the Start TLS directive rather than using native LDAP over TLS. This allows the LDAP server to listen on one port (normally 389) for LDAP connections, and to switch to TLS as directed by the client. Active Directory does not use this option, and it should only be selected if required by your LDAP server.
Require valid certificate from server – Validates the certificate presented by the server during the TLS exchange, matching the name specified above to the name on the certificate. Deselecting this default option will present an alert, but exchanges between SonicOS and the LDAP server will still use TLS – only without issuance validation.
Local certificate for TLS – Optional, to be used only if the LDAP server requires a client certificate for connections. Useful for LDAP server implementations that return passwords to ensure the identity of the LDAP client (Active Directory does not return passwords). This setting is not required for Active Directory.

If your network uses multiple LDAP/AD servers with referrals, then select one as the primary server (probably the one that holds the bulk of the users) and use the above settings for that server. It will then refer the SonicOS to the other servers for users in domains other than its own. For SonicOS to be able to log in to those other servers, each server must have a user configured with the same credentials (user name, password and location in the directory) as the login to the primary server. This may entail creating a special user in the directory for the SonicOS login. Note that only read access to the directory is required.

Force PAP to MSCHAPv2 – Optional, to enforce MS-CHAPv2 LDAP authentication select this option. If a RADIUS server is also configured, it provides authentication if LDAP authentication fails. This option is not selected by default.
2
Click Apply.

Schema Tab

To configure the LDAP server schema settings:
1
Click the Schema tab.
2
LDAP Schema – Select one of the following from the LDAP Schema drop-down menu:
* 
NOTE: Selecting any of the predefined schemas automatically populates the fields used by that schema with their correct values. These values cannot be changed and their fields are dimmed.
Microsoft Active Directory
RFC2798 inetOrgPerson
RFC2307 Network Information Service
Samba SMB
Novell eDirectory
User defined – Allows you to specify your own values; use this only if you have a specific or proprietary LDAP schema configuration.
3
Object class – Select the attribute that represents the individual user account to which the next two fields apply.
4
Login name attribute – Select one of the following to define the attribute that is used for login authentication:
sAMAccountName for Microsoft Active Directory
inetOrgPerson for RFC2798 inetOrgPerson
posixAccount for RFC2307 Network Information Service
sambaSAMAccount for Samba SMB
inetOrgPerson for Novell eDirectory
5
Qualified login name attribute – Optionally, select an attribute of a user object that sets an alternative login name for the user in name@domain format. This may be needed with multiple domains in particular, where the simple login name may not be unique across domains.
* 
NOTE: For Microsoft Active Directory, this is normally set to userPrinicpalName for log in using name@domain, but could be set to mail to enable log in by email address. For RFC2798 inetOrgPerson, it is set to mail.
6
User group membership attribute – Select the attribute that contains information about the groups to which the user object belongs. This is memberOf in Microsoft Active Directory. The other predefined schemas store group membership information in the group object rather than the user object, and therefore do not use this field.
7
Framed IP address attribute – Select the attribute that can be used to retrieve a static IP address that is assigned to a user in the directory. Currently it is only used for a user connecting via L2TP with the SonicOS L2TP server. In the future this may also be supported for Global VPN Client. In Active Directory the static IP address is configured on the Dial-in tab of a user’s properties.
8
User Group Objects – This section is auto-configured unless you select User Defined for the LDAP Schema.
Object class – Specify the name associated with the group of attributes.
Member attribute – Specify the attribute associated with a member.
Select whether this attribute is a Distinguished name or User ID.
Read from server – Click to read the user group object information from the LDAP server.
* 
NOTE: You must enter the primary domain on the Directory tab first.
Select whether you want to Automatically update the schema configuration or Export details of the schema.

Directory Tab

To configure the LDAP server directory settings:
1
On the Directory tab, configure the following fields:

Primary Domain – The user domain used by your LDAP implementation. For AD, this will be the Active Directory domain name, for example, yourADdomain.com. Changes to this field will, optionally, automatically update the tree information in the rest of the page. This is set to mydomain.com by default for all schemas except Novell eDirectory, for which it is set to o=mydomain.
User tree for login to server – The tree in which the user specified in the Settings tab resides. For example, in Active Directory the ‘administrator’ account’s default tree is the same as the user tree.
Trees containing users – The trees where users commonly reside in the LDAP directory. One default value is provided which can be edited, and up to a total of 64 DN values may be provided. SonicOS will search the directory using them all until a match is found, or the list is exhausted. If you have created other user containers within your LDAP or AD directory, you should specify them here.
Trees containing user groups – Same as above, only with regard to user group containers, and a maximum of 32 DN values may be provided. These are only applicable when there is no user group membership attribute in the schema's user object, and are not used with AD.
All the above trees are normally given in URL format but can alternatively be specified as distinguished names (for example, myDom.com/Sales/Users could alternatively be given as the DN ou=Users,ou=Sales,dc=myDom,dc=com). The latter form will be necessary if the DN does not conform to the normal formatting rules as per that example. In Active Directory the URL corresponding to the distinguished name for a tree is displayed on the Object tab in the properties of the container at the top of the tree.
* 
NOTE: AD has some built-in containers that do not conform (for example, the DN for the top level Users container is formatted as cn=Users,dc=…, using cn rather than ou) but SonicOS knows about and deals with these, so they can be entered in the simpler URL format.

Ordering is not critical, but since they are searched in the given order it is most efficient to place the most commonly used trees first in each list. If referrals between multiple LDAP servers are to be used, then the trees are best ordered with those on the primary server first, and the rest in the same order that they will be referred.

* 
NOTE: When working with AD, to determine the location of a user in the directory for the User tree for login to server field, the directory can be searched manually from the Active Directory Users and Settings control panel applet on the server, or a directory search utility such as queryad.vbs in the Windows NT/2000/XP Resource Kit can be run from any PC in the domain.
Auto-configure – This causes SonicOS to auto-configure the Trees containing users and Trees containing user groups fields by scanning through the directory/directories looking for all trees that contain user objects. To use auto-configure, first enter a value in the User tree for login to server field (unless anonymous login is set), and then click the Auto-configure button to bring up the following window:

a)
In the Auto Configure dialog, enter the desired domain in the Domain to search field.
b)
Select one of the following:
Append to existing trees – This selection will append newly located trees to the current configuration.
Replace existing trees – This selection will start from scratch removing all currently configured trees first.
2
Click OK.

The auto-configuration process may also locate trees that are not needed for user login. You can manually remove these entries.

If using multiple LDAP/AD servers with referrals, this process can be repeated for each, replacing the Domain to search value accordingly and selecting Append to existing trees on each subsequent run.

Referrals Tab

To configure the LDAP server referrals settings:
1
Click the Referrals tab.

2
Configure the following fields:
Allow referrals – Select this option any time that user information is located on an LDAP server other than the configured primary one.
Allow continuation references during user authentication – Select this option any time that individual directory trees have been manually configured to span multiple LDAP servers.
Allow continuation references during directory auto-configuration – Select this option to allow the trees to be read from multiple LDAP servers in a single operation.
Allow continuation references in domain searches – Select this option when using single-sign-on with users in multiple sub-domains having separate LDAP servers.

Users & Groups Tab

To configure the LDAP users and groups settings:
1
Click the Users & Groups tab.

2
Configure the following fields:
Allow only users listed locally – Requires that LDAP users also be present in the SonicOS local user database for logins to be allowed.
User group membership can be set locally by duplicating LDAP user names – Allows for group membership (and privileges) to be determined by the intersection of local user and LDAP user configurations.
Default LDAP User Group – A default group in SonicOS to which LDAP users will belong in addition to group memberships configured on the LDAP server.
Import users – You can click this button to configure local users in SonicOS by retrieving the user names from your LDAP server. The Import users button launches a dialog box containing the list of user names available for import.

In the LDAP Import Users dialog box, select the checkbox for each user that you want to import into SonicOS, and then click Save selected.

The list of users read from the LDAP server can be quite long, and you might not want to import all of them. A Remove from list button is provided, along with several methods of selecting unwanted users.You can use these options to reduce the list to a manageable size and then select the users to import.

Having users in SonicOS with the same name as existing LDAP users allows SonicWall user privileges to be granted upon successful LDAP authentication.

Import user groups – You can click this button to configure user groups SonicOS by retrieving the user group names from your LDAP server. The Import user groups button launches a dialog box containing the list of user group names available for import to the firewall.

In the LDAP Import User Groups dialog, select the checkbox for each group that you want to import into SonicOS, and then click Save selected.

Having user groups in SonicOS with the same name as existing LDAP/AD user groups allows SonicWall group memberships and privileges to be granted upon successful LDAP authentication.

Alternatively, you can manually create user groups on the LDAP/AD server with the same names as SonicWall built-in groups (such as ‘Guest Services’, ‘Content Filtering Bypass’, ‘Limited Administrators’) and assign users to these groups in the directory. This also allows SonicWall group memberships to be granted upon successful LDAP authentication.

The firewall can retrieve group memberships efficiently in the case of Active Directory by taking advantage of its unique trait of returning a ‘memberOf’ attribute for a user.

LDAP Relay

To configure the LDAP server relay settings:
1
Click the LDAP Relay tab.

The RADIUS to LDAP Relay feature is designed for use in a topology where there is a central site with an LDAP/AD server and a central SonicWall with remote satellite sites connected into it via low-end firewalls that may not support LDAP. In that case the central SonicWall can operate as a RADIUS server for the remote SonicWalls, acting as a gateway between RADIUS and LDAP, and relaying authentication requests from them to the LDAP server.

2
Configure the following fields:
Enable RADIUS to LDAP Relay – Enables this feature.
Allow RADIUS clients to connect via – Check the relevant checkboxes and policy rules will be added to allow incoming RADIUS requests accordingly.
RADIUS shared secret – This is a shared secret common to all remote SonicWalls.
User groups for legacy VPN users – Defines the user group that corresponds to the legacy ‘Access to VPNs’ privileges. When a user in this user group is authenticated, the remote SonicWall is notified to give the user the relevant privileges.
User groups for legacy VPN client users – Defines the user group that corresponds to the legacy ‘Access from VPN client with XAUTH’ privileges. When a user in this user group is authenticated, the remote SonicWall is notified to give the user the relevant privileges.
User groups for legacy L2TP users – Defines the user group that corresponds to the legacy ‘Access from L2TP VPN client’ privileges. When a user in this user group is authenticated, the remote SonicWall is notified to give the user the relevant privileges.
User groups for legacy users with Internet access – Defines the user group that corresponds to the legacy ‘Allow Internet access (when access is restricted)’ privileges. When a user in this user group is authenticated, the remote SonicWall is notified to give the user the relevant privileges.
* 
NOTE: The ‘Bypass filters’ and ‘Limited management capabilities’ privileges are returned based on membership to user groups named ‘Content Filtering Bypass’ and ‘Limited Administrators’ – these are not configurable.

Test Tab

To configure the LDAP server test settings:
1
Select the Test tab to test the configured LDAP settings:

The Test LDAP Settings page allows for the configured LDAP settings to be tested by attempting authentication with specified user and password credentials. Any user group memberships and/or framed IP address configured on the LDAP/AD server for the user are displayed.

Configuring SonicOS to Use the SonicWall SSO Agent

To configure your firewall to use the SonicWall SSO Agent:
1
Go to Users > Settings.
2
In the Single-sign-on method(s) section, select SSO Agent. Use this choice to add and configure a TSA as well as an SSO Agent for the SSO method.

3
Click Configure SSO.The SSO Authentication Configuration dialog displays.
Topics:  
SSO Agents Tab

On the SSO Agents tab under Authentication Agent Settings you can view any SSO Agents already configured:

The green LED next to the Agent’s IP address indicates that the agent is currently up and running.
A red LED would indicate that the agent is down.
A grey LED shows that the agent is disabled.

The LEDs are dynamically updated using AJAX.

1
Click the Add button to create an agent. The page is updated to display a new row in the table at the top, and two new tabs (Settings and Advanced) in the lower half of the page.
* 
TIP: You can modify any of the entries by clicking on it. The entry turns into an editable field.

2
Enter the following information in the Settings tab. As you type in values for the fields, the row at the top is updated in red to highlight the new information.
For Host Name or IP Address, enter the name or IP address of the workstation on which SonicWall SSO Agent is installed. By default, 0.0.0.0 is entered.
At Port, enter the port number that the SonicWall SSO Agent is using to communicate with the appliance. The default port is 2258.
* 
NOTE: Agents at different IP addresses can have the same port number.
At Shared Key, enter the shared key that you created or generated in the SonicWall SSO Agent. The shared key must match exactly. Re-enter the shared key in the Confirm Shared Key field.
At Timeout (seconds), enter a number of seconds before the authentication attempt times out. This field is automatically populated with the default of 10 seconds.
At Retries, enter the number of authentication attempts. The default is 6.
3
Click the Advanced tab.

4
At Maximum requests to send at a time, enter the maximum number of simultaneous requests to send from the appliance to the agent at one time. The default is 32.

The agent processes multiple requests concurrently, spawning a separate thread in the agent PC to handle each. The number of simultaneous requests that the authentication agent can handle depends on the performance level of the PC that it runs on and of the network. Increasing this setting could make SSO user authentication more efficient, but setting it too high could swamp the agent by sending too many requests at a time, thus overloading the PC and resulting in timeouts and authentication failures.

On the other hand, if the number of simultaneous requests sent from the appliance is too low, some requests will have to wait, possibly causing ring buffer overflows. Too many requests waiting could lead to slow response times in Single Sign On authentication. If this setting cannot be increased high enough to avoid ring buffer warnings without getting a significant numbers of timeouts, then consider moving the agent to a higher-performance, dedicated machine, or possibly adding additional agents. For more information about checking for ring buffer overflows and related statistics in the SonicOS TSR, see Single Sign-On Advanced Features.

* 
TIP: Look at the statistics in the Single Sign On Authentication section of the Tech Support Report. If significant numbers of timeouts are shown, then decreasing this value may help. If the Maximum time spent on ring approaches or exceeds the polling rate (configured on the Users tab) or if any ring buffer overflows are shown, then this value should probably be increased.
5
Click the General Settings tab under Authentication Agent Settings.

6
Configure the following options:
Select the Enable SSO agent authentication checkbox to use the SSO Agent for user authentication. This setting is selected by default.
Select the Try next agent on getting no name from NetAPI/WMI checkbox to force a retry of the authentication via a different SSO agent if there is no response or error from the first agent. This setting is not selected by default.
* 
NOTE: This setting affects only agents using NetAPI/WMI, not any agents that use just the domain controller security log lookup mechanism.
* 
IMPORTANT: See also the Poll the same agent that authenticated the user setting on the Users tab, which needs to be set if this setting is enabled.

The NetAPI/WMI protocols used by the SSO agent for user identification are provided by Windows, and what they actually do is outside the control of the agent or appliance. When using NetAPI or WMI, should Windows respond with no user name and no error to a request from an agent, then by default, the appliance assumes that other agents get the same and does not retry the request via another agent (as it would do should it receive an error response).

If you see authentication failures logged as SSO agent returned no user name when you think the users should have been identified, try enabling this setting. If this setting is enabled when the appliance receives a no-user-name response from an agent, the appliance treats the response as an error and retries the request via a different agent.

Typically, enabling this setting is needed in a situation where only some of the agents can reach certain users; for example, if it is necessary to place an agent at a remote site to identify the users there because they cannot be reached easily by the agents at the central site.

Select the Don't block user traffic while waiting for SSO checkbox to use the default policy while the user is being identified. This prevents browsing delays. This setting is not selected by default.

When a user is being identified via SSO, traffic from the user is normally blocked until identification is complete so proper policies can be applied where applicable. Sometimes an SSO agent takes a significant time to identify a user, however, and that delay can result in users experiencing browsing delays.

This setting allows you to override that delay and instead allow users traffic through while waiting for SSO, with default policies applied until the user is identified.

You also can choose whether to allow through traffic when a user needs to be identified for an access rule that requires user authentication (that is, when a user would not otherwise be allowed any access if not identified).

* 
CAUTION: Take care with doing this as it can temporarily allow through a user who would not be allowed when identified. If you choose to do this for selected access rules, then a setting for it appears in the advanced settings of those rules that require user authentication.
Select the Including for checkbox and either the All access rules (default) or the Selected access rules radio button to allow traffic affected by access rules that require user authentication, while waiting for user identification.
* 
CAUTION: This can temporarily allow access that would not be allowed when the user is identified.
To have all the SSO agents synchronize their user databases, select either:
Sync all agents – To synchronize together no matter what identification mechanisms they use, thus giving a single, homogenous user database duplicated on every agent.
Synch those with the same user identification mechanisms – To synchronize only those databases using the same identification mechanism; this is the default.

Each SSO agent maintains its own database of the users that it has identified, and the agents can optionally be configured to synchronize those databases, thus giving a common user database duplicated on each agent. A common, synchronized user database makes user lookups more efficient and gives better redundancy. By specifying synchronicity here, the appliance can inform each agent of the other agents with which to synchronize, thereby avoiding the complexity of having to configure it in the agents.

By default, the appliance has those agents configured to use the same user identification mechanisms synchronize together. For example, if some agents are reading domain controller logs while others use NetAPI, then two separate, external databases in the two groups of agents result, one database of those user found in the domain controller logs and a separate database of the users identified by NetAPI.

* 
NOTE: This setting can be overridden by explicitly configuring in each SSO agent the list of other agents with which to synchronize.
Configure the list of Windows service user names in the User names used by Windows services table. You can list up to 64 user names that may be used by services on the end-users’ PCs; any log ins with these names are assumed to be service log ins and are ignored by the SSO agent(s).
a)
Click the Add button. the Service User name dialog displays.

b)
Enter the service user name.
c)
Click OK.
d)
Repeat Step a through Step c for each user account.

Windows services log on to the machine or domain using user accounts just as real users do. Some of the Windows’ APIs used by the SSO agent do not provide for distinguishing these service log ins from real user log ins, which can lead to the SSO agent incorrectly reporting the user name used by a service instead of that of the actual user.

Users Tab
1
Click the Users tab to specify the following the User Settings options:
Select the Allow only users listed locally checkbox to allow only users listed locally on the appliance to be authenticated. This setting is disabled by default.
Select the Simple user names in local database checkbox to use simple user names. This setting is disabled by default.
* 
NOTE: This setting is dimmed unless the Allow only users listed locally setting is enabled.

User names returned from the authentication agent or from NTLM authentication usually include a domain component, for example, domain1/bob. When this setting is selected, the domain component of a user name is ignored, and just the user name component is matched against names in the SonicWall appliance’s local user database. If this box is not checked, local user account names that are to match SSO-authenticated users must conform to the full user name, including any domain component.

* 
NOTE: Domain components can take the following formats:
Windows: either DOMAIN1|bob or DOMAIN1/bob, where DOMAIN1 is the sort-form (NetBIOS) domain name; it must be all uppercase if local user names are case-sensitive.
Novell: either the user’s Novell name with context (for example, bob.user.domain1) or their LDAP distinguished name (for example, cn=bob,ou=users,o=domain1).
Select the Allow limited access for non-domain users checkbox to allow limited access to users who are logged in to a computer but not into a domain. These users are not given membership in the Trusted Users user group, even when set locally, and so do not get any access set for Trusted Users. The are given access through policies, etc., that apply to Everyone or that specifically list them as allowed users. This setting is disabled by default.

These users are identified in logs as computer-name/user-name. When using the local user database to authenticate users and the Simple user names in local database option is disabled, user names must be configured in the local database using the full computer-name/user-name identification.

* 
NOTE: This does not apply for users authenticated via NTLM. With NTLM, authentication non-domain users are given access only if the name/password matches a local user account created on the appliance.
If your network includes non-Windows devices or Windows computers with personal firewalls running:
a)
Select the Probe user for checkbox.
b)
Select one of the following, depending on which is configured for the SSO Agent:
NetAPI over NetBIOS
NetAPI over TCP
WMI
* 
TIP: Hovering the mouse over these options displays a small tooltip contain the TCP port number.

When the SSO agent attempts to identify a user in a Windows domain, if the agent uses NetAPI or WMI, then when the agent tries to communicate directly with the user’s computer from which the traffic is originating. This can cause problems:

When traffic is coming from non-Windows devices as such devices do not respond to, or may block, the Windows networking messages used by the SSO Agent to identify a user.
With Windows computers if personal firewalls on them are blocking them.

The result can be that the agent may get overloaded with multiple threads waiting for requests that are not getting replies.

To avoid these problems, enable this setting (it is disabled by default) and select the correct NetAPI/WMI protocol that the SSO agent is configured to use. Before sending a request to the agent to identify a user via NetAPI or WMI, the SonicWall appliance probes the machine from which the traffic originated to verify if it responds on the port used by the NetAPI or WMA protocol. If it does not, then the device fails SSO immediately without the agent getting involved.

* 
NOTE: This setting does not affect an agent that reads user login information from the domain controller(s).
If the Probe users for setting is enabled, it causes the firewall to probe for a response on the NetAPI/WMI port before requesting that the SSO Agent identify a user. The Probe timeout (seconds) is set to 5 seconds by default.
Select the Probe test mode checkbox to test that SSO probes are functioning correctly during SSO without interfering with user authentications. Probes are sent after initiating user authentication through the SSO agent. This setting is disabled by default.

If this setting is enabled, the probes are sent after initiating user authentication via the sSO agent (normally, the latter is done if the probe is successful). Statistics for the probing are updated as normal, and if a probe fails for a user who is successfully authenticated by the agent, then that is reported via a message on the console port.

For the Mechanism for setting user group memberships, select either:
Use LDAP to retrieve user group information radio button to use LDAP to retrieve user information. This option is selected by default.
To configure the LDAP settings click Configure. The LDAP Configuration dialog displays. For configuration information for this dialog, refer to Advanced LDAP Configuration.
Local configuration radio button to use locally configured user group settings.
In the Polling rate (minutes) field, enter a polling interval, in minutes (the default is 5). After a user has been identified and logged in, the SonicWall polls the authentication agent at this rate to verify the user is still logged on.

If you are using NTLM authentication, then in the NTLM settings you can selectively choose to have the appliance poll users by forcing them to re-authenticate via NTLM rather than polling via the agent.

Select the Poll the same agent that authenticated the user checkbox if the network topology requires that particular agents be used depending on the location of users, rather than polling any agent to determine if the user is still logged in. This setting is disabled by default.
* 
IMPORTANT: The Try next agent on getting no name from NetAPI/WMI setting on the SSO Agents General Settings tab also needs to be set if this is set.

By default, the appliance assumes that any SSO agent can send NetAPI or WMI requests to any user, so when polling to check if users are still logged in, the appliance can choose any agent based on current loadings. If this is not the case, and the network topography requires particular agents be used depending on the location of the users, then enable this setting. When it is enabled, after a user is successfully identified by an agent, subsequent polling of the user is performed via that same agent.

* 
NOTE: This setting affects only agents using NetAPI/WMI, not any agents that use just the domain controller security log lookup mechanism.
In the Hold time after (minutes) field, enter a time, in minutes, that the security appliance waits before trying again to identify traffic after an initial failure to do so. This feature rate limits requests to the agent to avoid possibly flooding it with requests if further traffic continues to be received from sources that repeatedly fail SSO. The default is 1 minute.
* 
NOTE: The times to hold off after getting errors from the SSO agent and after the agent reports that no user is logged in are set separately, so they are configured separately.
In the …after finding no user field, enter the number of minutes that the appliance should wait before trying again if it gets errors from the SSO agent or when the agent reports that no user is logged in. The default is 1 minute.
2
To give consistent naming for a domain in logging, select one of the following radio buttons for When different SSO sources report different name variants for a user’s domain:
Use the domain name as received (default)
Always use a consistent domain name; go to Step a.

By default, a user identified via SSO is logged in on the SonicWall appliance with whatever domain name is reported to it by the external source that identified the user. A doman, however, typically has two or three different variants of its domain name (for example, a Windows domain has its DNS name, its NetBIOS name, and its Kerberos realm name), and different SSO sources may report different variants of these for a user in the same domain.

This difference can cause difficulty in tracking users by domain in logging, so you can instead select to make the names consistent by having the same domain name variant used for all the users in a domain, no matter which variant is reported to the SonicWall appliance.

a
If you have selected Always use a consistent domain name, click the Select button. The Select the name variant to use for each domain pop-up dialog lists known domains from which you can select the names to use is displayed.

b
Select the variant(s) to use. The initial default variant for each domain is None, which means that behavior of using whatever domain name is reported to the appliance via SSO does not change until Always use a consistent domain name is enabled and the domain name to use is selected here.
* 
NOTE: If a domain is not shown in this list, wait until the SSO has identified some users in the domain, then repeat this step.
c
Click OK.

If, when using Single Sign On, you see unexpected user names shown on the Users > Status page, or logs of user login or user login failure with unexpected user names, those may be due to Windows service logins and those user names should be configured here so that the SSO agent will know to ignore them.

In cases where there are multiple firewalls communicating with an SSO agent, the list of service account names should be configured on only one of them. The effect of configuring multiple lists on different appliances is undefined.

Enforcement Tab
1
Click the Enforcement tab if you want to either trigger SSO on traffic from a particular zone, or bypass SSO for traffic from non-user devices such as internal proxy web servers or IP phones.
2
Under Per-Zone SSO Enforcement, select the checkboxes for any zones on which you want to trigger SSO to identify users when traffic is sent:
LAN
DMZ
VPN
WLAN

If SSO is already required on a zone by Application Control or other policies, those checkboxes are pre-selected and cannot be cleared. If Guest Services is enabled on a zone, SSO cannot be enforced and you cannot select the checkbox. On zones where it is not otherwise initiated, SSO enforcement can be enabled by this option.

* 
NOTE: On zones where security services policies or firewall access rules are set to require user authentication, SSO is always initiated for the affected traffic, and it is not necessary to also enable SSO enforcement here.

These per-zone SSO enforcement settings are useful for identifying and tracking users in event logging and AppFlow Monitor visualizations, even when SSO is not otherwise triggered by content filtering, IPS, or Application Control policies, or by firewall access rules requiring user authentication.

3
To bypass SSO for traffic from certain services or locations and apply the default content filtering policy to the traffic, select the appropriate service or location from the list in the SSO Bypass table or add a new service or location to the table. The table displays the built-in services that bypass SSO; these services cannot be delete.
* 
TIP: You could create SSO bypass address and/or service group objects for this and reference those same ones both here and in those access rules.
* 
NOTE: SSO bypass settings do not apply when SSO is triggered by firewall access rules requiring user authentication. To configure this type of SSO bypass, add separate access rules that do not require user authentication for the affected traffic. See Adding Access Rules for more information on configuring access rules.

By default, Linux and Mac users who are not authenticated by SSO via Samba are assigned the default content filtering policy. To redirect all such users who are not authenticated by SSO to manually enter their credentials, create an access rule from the WAN zone to the LAN zone for the HTTP service with Users Allowed set to All. Then configure the appropriate CFS policy for the users or user groups. See Adding Access Rules for more information on configuring access rules.

SSO bypass may be necessary, for example, for:

Traffic emanating from a non-user device, such as an internal mail server or an IP phone.
User traffic that does not need to be authenticated and might be adversely affected by delays waiting for SSO.

For traffic that bypasses SSO, the default content filtering policy is applied. If any APP rules or IPS/Anti-Spyware policies are set to include/exclude users, then that traffic is no included/excluded respectively with those.

The second setting is appropriate for user traffic that does not need to be authenticated, and triggering SSO might cause an unacceptable delay for the service.

4
Optionally, to add a service or location:
a
Click the Add button. The Add an SSO bypass rule dialog displays.

b
For Bypass SSO for, select either the Services or Addresses radio button.
c
Select a service or address from the drop-down menu.
d
Select the Bypass type:
Full bypass (don’t trigger SSO
Trigger SSO but bypass holding packets while waiting for it
e
Click Add. The entry is added to the table
5
To select a SSO bypass user name for logging:
a
Select the Log user name <bypass name> for SSO bypasses checkbox.
b
Specify a name for the SSO bypassed user.

This setting is selected by default, and a default name of SSO Bypass is specified.If this setting is enabled, then when traffic bypasses SSO (as configured here), the traffic is shown in logs and AppFlow Monitor with the given user name rather than as from an unknown user, thus allowing it to be differentiated from traffic sent by users whom SSO could not identify.

* 
TIP: You also can configure logging on the Users > Settings page under User Session Settings.
6
Optionally, select Create a dummy user checkbox. This setting is not selected by default.

If this setting is enabled, on receiving SSO bypass traffic, a dummy user entry is created with the given user name for the originating IP address. Then, in addition to the name appearing in logs and the AppFlow Monitor, the dummy user entry displays on the Users > Status page. The dummy name remains in existence until traffic from the IP address stops for the given inactivity time or, in the case of bypass services, until non-bypass traffic is received from it.

* 
NOTE: This dummy user name applies only for bypass rules set for full SSO bypass. Any set to trigger SSO, but bypass holding packets while waiting for it results in the user being set according to the result of the triggered SSO identification.
* 
NOTE: The logging part of this option also can be configured by the For logging of connections on which the user is not identified option in the User Session Settings section of the Users > Settings page
a
Optionally, specify an inactivity timeout, in minutes, in the Inactivity timeout (mins) field. The default is 15 minutes.
Terminal Services Tab
1
Click the Terminal Services tab to specify the following Terminal Services Agent Settings options.

2
To add agents, click the Add button. The page is updated to display a new row in the table at the top and new input fields in the lower half of the page. For existing agents:
Green LED-style icon next to an agent indicates that the agent is up and running.
Red LED icon indicates that the agent is down.
Yellow LED icon means that the TSA is idle and the appliance has not heard anything from it for 5 minutes or more.

Because TSA sends notifications to the appliance rather than the appliance sending requests to the agent, a lack of notifications could mean that there is a problem, but more likely means simply that no user on the terminal server is currently active.

In the Host Name or IP Address(es) field, enter the name or IP address of the terminal server on which SonicWall TSA is installed. If the terminal server is multi-homed (has multiple IP addresses) and you are identifying the host by IP address rather than DNS name, enter all the IP addresses as a comma-separated list.
* 
NOTE: As you type in values for the fields, the row at the top is updated in red to highlight the new information.
At Port, enter the port number that the SonicWall TSA is using to communicate with the appliance. The default port is 2259.
* 
NOTE: Agents at different IP addresses can have the same port number.
In the Shared Key field, enter the shared key that you created or generated in the SonicWall TSA. The shared key must match exactly. Re-enter the shared key in the Confirm Shared Key field.
3
Click the General Settings tab under Terminal Services Agent Settings to configure the following options:

Select the Enable Terminal Services agent authentication checkbox to use the TSA for user authentication. This setting is not enabled by default.
The Allow traffic from services on the terminal server to bypass user authentication in access rules checkbox is selected by default. This allows service traffic, such as Windows updates or anti-virus updates not associated with any user login session, to pass without authentication. That traffic normally would be blocked if the applicable firewall rules are set to require user authentication.

If you clear this checkbox, traffic from services can be blocked if firewall access rules require user authentication. In this case, you can add rules to allow access for All to the services traffic destinations, or configure the destinations as HTTP URLs that can bypass user authentication in access rules.

NTLM Tab
1
Click the NTLM tab.

NTLM authentication is supported by Mozilla-based browsers and can be used as a supplement to identifying users via an SSO agent or, with some limitations, on its own without the agent. The firewall interacts directly with the browser to authenticate the user. Users logged in with domain credentials are authenticated transparently; in other cases the user may need to enter credentials to login to the appliance, but should only need to do so once as the credentials are saved.

Consult the tooltips on this tab for additional details, and see How Does Browser NTLM Authentication Work? for more information.

2
Configure these settings;
Select one of the following choices from the Use NTLM to authenticate HTTP traffic drop-down list:
Never – Will never use NTML authentication
Before attempting SSO via the agent – Try to authenticate users with NTLM before using the SonicWall SSO agent
Only if SSO via the agent fails – Try to authenticate users via the SSO agent first; if that fails, try using NTLM
For Authentication domain, do one of the following:
Enter the full DNS name of the firewall’s domain in the form “www.somedomain.com”
Select the Use the domain from the LDAP configuration checkbox to use the same domain that is used in the LDAP configuration.

Fully transparent authentication can only occur if the browser sees the appliance domain as the local domain.

For Redirect the browser to this appliance via, select one of the following options to determine how a user’s browser is initially redirected to the firewall’s own Web server:
The interface IP address – Select this to redirect the browser to the IP address of the appliance Web server interface.
Its domain name from a reverse DNS lookup of the interface IP address – Enables the Show Reverse DNS Cache button at the bottom of the window; when clicked, a popup displays the appliance Web server’s Interface, IP Address, DNS Name, and TTL in seconds. Click the button to verify the domain name (DNS name) being used for redirecting the user’s browser.
Its configured domain name – Use the firewall's domain name as configured on the System > Administration page.
The name from the administration certificate – Use the imported certificate that is selected for HTTPS Web Management on the System > Administration page.
Enter a number of retries in the Maximum retries to allow on authentication failure.
To detect when users log out, select the polling method to be used by the appliance for Windows, Linux, and Macintosh users in the On the poll timer, for users authenticated user via NTLM options. Select the radio button for one of the following methods for users on each type of computer:
Poll via the SSO agent – If you are using an SSO Agent in your network, select this to use it to poll users; for users authenticated via NTLM, the user name that the agent learns must match the name user for the NTLM authentication, or the login session will be terminated. You may want to select a different polling method for Linux or MacOS users, as those systems do not support the Windows networking requests used by the SSO agent.
Re-authenticate via NTLM – This method is transparent to the user if the browser is configured to store the domain credentials, or the user instructed the browser to save the credentials.
Don’t re-authenticate – If you select this option, logout will not be detected other than via the inactivity timeout.
* 
NOTE: When multiple Content Filter policies are configured and 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 triggers an NTLM authentication request to the user. Without the access rule, restrictive CFS policies might block the user from Internet access and prevent authentication.
If you are using older legacy servers that require legacy LAN Manager components to be included in NTLM messages, select the Forward legacy LanMan in NTLM checkbox. This may cause authentication to fail in newer Windows servers that don’t allow LanMan in NTLM by default because it is not secure.
RADIUS Accounting Tab
1
Click the RADIUS Accounting tab to display the RADIUS Accounting Single-Sign-On tabs.

Single Sign-On by RADIUS accounting allows the appliance to act as a RADIUS accounting server for external third-party appliances, and to log users in or out based on the accounting messages from those devices. For third-party appliances that use RADIUS accounting for other purposes, SonicOS can also forward the RADIUS accounting messages to another RADIUS accounting server.

The Status column shows the current status for each RADIUS accounting client listed in the panel:

Green—the client is active
Yellow—the client is idle
Grey—the client is not detected
2
To add a new RADIUS client, click the Add… button. The RADIUS Accounting Single-Sign-On tabs, Settings, RADIUS, and Forwarding, appear in a view/edit pane in the lower half of the dialog.
* 
NOTE: Changes made in the view/edit pane are instated directly into the highlighted entry in the Accounting Clients table as they are made. On completion, click anywhere outside of the pane to close it. Individual fields in the Accounting Clients table also can be updated by clicking on them directly in the table.

3
In the Client host name or IP address field, enter the name or the IP address for the RADIUS client host.
4
In the Shared Secret field and the Confirm Secret field, enter your shared secret for the client.
5
Click the RADIUS tab.

6
From the User-Name attribute format drop-down menu, select the format for the user name login.

RADIUS Accounting does not specify the format of the content of the User-Name attribute passed in RADIUS Accounting messages. You need to enter, therefore, the format that is sent by the client. You can select from some common formats:

User-name
Domain\User-name
Domain/User-name
User-name@Domain
SonicWall SMA
Other – Non-standard format
* 
IMPORTANT: The pre-defined formats are for common cases. If those do not match what your network access server sends, then you must select Other as the User-Name attribute format and then enter a customized format.
7
If you selected:
A standard format, go to Step 8.
If you select Other, more settings appear so you can configure the components to be found in the attribute:

Format
Components
a
In the Format field, enter a limited scanf-style string, with either a %s or %[…] directive for each component. This directive tells the appliance what the network access device (NAS) sends in the User-Name attribute. This format is not specified by the RADIUS Accounting RFC. Devices are not constrained as to what they can send in this attribute, so, its content can be very variable. What you set here specifies how the appliance must decode the User-Name attribute to extract the user name, domain, and/or DN.
* 
TIP: When you select Other, these fields are set to the format string and components of the previously selected format. So, first select the pre-defined format that most closely matches what your network access server sends. This gives you a good starting point for entering your customized format. Then, change to Other.
b
From the Component drop-down menu, select one of the following:
Not used
User-Name (default)
Domain
DN

The components that you enter as a limited scanf-style string in the Format field consist of one or more of the following items:

User-Name
Domain
Fully qualified distinguished name (DN)
* 
NOTE: You can double click in the Components drop-down menu to display a tooltip with instructions on how to enter the scanf-style format.
c
Click Add component. The Add a component to the User-Name attribute format dialog displays.
* 
NOTE: If you understand the scanf-style format, you can edit the Format field directly instead of using the Add component button.
TIP: Use %s for a component that is followed by white space or is at the end. For a component followed by some other character, use %[^x]x. For example, the Format string for the name@domain format would be %[^@]@%s, with the three components set to User-Name, Domain, and Not used.

d
Select the type of component from the Component to add drop-down menu:
User-name
Domain
DN
e
Enter text to separate entries in the Preceding text after the User-name field.
f
Click Add. the Accounting Clients table is updated, and more options appear in the Radius view/edit pane.

g
Repeat Step b through Step f for each component.

To delete the last component you added, click Remove last component.

8
A RADIUS Accounting client can optionally send Interim Update messages periodically while a user is logged in. If the client does sends the messages at a reasonably constant interval, then the SonicWall appliance can monitor them and assume that the user has been logged out should the messages stop being sent. This process gives a fallback mechanism to guard against missing RADIUS Accounting Stop messages, which are sent on user log out.

Select a Log user out if no accounting interim updates are received option:

Disabled – to not have messages sent.
Enabled – to manually specify the Timeout interval. Set the timeout value greater than the period at which the RADIUS Accounting client sends the Interim-Update messages, and for dropped/missed Interim-Update messages, set the Timeout value at least 2 to 3 times greater than the period.
Auto (default) – to have the appliance detect automatically whether Interim-Update message are being sent periodically and, if they are, to use them as specified under Enabled and setting automatically the timeout accordingly.
* 
NOTE: If, after some time, the timeout stays at 0 (zero) when the page is reloaded, then it has not detected them being sent and is not timing them out.

It could take quite a considerable time to complete auto-detection, depending on how frequently the client sends them. For example, if the client sends them every 10 minutes, then it could take over 30 minutes before the measure timeout is shown her.e

* 
TIP: You can click the Show info link to monitor progress in a popup dialog.
* 
TIP: To rerun auto-detection, change the setting to Disabled and then back to Auto, clicking Apply after each change.
9
Click the Forwarding tab.

10
Under the Forwarding tab, you can enter up to four RADIUS accounting servers in these fields:
Name or IP address
Port (default 1813)
Shared Secret for the RADIUS accounting servers to which you want the client to forward message
Confirm Shared Secret

When you enter this information for a server, the Select from drop-down menu displays.

11
For each server, from the Select from drop-down menu, select either:
No forwarding
IP address of the accounting server

If requests from more than one client are to be forwarded to the same accounting server, then after it has been configured for any one client, it can be selected from the Select from drop-down menu for the others. All the information for the selected accounting server, including its shared secret, is copied and instated for this client.

12
In the Timeout (seconds) field and Retries field, enter the timeout period in seconds and the number of retries. The default for Timeout (seconds) is 10 seconds, and the default for Retries is 3.

To determine which users have logged out, the SonicWall network security appliance polls the SSO Agent by sending requests to multiple logged-in users in a single request message to the SSO Agent. To configure the number of user requests the firewall can send in a single request message to the Test tab

13
Select how the RADIUS accounting messages are forwarded from this client, either:
Try next on timeout
Forward to all
14
Select the General Settings tab.

15
Enable SSO or RADIUS accounting by selecting the Enable SSO or RADIUS accounting checkbox. This setting is enabled by default.
16
Specify the port in the Port number field. The default port is 1813.
17
Click the Advanced Settings tab.

18
To have the appliance track RADIUS Accounting messages for Start/Stop messages, select the Expect Start/Stop messages due to wireless roaming checkbox. This setting is disabled by default.

RADIUS Accounting clients send Start/Stop messages to notify the firewall of users connecting/disconnecting. If those clients are or use wireless access points, then the wireless users could roam between access points, which may cause them to generate spurious Start/Stop messages as the user connects to a new access point and disconnects form the old one. These roaming Start/Stop messages could interfere with the SSO authentication process, which normally processes Stop messages as notifications of user logout.

If this option is enabled, then the firewall tracks the RADIUS Accounting messages to look for this Start/Stop sequence. If the sequence is found, then the firewall considers the Stop messages as indications of roaming rather than as notifications of user logout.

That is, the firewall assumes Start/Stop messages are due to roaming switch-over between access points if those messages:

Are received (in any order): a Start message for a currently connected user that indicates the same user is at a different access point, along with a Stop message from the previous location
Occur together within the specified time.
* 
NOTE: The maximum switch-over time should allow for the RADIUS Accounting message possibly getting dropped and retransmitted. The recommended time is the same as the timeout multiplied by the maximum retries for the RADIUS Accounting clients.
19
To have the firewall ignore any RADIUS Accounting messages for users:
At specific IP addresses, select an address object or address group from the For users at these IP addresses drop-down menu or create a new address object or address group. The default is None.
Not at specific IP addresses, select an address object or address group from the For users not at these IP addresses drop-down menu or create a new address object or address group. The default is All.
With specific user names:
a)
Click Add. The Add RADIUS Accounting User Name Exclusion popup dialog displays.

b)
From the Ignore any user names that drop-down menu select
begin
end
c)
Enter the user name in the with field.
d)
Click Save. The entry is added to the list.

To edit an entry, select it and then click Edit.

To remove an entry, select it and then click Remove.

Test Tab
1
To test the agent settings you configured, click the Test tab.
* 
IMPORTANT: Performing tests on this page applies any changes that have been made.

You can test the connectivity between the appliance and an SSO agent or TSA. You can also test whether the SSO agent is properly configured to identify a user logged into a workstation.

2
If you have multiple agents configured, select the SSO agent or TSA to test from the Select agent to test drop-down menu. The drop-down menu includes SSO agents at the top, and TSA’s at the end under the heading --Terminal Server Agents--.
3
Select the type of test to perform:
Check agent connectivity radio button – Tests communication with the authentication agent. If the firewall can connect to the SSO agent, the message Agent is ready displays. If testing a TSA, the Test Status field displays the message, and the version and server IP address are displayed in the Information returned from the agent field.

For SSO agents only, select the Check user radio button, enter the IP address of a workstation in the Workstation IP address field. This tests if the SSO agent is properly configured to identify the user logged into a workstation.
* 
TIP: If the messages Agent is not responding or Configuration error display, check your settings and perform these tests again.
4
Click the Test button
5
When you are finished with all Authentication Agent configuration, click OK.

Configuring RADIUS Accounting for SSO

RADIUS accounting for Single Sign-On is configured on the Users > Settings page.

To configure RADIUS accounting for SSO:
1
Display the Users > Settings page.

2
Click the Configure SSO button. The SSO Authentication Configuration dialog appears.

3
Click the RADIUS Accounting tab. For the procedure to configure RADIUS Accounting, see RADIUS Accounting Tab.
4
Click Apply.

Advanced LDAP Configuration

If you selected Use LDAP to retrieve user group information on the Users tab as described in Configuring SonicOS to Use the SonicWall SSO Agent, you must configure your LDAP settings.

To configure LDAP to retrieve user group information:
1
On the Users tab in the SSO Authentication Configuration dialog, click the Configure button next to the Use LDAP to retrieve user group information option. The LDAP Configuration dialog displays.

Topics:  
Settings Tab
2
In the Name or IP address field, enter the name or IP address of your LDAP server.

3
In the Port Number field, enter the port number of your LDAP server. The default LDAP ports, which you can select from the drop-down menu, are:
Default LDAP port389
Default LDAP over TLS port636
Windows Global Catalog port3268
Global Catalog over TLS port3269
4