8. Click the General Settings tab to enter the following information:

– To use RADIUS accounting for SSO, select the Enable SSO by RADIUS accounting checkbox.

– At Port, enter the UDP port number on which to listen for RADIUS accounting.

Advanced LDAP Configuration

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

To configure LDAP settings, perform the following steps:

1. On the Users tab in the SSO Configure window, click the Configure button next to the Use LDAP to retrieve user group information option.

2. The Settings tab displays. In the Name or IP address field, enter the name or IP address of your LDAP server.

In the Port Number field, enter the port number of your LDAP server. The default LDAP ports are:

– Default LDAP port – 389

– Default LDAP over TLS port – 636

4. In the Server timeout (seconds) field, enter a number of seconds the firewall will wait for a response from the LDAP server before the attempt times out. Allowable values are 1 to 99999. The default is 10 seconds.

5. In the Overall operation timeout (minutes) field, enter a number of minutes the firewall will spend on any automatic operation before timing out. Allowable values are 1 to 99999. The default is 5 minutes.

6. Select the Anonymous login radio button to login anonymously. Some LDAP servers allow for the tree to be accessed anonymously. If your server supports this (MS AD generally does not), you may select this option.

– Select Give login name / location in tree to access the tree with the login name.

– Select Give bind distinguished name to access the tree with the distinguished name.

7. To login with a user’s name and password, enter the user’s name in the Login user name field and the password in the Login password field. The login name will automatically be presented to the LDAP server in full ‘dn’ notation.

Note Use the user’s name in the Login user name field, not a username or login ID. For example, John Doe would login as John Doe, not jdoe.

8. Select the LDAP version from the Protocol version drop-down menu, either LDAP version 2 or LDAP version 3. Most implementations of LDAP, including AD, employ LDAP version 3.

9. Select the Use TLS (SSL) checkbox to use Transport Layer Security (SSL) to login to the LDAP server. It is strongly recommended to use TLS to protect the username and password information that will be sent across the network. Most implementations of LDAP server, including AD, support TLS.

10. Select the Send LDAP ‘Start TLS’ request checkbox to allow the LDAP server to operate in TLS and non-TLS mode on the same TCP port. 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. AD does not use this option, and it should only be selected if required by your LDAP server.

Note Only check the Send LDAP ‘Start TLS’ request box if your LDAP server uses the same port number for TLS and non-TLS.

11. Select the Require valid certificate from server checkbox to require a valid certificate from the 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 the firewall and the LDAP server will still use TLS – only without issuance validation.

12. Select a local certificate from the Local certificate for TLS drop-down menu. This is optional, to be used only if the LDAP server requires a client certificate for connections. This feature is useful for LDAP server implementations that return passwords to ensure the identity of the LDAP client (AD does not return passwords). This setting is not required for AD.

13. Click Apply.

14. Click the Schema tab.

From the LDAP Schema drop-down menu, select one of the following LDAP schemas. Selecting any of the predefined schemas will automatically populate the fields used by that schema with their correct values. Selecting ‘user-defined’ will allow you to specify your own values – use this only if you have a specific or proprietary LDAP schema configuration.

– Microsoft Active Directory

– RFC2798 InetOrgPerson

– RFC2307 Network Information Service

– Samba SMB

– Novell eDirectory

– User defined

16. The Object class field defines which attribute represents the individual user account to which the next two fields apply. This will not be modifiable unless you select User defined.

17. The Login name attribute field defines which attribute is used for login authentication. This will not be modifiable unless you select User defined.

18. If the Qualified login name attribute field is not empty, it specifies 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. This is set to mail for Microsoft Active Directory and RFC2798 inetOrgPerson.

19. The User group membership attribute field contains the information in the user object of which groups it belongs to. 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.

20. The Framed IP address attribute field 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 using L2TP with the firewall L2TP server. In future releases, this may also be supported for the SonicWALL Global VPN Client (GVC). In Active Director, the static IP address is configured on the Dial-in tab of a user’s properties.

