Configure a Windows (Vista/7/8/2008/2012) service for authentication to eDirectory

Novell Client 2 SP1 (IR6) and later supports a new mechanism through which administrators can configure non-Novell-aware Windows services to be capable of authenticating to eDirectory, and therefore able to access Novell NCP-based volumes and paths.

By default this feature will not be enabled. Only by explicitly creating the Novell Client configuration described above will an eDirectory user account logon be attempted on behalf of the Windows service.

This is different from the Novell Client for Windows XP/2003, which would attempt to authenticate to eDirectory using the Windows account name and password "automatically" using a default eDirectory tree name and context, at the moment the UNC path access attempt was made. This type of "automatic" login attempt without pre-configuration is not available on the Novell Client for Windows 7 or Novell Client for Windows Server 2008 R2.

This feature is not designed or intended to work for services configured to run under "the Local System account" instead of an actual Windows user account. The Windows service must be configured to run under a specific Windows user account in order to use this eDirectory login feature on the Windows service's behalf.

With the eDirectory logon performed for Windows services in the Novell Client 2 SP1 (IR6) and later, the eDirectory logon occurs during Windows service startup, at the same time Windows is calling LogonUser to create the specific Windows user account logon session under which the Windows service will be running. The eDirectory login attempt processing occurs only once, and only during the Windows service startup.

The Novell Client will wait for the Windows network interfaces to become available, and will retry for a short period of time if "Tree or server not found" conditions are encountered during the eDirectory logon attempt. But if the eDirectory logon attempt ultimately fails for any reason (eDirectory tree can never be found, account password is incorrect, etc.), the Windows service will simply be allowed to start without an eDirectory login being available. There will be no future attempts or retries while the service is running, until the Windows service is shut down and then started up once again.

When the Windows service is running, the eDirectory authentications and NCP connections created on behalf of the Windows service are "private" to just that one instance of the running Windows service. The Windows service does not "see" or interfere with the NCP connections and eDirectory logins that are performed by interactive Windows users logging onto the same machine, nor do the Windows services "see" or interfere with the NCP connections or eDirectory logins of other Windows services. The same Windows user account can actually be specified on two or more Windows services, and each of those services will have an eDirectory login performed on their behalf. But these Windows service logon sessions are still considered separate, and are not shared or visible between Windows service instances.

Instead of using this "Service Account eDirectory Login" feature in Novell Client 2 SP1 (IR6) and later, other ways in which a Windows service might authenticate to eDirectory include:

The Windows service application can be written to invoke Novell APIs directly, such as NWDSLogin. This is something that would be designed and done by the application vendor, and not something an administrator can arbitrarily add to a Windows service application. Once logged into eDirectory, the Windows service application can expect that attempts to access UNC paths to Novell files and volumes within that tree will be able to successfully authenticate and access whichever paths the specified eDirectory user account was granted trustee assignments to.

The Windows service application can be written to invoke Microsoft Windows WNET APIs, such as WNetAddConnection. If the Windows service application permits the administrator to define what credentials (user account name and password) and path will be passed to the WNET API, specifying a Novell eDirectory user account DN and Novell server-based path can successfully authenticate the service to eDirectory. The Windows WNET APIs will employ each of the installed Windows-compatible network providers until one of them successfully authenticates with the credentials and path provided, so when the Novell Client network provider gets called, it will be able to employ the eDirectory user account DN to login and authenticate to the eDirectory tree and server represented by the target path.

The Windows service application could be setup to depend upon CIFS-based access through the Microsoft Client for Microsoft Networks, to access a Novell server which has CIFS emulation enabled for the volumes and paths the Windows service needs to access. Instead of requiring any separate eDirectory user account logon, the Windows service would attempt Windows-level authentication to the remote CIFS service using the Windows user account credentials specified in the Windows service's "Log On" configuration.

The Windows service application may be designed such that it intends to impersonate logged-on interactive users, and to act on the interactive user's behalf including use of the interactive user's existing eDirectory and NCP connections. As such the Windows service itself may not ever be logged into eDirectory, but at the times where eDirectory access is needed, the Windows service code was already intentionally impersonating the interactive Windows user logon session, and therefore has that user's eDirectory logins and NCP connections available. The simplest example of this is the Windows Print Spooler service. The Windows Print Spooler service itself (SPOOLSV.EXE) does not actually login to eDirectory on its own Windows service process. But users, who are logged into eDirectory and other remote resources, call the Windows Print APIs which call down to the Print Spooler service under impersonation. Whatever eDirectory or other remote resources the interactive user session can access defines which printer(s) the Print Spooler service will be able to access on their behalf. The Windows Print Spooler service itself was not required to login to any eDirectory or other remote resources.

Note:  The Service Account eDirectory Login configuration will use the Novell Client properties settings, same an an interactive user would.  The file system features like File Caching and File Commit have no idea how the eDirectory login was originally performed.  Those settings will be honored regardless of how the eDirectory login is performed.