Configuring Single Sign-On

SonicWALL SSO Agent identifies users by IP address using a SonicWALL ADConnector compatible protocol and automatically determines when a user has logged out to prevent unauthorized access. Based on data from SonicWALL SSO Agent, the SonicWALL security appliance queries LDAP or the local database to determine group membership. Memberships are matched against policy, and based on user privileges, access is granted or denied. The configured inactivity and session limit timers apply with SSO, though users who are logged out are automatically and transparently logged back in when they send further traffic.

Configuring SSO settings

To configure SSO settings:

1	On the User > Settings page, click Configure if you are using Active Directory for authentication.

 

2	In the Settings tab, click Enable SSO agent authentication.

3	Click Add.

NOTE: If a User Name or IP Address already exists, you can edit them in-line by clicking the desired column in the Authentication Agent Settings table.

4	In the Settings tab, enter the host name or IP Address of the workstation on which the SonicWALL SSO Agent is installed, in the Host Name or IP Address field.

 

5	In Port Number, enter the port number of the workstation on which SonicWALL SSO Agent is installed. The default port is 2258.

6	In the Shared Key field, 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.

NOTE: The Shared Keys only accept the following values: 0-9, a-f, A-F.

7	In the Timeout (seconds) field, enter a number of seconds before the authentication attempt times out.

8	In the Retries field, enter the number of authentication attempts.

9	Click on the Advanced tab inside the Settings tab.

The Maximum requests to send at a time setting is available on the Advanced tab of the SSO agent configuration.

This setting controls the maximum number of requests that can be sent from the appliance to the agent at the same time. The agent processes multiple requests concurrently, spawning a separate thread in the PC to handle each. Sending too many requests at a time can overload the PC on which the agent is running. If the number of requests to send exceeds the maximum, then some are placed on an internal “ring buffer” queue. Requests waiting on the ring buffer for too long could lead to slow response times in SSO authentication.

10

This setting works in conjunction with the automatically calculated number of user requests per message to the agent when polling to check the status of logged in users. The number of user requests per message is calculated based on recent polling response times. SonicOS adjusts this number as high as possible to minimize the number of messages that need to be sent, which reduces the load on the agent and helps reduce network traffic between the appliance and the agent. However, the number is kept low enough to allow the agent to process all of the user requests in the message within the poll period. This avoids potential problems such as time-outs and failures to quickly detect logged out users.

Users Tab

1	Click the Users tab. The User Settings page displays.

 

2	Click Allow only users listed locally to allow only users listed locally to be authenticated.

3	Click Simple user names in local database to use simple user names. This setting ignores the domain component of a user name. If this box is not checked, user names in the local database must match exactly the full names returned from the agent, including the domain component.

4

Check the box next to Allow limited access for non-domain users to allow limited access to users who are logged in to a computer but not into a domain. These users are not given access to the Trusted Users user group. They are identified in logs as computer-name/user-name. When completing local authentication 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.

5	(Available for SonicOS 5.6 and higher.) Select Probe users for and select either NetAPI or WMI (depending on which is configured for the SSO Agent) to attempt browser NTLM authentication before the SonicWALL SSO agent attempts to acquire the user information.

This causes the SonicWALL firewall appliance to probe for a response on the NetAPI/WMI port before requesting that the SSO Agent identify a user. If no response occurs, these devices will fail SSO immediately. For a Windows PC, the probe generally works (unless blocked by a personal firewall) and the SonicWALL SSO agent is used. For a Linux/Mac PC (assuming it is not set up to run Samba server) the probe fails, the SSO agent is bypassed and NTLM authentication is used when HTTP traffic is sent.

NTLM cannot identify the user until they browse with HTTP, so any traffic sent before that is treated as unidentified. The default CFS policy is applied, and any rule requiring authenticated users does not let the traffic pass.

If NTLM is configured to be used before the SonicWALL SSO agent, then if HTTP traffic is received first, the user is authenticated with NTLM. If non-HTTP traffic is received first, the SonicWALL SSO agent is used for authentication.

6	To use LDAP to retrieve user information, select Use LDAP to retrieve user group information.

7	To use local configuration, select Local configuration.

