SonicWall SSO requires minimal administrator configuration and is transparent to the user.
SSO is triggered in the following situations:
The SSO user table is also used for user and group identification needed by security services, including Content Filtering, Intrusion Prevention, Anti-Spyware, and Application Control.
For users on individual Windows workstations, the SSO Agent (on the SSO workstation) handles the authentication requests from the SonicWall network security appliance. There are six steps involved in SonicWall SSO authentication using the SSO Agent, as illustrated in SonicWall SSO Authentication Using the SSO Agent.
SonicWall SSO Authentication Using the SSO Agent
The SonicWall SSO authentication process is initiated when user traffic passes through a SonicWall security appliance, for example, when a user accesses the Internet. The sent packets are temporarily blocked and saved while the SonicWall security appliance sends a “User Name” request and workstation IP address to the authorization agent running the SSO Agent (the SSO workstation).
The authorization agent running the SSO Agent provides the SonicWall security appliance with the username currently logged into the workstation. A User IP Table entry is created for the logged in user, similarly to RADIUS and LDAP.
For users logged in from a Terminal Services or Citrix server, the SonicWall TSA takes the place of the SSO Agent in the authentication process. The process is different in several ways:
Once a user has been identified, the SonicWall security appliance queries LDAP or a local database (based on administrator configuration) to find user group memberships, match the memberships against policy, and grant or restrict access to the user accordingly. Upon successful completion of the login sequence, the saved packets are sent on. If packets are received from the same source address before the sequence is completed, only the most recent packet will be saved.
User names are returned from the authorization agent running the SSO Agent in the format <domain>/<user‑name>. For locally configured user groups, the user name can be configured to be the full name returned from the authorization agent running the SSO Agent (configuring the names in the SonicWall security appliance local user database to match) or a simple user name with the domain component stripped off (default).
For the LDAP protocol, the <domain>/<user-name> format is converted to an LDAP distinguished name by creating an LDAP search for an object of class domain with a dc (domain component) attribute that matches the domain name. If one is found, then its distinguished name is used as the directory sub-tree to search for the user’s object. For example, if the user name is returned as SV/bob, then a search for an object with objectClass=domain and dc=SV is performed. If that returns an object with distinguished name dc=sv,dc=us,dc=SonicWall,dc=com, then a search under that directory sub-tree is created for (in the Active Directory case) an object with objectClass=user and sAMAccountName=bob. If no domain object is found, then the search for the user object is made from the top of the directory tree.
Once a domain object has been found, the information is saved to avoid searching for the same object. If an attempt to locate a user in a saved domain fails, the saved domain information is deleted and another search for the domain object is made.
User logout is handled slightly differently by SonicWall SSO using the SSO Agent as compared to SSO with the TSA. The SonicWall security appliance polls the authorization agent running the SSO Agent at a configurable rate to determine when a user has logged out. Upon user logout, the authentication agent running the SSO Agent sends a User Logged Out response to the SonicWall security appliance, confirming that the user has been logged out and terminating the SSO session. Rather than being polled by the SonicWall network security appliance, the TSA itself monitors the Terminal Services/Citrix server for logout events and notifies the SonicWall network security appliance as they occur, terminating the SSO session. For both agents, configurable inactivity timers can be set, and for the SSO Agent, the user name request polling rate can be configured (set a short poll time for quick detection of logouts, or a longer polling time for less overhead on the system).
For users who are browsing using Mozilla-based browsers (including Internet Explorer, Firefox, Chrome and Safari) the SonicWall appliance supports identifying them via NTLM (NT LAN Manager) authentication. NTLM is part of a browser authentication suite known as “Integrated Windows Security” and is supported by all Mozilla-based browsers. It allows a direct authentication request from the appliance to the browser without involving the SonicWall SSO agent. NTLM is often used when a domain controller is not available, such as when the user is remotely authenticating over the Web.
NTLM Authentication is currently available for HTTP; it is not available for use with HTTPS traffic.
Browser NTLM authentication can be tried before or after the SonicWall SSO agent attempts to acquire the user information. For example, if the SonicWall SSO agent is tried first and fails to identify the user, then, if the traffic is HTTP, NTLM is tried.
To use this method with Linux or Mac clients as well as Windows clients, you can also enable SSO to probe the client 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. For a Windows PC the probe will generally work (unless blocked by a personal firewall) and the SonicWall SSO agent will be used. For a Linux/Mac PC (assuming it is not set up to run Samba server) the probe will fail, the SSO agent will be bypassed and NTLM authentication will be used when HTTP traffic is sent.
NTLM cannot identify the user until they browse with HTTP, so any traffic sent before that will be treated as unidentified. The default CFS policy will be applied, and any rule requiring authenticated users will 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 will be authenticated with NTLM. If non-HTTP traffic is received first, the SonicWall SSO agent will be used for authentication.
The number of NTLM user logins is combined with the number of SSO logins, and the total at any time cannot exceed the Max SSO Users limit for the appliance model. The specific Max SSO Users value is provided in the TSR. For information about the TSR, see the Using the Single Sign-On Statistics in the TSR.