User Management

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

Topics:

About User Management

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

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

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

Figure 36 shows an overview of user management.

Figure 36. User management topology

Topics:

Using Local Users and Groups for Authentication

The Dell SonicWALL network security appliance provides a local database for storing user and group information. You can configure the firewall to use this local database to authenticate users and control their access to the network; see Figure 37. 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.

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

The number of users supported by the local database on the SM 9800 is:

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 the web and the GVC, SSL-VP, and L2TP clients.

IMPORTANT: To achieve the maximum efficiency in handling these numbers, Dell SonicWALL recommends: • 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. • For wireless users, use RADIUS Accounting as much as possible.

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:

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 an “allow” list.

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

Using RADIUS for Authentication

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

Figure 38. User management: Using RADIUS for authentication

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

Using LDAP/Active Directory/eDirectory Authentication

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

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

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

Topics:

LDAP Terms

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

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

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:

SonicOS provides support for directory servers running the following protocols:

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:

NOTE: LDAP User Groups are not deleted if they are configured in any Access Rules, App Rules, or policies.

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:

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:

NOTE: Skip the first five steps if Certificate Services are already installed.

Exporting the CA Certificate from the Active Directory Server

To export the CA certificate from the AD server:

Importing the CA Certificate in to SonicOS

To import the CA certificate in to SonicOS:

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:

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.

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

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

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

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

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

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

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

Benefits of SonicWALL SSO

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

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

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

Other benefits of SonicWALL SSO include:

Platforms and Supported Standards

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

The SSO feature supports LDAP and local database protocols. SonicWALL SSO supports SonicWALL Directory Services Connector. For all features of SonicWALL SSO to work properly, SonicOS should be used with the latest version of SonicWALL Directory Services Connector.

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

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

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

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

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:

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:

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.

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:

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:

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

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

How Does SSO Agent Work?

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

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

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

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

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

Logging

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

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

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 .

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, with the SuperMassive 9800 supporting 512 terminal services agents.

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

Encryption of TSA Messages and Use of Session IDs

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

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

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

Connections to Local Subnets

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

Non-Domain User Traffic from the Terminal Server

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

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

Non-User Traffic from the Terminal Server

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

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

How Does Browser NTLM Authentication Work?

Topics:

NTLM Authentication of Domain Users

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

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

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:

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.

NOTE: Safari does not operate on Windows platforms.

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 Dell SonicWALL appliance can act as the RADIUS Accounting Server, and can use RADIUS Accounting messages sent from the customer's network access server for single sign-on (SSO) in the network.

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

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

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

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

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

Topics:

RADIUS Accounting Messages

RADIUS accounting uses two types of accounting messages:

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

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:

Dell SonicWALL Compatibility with Third Party Network Appliances

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

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

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

Proxy Forwarding

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

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

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

Non-Domain Users

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

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:

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 Dell 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.

IPv6 Considerations

In RADIUS accounting, these attributes are used to contain the user's 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.

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:

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:

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

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.

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.

Table 93 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.

User Groups

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

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

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:

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.