Directory Services Connector 4.0 Admin Guide

Directory Services Connector Overview

This section provides an overview of the SonicWall Directory Services Connector (DSC). It includes an introduction to DSC and the SSO Agent, along with the supported user identification methods and platform compatibility.


About Directory Services Connector

SonicWall Directory Services Connector includes the SonicWall Single Sign-On Agent (SSO Agent) as well as certain configuration functions. The SSO Agent provides centralized user identification to SonicWall network security appliances, interacting with the SonicOS Single Sign-On feature.

Directory Services Connector provides integration with both Active Directory and Novell eDirectory. Specifically, these are supported as follows:

SonicWall SuperMassive™ series, E-Class NSA series, NSA series, and TZ 600/500/400/300/215/210/205/200/105/100 series appliances to achieve transparent, automated Single-Sign-On integration with both Active Directory and Novell eDirectory.
SonicWall PRO and TZ 190/180 series appliances to achieve Single-Sign-On integration with Active Directory.

The SonicWall appliance can use Active Directory or Novell eDirectory to authenticate users and determine the filtering policies to assign to each user or user group. The SSO Agent identifies users by IP address and automatically determines when a user has logged out to prevent unauthorized access.

Along with the username information, the SSO Agent sends the following information to the appliance:

The Domain Controller on which information about logged in users is found.
The User Detection mechanism used by the Agent to find logged in users.
NOTE: It is normal for the system running SonicWall Directory Services Connector to have high CPU activity for the first 24 hours after installation, while the software creates a database of the user network.

About Polling and Notification

The SSO Agent can work both passively and actively. In the default configuration, both methods are used.

In passive mode, SonicOS on the SonicWall network security appliance sends a request that contains an IP address to the SSO Agent. The SSO Agent identifies the username associated with the IP address and then sends the result back to SonicOS.

In active mode, the SSO Agent attempts to detect user logon and logoff events and sends notifications to SonicOS.

About Single Sign-On and the SSO Agent with Active Directory

Single Sign-On (SSO) is a transparent user-authentication mechanism that provides privileged access to multiple network resources with a single workstation login. SonicWall security appliances provide SSO functionality using the SonicWall Single Sign-On Agent (SSO Agent) to identify user activity based on workstation IP address.

SSO is configured in the Users > Settings page of the SonicOS management interface. SSO is separate from the authentication method for login settings that can be used at the same time for authentication of VPN/L2TP client users or administrative users.

The SonicWall SSO Agent identifies users by polling/monitoring security log in Active Directory server and sends user login/logout notification to the appliance when it detects user login/logout. See the Identifying users diagram. Based on data from the SSO Agent, the SonicWall security appliance queries LDAP or the local database to determine group membership. Memberships are optionally checked by firewall policies to control who is given access, and can be used in selecting policies for Content Filtering and Application Firewall to control what they are allowed to access.

Identifying users

User names learned through SSO are reported in the SonicWall appliance logs of traffic and events from the users. The configured inactivity timer applies with SSO, but the session limit does not, though users who are logged out are automatically and transparently logged back in when they send further traffic.

Users logged into a workstation directly, but not logged into the domain, cannot be authenticated. For users that are not logged into the domain, an Authentication Required screen displays, indicating that a manual login is required for further authentication. If the workstation joins the Windows domain, the logged on user can be detected by WMI/NetAPI. The returned user name includes a Local: prefix. For example, Local:user01.

Users that are identified, but lack the group memberships required by the configured policy rules, are redirected to an Access Barred page.

About User Identification Methods

The SSO Agent supports the user identification methods described in the following sections:

About Client Probing

Client Probing includes both Windows Management Instrumentation (WMI) and NetAPI probing methods.

WMI is the infrastructure for management data and operations on Windows-based operating systems. The SSO Agent sends a WMI request to the client, and then determines the username and domain name by examining certain processes on the client machine.

NetAPI is another interface based on Windows DCE-RPC service. In this case, the SSO Agent sends a request that lists the users logged into the client workstation. This list includes interactive, service and batch log ons. The SSO Agent then determines the correct user name in this list. The NetAPI method is much faster than the WMI method, but might not always yield a correct username.

