Novell Client 2 SP1 for Windows 7 (IR6)
Novell Client 2 SP1 for Windows Server 2008 (IR6)
Novell Client 2 SP1 for Windows Server 2008 R2 (IR6)
Novell Client 2 SP3 for Windows 8
Novell Client 2 SP3 for Windows Server 2012
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.
To configure a Windows service for authentication to eDirectory:
Configure the Windows service to start using a specific Windows user account. The Windows user account used for the service is configured from the Windows "Services" control panel applet, by opening the properties of a specific service and specifying "This account:" in the "Log On" tab of the service's properties.
Ideally the Windows user account specified would not be a Windows user account which is also being used for normal interactive login, and would be created and granted necessary permissions strictly for the use of running a particular Windows service. Login to eDirectory is not supported for services running as "the Local System account", which is what most services run as by default when not configured with a specific Windows user account.
Create a subkey named "Service Account eDirectory Login", if one does not already exist, under the [HKEY_LOCAL_MACHINE\Software\Novell\Login] key in the registry.
Create a subkey under the [HKEY_LOCAL_MACHINE\Software\Novell\Login\Service Account eDirectory Login] key in the registry, using the name of the Windows user account specified for the Windows service "Log On" configuration.
For example, if the Windows service was configured to log on with a Windows user account named "AntiVirusUpdateUser", the registry key that needs to be created is [HKEY_LOCAL_MACHINE\Software\Novell\Login\Service Account eDirectory Login\AntiVirusUpdateUser]. If the Windows user account name was "DataSyncService", the registry key that needs to be created is [HKEY_LOCAL_MACHINE\Software\Novell\Login\Service Account eDirectory Login\DataSyncService], etc.
Within the Windows user account-specific subkey, create all of the following required registry values. These values are required for the eDirectory login mechanism to engage. If one or more of these values is missing, the eDirectory login on behalf of the Windows service will be disabled:
"Enabled" as 32-bit DWORD value of 0x00000001. This is required for the eDirectory login configuration to be honored. If this configuration needs to be temporarily disabled, this value can be set to 0x00000000 without having to remove any of the other configuration values.
"DefaultUserName" as a String value. Specifies the complete distinguished name (DN) of the eDirectory user account to login with. For example, "AntiVirusUpdate.Services.MyCorp". This eDirectory user account name does not have to match the Windows account name being used for the Windows service logon.
"DefaultTreeName" as a String value. Specifies one or more eDirectory tree names for which login should be attempted on behalf of the Windows service. For example, "MYTREE". To specify more than one eDirectory tree name, create a single String value (not "Multi-String Value") and provide a comma-separated list of eDirectory tree names/IP addresses for which login should be performed. For example, "MYTREE,ANOTHERTREE". You can enter a specific NCP server name, DNS name or string form of the IP address instead of the actual eDirectory tree name, in order to better control which eDirectory replica is used for this Windows service login to eDirectory. If a name is entered, it will either need to be successfully resolved by SLP or DNS, or by a local HOSTS file entry. Note that the same eDirectory user account DN and password will be used for each eDirectory tree authenticated on behalf of this Windows service.
Within the Windows user account-specific subkey, optionally create one or more of the following additional registry values. These values are optional, and absence of these registry values will not disable the eDirectory login on behalf of the Windows service:
"DefaultPassword" as a String value. If specified, contains a clear-text version of the password for the eDirectory user account specified in "DefaultUserName". If this value is NOT created in the registry, the Novell Client will default to attempting to login to eDirectory using the same password as was specified for the Windows user account in the Windows service "Log On" configuration. Keeping the eDirectory user account password and Windows user account password in sync and then NOT creating the "DefaultPassword" value in the registry is the recommended approach, to avoid the security implications of a clear-text password saved in the registry.
Now use the Windows "Services" control panel applet to stop and re-start the Windows service; or simply restart the Windows machine entirely. The next time Windows starts the configured service, in addition to Windows creating a Windows account logon session for the Windows user specified in the "Log On" configuration, the Novell Client will also attempt logging into eDirectory as the specified user account in the specified eDirectory tree(s).
If the eDirectory login is successful, the Windows service will be able to access UNC paths of file and volume resources on servers within the specified eDirectory tree(s), for whichever volumes and paths the eDirectory user account has been granted file system trustees. There will not be any eDirectory login script processing performed for this eDirectory login on behalf of the Windows service account; only UNC path access will be available.
For additional configuration required for IIS application, see TID 7011952, "Configure Service Account eDirectory Login for IIS 7.5 application pool."
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.