- Products
- Network Security
Next Generation FirewallNext-generation firewall for SMB, Enterprise, and Government
Security ServicesComprehensive security for your network security solution
Network Security ManagerModern Security Management for today’s security landscape
- Advanced Threat Protection
Capture ATPMulti-engine advanced threat detection
Capture Security applianceAdvanced Threat Protection for modern threat landscape
- Access Security
Cloud Edge Secure AccessDeploy Zero-Trust Security in minutes
Secure Mobile AccessRemote, best-in-class, secure access
Wireless Access PointsEasy to manage, fast and secure Wi-FI
SwitchesHigh-speed network switching for business connectivity
- Email Security
Email SecurityProtect against today’s advanced email threats
- Cloud Security
Cloud App SecurityVisibility and security for Cloud Apps
Cloud Firewall (NSv)Next-generation firewall capabilities in the cloud
- Endpoint Security
Capture ClientStop advanced threats and rollback the damage caused by malware
Content Filtering ClientControl access to unwanted and unsecure web content
- Product Widgets
- Product Menu Right Image
-
- Network Security
- Solutions
- Solutions Widgets
- Solutions Image Widgets
-
- Solutions Widgets
- Partners
- Partner Widgets
- Partners Image Widgets
-
- Partner Widgets
- Support
- Support Widget
- Support Image Widgets
-
- Support Widget
- Products
- Network Security
- Next Generation FirewallNext-generation firewall for SMB, Enterprise, and Government
- Security ServicesComprehensive security for your network security solution
- Network Security ManagerModern Security Management for today’s security landscape
- Advanced Threat Protection
- Capture ATPMulti-engine advanced threat detection
- Capture Security applianceAdvanced Threat Protection for modern threat landscape
- Access Security
- Cloud Edge Secure AccessDeploy Zero-Trust Security in minutes
- Secure Mobile AccessRemote, best-in-class, secure access
- Wireless Access PointsEasy to manage, fast and secure Wi-FI
- SwitchesHigh-speed network switching for business connectivity
- Email Security
- Email SecurityProtect against today’s advanced email threats
- Cloud Security
- Cloud App SecurityVisibility and security for Cloud Apps
- Cloud Firewall (NSv)Next-generation firewall capabilities in the cloud
- Endpoint Security
- Capture ClientStop advanced threats and rollback the damage caused by malware
- Content Filtering ClientControl access to unwanted and unsecure web content
- Product Widgets
- Product Menu Right Image
-
- Network Security
- Solutions
- Solutions Widgets
- Solutions Image Widgets
-
- Solutions Widgets
- Partners
- Partner Widgets
- Partners Image Widgets
-
- Partner Widgets
- Support
- Support Widget
- Support Image Widgets
-
- Support Widget
Tips on SSO Agent with Novell eDirectory
03/26/2020 
7 People found this article helpful
98,019 Views
Description
Some Tips on SSO Agent with Novell eDirectory
Resolution
Feature/Application:
For users on individual Windows workstations, the SSO Agent (on the SSO workstation) handles the authentication requests from the SonicWall UTM appliance. This article describes a scenario where a user wants to go to Facebook.com but the administrator has imposed some CFS restrictions.
The SonicWall has no user authentication information for the user’s IP address. In SSO with LDAP integration, the following steps are taken to remedy this:
- SonicWall sends user’s IP to the SSO agent
- SSO agent logs into the user’s machine with Domain Admin account
- SSO agent then uses NetAPI or WMI to query the LAST logged on user (this occurs at the time of login and is not really a separate step)
- SSO agent returns the response to the SonicWall
- SonicWall sends LDAP query to LDAP server asking for the user’s group information
- LDAP server returns the memberOf attributes to the SonicWall
- SonicWall checks all applicable groups for custom CFS policies
- SonicWall reads all CFS policies and applies the least restrictive conditions to the user
- User is allowed or denied access to Facebook.com in direct correlation to the processed CFS policies
However, in SSO integrated with Novell eDirectory, the process is notably different.
The process when integrating with eDirectory has some similarities, but is notably different.
Understand first that eDirectory is not a true directory services platform… Rather, this is more of user authentication database. So (in most cases) computers in the network are not actually joined to a domain. This prevents the SSO agent from being able to login to the user’s machine to run the NetAPI / WMI query (when users login, the login is generally processed by a Novell / Windows integration application… the user does not directly login to Windows).
So, the problem becomes “How do we query the last logged in user?”.
eDirectory can actually be configured to record the IP address of the system(s) from which the user logged in. As I understand, this does NOT happen by default. I’ve looked for documentation to forward to customers, but I’ve not had any luck here. Maybe someone with more insight could clear this one up for us?
In any case, the SSO agent must be told that it will be querying an eDirectory database. This is done by installing the eDirectory plugin when installing the SSO agent.
So, to review, there are two prerequisites when integrating the SSO with eDirectory:
- eDirectory server is configured to hold workstation IPs
- eDirectory plugin is installed with the SSO agent
Once these two conditions are met, the steps taken to address the example are:
- SonicWall sends user’s IP to the SSO agent
- SSO agent sends “filter: (&(objectclass=user)(networkAddress=31:23:0a:00:bc:d3))” to eDirectory server
- eDirectory server responds with “matchedDN:” which is to contain the username
- SSO agent returns the response to the SonicWall
The remainder of the procedure is “normal”, as above.
If you’re inquisitive, you’ll want to know why the networkAddress attribute is set to 31:23:0a:00:bc:d3. This is a hexadecimal representation of the IP address, preceded with two identifier fields. Please see below (this is an excerpt from a case of mine):
31 23 5A 04 04 04
Hex 31 is "1", hex 23 is "#", and so on.
In SYN_NET_ADDRESS, "1" means the query contains an IP address; "#" is used by LDAP to delimit fields of different data types; the rest of the string (5A 04 04 04) is the IP address: 90.4.4.4 ...
http://www.novell.com/coolsolutions/tip/5897.html
In the above, “31:23:0a:00:bc:d3” translates to “1 # 10.0.188.211”. This is the format that should be expected and handled by the eDirectory server... This is a good time to point out a potential issue with the integration process… eDirectory can hold the IP address in two formats – IP and TCP. We query for IP ONLY!!!
Related Articles
- ‘Error sending one-time password’ encountered when connecting to NetExtender
- Supported SonicWall and 3rd party SFP and SFP+ modules that can be used with SonicWall NSsp series
- Supported SonicWall and 3rd party SFP and SFP+ modules that can be used with SonicWall NSA series
Categories
- Firewalls > TZ Series
- Firewalls > SonicWall SuperMassive E10000 Series
- Firewalls > SonicWall SuperMassive 9000 Series
- Firewalls > SonicWall NSA Series
YES
NO