To use single sign-on, your SonicWall security appliance must be configured to use either SonicWall SSO Agent or Browser NTLM authentication only as the SSO method. SonicWall SSO Agent is also the correct method to select when configuring the appliance to use the SonicWall Terminal Services Agent.
|
1
|
Log in to your SonicWall security appliance and navigate to Users > Settings.
|
|
2
|
In the Single-sign-on method drop-down menu, select SonicWall SSO Agent. Use this choice to add and configure a TSA as well as an SSO Agent for the SSO method.
|
|
3
|
Click Configure SSO.The Authentication Agent Settings page displays, showing any Authentication 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.
|
|
4
|
On the Authentication Agent Settings page, click the Add button to add an agent. The page is updated to display a new row in the table at the top, and two new tabs and their input fields in the lower half of the page.
|
|
5
|
Enter the following information in the Settings tab:
|
|
•
|
In the Host Name or IP Address field, enter the name or IP address of the workstation on which SonicWall SSO Agent is installed.
|
|
•
|
In the Port field, enter the port number of the workstation on which SonicWall SSO Agent is installed. The default port is 2258. 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 SSO Agent. The shared key must match exactly. Re-enter the shared key in the Confirm Shared Key field.
|
|
•
|
In the Timeout (seconds) field, enter a number of seconds before the authentication attempt times out. This field is automatically populated with the default of 10 seconds.
|
|
•
|
In the Retries field, enter the number of authentication attempts.
|
|
6
|
Click the Advanced tab in the lower half of the page.
|
|
•
|
In the Maximum requests to send at a time field, enter the maximum number of requests to send from the appliance to the agent at one time. The default is 32.
|
The agent processes multiple requests concurrently, spawning a separate thread in the agent PC to handle each. Sending too many requests at a time can overload the PC. On the other hand, if the number of requests to be sent from the appliance exceeds the maximum, then some requests will wait on an internal “ring buffer” queue. Too many requests waiting could lead to slow response times in Single Sign On authentication. For more information, see Tuning Single Sign-On Advanced Settings.
|
7
|
Click the General Settings tab under Authentication Agent Settings to configure the following options:
|
|
•
|
Select the Enable SSO agent authentication check box to use the SSO Agent for user authentication.
|
|
•
|
Select the Try next agent on getting no name from NetAPI/WMI check box to force a retry of the authentication via a different SSO agent if there is no response or error from the first agent. This only affects agents using NetAPI/WMI.
|
|
•
|
Select the Don't block user traffic while waiting for SSO check box to use the default policy while the user is being identified. This prevents browsing delays.
|
|
8
|
|
9
|
Select the check box next to Allow only users listed locally to allow only users listed locally on the appliance to be authenticated.
|
|
10
|
Select the check box next to Simple user names in local database to use simple user names. When selected, the domain component of a user name will be ignored. User names returned from the authentication agent typically include a domain component, for example, domain1/user1. If this box is not checked, user names in the local database must match exactly the full names returned from the agent, including the domain component.
|
|
11
|
Select the check 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 will not be given membership in the Trusted Users user group, even when set locally, and so will not get any access set for Trusted Users. They are identified in logs as computer-name/user-name. When using the local user database to authenticate users, and the Simple user names in local database option is disabled, user names must be configured in the local database using the full computer-name/user-name identification.
|
|
12
|
If your network includes non-Windows devices or Windows computers with personal firewalls running, select the radio button for either NetAPI or WMI depending on which is configured for the SSO Agent. This causes the SonicWall network security 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. Such devices do not respond to, or may block, the Windows networking messages used by the SSO Agent to identify a user.
|
|
13
|
In the Probe timeout field, enter the number of seconds that the firewall should wait for a response from the agent on the NetAPI/WMI port. The probe is considered failed after this period. The default is 5 seconds.
|
|
14
|
To enable probing on the NetAPI/WMI port without aborting the SSO attempt if the probes fail, select the Probe test mode check box. Probe test mode is used to ensure that the probes do not cause failures where SSO could have worked if they were not used. If probe failures are reported when SSO is working, then either the probe timeout is too short or something in the network may be blocking them. For example, if you have an Access Control List set on a router in your network to allow NetAPI from the agent’s IP address only, that ACL will block the probes to the NetAPI port from the appliance.
|
If the statistics show 100% probe failures, then something is wrong in the network. If they show intermittent failures, you can try varying the Probe timeout setting to see if it helps.
|
15
|
To use LDAP to retrieve user information, select the Use LDAP to retrieve user group information radio button. Click Configure to configure the LDAP settings. The LDAP Configuration page displays. For configuration information for this page, refer to Advanced LDAP Configuration.
|
|
16
|
To use locally configured user group settings, select the Local configuration radio button.
|
|
17
|
In the Polling rate (minutes) field, enter a polling interval, in minutes. The security appliance will poll the workstation running SSO Agent once every interval to verify that users are still logged on. The default is 5.
|
|
18
|
In the Hold time after (minutes) field, enter a time, in minutes, that the security appliance will wait before trying again to identify traffic after an initial failure to do so. This feature rate-limits requests to the agent. The default is 1.
|
|
19
|
To populate the User names used by Windows services list, click the Add button. The Service User name dialog displays.
|
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.
To edit a service account name, select the name, click Edit, make the desired changes in the Service User name dialog box, and then click OK.
To remove service account names, select one or more names and then click Remove.
|
20
|
Enter the service login name (the simple name only, without the domain or PC name) into the Enter the name of a user account used by a Windows service field.
|
|
21
|
Click OK.
|
|
22
|
Click on 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.
|
|
23
|
Under Per-Zone SSO Enforcement, select the checkboxes for any zones on which you want to trigger SSO to identify users when traffic is sent. If SSO is already required on a zone by Application Control or other policies, those checkboxes are pre-selected and cannot be cleared. If Guest Services is enabled on a zone, SSO cannot be enforced and you cannot select the check box.
|
|
24
|
To bypass SSO for traffic from certain devices or locations and apply the default content filtering policy to the traffic, select the appropriate address object or address group from the first drop-down menu under SSO Bypass. To bypass SSO for certain services or types of traffic, select the service from the second drop-down menu.
|
|
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.
|
|
25
|
Click the Terminal Services tab. The Terminal Services Agent Settings page displays.
|
|
26
|
Within this page, on the Terminal Services Agents tab, 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.
|
|
27
|
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.
|
|
28
|
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.
|
|
29
|
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.
|
|
30
|
Click the General Settings tab.
|
|
31
|
The Allow traffic from services on the terminal server to bypass user authentication in access rules check box is selected by default. This allows traffic such as Windows updates or anti-virus updates, which is not associated with any user login session, to pass without authentication. If you clear this 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.
|
|
32
|
Click the NTLM tab. The NTLM Browser Authentication page displays. NTLM authentication is supported by Mozilla-based browsers and can be used as a supplement to identifying users via an SSO agent or, with some limitations, on its own without the agent. The SonicWall appliance 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 log in 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.
|
33
|
Select one of the following choices from the Use NTLM to authenticate HTTP traffic drop-down menu:
|
|
•
|
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.
|
|
34
|
For Authentication domain, do one of the following:
|
|
•
|
Select the Use the domain from the LDAP configuration check box to use the same domain that is used in the LDAP configuration.
|
|
35
|
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 SonicWall appliance’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 domain name – Type in the Web server domain name to which the user’s browser should be redirected.
|
|
36
|
Enter a number of retries in the Maximum retries to allow on authentication failure.
|
|
37
|
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 used for the NTLM authentication, or the login session will be terminated. You may want to select a different polling method for Linux or Mac 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.
|
|
38
|
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 check box. This may cause authentication to fail in newer Windows servers that don’t allow LanMan in NTLM by default because it is not secure.
|
|
39
|
If you have multiple agents configured, select the SSO agent or TSA to test from the Select agent to test drop-down list. The drop-down list includes SSO agents at the top, and TSA’s at the end under the heading --Terminal Server Agents--.
|
|
40
|
Select the Check agent connectivity radio button and then click the Test button. This will test communication with the authentication agent. If the SonicWall security appliance can connect to the SSO agent, you will see the message Agent is ready. If testing a TSA, the Test Status field displays the message, and the version and server IP address are displayed in the Information returned from the agent field.
|
|
41
|
For SSO agents only, select the Check user radio button, enter the IP address of a workstation in the Workstation IP address field, then click Test. This will test if the SSO agent is properly configured to identify the user logged into a workstation.
|
|
TIP: If you receive the messages Agent is not responding or Configuration error, check your settings and perform these tests again.
|