8	In the Polling rate (minutes) field, enter a polling interval, in minutes, that the security appliance polls the workstation running SSO Agent to verify that users are still logged on.

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

10	(Available for SonicOS 5.6 and higher.) To populate the User names used by Windows services list, type the service login name in the dialog box (the simple name only, without the domain or PC name) add click Add. Repeat as necessary for additional user names, and then click Update.

Enforcement Tab

NOTE: On appliances running SonicOS versions 5.5 and lower, the Enforcement tab is called the Content Filter tab. The configuration is identical, regardless of the name of the tab.

The Enforcement tab settings are for triggering or bypassing SSO when it is used to identify users for the security services, log-in, and so on. They do not affect its use with firewall access rules that require user authentication.

 

1	Under Pre-Zone SSO Enforcement, select the zones you want SSO to identify users sending traffic from.

If SSO user authentication is used for content filtering, IPS, App Control, and so on. Then it is initiated to identify users sending traffic from the relevant zones. On zones where it is not otherwise initiated, SSO enforcement can be enabled here.

NOTE: Where 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 for it here.

2

(Available in SonicOS releases 5.6 and higher.) To bypass SSO for traffic from certain devices or locations and apply the default content filtering policy to the traffic, select the appropriate address object or address group from the first pull-down menu under SSO Bypass. To bypass SSO for certain services or types of traffic, select the service from the second pull-down menu.

The first setting is used where traffic that would be subject to security services screening can emanate from a device other than a user's workstation (such as an internal proxy Web server or IP phone). It prevents the SonicWALL from attempting to identify such a device as a network user in order to select the content filtering policy to apply. The default content filtering policy is used for all traffic from the selected IP addresses.

The second setting is appropriate for user traffic that does not need to be authenticated, and triggering SSO might cause an unacceptable delay for the service.

SSO bypass settings do not apply when SSO is triggered by firewall access rules requiring user authentication. To configure this type of SSO bypass, add access rules that do not require user authentication for the affected traffic.

Terminal Services Tab

1	(Available in SonicOS releases 5.6 and higher.) Click the Terminal Services tab.

2	Click Enable Terminal Services agent authentication.

 

3	Click Add. 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.

NOTE: If Agents already exist, you can edit them in-line by clicking the desired column in the Terminal Services Agents table.

4

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.

5	In the Port field, enter the port number of the workstation on which SonicWALL TSA is installed. The default port is 2259. Note that agents at different IP addresses can have the same port number.

NOTE: In global view, a maximum of 256 TSA agents can be configured. On the unit level, the maximum depends on the type of SonicWALL appliance.

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

7	Repeat Steps <Blue XRef>3 through <Blue XRef>6 to add additional TSA agents.

8	Click the General Settings tab inside the Terminal Services tab.

 

9

Allow traffic from services on the terminal server to bypass user authentication in access rules is selected by default. This allows traffic such as Windows updates or anti-virus updates that is not associated with any user login session, to pass without authentication. If you clear this check box, 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

Configure NTLM authentication only if you want to authenticate Web users without using the SSO Agent or TSA. With NTLM authentication, users are identified as soon as they send HTTP traffic. NTLM requires RADIUS to be configured (in addition to LDAP, if using LDAP), for access to MSCHAP authentication. If LDAP is configured, a separate tab for RADIUS appears when NTLM is used.

 

1	Click the Use NTLM to authenticate HTTP traffic drop-down menu, then select Enabled.

2	In the Authentication domain text-field, enter the full DNS name of the domain, or if using LDAP you can select Use the domain from the LDAP configuration to use the same domain that is entered in the LDAP configuration.

3	Select a way to redirect the browser to this appliance:

•	The interface IP address To begin the NTLM authentication process, an HTTP connection from a user’s browser is intercepted and the browser is redirected to the appliance’s own web server. Here you can configure the domain name or IP address that it is redirected to.

•	Its domain name from a reverse DNS lookup of the interface IP address

•	Its domain name Manually enter the domain name in the text-field if this option is selected.

4	Enter the maximum number of retries to allow for authentication failures.

