Configuring SonicOS to Use the SonicWALL SSO Agent

Use the following procedure to configure your firewall to use the SonicWALL SSO Agent:

Go to Users > Settings.

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.

Click Configure SSO.The SSO Authentication Configuration dialog displays.

Topics:

•

SSO Agents Tab

•

Users Tab

•

Enforcement Tab

•

Terminal Services Tab

•

NTLM Tab

•

Radius Accounting Tab

•

Test Tab

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.

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.


	TIP: You can modify any of the entries by clicking on it. The entry turns into an editable field.

Enter the following information in the Settings tab. As you type in values for the fields, the row at the top is updated in red to highlight the new information.

•

For Host Name or IP Address, enter the name or IP address of the workstation on which SonicWALL SSO Agent is installed. By default, 0.0.0.0 is entered.

•

At Port, enter the port number that the SonicWALL SSO Agent is using to communicate with the appliance. The default port is 2258.


	NOTE: 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.

Click the Advanced tab.

At Maximum requests to send at a time, enter the maximum number of simultaneous 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. The number of simultaneous requests that the authentication agent can handle depends on the performance level of the PC that it runs on and of the network. Increasing this setting could make SSO user authentication more efficient, but setting it too high could swamp the agent by sending too many requests at a time, thus overloading the PC and resulting in timeouts and authentication failures.

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. If this setting cannot be increased high enough to avoid ring buffer warnings without getting a significant numbers of timeouts, then consider moving the agent to a higher-performance, dedicated machine, or possibly adding additional agents. For more information about checking for ring buffer overflows and related statistics in the SonicOS TSR, see Single Sign-On Advanced Features .


	TIP: Look at the statistics in the Single Sign On Authentication section of the Tech Support Report. If significant numbers of timeouts are shown, then decreasing this value may help. If the Maximum time spent on ring approaches or exceeds the polling rate (configured on the Users tab) or if any ring buffer overflows are shown, then this value should probably be increased.

Click the General Settings tab under Authentication Agent Settings.

Configure the following options:

•

Select the Enable SSO agent authentication checkbox to use the SSO Agent for user authentication. This setting is selected by default.

•

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. This setting is not selected by default. See also the Poll the same agent that authenticated the user setting on the Users tab, which needs to be set if this setting is enabled.


	NOTE: This setting affects only agents using NetAPI/WMI, not any agents that use just the domain controller security log lookup mechanism.

The NetAPI/WMI protocols used by the SSO agent for user identification are provided by Windows, and what they actually do is outside the control of the agent or appliance. When using NetAPI or WMI, should Windows respond with no user name and no error to a request from an agent, then by default, the appliance assumes that other agents get the same and does not retry the request via another agent (as it would do should it receive an error response).

If you enable this setting, then on getting such a response with no user name from an agent, the appliance treats the response as an error and retries the request via a different agent. Should you see authentication failures getting logged as SSO agent returned no user name when you think the users should have been identified, try enabling this setting.

Enabling this setting would typically be needed in a situation where only some of the agents can reach certain users, for example, if it is necessary to place an agent at a remote site to identify the users there because they cannot be reached easily by the agents at the central site.

•

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. This setting is not selected by default.

When a user is being identified via SSO, traffic from the user is normally blocked until identification is complete so proper policies can be applied where applicable. Sometimes an SSO agent takes a significant time to identify a user, however, and that delay can result in users experiencing browsing delays.

This setting allows you to override that delay and instead allow users traffic through while waiting for SSO, with default policies applied until the user is identified.

You also can choose whether to allow through traffic when a user needs to be identified for an access rule that requires user authentication (that is, when a user would not otherwise be allowed any access if not identified).


	IMPORTANT: Take care with doing this as it can temporarily allow through a user who would not be allowed when identified. If you choose to do this for selected access rules, then a setting for it appears in the advanced settings of those rules that require user authentication.

•

Select the Including for checkbox and either the All access rules (default) or the Selected access rules radio button to allow traffic affected by access rules that require user authentication, while waiting for user identification.


	CAUTION: This can temporarily allow access that would not be allowed when the user is identified.

•

To have all the SSO agents synchronize their user databases, select either:

•

Sync all agents – To synchronize together no matter what identification mechanisms they use, thus giving a single, homogenous user database duplicated on every agent.

•

Synch those with the same user identification mechanisms – To synchronize only those databases using the same identification mechanism; this is the default.