Windows Firewall might block both methods by default. To enable:

WMI methods in the Windows Firewall, you can select Windows Management Instrumentation in the Control Panel > All Control Panel Items > Windows Firewall > Allowed Programs.
The NetAPI method in Windows Firewall, you can select File and Printer Sharing.

Because the Windows API does not provide an interface to set the timeout for both probing methods, the default timeout is set to three seconds when the IP address is not accessible or when the connection is dropped by the Windows Firewall. The SSO Agent first creates a TCP connection to the target machine to check the connectivity. For WMI, the port is 445. For NetAPI, the port is 135. The default timeout is 3 seconds for both methods.

If a user logs onto a machine using a local account instead of a Windows domain account, the SSO Agent can only identify this user through a Client Probing method. This is because the other methods all involve Active Directory. When the administrator enables the WMI/NetAPI Scanner option in Directory Services Connector, the SSO Agent will repeatedly probe these IP addresses using Client Probing methods. The SSO Agent can detect when the user has logged off, and it sends a log off notification to SonicOS.

About Domain Controller Querying

The Domain Controller (DC) is a server that responds to security authentication requests (logging in, checking permissions, and so on), within the Windows Server domain. Two methods are supported that identify users who log on to the Windows domain. They are the DC Security Log and Server Session methods.


About DC Security Logs

In Microsoft Windows, the Security Log contains records of log in and log out activity or other security-related events specified by the system's audit policy. When a domain user tries to log in to the domain network, the domain controller logs a message in the security log. The SSO Agent monitors event messages with specific Event IDs, and notifies SonicOS of the user information and logoff status.

About Server Sessions

Any connection to a file or print service creates a “session” in the server’s session table. In the normal operation of an AD domain, users on Windows systems connect to the sysvol share on the domain controller to check for new Group Policy Objects every one to two hours. The user appears in the session table for about five minutes each time. Log out messages are sent to the firewall when the SSO Agent cannot find the user after two hours.

Usually, Server Sessions is a more efficient method than DC Security logs, but sometimes, Server Sessions is not as accurate. In multiple domain environments, incorrect domain names might be reported. If the user switches between two logged on usernames, the SSO Agent cannot detect it.

About Enabling Audit Logs in DC Policy

Audit Logon is disabled by default in Windows Server. Steps to enable Audit Logon are provided in the following sections:

About Using Non-Admin Accounts to Access the DC Security Logs for SSO

SSO Agent service users do not have to be domain administrators. You can also use a normal domain user with some additional permissions granted, for access. For more information, refer to the Configuring a Non-Admin Domain Account for SSO Agent to Read Domain Security Logs Configuration Guide.

About Exchange Servers

When a user logs on to a computer that is not in the domain, the DC server does not have the user and IP address information. Typically, this is handled by the Client Probing method. You can also use the Exchange Server to identify the user.

This works only as a supplement to the Domain Security Log method. Although it works for machines not joined to a domain, it only works if users use Microsoft Outlook after logging in.

If the user opens Outlook to send or receive mail using a domain user name and credentials, both the DC and Exchange Server log events for this activity. On the DC, the event is logged, but the IP address given is not the real source. Instead, it points to the Exchange Server. On the Exchange server, a security log entry is made that contains both the user name and the source IP address. Each time Outlook receives email; there is also an event recorded by the Exchange server. The SSO Agent can monitor these events in the Exchange security log.

About Novell eDirectory

Novell eDirectory (formerly known as Novell Directory Services (NDS), sometimes referred to as NetWare Directory Services) is an X.500-compatible directory service software product initially released in 1993 by Novell for centrally managing access to resources on multiple servers and computers within a given network. eDirectory is a hierarchical, object oriented database used to represent certain assets in an organization in a logical tree, including organizations, organizational units, people, positions, servers, volumes, workstations, applications, printers, services, and groups.

When a user logs on to an eDirectory network, the user’s IP address is added to the networkAddress field in the user's record. If the user logs on to the eDirectory network multiple times from different machines, there will be multiple networkAddress fields. If the user logs off the eDirectory network properly, the corresponding networkAddress field is removed immediately. Otherwise the field is kept for some time before it is removed.

