Filter
Top Products
User Management
1013
SonicOS 5.8.1 Administrator Guide
Connections to Local Subnets
The TSA dynamically learns network topology based on information returned from the
appliance and, once learned, it will not send notifications to the appliance for subsequent user
connections that do not go through the appliance. As there is no mechanism for the TSA to
“unlearn” these local destinations, the TSA should be restarted if a subnet is moved between
interfaces on the appliance.
Non-Domain User Traffic from the Terminal Server
The SonicWALL appliance has the Allow limited access for non-domain users setting for
optionally giving limited access to non-domain users (users logged into their local machine and
not into the domain), and this works for terminal services users as it does for other SSO users.
If your network includes non-Windows devices or Windows computers with personal firewalls
running, check the box next to Probe user for and select the radio button for either NetAPI or
WMI depending on which is configured for the SSO Agent. This causes the SonicWALL
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.
Non-User Traffic from the Terminal Server
Non-user connections are opened from the Terminal Server for Windows updates and anti-virus
updates. The TSA can identify a connection from a logged-in service as being a non-user
connection, and indicates this in the notification to the appliance.
To control handling of these non-user connections, an Allow Terminal Server non-user traffic
to bypass user authentication in access rules checkbox is available in the TSA configuration
on the appliance. When selected, these connections are allowed. If this checkbox is not
selected, then the services are treated as local users and can be given access by selecting the
Allow limited access for non-domain users setting and creating user accounts on the
appliance with the corresponding service names.
How Does Browser NTLM Authentication Work?
See the following sections:
• “NTLM Authentication of Domain Users” on page 1013
• “NTLM Authentication of Non-Domain Users” on page 1014
• “Credentials for NTLM Authentication in the Browser” on page 1014
NTLM Authentication of Domain Users
For domain users, the NTLM response is authenticated via the MSCHAP mechanism in
RADIUS. RADIUS must be enabled on the appliance.
The following settings on the Users tab of the SSO configuration apply when configuring NTLM
authentication:
• Allow only users listed locally
• Simple user names in local database
• Mechanism for setting user group memberships (LDAP or local)