Each SSO agent maintains its own database of the users that it has identified, and the agents can optionally be configured to synchronize those databases, thus giving a common user database duplicated on each agent. A common, synchronized user database makes user lookups more efficient and gives better redundancy. By specifying synchronicity here, the appliance can inform each agent of the other agents with which to synchronize, thereby avoiding the complexity of having to configure it in the agents.

By default, the appliance has those agents configured to use the same user identification mechanisms synchronize together. For example, if some agents are reading domain controller logs while others use NetAPI, then two separate, external databases in the two groups of agents result, one database of those user found in the domain controller logs and a separate database of the users identified by NetAPI.


	NOTE: This setting can be overridden by explicitly configuring in each SSO agent the list of other agents with which to synchronize.

•

Configure the list of Windows service user names in the User names used by Windows services table. You can list up to 64 user names that may be used by services on the end-users’ PCs; any log ins with these names are assumed to be service log ins and are ignored by the SSO agent(s).

Click the Add button. the Service User name dialog displays.

Enter the service user name.

Click OK.

Windows services log on to the machine or domain using user accounts just as real users do. Some of the Windows’ APIs used by the SSO agent do not provide for distinguishing these service log ins from real user log ins, which can lead to the SSO agent incorrectly reporting the user name used by a service instead of that of the actual user.

Users Tab

Click the Users tab to specify the following the User Settings options:

•

Select the Allow only users listed locally checkbox to allow only users listed locally on the appliance to be authenticated. This setting is disabled by default.

•

Select the Simple user names in local database checkbox to use simple user names. This setting is disabled by default.


	NOTE: This setting is dimmed unless the Allow only users listed locally setting is enabled.

User names returned from the authentication agent or from NTLM authentication usually include a domain component, for example, domain1/bob. When this setting is selected, the domain component of a user name is ignored, and just the user name component is matched against names in the Dell SonicWALL appliance’s local user database. If this box is not checked, local user account names that are to match SSO-authenticated users must conform to the full user name, including any domain component.

NOTE: Domain components can take the following formats:

•

Windows: either DOMAIN1|bob or DOMAIN1/bob, where DOMAIN1 is the sort-form (NetBIOS) domain name; it must be all uppercase if local user names are case-sensitive.

•

Novell: either the user’s Novell name with context (for example, bob.user.domain1) or their LDAP distinguished name (for example, cn=bob,ou=users,o=domain1).

•

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 are not given membership in the Trusted Users user group, even when set locally, and so do not get any access set for Trusted Users. The are given access through policies, etc., that apply to Everyone or that specifically list them as allowed users. This setting is disabled by default.

These users 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.


	NOTE: This does not apply for users authenticated via NTLM. With NTLM, authentication non-domain users are given access only if the name/password matches a local user account created on the appliance.

•

If your network includes non-Windows devices or Windows computers with personal firewalls running, select the Probe user for checkbox and then select one of the following, depending on which is configured for the SSO Agent:

•

NetAPI over NetBIOS

•

NetAPI over TCP

•

WMI

When the SSO agent attempts to identify a user in a Windows domain, if the agent uses NetAPI or WMI, then when the agent tries to communicate directly with the user’s computer from which the traffic is originating. This can cause problems:

•

When traffic is coming from non-Windows devices as such devices do not respond to, or may block, the Windows networking messages used by the SSO Agent to identify a user.

•

With Windows computers if personal firewalls on them are blocking them.

The result can be that the agent may get overloaded with multiple threads waiting for requests that are not getting replies.

To avoid these problems, enable this setting (it is disabled by default) and select the correct NetAPI/WMI protocol that the SSO agent is configured to use. Before sending a request to the agent to identify a user via NetAPI or WMI, the Dell SonicWALL appliance probes the machine from which the traffic originated to verify if it responds on the port used by the NetAPI or WMA protocol. If it does not, then the device fails SSO immediately without the agent getting involved.


	NOTE: This setting does not affect an agent that reads user login information from the domain controller(s).

•

If the Probe users for setting is enabled, it causes the firewall to probe for a response on the NetAPI/WMI port before requesting that the SSO Agent identify a user. The Probe timeout (seconds) is set to 5 seconds by default.

•

Select the Probe test mode checkbox to test that SSO probes are functioning correctly during SSO without interfering with user authentications. Probes are sent after initiating user authentication through the SSO agent. This setting is disabled by default.

