Configuring SonicOS to Use the SonicWALL SSO Agent

To configure your firewall to use the SonicWALL SSO Agent:

Topics:

SSO Agents Tab

On the SSO Agents tab under Authentication Agent Settings you can view any SSO Agents already configured:

The LEDs are dynamically updated using AJAX.

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

NOTE: Agents at different IP addresses can have the same port number.

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.

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

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

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 see authentication failures logged as SSO agent returned no user name when you think the users should have been identified, try enabling this setting. If this setting is enabled when the appliance receives a no-user-name response from an agent, the appliance treats the response as an error and retries the request via a different agent.

Typically, enabling this setting is 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.

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

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

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

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.

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

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

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.

TIP: Hovering the mouse over these options displays a small tooltip contain the TCP port number.

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:

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

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.

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

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.

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.

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.

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

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. On zones where it is not otherwise initiated, SSO enforcement can be enabled by this option.

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.

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.

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

SSO bypass may be necessary, for example, for:

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.

This setting is selected by default, and a default name of SSO Bypass 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.

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

NOTE: The logging part of this option also can be configured by the For logging of connections on which the user is not identified option in the User Session Settings section of the Users > Settings page

Terminal Services Tab

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.

NOTE: As you type in values for the fields, the row at the top is updated in red to highlight the new information.

NOTE: Agents at different IP addresses can have the same port number.

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

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.

Fully transparent authentication can only occur if the browser sees the appliance domain as the local domain.

NOTE: When multiple Content Filter policies are configured and NTLM is enabled for Single Sign-On enforcement, an HTTP/HTTPS access rule with Trusted Users as Users Allowed must be added to the LAN to WAN rules in the Firewall > Access Rules page. This rule triggers an NTLM authentication request to the user. Without the access rule, restrictive CFS policies might block the user from Internet access and prevent authentication.

Radius Accounting Tab

NOTE: This tab displays only if RADIUS is enabled.

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:

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.

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

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.

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

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.

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.

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

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

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.

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

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.

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 this option to set group membership according to the options selected on the Users tab.

Select this option to use the RADIUS users attribute value (Filter-ID) to determine the user’s group membership. This option provides a way to apply the Content Filtering policies (CFS policies) that are configured for that group.

To set this up, first manually create a local user group on the firewall and give it a name, such as “group-a”. Then configure the CFS policy for group-a. On the RADIUS side, configure a RADIUS Filter-ID attribute to contain “group-a” for the desired users. With this configuration, whenever one of the specified users logs in, SonicOS applies the CFS policy to that user.

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.

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

Configuring RADIUS Accounting for SSO

RADIUS accounting for Single Sign-On is configured on the Users > Settings page.

To configure RADIUS accounting for SSO:

Advanced LDAP Configuration

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

To configure LDAP to retrieve user group information:

Topics:

Settings Tab

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

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

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.

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.

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.

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.

Schema Tab

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

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.

Directory Tab

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

To add new trees:

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:

To edit an existing tree in the table:

To remove an existing tree in the table:

To edit an existing tree in the table:

To remove an existing tree in the table:

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

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.

Referrals Tab

Users & Groups Tab

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.

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 LDAP Import User Groups dialog displays.

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.

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.

To edit an existing tree in the table:

To remove an existing tree in the table:

LDAP Relay Tab

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.

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.

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.

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.