5	Using the radio buttons, select whether or not to re-authenticate by way of NTLM for Windows users, Linux users, and Macintosh users.

6	Click Forward legacy LanMan in NTLM to enable this feature.

RADIUS Accounting Tab

Single-sign-on by RADIUS accounting allows the appliance to act as a RADIUS accounting server for external third-party appliances and automatically log users in/out based on the accounting messages from them. For third-party appliances that use RADIUS accounting for other purposes, it can be set up to forward the accounting messages on to another RADUIS accounting server.

 

1	Click Enable SSO by RADIUS accounting to enable this feature.

2	(optional) Enter a value for a port in the Port number text-field. The minimum value is 1 and the maximum is 65535.

3	Click Add... under RADIUS accounts.

NOTE: If RADIUS accounts already exist, you can edit them in-line by clicking the desired column in the RADIUS accounts table.

 

4	In the Settings tab, enter the Client Host Name or IP Address for the RADIUS client host.

5	(optional) Enter the Shared Key, and then enter it again to confirm. If you leave these text-fields blank, the current Shared Keys of the appliances remains unchanged.

NOTE: The Shared Keys only accept the following values: 0-9, a-f, A-F.

6	Click the RADIUS tab.

 

7	Click the User-Name attribute format drop-down menu, then select a format for the user name login. Depending on the selected attribute format, different options display in the RADIUS tab:

If you select Domain\User-name, Domain/User-name, or User-name@Domain. The following options display:

•	If domain component is missing—select which action is taken by clicking Assume a non-domain user or Look up the user name via LDAP.

If you select other..., the following options display:

•	Format—enter a scanf-style format specifier with either a “%s” or “%[...]” directive for each component.

•	Add Component—add a name, domain, or Fully Qualified Distinguished Name (DN) component into the format.

•	Remove Last Component—remove the last component from the format.

•	Components—click the drop-down list(s) and select a component (Not used, User-name, Domain, DN).

•	If domain component is missing—select which action is taken by clicking Assume a non-domain user or Look up the user name via LDAP.

NOTE: The RADIUS Accounting specification does not specify the format of the content of the User-Name attribute passed in RADIUS accounting messages, so you need to enter the format that is sent by the client. You can select from some common formats, or for other cases you can specify a format.

8	(optional) Select Log user out if no accounting interim updates are received, then enter a value in the time text-field. You can enter a time limit between 0 and 99999.

NOTE: This option is disabled by default.

9	Click the Forwarding tab. This gives you the option to enter up to four RADIUS accounting servers. If one or more RADIUS account servers are configured, then RADIUS accounting messages from this client will be forwarded on to them.

 

10	Enter the Name or IP Address, Port number, and Shared Secret for each the RADIUS accounting server you want to add. The minimum port number value is 1 and the maximum is 65535. If you leave the Shared Secret text-fields blank, the current Shared Keys of the appliances remains unchanged.

NOTE: The Shared Keys only accept the following values: 0-9, a-f, A-F.

11

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

12	In the Timeout field and Retries field, enter the timeout period (0-999 seconds) and the number of retries (0-99).

13	Click Try next on timeout or Forward to all.

14

Click OK.

Content Filter Tab

1	Click the Content Filter tab if you are using the SonicWALL Content Filtering Service (CFS) and there is a proxy server in your network.

NOTE: The Content Filter tab is only displayed for SonicOS releases 5.5 and lower, and if Premium CFS is enabled on the SonicWALL security appliance. For SonicOS releases 5.6 and higher, the Content Filter tab is combined with the Enforcement tab. See Enforcement Tab on page 625 for more information.

 

2

To bypass SSO for content filtering traffic and apply the default content filtering policy to the traffic, select the appropriate address object or address group from the pull-down list. This setting should be used where traffic that would be subject to content filtering can emanate from a device other than a user's workstation (such as an internal proxy web server). It prevents the SonicWALL from attempting to identify such a device as a network user in order to select the content filtering policy to apply. The default content filtering policy is used for all traffic from the selected IP addresses.

Test Tab

1	You can test the Transparent Authentication Configuration settings on the Policies > Diagnostics > Network page. For more information, click the Test tab.

2	When finished, click OK.