For this user identification method, the SSO Agent repeatedly queries the eDirectory using the LDAP protocol; see User identification with eDirectory.

User identification with eDirectory

The sequence of events shown in User identification with eDirectory is:

The user logs into the network and authenticates with eDirectory.
The user initiates a request for an Internet resource (such as a Web page, an audio or video stream, or a chat program). The SonicWall network security appliance detects the request.
The SonicWall appliance queries the SSO Agent.
The SSO Agent queries the eDirectory server about the user.

The SSO Agent communicates the user’s content filtering policies to the SonicWall appliance, based on the user’s individually assigned policies and any policies inherited from groups and from organizational units. The SonicWall appliance allows, logs, or blocks the user’s request, based on the user’s content filtering policies.

About Using Samba on Linux/UNIX Clients

Samba 3.0 or newer can be installed on Linux/UNIX clients for use with SonicWall SSO. Samba is a software package used on Linux/UNIX machines to give them access to resources in a Windows domain (by way of Samba’s smbclient utility). A user working on a Linux PC with Samba in a Windows domain can be identified through the SSO, but it requires proper configuration of the Linux PC, and possibly some reconfiguration of the appliance, as described in the Using Single Sign-On with Samba technote.

Without Samba, Linux PCs do not support the Windows networking requests that are used by the SonicWall SSO Agent, and therefore, do not work with NetAPI or WMI client probing methods. Linux users can still get access, but they need to log in to do so. They can be redirected to the login prompt if policy rules are set to require authentication.

Without Samba, the DC Security Log method will work for using Single Sign-On with Linux clients.

About NetBIOS Name Support

Windows provides support for applications that use the NetBIOS networking APIs and the flat NetBIOS names. This allows identification of Windows domains for computers that are running Windows. A fully qualified domain name (FQDN), sometimes also referred to as an absolute domain name, is a domain name that specifies its exact location in the tree hierarchy of the Domain Name System (DNS). It specifies all domain levels, including the top-level domain and the root zone.

Both the NetBIOS name and the FQDN domain name can be found through an LDAP search. The SSO Agent connects to the DC using these service credentials and completes the LDAP search.

The SSO Agent remembers these names and sends the correct domain name to the firewall according to the administrator’s configuration of the SSO Agent. By default, it sends the NetBIOS name.

Platform Compatibility

To use SonicWall Single Sign-On, it is required that the SSO Agent be installed on a server that can communicate with the Active Directory or eDirectory server and with clients and the SonicWall security appliance directly using the IP address or using a path, such as VPN. The following requirements must be met in order to run the SSO Agent:

Port 2258 must be open; the firewall uses UDP port 2258 by default to communicate with the SSO Agent; if a custom port is configured instead of 2258, then this requirement applies to the custom port
Windows Server, with latest service pack
.NET Framework 4.0 or above
NetAPI or WMI (unless using DC Windows Security Log as the Client Probing Method)
The SSO Agent must run under Domain Admin privileges

SonicWall Directory Services Connector and SSO Agent runs as either a 32-bit or 64-bit application. This improves the performance of 64-bit agent machines, especially in cases where the agent is set to use NetAPI or WMI as the Client Probing Method.


SonicWall Appliance/Firmware Compatibility

SonicWall Directory Services Connector is a supported release for use with the following SonicWall platforms:

SuperMassive 9200 / 9400 / 9600 running SonicOS 6.1 and above
SuperMassive E10200 / E10400 / E10800 running SonicOS 6.0.x
NSA 2600 / 3600 / 4600 / 5600 / 6600 running SonicOS 6.1 and above
NSA E-Class E5500 / E6500 / E7500 / E8500 / E8510 running SonicOS 5.0 and above
NSA 240 / 2400 / 3500 / 4500 / 5000 running SonicOS 5.0 and above
NSA 220 / 220W / 250M / 250MW running SonicOS 5.8.1 and above
SOHO running SonicOS and above
SOHO W running SonicOS and above
TZ600 / TZ500 / TZ400 / TZ300 running SonicOS and above
TZ500W / TZ400W / TZ300W running SonicOS and above
TZ 215 / 215W / 205 / 205W / 105 / 105W running SonicOS 5.8.1 and above
TZ 210 / 210W / 200 / 200W / 100 / 100W running SonicOS 5.0 and above
TZ 190 / 190W / 180 / 180W running SonicOS 4.0 and above
PRO 2040 / 3060 / 4060 / 4100 / 5060 running SonicOS 4.0 and above
NOTE: SonicOS 5.5 or newer is required for Novell eDirectory Support.
NOTE: SSO Agent performance is sensitive to the round trip network time during frequent information exchanges with the network security appliance. The Agent machine should be as close as possible to the appliance for a recommended round-trip time of less than 1 ms.

