User Management : User Management

Configuring Single Sign-On
Configuring SSO is a process that includes installing and configuring the SonicWALL SSO Agent and/or the SonicWALL Terminal Services Agent (TSA), and configuring a firewall running SonicOS to use the SSO Agent or TSA. For an introduction to SonicWALL SSO, see Single Sign-On Overview . The following sections describe how to configure SSO:
Installing the SonicWALL SSO Agent
The SonicWALL SSO Agent is part of the SonicWALL Directory Connector. The SonicWALL SSO Agent must be installed on at least one, and up to eight, workstations or servers in the Windows domain that have access to the Active Directory server using VPN or IP. The SonicWALL SSO Agent must have access to your firewall.
To install the SonicWALL SSO Agent, perform the following steps:
1
Locate the SonicWALL Directory Connector executable file and double click it. It may take several seconds for the InstallShield to prepare for the installation.
2
On the Welcome page, click Next to continue. The License Agreement displays.
3
Select I accept the terms in the license agreement and click Next to continue. The Customer Information page displays.
4
Enter your name in the User Name field and your organization name in the Organization field. Select to install the application for Anyone who uses this computer (all users) or Only for me (Sonicwall User).
5
Click Next to continue. The Destination Folder page displays.
6
To specify a custom location, click Browse, select the folder, and click Next.
The Custom Setup page displays.
7
8
Click Install to install SSO Agent. The SonicWALL Directory Connector Service User Configuration page displays.
9
To configure a common service account that the SSO Agent will use to log into a specified Windows domain, enter the username of an account with administrative privileges in the Username field, the password for the account in the Password field, and the domain name of the account in the Domain Name field. Click Next. The Default SSO Agent SonicWALL Appliance Configuration page displays.
10
Enter the IP address of your firewall in the SonicWALL Appliance IP field. Type the port number for the same appliance in the SonicWALL Appliance Port field. Enter a shared key (a hexadecimal number from 1 to 16 digits in length) in the Shared Key field. Click Next to continue.
The SonicWALL SSO Agent installs. The status bar displays.
11
When installation is complete, optionally check the Launch SonicWALL Directory Connector box to launch the SonicWALL Directory Connector, and click Finish.
If you checked the Launch SonicWALL Directory Connector box, the SonicWALL Directory Connector displays.
Installing the SonicWALL Terminal Services Agent
Install the SonicWALL TSA on one or more terminal servers on your network within the Windows domain. The SonicWALL TSA must have access to your SonicWALL security appliance, and the appliance must have access to the TSA. If you have a software firewall running on the terminal server, you may need to open up the UDP port number for incoming messages from the appliance.
SonicWALL TSA is available for download without charge from MySonicWALL.
To install the SonicWALL TSA, perform the following steps:
1
You can find these on http://www.mysonicwall.com
2
3
4
The License Agreement displays. Select I agree and click Next to continue.
5
6
On the Confirm Installation window, click Next to start the installation.
7
8
When installation is complete, click Close to exit the installer.
9
Configuring the SonicWALL SSO Agent
The SonicWALL SSO Agent communicates with workstations using NetAPI or WMI, which both provide information about users that are logged into a workstation, including domain users, local users, and Windows services. WMI is pre-installed on Windows Server 2003, Windows XP, Windows ME, and Windows 2000. For other Windows versions, visit www.microsoft.com to download WMI. Verify that WMI or NetAPI is installed prior to configuring the SonicWALL SSO Agent.
The .NET Framework 2.0 must installed prior to configuring the SonicWALL SSO Agent. The .NET Framework can be downloaded from Microsoft at www.microsoft.com.
To configure the communication properties of the SonicWALL SSO Agent, perform the following tasks:
1
Launch the SonicWALL Configuration Tool by double-clicking the desktop shortcut or by navigating to Start > All Programs > SonicWALL > SonicWALL Directory Connector > SonicWALL Configuration Tool.
NOTE: If the IP address for a default firewall was not configured, or if it was configured incorrectly, a pop up will display. Click Yes to use the default IP address (192.168.168.168) or click No to use the current configuration.
If you clicked Yes, the message Successfully restored the old configuration will display. Click OK.
If you clicked No, or if you clicked Yes but the default configuration is incorrect, the message SonicWALL SSO Agent service is not running. Please check the configuration and start the service. will display. Click OK.
If the message SonicWALL SSO Agent service is not running. Please check the configuration and start the service displays, the SSO Agent service will be disabled by default. To enable the service, expand the SonicWALL Directory Connector Configuration Tool in the left navigation panel by clicking the + icon, highlight the SonicWALL SSO Agent underneath it, and click the button.
2
3
From the Logging Level drop-down menu, select the level of events to be logged in the Windows Event Log. The default logging level is 1. Select one of the following levels:
Logging Level 0 - Only critical events are logged.
Logging Level 1 - Critical and significantly severe events are logged.
Logging Level 2 - All requests from the appliance are logged, using the debug level of severity.
4
In the Refresh Time field, enter the frequency, in seconds, that the SSO Agent will refresh user log in status. The default is 60 seconds.
5
From the Query Source drop-down menu, select the protocol that the SSO Agent will use to communicate with workstations, either NETAPI or WMI.
WMI is pre-installed on Windows Server 2003, Windows XP, Windows Me, and Windows 2000. Both NetAPI and WMI can be manually downloaded and installed. NetAPI and WMI provide information about users that are logged into a workstation, including domain users, local users, and Windows services.
6
In the Configuration File field, enter the path for the configuration file. The default path is
C:\Program Files\SonicWALL\DCON\SSO\CIAConfig.xml.
7
Click Accept.
8
Adding a Dell SonicWALL Network Security Appliance
Use these instructions to manually add a firewall if you did not add one during installation, or to add additional firewalls.
To add a firewall, perform the following steps:
1
2
3
Enter the appliance IP address for your Dell SonicWALL network security appliance in the Appliance IP field. Enter the port for the same appliance in the Appliance Port field. The default port is 2258. Give your appliance a friendly name in the Friendly Name field. Enter a shared key in the Shared Key field or click Generate Key to generate a shared key.
4
Your appliance will display in the left-hand navigation panel under the Dell SonicWALL Appliance tree.
Editing Appliances in SonicWALL SSO Agent
You can edit all settings on firewalls previously added in SonicWALL SSO Agent, including IP address, port number, friendly name, and shared key. To edit a firewall in SonicWALL SSO Agent, select the appliance from the left-hand navigation panel and click the Edit icon above the left-hand navigation panel. You can also click the Edit tab at the bottom of the right-hand window.
Deleting Appliances in SonicWALL SSO Agent
To delete a firewall you previously added in SonicWALL SSO Agent, select the appliance from the left-hand navigation panel and click the Delete icon above the left-hand navigation panel.
Modifying Services in SonicWALL SSO Agent
You can start, stop, and pause SonicWALL SSO Agent services to firewalls. To pause services for an appliance, select the appliance from the left-hand navigation panel and click the Pause button . To stop services for an appliance, select the appliance from the left-hand navigation panel and click the Stop button . To resume services, click the Start button .
Configuring the SonicWALL Terminal Services Agent
After installing the SonicWALL TSA and restarting your Windows Server system, you can double-click the SonicWALL TSA desktop icon created by the installer to launch it for configuration, to generate a trouble shooting report (TSR), or to see the status and version information.
Topics:
Adding a Dell SonicWALL Network Security Appliance to SonicWALL TSA Settings
Perform the following steps to add a Dell SonicWALL network security appliance to the SonicWALL TSA:
1
2
The SonicWALL Terminal Services Agent window displays. On the Settings tab, type the IP address of the firewall into the Appliance IP field.
3
Type the communication port into the Appliance Port field. The default port is 2259, but a custom port can be used instead. This port must be open on the Windows Server system.
4
Type the encryption key into the Shared Secret field. Select the Show Secret checkbox to view the characters and verify correctness. The same shared secret must be configured on the firewall.
5
In the Timeout drop-down list, select the number of seconds that the agent will wait for a reply from the appliance before retrying the notification. The range is 5 to 10 seconds, and the default is 5 seconds.
6
In the Retries drop-down list, select the number of times the agent will retry sending a notification to the appliance when it does not receive a reply. The range is 3 to 10 retries, and the default is 5.
7
To enable full details in log messages, select the Enable Verbose Log checkbox. Do this only to provide extra, detailed information in a trouble shooting report. Avoid leaving this enabled at other times because it may impact performance.
8
Click Apply. A dialog box indicates that the SonicWALL TSA service has restarted with the new settings.
Creating a SonicWALL TSA Trouble Shooting Report
You can create a trouble shooting report (TSR) containing all current log messages and information about the agent, driver, and system settings to examine or to send to SonicWALL Technical Support for assistance.
Perform the following steps to create a TSR for the SonicWALL TSA:
1
Double-click the SonicWALL TSA desktop icon. The SonicWALL Terminal Services Agent window displays.
2
Click the Reports tab.
3
4
Viewing SonicWALL TSA Status and Version
To display the current status of the SonicWALL TSA service on your Windows Server system, or to view the version number of the SonicWALL TSA, perform the following steps:
1
Double-click the SonicWALL TSA desktop icon. The SonicWALL Terminal Services Agent window displays.
2
Click the About tab.
3
Click Close.
Configuring SonicOS to Use the SonicWALL SSO Agent
Use the following procedure to configure your firewall to use the SonicWALL SSO Agent:
1
Go to Users > Settings.
2
In the Single-sign-on method(s) section, select SonicWALL SSO Agent. Use this choice to add and configure a TSA as well as an SSO Agent for the SSO method.
3
Click Configure SSO.The SSO Authentication Configuration page displays.
4
Click the SSO Agents tab at the top left, and on the SSO Agents tab under Authentication Agent Settings you can view any SSO Agents already configured. The green LED next to the Agent’s IP address indicates that the agent is currently up and running. A red LED would indicate that the agent is down. A grey LED shows that the agent is disabled. The LEDs are dynamically updated using AJAX.
5
Click the Add button to create an agent. The page is updated to display a new row in the table at the top, and two new tabs (Settings and Advanced) in the lower half of the page.
6
For Host Name or IP Address, enter the name or IP address of the workstation on which SonicWALL SSO Agent is installed.
As you type in values for the fields, the row at the top is updated in red to highlight the new information.
At Port, enter the port number that the SonicWALL SSO Agent is using to communicate with the appliance. The default port is 2258. Note that agents at different IP addresses can have the same port number.
At Shared Key, enter the shared key that you created or generated in the SonicWALL SSO Agent. The shared key must match exactly. Re-enter the shared key in the Confirm Shared Key field.
At Timeout (seconds), enter a number of seconds before the authentication attempt times out. This field is automatically populated with the default of 10 seconds.
At Retries, enter the number of authentication attempts. The default is 6.
7
Click the Advanced tab and then enter the following information:
At Maximum requests to send at a time, enter the maximum number of requests to send from the appliance to the agent at one time. The default is 32.
The agent processes multiple requests concurrently, spawning a separate thread in the agent PC to handle each. Sending too many requests at a time can overload the PC. On the other hand, if the number of simultaneous requests sent from the appliance is too low, some requests will have to wait, possibly causing ring buffer overflows. Too many requests waiting could lead to slow response times in Single Sign On authentication. For more information about checking for ring buffer overflows and related statistics in the SonicOS TSR, see Tuning Single Sign-On Advanced Settings .
8
Click the General Settings tab under Authentication Agent Settings to configure the following options:
Select the Enable SSO agent authentication checkbox to use the SSO Agent for user authentication.
Select the Try next agent on getting no name from NetAPI/WMI checkbox to force a retry of the authentication via a different SSO agent if there is no response or error from the first agent. This only affects agents using NetAPI/WMI.
Select the Don't block user traffic while waiting for SSO checkbox to use the default policy while the user is being identified. This prevents browsing delays.
Select the Including for checkbox and either the All access rules or the Selected access rules radio button to allow traffic affected by access rules that require user authentication, while waiting for user identification.
9
Click the Users tab to display the User Settings page to specify the following options:
Select the Allow only users listed locally checkbox to allow only users listed locally on the appliance to be authenticated.
Select the Simple user names in local database checkbox to use simple user names. When selected, the domain component of a user name will be ignored. User names returned from the authentication agent typically include a domain component, for example, domain1/user1. If this box is not checked, user names in the local database must match exactly the full names returned from the agent, including the domain component.
Select the Allow limited access for non-domain users checkbox to allow limited access to users who are logged in to a computer but not into a domain. These users will not be given membership in the Trusted Users user group, even when set locally, and so will not get any access set for Trusted Users. They are identified in logs as computer-name/user-name.
When using the local user database to authenticate users, and the Simple user names in local database option is disabled, user names must be configured in the local database using the full computer-name/user-name identification.
If your network includes non-Windows devices or Windows computers with personal firewalls running, select the Probe user for checkbox and then select either NetAPI over NetBIOS, NetAPI over TCP, 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. The Probe timeout (seconds) is set to 5 seconds by default.
Select the Probe test mode checkbox to allow testing that SSO probes are functioning correctly during SSO without interfering with user authentications. Probes are sent after initiating user authentication through the SSO agent.
To use LDAP to retrieve user information, select the Use LDAP to retrieve user group information radio button. Click Configure to configure the LDAP settings. The LDAP Configuration page displays. For configuration information for this page, refer to Advanced LDAP Configuration .
At Polling rate (minutes) field, enter a polling interval, in minutes (the default is 1). The security appliance will poll the workstation running SSO Agent once every interval to verify that users are still logged on.
At Hold time after (minutes) field, enter a time, in minutes, that the security appliance will wait before trying again to identify traffic after an initial failure to do so. This feature rate-limits requests to the agent. The default is 1.
Select the Poll the same agent that authenticated the user checkbox if the network topology requires that particular agents be used depending on the location of users, rather than polling any agent to determine if the user is still logged in.
At after finding no user, enter the number of minutes that the appliance should wait before trying again if it gets errors from the SSO agent or when the agent reports that no user is logged in.
10
To populate the User names used by Windows services list, click the Add button. In the Service User name dialog box, type the service login name (the simple name only, without the domain or PC name) into the Enter the name of a user account used by a Windows service field and then click OK.
The purpose of this list is to distinguish the login names used by Windows services from real user logins. When the SSO agent queries Windows to find the user logged into a computer, Windows actually returns a list of user accounts that are/have been logged in to the computer and does not distinguish user logins from service logins, hence giving the SSO agent no way to determine that a login name belongs to a service. This may result in the SSO agent incorrectly reporting a service name instead of the actual user name.
You can enter up to 64 login names here that may be used by services on end-user computers. The SSO agent will ignore any logins using these names.
If, when using Single Sign On, you see unexpected user names shown on the Users > Status page, or logs of user login or user login failure with unexpected user names, those may be due to Windows service logins and those user names should be configured here so that the SSO agent will know to ignore them.
In cases where there are multiple firewalls communicating with an SSO agent, the list of service account names should be configured on only one of them. The effect of configuring multiple lists on different appliances is undefined.
11
To edit an existing service account name, select the name, click Edit. Make the desired changes in the Service User name dialog box and then click OK.
To remove service account names, select one or more names and then click Remove.
12
Click the Enforcement tab if you want to either trigger SSO on traffic from a particular zone, or bypass SSO for traffic from non-user devices such as internal proxy web servers or IP phones.
Under Per-Zone SSO Enforcement, select the checkboxes for any zones on which you want to trigger SSO to identify users when traffic is sent. If SSO is already required on a zone by Application Control or other policies, those checkboxes are pre-selected and cannot be cleared. If Guest Services is enabled on a zone, SSO cannot be enforced and you cannot select the checkbox.
These per-zone SSO enforcement settings are useful for identifying and tracking users in event logging and AppFlow Monitor visualizations, even when SSO is not otherwise triggered by content filtering, IPS, or Application Control policies, or by firewall access rules requiring user authentication.
On zones where security services policies or firewall access rules are set to require user authentication, SSO will always be initiated for the affected traffic and it is not necessary to also enable SSO enforcement here.
The first setting is used where traffic that would be subject to security services screening can emanate from a device other than a user's workstation (such as an internal proxy Web server or IP phone). It prevents the SonicWALL from attempting to identify such a device as a network user in order to select the content filtering policy to apply. The default content filtering policy will be used for all traffic from the selected IP addresses.
The second setting is appropriate for user traffic that does not need to be authenticated, and triggering SSO might cause an unacceptable delay for the service.
SSO bypass settings do not apply when SSO is triggered by firewall access rules requiring user authentication. To configure this type of SSO bypass, add access rules that do not require user authentication for the affected traffic. See Adding Access Rules for more information on configuring access rules.
NOTE: By default, Linux and Mac users who are not authenticated by SSO via Samba are assigned the default content filtering policy. To redirect all such users who are not authenticated by SSO to manually enter their credentials, create an access rule from the WAN zone to the LAN zone for the HTTP service with Users Allowed set to All. Then configure the appropriate CFS policy for the users or user groups. See Adding Access Rules for more information on configuring access rules.
13
Click the Terminal Services tab to display the Terminal Services Agent Settings page.
Click the Terminal Services Agents tab and then click the Add button. The page is updated to display a new row in the table at the top, and new input fields in the lower half of the page.For existing agents, 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. A yellow LED icon means that the TSA is idle and the appliance has not heard anything from it for 5 minutes or more. Because TSA sends notifications to the appliance rather than the appliance sending requests to the agent, a lack of notifications could mean that there is a problem, but more likely means simply that no user on the terminal server is currently active.
In the Host Name or IP Address(es) field, enter the name or IP address of the terminal server on which SonicWALL TSA is installed. If the terminal server is multi-homed (has multiple IP addresses) and you are identifying the host by IP address rather than DNS name, enter all the IP addresses as a comma-separated list.
At Port, enter the port number that the SonicWALL TSA is using to communicate with the appliance. The default port is 2259. Note that agents at different IP addresses can have the same port number.
In the Shared Key field, enter the shared key that you created or generated in the SonicWALL TSA. The shared key must match exactly. Re-enter the shared key in the Confirm Shared Key field.
14
Click the General Settings tab under Terminal Services Agent Settings to configure the following options:
Select the Enable Terminal Services agent authentication checkbox to use the TSA for user authentication.
The Allow traffic from services on the terminal server to bypass user authentication in access rules checkbox is selected by default. This allows traffic such as Windows updates or anti-virus updates, which is not associated with any user login session, to pass without authentication. If you clear this checkbox, traffic from services can be blocked if firewall access rules require user authentication. In this case, you can add rules to allow access for “All” to the services traffic destinations, or configure the destinations as HTTP URLs that can bypass user authentication in access rules.
15
Click the NTLM tab. The NTLM Browser Authentication page displays.
NTLM authentication is supported by Mozilla-based browsers and can be used as a supplement to identifying users via an SSO agent or, with some limitations, on its own without the agent. The firewall interacts directly with the browser to authenticate the user. Users logged in with domain credentials are authenticated transparently; in other cases the user may need to enter credentials to login to the appliance, but should only need to do so once as the credentials are saved.
Consult the tooltips on this tab for additional details, and see How Does Browser NTLM Authentication Work? for more information.
Select one of the following choices from the Use NTLM to authenticate HTTP traffic drop-down list:
Never – Never use NTML authentication
Before attempting SSO via the agent – Try to authenticate users with NTLM before using the SonicWALL SSO agent
Only if SSO via the agent fails – Try to authenticate users via the SSO agent first; if that fails, try using NTLM
For Authentication domain, do one of the following:
Select the Use the domain from the LDAP configuration checkbox to use the same domain that is used in the LDAP configuration.
Fully transparent authentication can only occur if the browser sees the appliance domain as the local domain.
For Redirect the browser to this appliance via, select one of the following options to determine how a user’s browser is initially redirected to the firewall’s own Web server:
The interface IP address – Select this to redirect the browser to the IP address of the appliance Web server interface.
Its domain name from a reverse DNS lookup of the interface IP address – Enables the Show Reverse DNS Cache button at the bottom of the window; when clicked, a popup displays the appliance Web server’s Interface, IP Address, DNS Name, and TTL in seconds. Click the button to verify the domain name (DNS name) being used for redirecting the user’s browser.
Its configured domain name – Use the firewall's domain name as configured on the System > Administration page.
The name from the administration certificate – Use the imported certificate that is selected for HTTPS Web Management on the System > Administration page.
Enter a number of retries in the Maximum retries to allow on authentication failure.
To detect when users log out, select the polling method to be used by the appliance for Windows, Linux, and Macintosh users in the On the poll timer, for users authenticated user via NTLM options. Select the radio button for one of the following methods for users on each type of computer:
Poll via the SSO agent – If you are using an SSO Agent in your network, select this to use it to poll users; for users authenticated via NTLM, the user name that the agent learns must match the name user for the NTLM authentication, or the login session will be terminated. You may want to select a different polling method for Linux or MacOS users, as those systems do not support the Windows networking requests used by the SSO agent.
Re-authenticate via NTLM – This method is transparent to the user if the browser is configured to store the domain credentials, or the user instructed the browser to save the credentials.
Don’t re-authenticate – If you select this option, logout will not be detected other than via the inactivity timeout.
If you are using older legacy servers that require legacy LAN Manager components to be included in NTLM messages, select the Forward legacy LanMan in NTLM checkbox. This may cause authentication to fail in newer Windows servers that don’t allow LanMan in NTLM by default because it is not secure.
16
Click the RADIUS Accounting tab to display the RADIUS Accounting Single-Sign-On page.
Single Sign-On by RADIUS accounting allows the appliance to act as a RADIUS accounting server for external third-party appliances, and to log users in or out based on the accounting messages from those devices. SonicOS can also forward the accounting messages to another RADIUS accounting server.
17
Click the Test tab to display the Test Authentication Agent Settings page.
You can test the connectivity between the appliance and an SSO agent or TSA. You can also test whether the SSO agent is properly configured to identify a user logged into a workstation.If you have multiple agents configured, select the SSO agent or TSA to test from the Select agent to test drop-down list. The drop-down list includes SSO agents at the top, and TSA’s at the end under the heading --Terminal Server Agents--.
Select the Check agent connectivity radio button and then click the Test button. This will test communication with the authentication agent. If the firewall can connect to the SSO agent, you will see the message Agent is ready. If testing a TSA, the Test Status field displays the message, and the version and server IP address are displayed in the Information returned from the agent field.
For SSO agents only, select the Check user radio button, enter the IP address of a workstation in the Workstation IP address field, then click Test. This will test if the SSO agent is properly configured to identify the user logged into a workstation.
TIP: If you receive the messages Agent is not responding or Configuration error, check your settings and perform these tests again.
18
Configuring RADIUS Accounting for SSO
RADIUS accounting for Single Sign-On is configured on the Users > Settings page.
To configure RADIUS accounting for SSO, follow these steps:
1
Display the Users > Settings page.
2
Click the Configure SSO button. The SSO Authentication Configuration dialog appears.
3
Click the RADIUS Accounting tab.
4
To add a new RADIUS client, click the Add button. The Settings, RADIUS, and Forwarding tabs appear in the lower half of the screen.
Repeat these steps for each RADIUS accounting client that you want to add; each RADIUS accounting client that you add is listed in the RADIUS Accounting Single-Sign-On panel.
The Status column shows the current status for each RADIUS accounting client listed in the panel as follows:
5
Click the Settings tab to enter the following information:
In the Client host name or IP address field, enter the name or the IP address for the RADIUS client host.
In the Shared Secret and the Confirm Secret fields, enter your shared secret for the client.
6
Click the RADIUS tab to specify user options.
From the User-Name attribute format drop-down list, select the format for the user name login.
Select the Log user out if no accounting interim updates are received checkbox and then enter the period of time in minutes after which the user is logged out.
7
Click the Forwarding tab to configure message delivery settings for up to four RADIUS accounting servers.
At Timeout, enter the timeout period in seconds.
At Retries, enter the number of retries.
Try next on timeout – In case a server times out, SonicOS will use the next server on the list to forward messages.
Forward to all – SonicOS will forward messages to all servers on the list.
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 , you must configure your LDAP settings.
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.
3
In the Port Number field, enter the port number of your LDAP server. The default LDAP ports are:
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.
15
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.
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.
24
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.
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.
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
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.
32
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.
37
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:
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.
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).
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
Topics:
Overview
When a user first tries to send traffic through a SonicWALL that is using SSO, the appliance sends a “who is this” request to SonicWALL SSO Agent. The agent queries the user’s PC via Windows networking, and returns the user name to the firewall. If the user name matches any criteria set in the policies, then the user is considered as “logged on” by the SonicWALL. When users are logged into the SonicWALL using SSO, the SSO feature also provides detection of logouts. To detect logouts, the appliance repeatedly polls the agent to check if each user is still logged in. This polling, along with the initial identification requests, could potentially result in a large loading on the SonicWALL SSO Agent application and the PC on which it is running, especially when very large numbers of users are connecting.
The SonicWALL SSO feature utilizes a rate-limiting mechanism to prevent the appliance from swamping the agent with these user requests. Both automatic calculations and a configurable setting on the appliance govern how this rate-limiting operates. The SonicWALL SSO feature automatically calculates the maximum number of user requests contained in each message to the agent that can be processed in the poll period, based on recent polling response times. Also, the timeout on a multi-user request is automatically set to be long enough to reduce the likelihood of an occasional long timeout during polling. The configurable setting controls the number of requests to send to the agent at a time, and can be tuned to optimize SSO performance and prevent potential problems. This section provides a guide to choosing suitable settings.
The potential for problems resulting from overloading the agent can be reduced by running the agent on a dedicated high-performance PC, and possibly also by using multiple agents on separate PCs, in which case the load will be shared between them. The latter option also provides redundancy in case one of the agent PCs fails. The agent should run on a Windows Server PC (some older workstations could be used but changes in later Windows 2000/XP/Vista workstation releases and in service packs for the older versions added a TCP connection rate limiting feature that interferes with operation of the SSO agent).
About the Advanced Settings
The Maximum requests to send at a time setting is available on the Advanced tab of the SSO agent configuration.
This setting controls the maximum number of requests that can be sent from the appliance to the agent at the same time. The agent processes multiple requests concurrently, spawning a separate thread in the PC to handle each. Sending too many requests at a time can overload the PC on which the agent is running. If the number of requests to send exceeds the maximum, then some are placed on an internal “ring buffer” queue (see Using the Single Sign-On Statistics in the TSR and Viewing SSO Mouseover Statistics and Tooltips ). Requests waiting on the ring buffer for too long could lead to slow response times in SSO authentication.
This setting works in conjunction with the automatically calculated number of user requests per message to the agent when polling to check the status of logged in users. The number of user requests per message is calculated based on recent polling response times. SonicOS adjusts this number as high as possible to minimize the number of messages that need to be sent, which reduces the load on the agent and helps reduce network traffic between the appliance and the agent. However, the number is kept low enough to allow the agent to process all of the user requests in the message within the poll period. This avoids potential problems such as timeouts and failures to quickly detect logged out users.
Viewing SSO Mouseover Statistics and Tooltips
The SSO Configuration page provides mouseover statistics about each agent, and mouseover tooltips for many fields. On the Settings tab, a green LED-style icon next to an agent indicates that the agent is up and running. A red LED icon indicates that the agent is down.
To view the statistics for a particular agent, hover your mouse pointer over the statistics icon to the right of the SSO agent. This also works for individual TSAs on the Terminal Services tab.
To view the statistics for all SSO activity on the appliance, hover your mouse pointer over the statistics icon at the bottom of the table, in the same row as the Add button.
To close the statistics display, click close.
To clear all the displayed values, click Click to reset.
To view the tooltips available for many fields in the SSO configuration screens, hover your mouse pointer over the triangular icon to the right of the field. The tooltip will display until you move your mouse pointer away.
Using the Single Sign-On Statistics in the TSR
A rich set of SSO performance and error statistics is included in the trouble shooting report (TSR). These can be used to gauge how well SSO is performing in your installation. Download the TSR on the System > Diagnostics page and search for the title “SSO operation statistics”. The following are the counters to look at in particular:
1
Under SSO ring buffer statistics, look at Ring buffer overflows and Maximum time spent on ring. If the latter approaches or exceeds the polling rate, or if any ring buffer overflows are shown, then requests are not being sent to the agent quickly enough. Also, if the Current requests waiting on ring is constantly increasing, that would indicate the same. This means that the Maximum requests to send at a time value should be increased to send requests faster. However, that will increase the load on the agent, and if the agent cannot handle the additional load, then problems will result, in which case it may be necessary to consider moving the agent to a more powerful PC or adding additional agents.
2
Under SSO operation statistics, look at Failed user id attempts with time outs and Failed user id attempts with other errors. These should be zero or close to it – significant failures shown here indicate a problem with the agent, possibly because it cannot keep up with the number of user authentications being attempted.
3
Also under SSO operation statistics, look at the Total users polled in periodic polling, User polling failures with time outs, and User polling failures with other errors. Seeing some timeouts and errors here is acceptable and probably to be expected, and occasional polling failures will not cause problems. However, the error rate should be low (an error rate of about 0.1% or less should be acceptable). Again, a high failure rate here would indicate a problem with the agent, as above.
4
Under SSO agent statistics, look at the Avg user ID request time and Avg poll per-user resp time. These should be in the region of a few seconds or less – something longer indicates possible problems on the network. Note, however, that errors caused by attempting to authenticate traffic from non-Windows PCs via SSO (which can take a significantly long time) can skew the Avg user ID request time value, so if this is high but Avg poll per-user resp time looks correct, that would indicate the agent is probably experiencing large numbers of errors, likely due to attempting to authenticate non-Windows devices – see below, Step 6.
5
If using multiple agents, then also under SSO agent statistics look at the error and timeout rates reported for the different agents, and also their response times. Significant differences between agents could indicate a problem specific to one agent that could be addressed by upgrading or changing settings for that agent in particular.
6
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.
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.
To limit the rate of errors due to this you can also extend the Hold time after failure setting on the Users tab.
Examining the Agent
If the above statistics indicate a possible problem with the agent, a good next step would be to run Windows Task Manager on the PC on which the agent is running and look at the CPU usage on the Performance tab, plus the CPU usage by the “CIAService.exe” process on the Processes tab. If the latter is using a large percentage of the CPU time and the CPU usage is spiking close to 100%, this is an indication that the agent is getting overloaded. To try to reduce the loading you can decrease the Maximum requests to send at a time setting; see Using the Single Sign-On Statistics in the TSR above, Step 1.
Remedies
If the settings cannot be balanced to avoid overloading the agent’s PC while still being able to send requests to the agent fast enough, then one of the following actions should be taken:
Consider reducing the polling rate configured on the Users tab by increasing the poll time. This will reduce the load on the agent, at the cost of detecting logouts less quickly. Note that in an environment with shared PCs, it is probably best to keep the poll interval as short as possible to avoid problems that could result from not detecting logouts when different users use the same PC, such as the initial traffic from the second user of a PC possibly being logged as sent by the previous user.
Configuring Firewall Access Rules
Enabling SonicWALL SSO affects policies on the Firewall > Access Rules page of the SonicOS management interface. Rules set under Firewall > Access Rules are checked against the user group memberships returned from a SSO LDAP query, and are applied automatically.
Topics:
Automatically Generated Rules for SonicWALL SSO
When a SonicWALL SSO agent or TSA is configured in the SonicOS management interface, a Firewall access rule and corresponding NAT policy are created to allow the replies from the agent into the LAN. These rules use either a SonicWALL SSO Agents or SonicWALL Terminal Services Agents address group object, which has a member address object for each configured agent. The member address objects are automatically added to and deleted from the group object as agents are added or deleted. The member address objects are also updated automatically as an agent’s IP address changes, including when an IP address is resolved via DNS (where an agent is given by DNS name).
If SonicWALL SSO agents or TSAs are configured in different zones, the Firewall access rule and NAT policy are added to each applicable zone. The same SonicWALL SSO Agents or SonicWALL Terminal Services Agents address group is used in each zone.
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.
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.
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:
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.
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.
For detailed information about access rules, see Firewall > Access Rules .
Managing SonicOS with HTTP Login from a Terminal Server
The firewall normally grants access through policies based on authentication credentials supplied via HTTP login for one user at an IP address. For users on a terminal server, this method of authenticating one user per IP address is not possible. However, HTTP login is still allowed from a terminal server only for the purpose of administration of the appliance, subject to the following limitations and requirements:
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.”
Viewing and Managing SSO User Sessions
This section provides information to help you manage SSO on your firewall. See the following sections:
Logging Out SSO Users
The Users > Status page displays Active User Sessions on the firewall. The table lists User Name, IP Address, Session Time, Time Remaining, Inactivity Remaining, Settings, and Logout. For users authenticated using SonicWALL SSO Agent, the message Auth. by SSO Agent will display. To logout a user, click the delete icon next to the user’s entry.
NOTE: Changes in a user’s settings, configured under Users > Settings, will not be reflected during that user’s current session; you must manually log the user out for changes to take effect. The user will be transparently logged in again, with the changes reflected.
Configuring Additional SSO User Settings
The Users > Settings page provides 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.
Changes applied in the Users > Settings page during an active SSO session will not be reflected during that session.
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
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
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.