21. The Object class field defines the type of entries that an LDAP directory may contain. A sample object class, as used by AD, would be ‘user’ or ‘group’.

22. The Member attribute field defines which attribute is used for login authentication.

23. Select the Directory tab.

In the Primary Domain field, specify the user domain used by your LDAP implementation. For AD, this will be the Active Directory domain name, such as 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.

25. In the User tree for login to server field, specify the tree in which the user specified in the ‘Settings’ tab resides. For example, in AD the ‘administrator’ account’s default tree is the same as the user tree.

26. In the Trees containing users field, specify the trees where users commonly reside in the LDAP directory. One default value is provided that can be edited, a maximum of 64 DN values may be provided, and the firewall searches the directory 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.

27. In the Trees containing user groups specify the trees where user groups commonly reside in the LDAP directory. 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.

The above-mentioned 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 the SonicWALL 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 locate 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.

28. The Auto-configure button causes the firewall 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. The ‘User tree for login to server’ must first be set.
Select whether to append new located trees to the current configuration, or to start from scratch removing all currently configured trees first, and then click OK. Note that it will quite likely locate trees that are not needed for user login and manually removing such entries is recommended.

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

29. Select the Referrals tab.

30. If multiple LDAP servers are in use in your network, LDAP referrals may be necessary. Select one or more of the following check boxes:

– Allow referrals – Select when user information is located on an LDAP server other than the primary one.

– Allow continuation references during user authentication – Select when individual directory trees span multiple LDAP servers.

– Allow continuation references during directory auto-configuration – Select to read directory trees from multiple LDAP servers in the same operation.

– Allow continuation references in domain searches – Select to search for sub-domains in multiple LDAP servers.

31. Select the LDAP Users tab.

Check the Allow only users listed locally box to require that LDAP users also be present in the firewall local user database for logins to be allowed.

33. Check the User group membership can be set locally by duplicating LDAP user names box to allow for group membership (and privileges) to be determined by the intersection of local user and LDAP user configurations.

34. From the Default LDAP User Group drop-down menu, select a default group on the firewall to which LDAP users will belong in addition to group memberships configured on the LDAP server.

Tip Group memberships (and privileges) can also be assigned simply with LDAP. By creating user groups on the LDAP/AD server with the same name as built-in groups (such as Guest Services, Content Filtering Bypass, Limited Administrators), and by assigning users to these groups in the directory, or by creating user groups on the firewall with the same name as existing LDAP/AD user groups, group memberships are automatically granted to users upon successful LDAP authentication.

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

35. Click the Import user groups button to import user groups from the LDAP server. The names of user groups on the LDAP server need to be duplicated on the SonicWALL if they are to be used in policy rules, CFS policies, etc.

36. Select the LDAP Relay tab.

Select the Enable RADIUS to LDAP Relay checkbox to enable RADIUS to LDAP relay. 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 firewall with remote satellite sites connected into it using firewalls that may not support LDAP. In that case, the central firewall can operate as a RADIUS server for the remote firewalls, acting as a gateway between RADIUS and LDAP, and relaying authentication requests from them to the LDAP server.

38. Under Allow RADIUS clients to connect via, select the relevant checkboxes and policy rules will be added to allow incoming RADIUS requests accordingly. The options are:

– Trusted Zones

– WAN Zone

– Public Zones

– Wireless Zones

– VPN Zone

39. In the RADIUS shared secret field, enter a shared secret common to all remote firewalls.

40. In the User groups for legacy users fields, define the user groups that correspond to the legacy ‘VPN users,’ ‘VPN client users,’ ‘L2TP users’ and ‘users with Internet access’ privileges. When a user in one of the given user groups is authenticated, the remote firewalls will be informed that the user is to be given the relevant privilege.

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.

41. Select the Test tab.

The ‘Test’ 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 will be displayed.

42. In the Username and Password fields, enter a valid LDAP login name for the LDAP server you configured.

43. Select Password authentication or CHAP (Challenge Handshake Authentication Protocol).