Virtual Environment Compatibility

Recommended Virtual Environments for Directory Services Connector include:

VMware ESX 5.5
VMware ESX 5.1
VMware ESX 4.x
Microsoft Hyper-V 2012 R2
Microsoft Hyper-V 2008 R2

Virtual Machine host configuration requirements:

OS - Windows Server 2008 / 2008R2 / 2012 / 2012R2 / 2016 — 32-bit/64-bit
CPU – Intel Xenon (4 processors)
Memory - 4GB

eDirectory Server Compatibility

SonicWall Directory Services Connector is supported for use with the following eDirectory servers:

Novell eDirectory 8.8.5
Novell eDirectory 8.8.7

Exchange Server Compatibility

SonicWall Directory Services Connector is supported for use with the following exchange servers:

Exchange server 2016
Exchange server 2013
Exchange server 2010

Domain Controller Server Compatibility

SonicWall Directory Services Connector is supported for use with Domain Controllers running the following operating systems:

Windows Server 2016 – 64-bit
Windows Server 2012 – 64-bit
Windows Server 2012 R2 – 64-bit
Windows Server 2008 R2 – 64-bit
Windows Server 2008 – 32/64-bit
Windows Server 2003 R2 – 32/64-bit

It is recommended to run the SSO Agent service using a domain administrator account. An account with fewer permissions, such as a domain user account, does have sufficient privileges for all service components to interact with the Domain Controller.

SSO Agent Platform Compatibility

NOTE: For best performance, SonicWall recommends installing the SSO Agent on a dedicated system.

SonicWall Directory Services Connector and SSO Agent are supported for installation on 32-bit and 64-bit Windows systems running the following operating systems:

Windows Server 2016
Windows Server 2012
Windows Server 2012 R2
Windows Server 2008 R2
Windows Server 2008
Windows Server 2003 R2
Windows 10
Windows 8
Windows 7

On all Windows 32-bit and 64-bit servers, a .NET Framework must be installed. The following versions of.NET Framework are supported:

.NET Framework 4.5
.NET Framework 4.0

The following Microsoft Windows operating systems are not supported as servers:

Windows 2000 – All versions
NOTE: Windows Server 2008 and higher or Windows 7 and higher are recommended.

The following limitations exist in Windows operating systems prior to Windows Server 2008 or Windows 7:

Certain Windows API elements are not supported, including the Event Subscription API for communicating with the Domain Controller. This requires Directory Services Connector to use the WMI event subscription mechanism on older Windows versions, which is much slower than event subscription.
The SMB2 protocol is not supported on older Windows versions.
Single Sign-On related functions may operate at approximately half the performance on older Windows versions.

Client Compatibility

Directory Services Connector is compatible with the following client operating systems for the purpose of determining the logged in username and other information necessary for user authentication:

Windows 10 – 32/64-bit
Windows 8 – 32/64-bit
Windows 7 – 32/64-bit
Windows Vista – 32/64-bit
Windows XP – 32/64-bit

Citrix or Terminal Services Compatibility

The SonicWall SSO Agent is not supported in a Citrix or Terminal Services Environment.

In these environments, you can use the SonicWall Terminal Services Agent (TSA) to communicate with the SonicOS Single Sign-On feature.

The TSA is not included as part of SonicWall Directory Services Connector. For more information about the TSA, see the latest Terminal Services Agent Release Notes and the latest SonicOS Administration Guide, available at: https://support.sonicwall.com/.