Tips on SSO Agent with Novell eDirectory

03/26/2020 7 11151

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!!!