SonicOS 7.1 Users
- SonicOS 7.1
- About SonicOS
- About User Management
- Using Local Users and Groups for Authentication
- Using RADIUS for Authentication
- Using LDAP/Active Directory/eDirectory Authentication
- Using RADIUS
- Using TACACS+
- Using Single Sign-On
- What is Single Sign-On?
- Benefits of SonicWall SSO
- Platforms and Supported Standards
- How Does Single Sign-On Work?
- How Does SSO Agent Work?
- How Does Terminal Services Agent Work?
- How Does Browser NTLM Authentication Work?
- How Does RADIUS Accounting for Single-Sign-On Work?
- Installing the Single Sign-On Agent and/or Terminal Services Agent
- Single Sign-On Advanced Features
- Configuring Access Rules
- Managing SonicOS with HTTP Login from a Terminal Server
- Viewing and Managing SSO User Sessions
- Multiple Administrator Support
- Configuring Users Status
- Configuring User Settings
- User Login Settings
- Setting the Authentication Method for Login
- Configuring RADIUS Authentication
- Configuring LDAP
- Configuring TACACS+
- Requiring User Names be Treated as Case-Sensitive
- Preventing Users From Logging in from More than One Location
- Forcing Users to Log In Immediately After Changing Their Passwords
- Displaying User Login Information Since the Last Login
- Setting the Single-Sign-On Methods
- One-Time Password Settings
- Configuring the User Web Login Settings
- Adding URLs to Authentication Bypass
- User Session Settings
- Accounting
- [[[Missing Linked File System.LinkedTitle]]]
- User Login Settings
- Configuring and Managing Partitions
- Configuring Local Users and Groups
- Configuring Guest Services
- Configuring Guest Accounts
- Managing Guest Status
- SonicWall Support
Using SSO on Mac and Linux Without Samba
Without Samba, Mac and Linux users can still get access, but you need to log in to the firewall to do so. This can cause the following problems:
- Traffic from Mac or Linux systems might keep triggering SSO identification attempts unless the user logs in. This could potentially be a performance overhead to the SSO system if there are a large number of such systems, although the effect would be somewhat mitigated by the “hold after failure” timeout.
- If per-user Content Filtering (CFS) policies are used without policy rules with user level authentication, the default CFS policy is applied to users of Mac and Linux systems unless they manually log in first.
- If policy rules are set requiring user level authentication, Web browser connections from users of Mac and Linux systems are redirected to the login page after the SSO failure, but the failure might initiate a timeout that would cause a delay for the user.
To avoid these problems, the Don't invoke Single Sign On to Authenticate Users option is available when configuring access rules on the Policies > Rules > Access Rules page (for more information about configuring access rules, refer to SonicOS Access Rules). This option is visible only when SonicWall SSO is enabled. If this option is selected, SSO is not attempted for traffic that matches the rule, and unauthenticated HTTP connections that match it are directed straight to the login page. Typically, the Source drop-down menu would be set to an address object containing the IP addresses of Mac and Linux systems.
In the case of Content Filtering Service (CFS), a rule with this option enabled can be added “in front of” CFS so that HTTP sessions from Mac and Linux systems are automatically redirected to log in, avoiding the need for these users to log in manually.
Do not select the Don't invoke Single Sign On to Authenticate Users option for use with devices that are allowed to bypass the user authentication process entirely. Any devices that could be affected by an access rule when this option is enabled must be capable of logging in manually. A separate access rule should be added for such devices, with Users Allowed set to All.
Was This Article Helpful?
Help us to improve our support portal