User_Management
This chapter describes the user management capabilities of your SonicWALL SuperMassive for locally and remotely authenticated users. This chapter contains the following sections:
• Introduction to User Management
• Viewing Status on Users > Status
• Configuring Settings on Users > Settings
• Configuring RADIUS Authentication
• Configuring LDAP Integration in SonicOS
• RADIUS Accounting for Single-Sign-On
• Configuring Multiple Administrator Support
Introduction to User Management
See the following sections for more information:
• Using Local Users and Groups for Authentication
• Using RADIUS for Authentication
• Using LDAP / Active Directory / eDirectory Authentication
• Multiple Administrator Support Overview
Using Local Users and Groups for Authentication
The SonicWALL SuperMassive provides a local database for storing user and group information. You can configure the SonicWALL 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 for this purpose 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. For networks with larger numbers of users, user authentication using LDAP or RADIUS servers can be more efficient.
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 in order 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 SonicWALL. 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 this 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 SonicWALL is currently licensed for Premium Content Filtering Service.
Using RADIUS for Authentication
Remote Authentication Dial In User Service (RADIUS) is a protocol used by SonicWALL SuperMassives 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.
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 which you can manage using LDAP. Some are open standards SAMBA, which are implementations of the LDAP standards. Some are proprietary systems like Novell eDirectory which provide an LDAP API for managing the user repository information. Add new diagram here: SuperMassive network diagram.
In addition to RADIUS and the local user database, SonicOS supports LDAP for user authentication, with support for numerous schemas including Microsoft Active Directory (AD), 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.
LDAP Directory Services Supported in SonicOS
In order to integrate with the most common directory services used in company networks, SonicOS supports integration with the following LDAP schemas:
• Microsoft Active Directory
• RFC2798 InetOrgPerson
• RFC2307 Network Information Service
• Samba SMB
• Novell eDirectory
• User-defined schemas
SonicOS provides support for directory servers running the following protocols:
• LDAPv2 (RFC3494)
• LDAPv3 (RFC2251-2256, RFC3377)
• LDAPv3 over TLS (RFC2830)
• LDAPv3 with STARTTLS (RFC2830)
• LDAP Referrals (RFC2251)
LDAP Terms
The following terms are useful when working with LDAP and its variants:
• Schema – The schema is the set of rules or the structure that defines the types of data that can be stored in a directory, and how that data can be stored. Data is stored in the form of ‘entries’.
• Active Directory (AD) – The Microsoft directory service, commonly used with Windows-based networking. Microsoft Active Directory is compatible with LDAP.
• eDirectory – The Novell directory service, used for Novell NetWare-based networking. Novell eDirectory has an LDAP gateway that can be used for management.
• Entry – The data that is stored in the LDAP directory. Entries are stored in ‘attribute’/value (or name/value) pairs, where the attributes are defined by ‘object classes’. A sample entry would be ‘cn=john’ where ‘cn’ (common name) is the attribute, and ‘john’ is the value.
• Object class – Object classes define the type of entries that an LDAP directory may contain. A sample object class, as used by AD, would be ‘user’ or ‘group’.
Microsoft Active Directory’s Classes can be browsed at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/classes_all.asp
• Object - In LDAP terminology, the entries in a directory are referred to as objects. For the purposes of the SonicOS implementation of the LDAP client, the critical objects are ‘User’ and ‘Group’ objects. Different implementations of LDAP can refer to these object classes in different fashions, for example, Active Directory refers to the user object as ‘user’ and the group object as ‘group’, while RFC2798 refers to the user object as ‘inetOrgPerson’ and the group object as ‘groupOfNames’.
• Attribute - A data item stored in an object in an LDAP directory. Object can have required attributes or allowed attributes. For example, the ‘dc’ attribute is a required attribute of the ‘dcObject’ (domain component) object.
• dn - A ‘distinguished name’, which is a globally unique name for a user or other object. It is made up of a number of components, usually starting with a common name (cn) component and ending with a domain specified as two or more domain components (dc). For example, ‘cn=john,cn=users,dc=domain,dc=com’
• cn – The ‘common name’ attribute is a required component of many object classes throughout LDAP.
• ou – The ‘organizational unit’ attribute is a required component of most LDAP schema implementations.
• dc – The ‘domain component’ attribute is commonly found at the root of a distinguished name, and is commonly a required attribute.
• TLS – Transport Layer Security is the IETF standardized version of SSL (Secure Sockets Layer). TLS 1.0 is the successor to SSL 3.0.
Further Information on LDAP Schemas
• Microsoft Active Directory: Schema information is available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/active_directory_schema.asp and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ldap/ldap/ldap_reference.asp
• RFC2798 InetOrgPerson: Schema definition and development information is available at http://rfc.net/rfc2798.html
• RFC2307 Network Information Service: Schema definition and development information is available at http://rfc.net/rfc2307.html
• Samba SMB: Development information is available at http://us5.samba.org/samba/
• Novell eDirectory: LDAP integration information is available at http://www.novell.com/documentation/edir873/index.html?page=/documentation/edir873/edir873/data/h0000007.html
• User-defined schemas: See the documentation for your LDAP installation. You can also see general information on LDAP at http://rfc.net/rfc1777.html
This section provides an introduction to the SonicWALL SonicOS Single Sign-On feature. This section contains the following subsections:
• Platforms and Supported Standards
• How Does Single Sign-On Work?
• How Does SonicWALL SSO Agent Work?
• How Does SonicWALL Terminal Services Agent Work?
• How Does Browser NTLM Authentication Work?
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 SuperMassives provide SSO functionality using the SonicWALL Single Sign-On Agent (SSO Agent) and SonicWALL Terminal Services Agent (TSA) to identify user activity. The SonicWALL Single Sign-On Agent (SSO Agent) identifies users based on workstation IP address. The SonicWALL 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 SonicWALL 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 SonicWALL SuperMassive 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 will not be authenticated unless they send HTTP traffic and browser NTML authentication is enabled (although they can optionally be authenticated for limited access). For users that 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.
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 SonicWALL SuperMassives that uses user-level authentication, including Content Filtering Service (CFS), Firewall Access Rules, group membership and inheritance, and security services (Application Control, 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 SonicWALL SuperMassive appliance model and ranges from 4 to 256.
• 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
SonicWALL SSO is available on SonicWALL SuperMassives running SonicOS 6.0 or higher. The SonicWALL SSO Agent is compatible with all versions of SonicOS that support SonicWALL SSO. The SonicWALL TSA is supported on SonicOS 6.0 and higher.
The SonicWALL SSO feature supports LDAP and local database protocols. SonicWALL SSO supports SonicWALL Directory Connector. For all features of SonicWALL SSO to work properly, SonicOS 6.0 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 SonicWALL SSO Agent is not required for browser NTLM authentication.
Except when using only browser NTLM authentication, using SonicWALL SSO requires that the SonicWALL 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 SonicWALL TSA be installed on any terminal servers in the domain.
The following requirements must be met in order to run the SSO Agent:
• UDP port 2258 (by default) must be open; the firewall uses UDP port 2258 by default to communicate with SonicWALL SSO Agent; if a custom port is configured instead of 2258, then this requirement applies to the custom port
• Windows Server, with latest service pack
• .NET Framework 2.0
• Net API or WMI
Note Mac and Linux PCs do not support the Windows networking requests that are used by the SonicWALL 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 SonicWALL 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)
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 SonicWALL SuperMassive appliance. There are six steps involved in SonicWALL SSO authentication using the SSO Agent, as illustrated in the following figure. Add new diagram here: SuperMassive network diagram.
The SonicWALL SSO authentication process is initiated when user traffic passes through a SonicWALL SuperMassive, for example, when a user accesses the Internet. The sent packets are temporarily blocked and saved while the SonicWALL SuperMassive 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 SonicWALL SuperMassive with the username 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 SonicWALL 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 SonicWALL SuperMassive appliance.
• 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 the firewall when the user logs out, so no polling occurs.
Once a user has been identified, the SonicWALL SuperMassive 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 SonicWALL SuperMassive 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 SonicWALL SuperMassive 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 SonicWALL SuperMassive, confirming that the user has been logged out and terminating the SSO session. Rather than being polled by the SonicWALL SuperMassive appliance, the TSA itself monitors the Terminal Services / Citrix server for logout events and notifies the SonicWALL SuperMassive appliance 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 SonicWALL SuperMassive supports identifying them via NTLM (NT LAN Manager) authentication. NTLM is part of a browser authentication suite known as “Integrated Windows Security” and is supported by all Mozilla-based browsers. It allows a direct authentication request from the appliance to the browser without involving the SonicWALL 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 SonicWALL SSO agent attempts to acquire the user information. For example, if the SonicWALL 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 SonicWALL SuperMassive appliance to probe for a response on the NetAPI/WMI port before requesting that the SSO Agent identify a user. If no response occurs, these devices will fail SSO immediately. For a Windows PC the probe will generally work (unless blocked by a personal firewall) and the SonicWALL SSO agent will be used. For a Linux/Mac PC (assuming it is not set up to run Samba server) the probe will fail, the SSO agent will be bypassed and NTLM authentication will be used when HTTP traffic is sent.
NTLM cannot identify the user until they browse with HTTP, so any traffic sent before that will be treated as unidentified. The default CFS policy will be applied, and any rule requiring authenticated users will not let the traffic pass.
If NTLM is configured to be used before the SonicWALL SSO agent, then if HTTP traffic is received first, the user will be authenticated with NTLM. If non-HTTP traffic is received first, the SonicWALL SSO agent will be used for authentication.
How Does SonicWALL SSO Agent Work?
The SonicWALL SSO Agent can be installed on any workstation with a Windows domain that can communicate with clients and the SonicWALL SuperMassive directly using the IP address or using a path, such as VPN. For installation instructions for the SonicWALL SSO Agent, refer to the 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 SonicWALL SSO Agent only communicates with clients and the SonicWALL SuperMassive. SonicWALL SSO Agent uses a shared key for encryption of messages between the SSO Agent and the SonicWALL SuperMassive. Add new diagram here: SuperMassive network diagram.
Note The shared key is generated in the SSO Agent and the key entered in the SonicWALL SuperMassive during SSO configuration must match the SSO Agent-generated key exactly.
The SonicWALL SuperMassive queries the SonicWALL SSO Agent over the default port 2258. The SSO Agent then communicates between the client and the SonicWALL SuperMassive to determine the client’s user ID. The SonicWALL SSO Agent is polled, at a rate that is configurable by the administrator, by the SonicWALL SuperMassive to continually confirm a user’s login status.
The SonicWALL SSO Agent sends log event messages to the Windows Event Log based on administrator-selected logging levels.
The SonicWALL SuperMassive also logs SSO Agent-specific events in its event log. The following is a list of SSO Agent-specific log event messages from the SonicWALL SuperMassive:
• 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 SonicWALL SuperMassive.
• User login denied - SSO Agent agent timeout – Attempts to contact the SonicWALL 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 SonicWALL SSO Agent.
• User login denied - SSO Agent agent name resolution failed – The SonicWALL 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 SonicWALL Terminal Services Agent Work?
The SonicWALL 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 SonicWALL SuperMassive directly using the IP address or using a path, such as VPN. Add new diagram here: SuperMassive network diagram.
For installation instructions for the SonicWALL TSA, refer to the Installing the SonicWALL Terminal Services Agent.
See the following sections for information about the SonicWALL TSA:
• Encryption of TSA Messages and Use of Session IDs
• Connections to Local Subnets
• Non-Domain User Traffic from the Terminal Server
• Non-User Traffic from the Terminal Server
To accommodate large installations with thousands of users, SonicWALL SuperMassive appliances are configurable for operation with multiple terminal services agents (one per terminal server). The number of agents supported depends on the model, as shown in Table 2.
Table 2 Multiple TSA Support per Model
|
For the SonicWALL SuperMassive series, a maximum of 32 IP addresses is supported per terminal server.
Encryption of TSA Messages and Use of Session IDs
SonicWALL TSA uses a shared key for encryption of messages between the TSA and the SonicWALL SuperMassive appliance 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 SonicWALL SuperMassive appliance 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.
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 SonicWALL SuperMassive appliance 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 SonicWALL SuperMassive appliance 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?
See the following sections:
• NTLM Authentication of Domain Users
• NTLM Authentication of Non-Domain Users
• Credentials for NTLM Authentication in the Browser
NTLM Authentication of Domain Users
For domain users, the NTLM response is authenticated via the MSCHAP mechanism in RADIUS. RADIUS must be enabled on the appliance.
The following settings on the Users tab of the SSO configuration apply when configuring NTLM authentication:
• Allow only users listed locally
• Simple user names in local database
• Mechanism for setting user group memberships (LDAP or local)
• User group memberships can be set locally by duplicating LDAP user names (set in the LDAP configuration and applicable when the user group membership mechanism is LDAP)
• Polling rate
NTLM Authentication of Non-Domain Users
With NTLM, non-domain users could be users who are logged into their PC rather than into the domain , or could be users who were prompted to enter a user name and password and entered something other than their domain credentials. In both cases, NTLM allows for distinguishing these from domain users.
If the user name matches a local user account on the SonicWALL SuperMassive 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 SonicWALL SuperMassive 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 7 – Internet Explorer uses the user’s domain credentials and authenticates transparently if the website that it is logging into (the SonicWALL SuperMassive) is in the local intranet, according to the Security tab in its Internet Options. This requires adding the SonicWALL SuperMassive 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 7 – Chrome behaves the same as Internet Explorer, including requiring that the SonicWALL SuperMassive is added to the list of websites in the Local Intranet zone in the Internet Options.
• Firefox 3.6 – Firefox uses the user’s domain credentials and authenticates transparently if the website that it is logging into (the SonicWALL SuperMassive) 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 3.6 – Although Safari does support NTLM, it does not currently support fully transparent logon using the user’s domain credentials.
• 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.
Multiple Administrator Support Overview
This section provides an introduction to the Multiple Administrators Support feature. This section contains the following subsections:
• What is Multiple Administrators Support?
• Benefits
• How Does Multiple Administrators Support Work?
What is Multiple Administrators Support?
The original version of SonicOS supported only a single administrator to log on to a SonicWALL SuperMassive 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 usernames 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.
Multiple Administrators Support provides the following benefits:
• Improved productivity - Allowing multiple administrators to access a SonicWALL SuperMassive 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 SonicWALL SuperMassive 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:
• Priority for Preempting Administrators
• GMS and Multiple Administrator Support
In order to allow multiple concurrent administrators, while also preventing potential conflicts caused by multiple administrators making configuration changes at the same time, the following configuration modes have been defined:
• Configuration mode - Administrator has full privileges to edit the configuration. If no administrator is already logged into the appliance, this is the default behavior for administrators with full and limited administrator privileges (but not read-only administrators).
Note Administrators with full configuration privilege can also log in using the Command Line Interface (CLI).
• Read-only mode - Administrator cannot make any changes to the configuration, but can view the browse the entire management UI and perform monitoring actions.
Only administrators that are members of the SonicWALL Read-Only Admins user group are given read-only access, and it is the only configuration mode they can access.
• Non-configuration mode - Administrator can view the same information as members of the read-only group and they can also initiate management actions that do not have the potential to cause configuration conflicts.
Only administrators that are members of the SonicWALL Administrators user group can access non-configuration mode. This mode can be entered when another administrator is already in configuration mode and the new administrator chooses not to preempt the existing administrator. By default, when an administrator is preempted out of configuration mode, he or she is converted to non-configuration mode. On the System > Administration page, this behavior can be modified so that the original administrator is logged out.
The following table provides a summary of the access rights available to the configuration modes. Access rights for limited administrators are included also, but note that this table does not include all functions available to limited administrators.
|
The Multiple Administrators Support feature introduces two new default user groups:
• SonicWALL Administrators - Members of this group have full administrator access to edit the configuration.
• SonicWALL Read-Only Admins - Members of this group have read-only access to view the full management interface, but they cannot edit the configuration and they cannot switch to full configuration mode.
It is not recommended to include users in more than one of these user groups. However, if you do so, the following behavior applies:
• If members of the SonicWALL Administrators user group are also included in the Limited Administrators or SonicWALL Read-Only Admins user groups, the members will have full administrator rights.
• If members of the Limited Administrators user group are included in the SonicWALL Read-Only Admins user group, the members will have limited administrator rights.
Priority for Preempting Administrators
The following rules govern the priority levels that the various classes of administrators have for preempting administrators that are already logged into the appliance:
1. The admin user and SonicWALL Global Management System (GMS) both have the highest priority and can preempt any users.
2. A user that is a member of the SonicWALL Administrators user group can preempt any users except for the admin and SonicWALL GMS.
3. A user that is a member of the Limited Administrators user group can only preempt other members of the Limited Administrators group.
GMS and Multiple Administrator Support
When using SonicWALL GMS to manage a SonicWALL SuperMassive, 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.