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:
|
•
|
|
•
|
|
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
|
|
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
|
|
•
|
|
7
|
is displayed by default next to the SonicWALL SSO Agent feature. Click |
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.
|
|
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.
|
3
|
On the Welcome page, click Next to continue.
|
|
4
|
|
5
|
On the Select Installation Folder window, select the destination folder. To use the default folder, C:\Program Files\SonicWALL\SonicWALL Terminal Services Agent\, click Next. To specify a custom location, click Browse, select the folder, and click Next.
|
|
6
|
On the Confirm Installation window, click Next to start the installation.
|
|
8
|
When installation is complete, click Close to exit the installer.
|
|
9
|
You must restart your system before starting the SonicWALL Terminal Services Agent. To restart immediately, click Yes in the dialog box. To restart later, click No.
|
|
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 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.
button.|
2
|
In the left-hand navigation panel, expand the SonicWALL Directory Connector Configuration Tool by clicking the + icon. Right click the SonicWALL SSO Agent and select Properties.
|
|
3
|
From the Logging Level drop-down menu, select the level of events to be logged in the Windows Event Log. The default logging level is 1. Select one of the following levels:
|
|
•
|
Logging Level 0 - Only critical events are logged.
|
|
•
|
Logging Level 1 - Critical and significantly severe events are logged.
|
|
•
|
Logging Level 2 - All requests from the appliance are logged, using the debug level of severity.
|
|
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.
|
|
6
|
In the Configuration File field, enter the path for the configuration file. The default path is
C:\Program Files\SonicWALL\DCON\SSO\CIAConfig.xml. |
|
7
|
Click Accept.
|
|
8
|
Click OK.
|
|
2
|
Expand the SonicWALL Directory Connector and SonicWALL SSO Agent trees in the left column by clicking the + button. Right click SonicWALL Appliance and select Add.
|
|
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.
|
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.
above the left-hand navigation panel. You can also click the Edit tab at the bottom of the right-hand window. 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.
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 
.
. 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 . 
Perform the following steps to add a Dell SonicWALL network security appliance to the SonicWALL TSA:
|
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.
|
|
1
|
|
2
|
Click the Reports tab.
|
|
•
|
Save it as a text file, click Save As.
|
|
4
|
When finished, click Close.
|
|
1
|
|
2
|
Click the About tab.
|
|
3
|
Click Close.
|
|
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
|
|
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
|
Enter the following information in the Settings tab:
|
|
•
|
For Host Name or IP Address, enter the name or IP address of the workstation on which SonicWALL SSO Agent is installed.
|
|
•
|
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.
|
|
•
|
|
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
|
|
•
|
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 .
|
|
•
|
To use locally configured user group settings, select the Local configuration radio button.
|
|
•
|
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.
|
|
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.
|
|
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.
|
|
•
|
To bypass SSO for traffic from certain devices or locations and apply the default content filtering policy to the traffic, select the appropriate address object or address group from the first drop-down menu under SSO Bypass. To bypass SSO for certain services or types of traffic, select the service from the second drop-down menu.
|
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.
|
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.
|
|
•
|
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.
|
|
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.
|
RADIUS accounting for Single Sign-On is configured on the Users > Settings page.
|
1
|
Display the Users > Settings page.
|
|
2
|
|
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.
|
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.
|
|
•
|
|
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
|
|
•
|
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.
|
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.
|
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. |
|
29
|
Select the Referrals tab.
|
|
•
|
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.
|
|
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.
|
|
42
|
In the Username and Password fields, enter a valid LDAP login name for the LDAP server you configured.
|
|
43
|
|
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.
|
|
•
|
|
•
|
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.
to the right of the SSO agent. This also works for individual TSAs on the Terminal Services tab.
To clear all the displayed values, click Click to reset.
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.
|
|
•
|
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.
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.
|
•
|
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.
|
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.
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.
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).
|
•
|
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
http://www.sonicwall.com/downloads/Using_SSO_with_Samba_TechNote.pdf
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.
|
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.
|
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.
|
•
|
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.”
|
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.
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.
|
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.
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.
|
1
|
|
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.
Captured SSO messages are displayed fully decoded on the System > Packet Monitor screen.
|
1
|
|
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.