Note CHAP only works with a server that supports retrieving user passwords using LDAP and in some cases requires that the LDAP server to be configured to store passwords reversibly. CHAP cannot be used with Active Directory.

44. Click Test. Status and information returned from the LDAP server are displayed in the Test Status, Message from LDAP, and Returned User Attributes fields.

Tuning Single Sign-On Advanced Settings

This section provides detailed information to help you tune the advanced SSO settings on your firewall. See the following sections:

• Overview on page 749

• About the Advanced Settings on page 749

• Viewing SSO Mouseover Statistics and Tooltips on page 750

• Using the Single Sign-On Statistics in the TSR on page 752

• Examining the Agent on page 753

• Remedies on page 753

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 on page 752 and Viewing SSO Mouseover Statistics and Tooltips on page 750). 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 below, #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.

– 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 on page 754.

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

For information about viewing SSO statistics on the SSO configuration page, see Viewing SSO Mouseover Statistics and Tooltips on page 750.

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, #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.

See the following sections for more information:

• Automatically Generated Rules for SonicWALL SSO on page 753

• Accommodating Mac and Linux Users on page 754

• Allowing ICMP Pings from a Terminal Server on page 755

• About Firewall Access Rules on page 755

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 following technote:
http://www.sonicwall.com/downloads/Using_SSO_with_Samba_TechNote.pdf

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 (with View Style set to All Rules). This checkbox is visible only when SonicWALL SSO is enabled and when the Users Allowed field on the Add Rule page is not set to All. If this checkbox is selected, SSO will not be attempted for traffic that matches the rule, and unauthenticated HTTP connections that match it will be directed straight to the login page. Typically, the Source field 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.

Note 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 on page 395.

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 on page 757

• Configuring Additional SSO User Settings on page 757

• Viewing SSO and LDAP Messages with Packet Monitor on page 757

• Capturing SSO Messages on page 757

• Capturing LDAP Over TLS Messages on page 758

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 the administrator with 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 will be 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 will not be 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, perform the following steps:

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 will be marked with (sso) in the ingress/egress interface field. They will have dummy Ethernet, TCP, and IP headers, so some values in these fields may not be correct.

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

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

 

Capturing LDAP Over TLS Messages

To capture decrypted LDAP over TLS (LDAPS) packets, perform the following steps:

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 will be marked with (ldp) in the ingress/egress interface field. They will have dummy Ethernet, TCP, and IP headers, so some values in these fields may not be correct. The LDAP server port will be 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 will be 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 will enable decrypted LDAPS packets to be fed to the packet monitor, but any monitor filters will still be applied to them.

Note LDAPS capture only works for connections from the firewall’s LDAP client, and will not display LDAP over TLS connections from an external LDAP client that pass through the appliance.

Configuring Multiple Administrator Support

This section contains the following subsections:

• Configuring Additional Administrator User Profiles on page 760

• Configuring Administrators Locally when Using LDAP or RADIUS on page 761

• Preempting Administrators on page 761

• Activating Configuration Mode on page 762

• Verifying Multiple Administrators Support Configuration on page 762

• Viewing Multiple Administrator Related Log Messages on page 763

Configuring Additional Administrator User Profiles

To configure additional administrator user profiles, perform the following steps:

1. While logged in as admin, navigate to the Users > Local Users page.

2. Click the Add User button.

3. Enter a Name and Password for the user.

4. Click on the Group Membership tab.

Select the appropriate group to give the 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 and click OK.

7. To configure the multiple administrator feature such that administrators are logged out when they are preempted, navigate to the System > Administration page.

8. Select the Log out radio button for the On preemption by another administrator option and 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 that in the case of RADIUS you will probably need special configuration of the RADIUS server to return the user group information – see the SonicWALL RADIUS documentation for details.

When using RADIUS or LDAP authentication, if you want to keep the configuration of administrative users local to the appliance whilst having those users authenticated by RADIUS/LDAP, perform these steps:

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 window 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, perform the following steps:

1. Navigate to the System > Administration page.

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.

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