If this setting is enabled, the probes are sent after initiating user authentication via the sSO agent (normally, the latter is done if the probe is successful). Statistics for the probing are updated as normal, and if a probe fails for a user who is successfully authenticated by the agent, then that is reported via a message on the console port.

•

For the Mechanism for setting user group memberships, select either:

•

Use LDAP to retrieve user group information radio button to use LDAP to retrieve user information

•

To configure the LDAP settings click Configure. The LDAP Configuration dialog displays. For configuration information for this dialog, refer to Advanced LDAP Configuration .

•

Local configuration radio button to use locally configured user group settings.

•

In the Polling rate (minutes) field, enter a polling interval, in minutes (the default is 5). After a user has been identified and logged in, the Dell SonicWALL poll the authentication agent at this rate to verify the user is still logged in.

If you are using NTLM authentication, then in the NTLM settings you can selectively choose to have the appliance poll users by forcing them to re-authenticate via NTLM rather than polling via the agent.

•

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. This setting is disabled by default.


	NOTE: The Try next agent on getting no name from NetAPI/WMI setting on the SSO Agents General Settings tab also needs to be set if this is set.

By default, the appliance assumes that any SSO agent can send NetAPI or WMI requests to any user, so when polling to check if users are still logged in, the appliance can choose any agent based on current loadings. If this is not the case, and the network topography requires particular agents be used depending on the location of the users, then enable this setting. When it is enabled, after a user is successfully identified by an agent, subsequent polling of the user is performed via that same agent.


	NOTE: This setting affects only agents using NetAPI/WMI, not any agents that use just the domain controller security log lookup mechanism.

•

In the Hold time after (minutes) field, enter a time, in minutes, that the security appliance waits before trying again to identify traffic after an initial failure to do so. This feature rate limits requests to the agent to avoid possibly flooding it with requests if further traffic continues to be received from sources that repeatedly fail SSO. The default is 1 minute.


	NOTE: The times to hold off after getting errors from the SSO agent and after the agent reports that no user is logged in are set separately, so they are configured separately.

•

In the …after finding no user field, 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. The default is 1 minute.

To give consistent naming for a domain in logging, select one of the following radio buttons for When different SSO sources report different name variants for a user’s domain:

•

Use the domain name as received (default)

•

Always use a consistent domain name

By default, a user identified via SSO is logged in on the Dell SonicWALL appliance with whatever domain name is reported to it by the external source that identified the user. A doman, however, typically has two or three different variants of its domain name (for example, a Windows domain has its DNS name, its NetBIOS name, and its Kerberos realm name), and different SSO sources may report different variants of these for a user in the same domain.

This difference can cause difficulty in tracking users by domain in logging, so you can instead select to make the names consistent by having the same domain name variant used for all the users in a domain, no matter which variant is reported to the Dell SonicWALL appliance.

If you have selected Always use a consistent domain name, click the Select button. The Select the name variant to use for each domain dialog lists known domains from which you can select the names to use is displayed.

Select the variant(s) to use. The initial default variant for each domain is None, which means that behavior of using whatever domain name is reported to the appliance via SSO does not change until Always use a consistent domain name is enabled and the domain name to use is selected here.


	NOTE: If a domain is not shown in this list, wait until the SSO has identified some users in the domain, then repeat this step.

Click OK.

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.

Enforcement Tab

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.

•

LAN

•

DMZ

•

VPN

•

WLAN

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.


	NOTE: On zones where security services policies or firewall access rules are set to require user authentication, SSO is always initiated for the affected traffic and it is not necessary to also enable SSO enforcement here.

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.

To bypass SSO for traffic from certain services or locations and apply the default content filtering policy to the traffic, select the appropriate service or location from the list in the SSO Bypass table or add a new service or location to the table. The table displays the built-in services that bypass SSO; these services cannot be delete.


	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. TIP: You could create SSO bypass address and/or service group objects for this and reference those same ones both here and in those access rules.

SSO bypass may be necessary, for example, for:

•

Traffic emanating from a non-user device, such as an internal mail server or an IP phone.

•

User traffic that does not need to be authenticated and might be adversely affected by delays waiting for SSO.

For traffic that bypasses SSO, the default content filtering policy is applied. If any APP rules or IPS/Anti-Spyware policies are set to include/exclude users, then that traffic is no included/excluded respectively with those.

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 separate access rules that do not require user authentication for the affected traffic. See Adding Access Rules for more information on configuring access rules.

Optionally, to add a service or location:

Click the Add button. The Add an SSO bypass rule dialog displays.

For Bypass SSO for, select either the Services or Addresses radio button.

Select a service or address from the drop-down menu.

Select the Bypass type:

•

Full bypass (don’t trigger SSO

•

Trigger SSO but bypass holding packets while waiting for it

Click Add. The entry is added to the table

To select a SSO bypass user name for logging, select the Log user name <bypass name> for SSO bypasses checkbox and specify a name for the SSO bypassed user. This setting is selected by default and a default name of Unknown (SSO bypassed) is specified.If this setting is enabled, then when traffic bypasses SSO (as configured here), the traffic is shown in logs and AppFlow Monitor with the given user name rather than as from an unknown user, thus allowing it to be differentiated from traffic sent by users whom SSO could not identify.


	TIP: You also can configure logging on the Users > Settings page under User Session Settings.

Optionally, select Create a dummy user checkbox. This setting is not selected by default.

If this setting is enabled, on receiving SSO bypass traffic, a dummy user entry is created with the given user name for the originating IP address. Then, in addition to the name appearing in logs and the AppFlow Monitor, the dummy user entry shows on the Users > Status page. The dummy name remains in existence until traffic from the IP address stops for the given inactivity time or, in the case of bypass services, until non-bypass traffic is received from it.


	NOTE: This dummy user name applies only for bypass rules set for full SSO bypass. Any set to trigger SSO, but bypass holding packets while waiting for it results in the user being set according to the result of the triggered SSO identification.

Optionally, specify an inactivity timeout, in minutes, in the Inactivity timeout (mins) field. The default is 15 minutes.

Terminal Services Tab

Click the Terminal Services tab to specify the following Terminal Services Agent Settings options.

•

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.

•

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

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. This setting is enabled by default.

•

The Allow traffic from services on the terminal server to bypass user authentication in access rules checkbox is selected by default. This allows service traffic, such as Windows updates or anti-virus updates not associated with any user login session, to pass without authentication. That traffic normally would be blocked if the applicable firewall rules are set to require user 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.

NTLM Tab

Click the NTLM tab.

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.

Configure these settings;

•

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:

•

Enter the full DNS name of the firewall’s domain in the form “www.somedomain.com”

•

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.

Radius Accounting Tab

Click the RADIUS Accounting tab to display the RADIUS Accounting Single-Sign-On tabs.

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. For third-party appliances that use RADIUS accounting for other purposes, SonicOS can also forward the RADIUS accounting messages to another RADIUS accounting server.

The Status column shows the current status for each RADIUS accounting client listed in the panel:

•

Green—the client is active

•

Yellow—the client is idle

To add a new RADIUS client, click the Add… button. The RADIUS Accounting Single-Sign-On tabs, Settings, RADIUS, and Forwarding, appear in a view/edit pane in the lower half of the dialog.


	NOTE: Changes made in the view/edit pane are instated directly into the highlighted entry in the Accounting Clients table as they are made. On completion, click anywhere outside of the pane to close it. Individual fields in the Accounting Clients table also can be updated by clicking on them directly in the table.

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 field and the Confirm Secret field, enter your shared secret for the client.

Click the RADIUS tab.

From the User-Name attribute format drop-down menu, select the format for the user name login.

RADIUS Accounting does not specify the format of the content of the User-Name attribute passed in RADIUS Accounting messages. You need to enter, therefore, the format that is sent by the client. You can select from some common formats:

•

•

•

•

•


	IMPORTANT: These pre-defined formats are for common cases,. If those do not match what your network access server sends, then you must select Other as the User-Name attribute format and then enter a customized format.

Or, you can select a non-standard format, Other.

If you selected:

•

A standard format, go to Step 8.

•

If you select Other, more settings appear so you can configure the components to be found in the attribute:

•

Format

•

Components

In the Format field, enter a limited scanf-style string, with either a %s or %[…] directive for each component. This directive tells the appliance what the network access device (NAS) sends in the User-Name attribute. This format is not specified by the RADIUS Accounting RFC. Devices are not constrained as to what they can send in this attribute, so, its content can be very variable. What you set here specifies how the appliance must decode the User-Name attribute to extract the user name, domain, and/or DN.


	TIP: When you select Other, these fields are set to the format string and components of the previously selected format. So, first select the pre-defined format that most closely matches what your network access server sends. This gives you a good starting point for entering your customized format. Then, change to Other.

From the Component drop-down menu, select one of the following:

•

Not used

•

User-Name (default)

•

Domain

•

The components that you enter as a limited scanf-style string in the Format field consist of one or more of the following items:

•

User-Name

•

Domain

•

Fully qualified distinguished name (DN)


	NOTE: You can double click in the Components drop-down menu to display a tooltip with instructions on how to enter the scanf-style format.

Click Add component. The Add a component to the User-Name attribute format dialog displays.


	NOTE: If you understand the scanf-style format, you can edit the Format field directly instead of using the Add component button. TIP: Use %s for a component that is followed by white space or is at the end. For a component followed by some other character, use %[^x]x. For example, the Format string for the name@domain format would be %[^@]@%s, with the three components set to User-Name, Domain, and Not used.

Select the type of component from the Component to add drop-down menu:

•

User-name

•

Domain

•

Enter text to separate entries in the Preceding text after the User-name field.

Click Add. the Accounting Clients table is updated and more options appear in the Radius view/edit pane.

Repeat Step b through Step f for each component.

To delete the last component you added, click Remove last component.

A RADIUS Accounting client can optionally send Interim Update messages periodically while a user is logged in. If the client does sends the messages at a reasonably constant interval, then the Dell SonicWALL appliance can monitor them and assume that the user has been logged out should the messages stop being sent. This process gives a fallback mechanism to guard against missing RADIUS Accounting Stop messages, which are sent on user log out.

Select a Log user out if no accounting interim updates are received option.

•

Disabled – to not have messages sent.

•

Enabled – to manually specify the Timeout interval. Set the timeout value greater than the period at which the RADIUS Accounting client sends the Interim-Update messages, and for dropped/missed Interim-Update messages, set the Timeout value at least 2 to 3 times greater than the period.

•

Auto (default) – to have the appliance detect automatically whether Interim-Update message are being sent periodically and, if they are, to use them as specified under Enabled and setting automatically the timeout accordingly.


	NOTE: If, after some time, the timeout stays at 0 (zero) when the page is reloaded, then it has not detected them being sent and is not timing them out. It could take quite a considerable time to complete auto-detection, depending on how frequently the client sends them. For example, if the client sends them every 10 minutes, then it could take over 30 minutes before the measure timeout is shown her.e


	TIP: You can click the Show info link to monitor progress in a popup dialog.


	TIP: To rerun auto-detection, change the setting to Disabled and then back to Auto, clicking Apply after each change.

Click the Forwarding tab.

Under the Forwarding tab, you can enter up to four RADIUS accounting servers in these fields:

•

Name or IP address

•

Port (default 1813)

•

Shared Secret for the RADIUS accounting servers to which you want the client to forward message

•

Confirm Shared Secret

When you enter this information for a server, the Select from drop down menu displays.

For each server, from the Select from drop-down menu, select either:

•

No forwarding

•

IP address of the accounting server

If requests from more than one client are to be forwarded to the same accounting server, then after it has been configured for any one client, it can be selected from the Select from drop-down menu for the others. All the information for the selected accounting server, including its shared secret, is copied and instated for this client.

In the Timeout (seconds) field and Retries field, enter the timeout period in seconds and the number of retries. The default for Timeout (seconds) is 10 seconds, and the default for Retries is 3.

To determine which users have logged out, the Dell SonicWALL network security appliance polls the SSO Agent by sending requests to multiple logged-in users in a single request message to the SSO Agent. To configure the number of user requests the firewall can send in a single request message to the Test tab

Select how the RADIUS accounting messages are forwarded from this client, either:

•

Try next on timeout

•

Forward to all

Select the General Settings tab.

Enable SSO or RADIUS accounting by selecting the Enable SSO or RADIUS accounting checkbox. This setting is enabled by default.

Specify the port in the Port number field. The default port is 1813.

To ignore messages for users at specific IP addresses, select an address object or address group from the Ignore any messages for users at these IP addresses drop-down menu or create a new address object or address group. The default is None.

Test Tab

Click the Test tab.


	IMPORTANT: Performing tests on this page applies any changes that have been made.

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 menu. The drop-down menu 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 tests communication with the authentication agent. If the firewall can connect to the SSO agent, the message Agent is ready displays. 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 tests if the SSO agent is properly configured to identify the user logged into a workstation.


	TIP: If the messages Agent is not responding or Configuration error display, check your settings and perform these tests again.

When you are finished with all Authentication Agent configuration, click OK.

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:

Display the Users > Settings page.

Click the Configure SSO button. The SSO Authentication Configuration dialog appears.

Click the RADIUS Accounting tab. For the procedure to configure RADIUS Accounting, see Radius Accounting Tab .

Click Apply.

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.

On the Users tab in the SSO Authentication Configuration dialog, click the Configure button next to the Use LDAP to retrieve user group information option. The LDAP Configuration dialog displays.

Topics:

•

•

•

•

•

•

•

Settings Tab

In the Name or IP address field, enter the name or IP address of your LDAP server.

In the Port Number field, enter the port number of your LDAP server. The default LDAP ports, which you can select from the drop-down menu, are:

•

Default LDAP port – 389

•

Default LDAP over TLS port – 636

•

Windows Global Catalog port – 3268

•

Global Catalog over TLS port – 3269

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.

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.


	NOTE: Some operations, such as directory configuration or importing user groups, can take a number of minutes, especially if running across multiple LDAP servers.

Specify the type of log in from these radio buttons:

•

Anonymous login to login anonymously. Some LDAP servers allow for the tree to be accessed anonymously. If your server supports this (Microsoft Active Directory generally does not), you may select this option. The Login user name and Login password fields remain dimmed. Go to Step 10.

•

Give login name/location in tree to access the tree with the login name. The Login user name and Login password fields become active. Go to Step 7.


	NOTE: Be sure to enter the user tree in the User tree for log in to server field on the Directory tab.

•

Give bind distinguished name to access the tree with the distinguished name. The Login user name field changes to Bind distinguished name field, and it and the Login password field become active. Go to Step 8.

To login with a user’s name, enter the user’s name in the Login user name field. The login name is presented automatically to the LDAP server in full dn notation. Go to Step 9.


	NOTE: Use the user’s name (that is in the first component of the user’s distinguished name, in the Login user name field, not a username or login ID. For example, John Doe may normally log in as jdoe, but would log in here as John Doe, not jdoe.

In the Bind distinguished name field, specify the full distinguished name (DN) to use to bind to the LDAP server.

Enter a password in the Login password field.

Select the LDAP version from the Protocol version drop-down menu, either LDAP version 2 or LDAP version 3 (default). Most implementations of LDAP, including Active Directory, employ LDAP version 3.

Select the Use TLS (SSL) checkbox to use Transport Layer Security (SSL) to login to the LDAP server. This option is selected by default.


	IMPORTANT: 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 Active Directory, support TLS.

Optionally, 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. This option is not selected by default.


	NOTE: Only check the Send LDAP ‘Start TLS’ request box if your LDAP server uses the same port number for TLS and non-TLS, and it should only be selected if required by your LDAP server.

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.

Select the Require valid certificate from server checkbox to require a valid certificate from the server. The certificate presented by the server is validated during the TLS exchange by matching the name specified above to the name on the certificate. This option is selected by default.


	NOTE: 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.

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 (Active Directory does not return passwords). This setting is not required for Active Directory. The default is None.

Click Apply.

Schema Tab

Click the Schema tab.

From the LDAP Schema drop-down menu, select one of the following LDAP schemas. Selecting any of the predefined schemas automatically populates the fields used by that schema with their correct values.

•

Microsoft Active Directory (default)

•

RFC2798 InetOrgPerson

•

RFC2307 Network Information Service

•

Samba SMB

•

Novell eDirectory

•

User defined – Allows you to specify your own values.


	IMPORTANT: Use this only if you have a specific or proprietary LDAP schema configuration.

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

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

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.

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. This field is not modifiable unless you select User defined.

The Additional user group ID user attribute, along with the Additional user group match user group attribute set in the User Group Objects section, allow for a schema that sets additional memberships for a user in addition to those found via member/memberOf attributes, for example, Active Directory’s primary group attribute.

If the Additional user group ID user attribute is specified and its use enabled by selecting the Use checkbox, then when a user object is found with one or more instances of this attribute, a search for additional user groups matching those is made in the LDAP directory. If a group is found with the Additional user group match attribute set to that value, then the user is also made a member of that group.


	TIP: With Active Directory, enabling the use of these attributes set to primaryGroupID and primary Group Token gives users membership of their primary user group, typically, Domain Users.

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.

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.

The Member attribute field defines which attribute is used for login authentication. Select whether the attribute is a:

•

Distinguished name

•

User ID

The Additional user group match attribute, along with the Additional user group ID attribute, allow for a schema that sets additional memberships for a user in addition to those found via member/memberOf attributes. For more information, see Step 7.

Optionally, to read the details of the schema, click the Read from server button. The LDAP Read Schema dialog displays.

Specify whether to:

•

Automatically update the schema configuration (default)

•

Export details of the schema

Click OK.

Directory Tab

Select the Directory tab.

In the Primary Domain field, specify the user domain used by your LDAP implementation. For AD, this will be the Active Directory domain name, such as yourADdomain.com. Changes to this field will, optionally, automatically update the tree information in the rest of the page. This is set to mydomain.com by default for all schemas except Novell eDirectory, for which it is set to o=mydomain.

In the User tree for login to server field, specify the tree in the directory that holds the user object for the user account specified in the Login user name field on the Settings tab resides. For example, in Active Directory (AD) the administrator account’s default tree is the same as the user tree.


	NOTE: This field is dimmed unless Give login name/location in tree is selected on the Settings tab.

The Trees containing users table lists the trees where user objects commonly reside in the LDAP directory. During user authentication, the listed trees are searched to locate the user. One default value, mydomain.com/user, 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.

To add new trees:

Click Add. The New Tree dialog displays with the default tree.

Enter the new tree.

You can simply specify the primary domain, which encompasses sub-domains on secondary LDAP servers also, or to improve search efficiency, you can enter specific sub-trees within the directory.

You can specify a tree in either:

•

Path format (for example, domain.com/people)

•

Distinguished name format (for example, ou=people,dc=domain,dc=com); this format may be necessary for trees having DNs with non-standard formatting. When using this format, any period (.) or slash (/) character must be preceded by a backslash (\). For additional escaping requirements for characters in distinguished names, see RFC2253.

Click OK. The tree is added to the table.

To edit an existing tree in the table:

Select the tree in the table.

Click Edit.

Make the necessary changes.

Click OK. The changes are made to the tree in the table.

To remove an existing tree in the table:

Select the tree in the table.

Click Remove.

Ordering is not critical, but as trees 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. To reposition an entry in the table:

Select the tree to be moved.

Click the Up or Down arrow until the entry is in the desired position.

Repeat Step a and Step b for each tree to be repositioned.

In the Trees containing user groups specify the trees where user group objects 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. To add new trees:

Click Add. The New Tree dialog displays with the default tree.

Enter the new tree. For formatting information, see Step 4.

Click OK. The tree is added to the table.

To edit an existing tree in the table:

Select the tree in the table.

Click Edit.

Make the necessary changes.

Click OK. The changes are made to the tree in the table.

To remove an existing tree in the table:

Select the tree in the table.

Click Remove.

Select the tree to be moved.

Click the Up or Down arrow until the entry is in the desired position.

Repeat Step a and Step b for each tree to be repositioned.

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 Primary Domain and User tree for login to server must first be set.


	NOTE: It will quite likely locate trees that are not needed for user login and manually removing such entries is recommended.

Click Auto-configure. The LDAP User/Group Trees Auto Configure dialog displays.

Select whether to:

•

Append to existing trees – New trees are added to the current configuration

•

Replace existing trees – Remove all currently configured trees first before adding new trees

Click OK.


	NOTE: This may take some time.


	TIP: 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.

Click Apply.

Referrals Tab

Select the Referrals tab.

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

•

Allow referrals – Select when user information is located on an LDAP server other than the primary one. This setting is enabled by default.

•

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. This setting is enabled by default.

•

Allow continuation references in domain searches – Select to search for sub-domains in multiple LDAP servers. This setting is enabled by default.

Click Apply.

Users & Groups Tab

Select the Users & Groups tab.

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

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

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.

Click the Import users button to configure local users on the Dell SonicWALL by retrieving the user names from your LDAP server. The LDAP Import Users dialog displays, listing the user names available for import to the Dell SonicWALL.

Select the checkbox for each user you want to import into the Dell SonicWALL appliance.

Click Save selected.

The list of users read from the LDAP server can be quite long, and you might not want to import all of them. A Remove from list button is provided, along with several methods of selecting unwanted users.You can use these options to reduce the list to a manageable size and then select the users to import.

Having users on the Dell SonicWALL with the same name as existing LDAP users allows Dell SonicWALL user privileges to be granted upon successful LDAP authentication.

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

Select whether to:

•

Import user groups from the LDAP directory (default)

•

Auto-configure groups for setting memberships by LDAP location (OU)

The LDAP Import User Groups dialog displays.

Select the checkbox for each user group you want to import into the Dell SonicWALL appliance.

Click Save selected.

The list of user groups read from the LDAP server can be quite long, and you might not want to import all of them. A Remove from list button is provided, along with several methods of selecting unwanted users.You can use these options to reduce the list to a manageable size and then select the users to import.

Having user groups on the Dell SonicWALL appliance with the same name as existing LDAP/AD user groups allows Dell SonicWALL group memberships and privileges to be granted upon successful LDAP authentication.

Alternatively, you can manually create user groups on the LDAP/AD server with the same names as Dell SonicWALL built-in groups (such as Guest Services, Content Filtering Bypass, Limited Administrators) and assign users to these groups in the directory. This also allows Dell SonicWALL group memberships to be granted upon successful LDAP authentication.

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

To enable LDAP user group mirroring, select the Mirror LDAP user groups locally checkbox.

When LDAP user group mirroring is enabled, the Dell SonicWALL appliance periodically auto-imports user groups and user-group nestings (memberships where groups are members of other groups) from the LDAP server(s) to create local user groups that mirror those in the LDAP directory.

These mirror user groups are listed separately on the Users > Local Groups page and have names that include the domain in which they are located. The groups can be selected in access rules, CFS policies, and so forth, just as other local user groups, although there are a few restrictions, for example, they cannot have other user groups added as members locally on the Dell SonicWALL appliance, although they can be made members of other local user groups and local users can be made members of them.

Users who are members of a user group on the LDAP server automatically receive any access privileges set via its local mirror group.

The maximum number of user groups that can be imported is limited per product, and an event log is generated if not all the groups found on the LDAP server can be imported because the maximum number has been exceeded.


	TIP: To avoid exceeding this limit, select to import only groups that have members and/or set filters to avoid importing unneeded groups. To obtain an XML list of all the user groups that the appliance will try to mirror, enter the following in your browser’s address bar: https://<ip—address>/ldapMirror.xml. You can also determine the maximum number of user groups by displaying the tooltip for this setting.

The groups are imported from the directory trees configured in the Trees containing user groups table on the Directory tab (see Directory Tab ). Filters can be configured in the Exclude groups in these sub-trees table below.

When the Mirror LDAP user groups locally is selected, the Refresh period (minutes) field becomes active. Enter the maximum time between refreshes. The default is 5 minutes.

Optionally, to refresh immediately, click the Refresh now button.

Select the groups to mirror:

•

All user groups on the LDAP server

•

Only groups that have member users or groups (default)

Exclude sub-trees in the LDAP directory from mirroring by adding sub-trees to the Exclude groups in these sub-trees table. You can exclude up to 32 sub-trees in the LDAP directory; any user groups located in or under the given sub-trees are not mirrored.

Click the Add button. The New Tree dialog displays.

Enter the new tree.

Click OK. The tree is added to the table.

To edit an existing tree in the table:

Select the tree in the table.

Click Edit.

Make the necessary changes.

Click OK. The changes are made to the tree in the table.

To remove an existing tree in the table:

Select the tree in the table.

Click Remove.

Select the tree to be moved.

Click the Up or Down arrow until the entry is in the desired position.

Repeat Step a and Step b for each tree to be repositioned.

Click Apply.

LDAP Relay Tab

Select the LDAP Relay tab.

Select the Enable RADIUS to LDAP Relay checkbox to enable RADIUS to LDAP relay. This setting is not enabled by default.

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.

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

•

Trusted Zones

•

WAN Zone (default)

•

Public Zones

•

Wireless Zones

•

VPN Zone (default)

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

In the user groups for legacy users fields, define the user groups that correspond to the legacy users:

•

User group for legacy VPN users

•

User group for legacy VPN client users

•

User group for legacy L2TP users

•

User group for legacy users with Internet access

These settings allow inter operation with remote Dell SonicWALL appliances running non-enhanced firmware that does not support user groups. When a user in one of the given user groups is authenticated, the remote Dell SonicWALL appliance is informed that the user is to be given the relevant privilege.


	NOTE: The ‘Bypass filters’ and ‘Limited management capabilities’ privileges are returned based on membership to user groups named ‘Content Filtering Bypass’ and ‘Limited Administrators’ – these are not configurable.

Click Apply.

Test Tab

Select the Test tab.

The Test tab tests the configured LDAP settings 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.

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

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


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

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

Click Apply.

Click OK.