There is a need to allow a non-Novell-aware Windows service application to access Novell network resources by UNC path.
For specifically the Novell Client 4.91 SP3 and 4.91 SP4, apply the post-updates to NOVNPNT.DLL and NWGINA.DLL. Navigate to download.novell.com and search for NOVNPNT.DLL dated 24Sep2007 or later. The fix is documented as "Application running as a service fails to login. (Bug 270056)." Without these updates applied, some of the functionality described in this document will not appear to work as expected.
To allow a non-Novell-aware Windows service application to access Novell network resources by UNC path, use the following configuration steps. For other situations and for additional technical information, please see the "Windows service background" section elsewhere in this document.
Note that this discussion and configuration is specific to the Novell Client for Windows XP/2003, and does not apply to the Novell Client for Windows Vista.
1. Configure the service to access its network resources by UNC path, as opposed to trying to reference network drive letters. For additional information regarding why network drive letters are not accessible by a Windows service, see the "Windows service background" and specifically the "Network drives mapped by an interactive Windows user are not available to a Windows service" sections.
2. Configure the Windows service to start with a specific Windows user account name and password. Create the Windows user account with the same name as the eDirectory user object you will want the service to login with. For example if the service will be expected to login as "AVUPDATE.Accounting.WidgetCo", create the Windows account name as "AVUPDATE". You then assign the Windows service to start as the specific Windows account "AVUPDATE" in the Windows "Services" control panel.
3. Set the "Tree:" and "Name context:" pair in the "Client" tab of the Novell Client Properties such that the "Name context:" reflected for the eDirectory tree the service will be logging in to is set to the correct context for the service's eDirectory user. For example if the service will be expected to login to the eDirectory tree "MYTREE" as "AVUPDATE.Accounting.WidgetCo", the "Name context:" for "MYTREE" will need to be "Accounting.WidgetCo". This configuration can be established by editing the "Client" tab directly, or by logging on interactively as any eDirectory user from the "Accounting.WidgetCo" container.
At this point, once the Windows service is restarted, when the service attempts to access a UNC path to a Novell resource, the Novell Client will attempt to login to eDirectory on the non-Novell-aware Windows service's behalf. The Windows username and password the service started with will be attempted in conjunction with the context shown in the "Name context:" shown in the "Client" tab for the target eDirectory tree. If this login is successful, the Windows service will be able to access eDirectory with the rights of this eDirectory login that has been established specific for the Windows service.
For other situations and for additional technical information, please see the "Windows service background" discussion in the "Additional Information" section of this document.
Windows service background:
On machines where the Novell Client for Windows is installed, sometimes it is desired that an application running as a Windows service be able to access Novell network resources. There are several Windows service-specific differences in how this occurs as compared to a normal interactive Windows user logon. This document intends to describe some of those differences and the different methods by which a Windows service might achieve access to Novell network resources.
Windows runs applications and processes under what is referred to as a "logon session". There are default "LocalSystem" logon sessions one or more Windows services can share and run together under. And any time a specific username and password are supplied (either for an interactive user logon or a Windows service logon), Windows creates a unique logon session associated with that logon.
Logon sessions are important to this discussion because network resources, such as mapped drives and authenticated connections, are associated to the specific Windows logon session that created them. The Novell login and NCP connections created by the interactive user's logon are typically not accessible or visible to the Windows services running on the same machine. Because the interactive user is running under their own unique Windows logon session, and the Windows services are running under one of the "LocalSystem" logon sessions or their own unique Windows service logon session.
In order for a Windows service to have access to Novell network resources, "something" has to perform a Novell login from "inside" the same Windows logon session as the service is running, so that the resulting Novell authentication and NCP connections will be accessible to the Windows service. There are several ways in which this Novell login can occur from within a service:
Novell-aware Windows service application:
With a Windows service that is Novell-aware, the service application will have a Novell-specific configuration for what eDirectory identity the Windows service should try to connect as. The exact nature of how this is configured depends upon the application vendor. The Window service application will then make Novell-specific API calls, such as NWDSLogin, to perform an eDirectory login as the specified eDirectory user. Examples include virus scanners that have a configuration for logging in and downloading updated virus definitions from a Novell server, or network printing service applications that use a specific eDirectory identity for logging in and managing printing objects.
This is the "best" scenario, because it is completely non-ambiguous with regard to the eDirectory tree and identity that the Windows service should login to Novell as. But this approach requires that the Windows service application vendor write their software to be Novell-aware, and cannot be arbitrarily introduced into a Windows service that wasn't already written with this approach in mind.
Depending on a separate Novell-aware Windows service application:
With a Windows service that is not Novell-aware, the service application might indirectly depend on some other Windows service application that runs under the same "LocalSystem" logon session being Novell-aware, and this other Windows service is what causes an eDirectory login with a known identity to occur. The primary example is when the Novell ZENworks Workstation Manager service is configured to login to eDirectory as a registered workstation object. Other Windows services that run in the same "LocalSystem" Windows logon session as the ZENworks Workstation Manager can leverage the fact that the "LocalSystem" Windows logon session is now logged into eDirectory as the workstation object.
This scenario can be the most convenient for network environments that are already using registered ZENworks Workstation Manager objects, provided that the eDirectory rights necessary for the additional Windows service(s) that will be leveraging the Workstation Manager login can be added to the ZENworks workstation object.
Non-Novell-aware Windows service application:
With a Windows service that is not Novell-aware, the service application might still use standard Windows network APIs and UNC paths which, in turn, end up causing Windows to invoke the installed Novell Client for Windows network provider functions. When the Novell network provider functions are called, they will determine that the current Windows logon session is not already authenticated to the UNC path the Windows service is attempting to access. The Novell network provider will then attempt to perform an automatic eDirectory login based upon the Windows username and password the current Windows logon session was established with. Note this option is only possible when the Windows service has been configured to start under a specific Windows user account; if the Windows service is running as one of the standard "LocalSystem" logon sessions, there isn't any Windows username and password to attempt logging into eDirectory with.
This scenario is perhaps the most common for non-Novell-aware Windows services. But it does not afford the greatest reliability, due to the fact that there is not an explicit specification for what eDirectory identity the Windows service should attempt to login with. The "Novell Client settings for a non-Novell-aware Windows service application" section below goes into greater detail on the limitations and configuration of this scenario.
Novell Client settings for a non-Novell-aware Windows service application:
Typically, for an interactive Windows user logon, the user provides only their password and maybe their username. The rest of the information needed for an eDirectory logon â the eDirectory tree name and the eDirectory context â come from the "eDirectory" tab defaults stored as part of the Novell Client "Location Profile".
For a non-Novell-aware Windows service that is not directly invoking any Novell-specific login APIs, the only information the Novell network provider has available at the time the Windows service is attempting to access a particular UNC path is the Windows username and Windows password that were used for establishing the Windows logon session under which the service is running.
Therefore in order to make an eDirectory logon attempt, the information of eDirectory tree name and eDirectory context must come from somewhere else. The eDirectory tree name is actually inferred by the UNC path the Windows service is attempting to connect to. For example, if the Windows service is attempting to access "\\FS1\SYS", the Novell Client will determine which eDirectory tree "FS1" is a member of.
For the eDirectory context, since there is not a Novell login dialog or "Location Profile" involved in the Windows service's indirect authentication attempt via the Novell network provider, the eDirectory context to be used in conjunction with the Windows username ends up being determined by the "Tree:" and "Name context:" pairs that can be viewed on the "Client" tab of the Novell Client Properties.
So for example, say that a Windows service was started user the Windows account "AVUPDATE" with password "novirus". And that when the service attempted to access "\\FS1\SYS", the Novell Client determined that "FS1" was part of the eDirectory tree "MYTREE". If the "Client" tab in the Novell Client properties showed that the current default context for "MYTREE" was "Accounting.WidgetCo", the non-Novell-aware Windows service's attempt to access "\\FS1\SYS" would result in the Novell Client network provider attempting to login to the eDirectory tree "MYTREE" as "AVUPDATE.Accounting.WidgetCo" using password "novirus".
A problem that can be experienced with the "Tree:" and "Name context:" pairs on the "Client" tab of the Novell Client Properties is that these values are intentionally updated as users and/or applications reset what they consider to be the "default" eDirectory name context. This is what makes the non-Novell-aware Windows service application approach more fragile than the Novell-aware Windows service that has an explicit eDirectory username and context that the Novell-aware Windows service will attempt to login as.
So even though a non-Novell-aware Windows service might be able to login successfully today with the "Tree:" and "Name context:" pair currently shown on the "Client" tab, the service can start failing to successfully login tomorrow. And upon visiting the "Client" tab in the Novell Client Properties, it will be found that the "Name context:" value for the relevant eDirectory tree has been changed, likely due to some unrelated user or application activity.
If and when this indirect login attempt by a non-Novell-aware Windows service fails, the Novell Client network provider will also attempt a bindery-mode authentication using just the Windows username and password. If the bindery-mode attempt also fails, then the Windows service will simpy fail accessing the specified Novell resource. There is no failure dialog, and unlike a normal interactive user login attempt, no interactive Novell login dialog will appear in response to the Windows service application's failure to achieve a successful automatic login.
As noted earlier, for the "LocalSystem" logon sessions used by many services there is not an associated Windows username and password available for the logon session. Therefore the automatic eDirectory logon attempt on the Windows service's behalf cannot occur, because there isn't even a Windows username and password for the Novell Client network provider to utilize in constructing a set of eDirectory credentials to attempt for the login.
Windows services that temporarily impersonate the calling application:
The line between "a Windows service can only access those Novell authentications and NCP connections that have occurred in the Windows logon session the service is running under" can become blurred when the Windows service provides an RPC interface for providing services. As part of the RPC interface mechanism, its possible for the Windows service to temporarily "impersonate" the interactive user's Windows logon session, for the purpose of performing some action that needs to succeed or fail based on the rights that the interactive user has (as opposed to the rights that the Windows service has, which are typically greater).
An example of this is the Windows print spooler service. When user applications make Windows spooler API calls, when the Windows spooler service invokes a network print provider, the service will typically impersonate the Windows logon session of the user application that made the API call. The Windows print spooler service itself is not logged into eDirectory, and is running under one of the standard "LocalSystem" logon sessions that doesn't have a Windows username and password available.
But the Windows print spooler service is still able to print to Novell printers, because each time a user application calls the Windows spooler service, the Windows spooler service temporarily impersonates the Windows logon session the application is running in, and this interactive user's Windows logon session actually is logged in to eDirectory and allows successful access to the printers the eDirectory user has rights to use.
Problems caused by services running in the same scope as ZENworks Workstation Manager:
A potential downside to the "Depending on a separate Novell-aware Windows service application" scenario described earlier is that if there are two or more Novell-aware Windows services trying to run in the same Windows logon session, they will end up "stepping on one another" since any given Windows logon session can only be authenticated as a single eDirectory user to any given eDirectory tree.
For example, say the ZENworks Workstation Manager service running in the "LocalSystem" logon session logs in to eDirectory tree "MYTREE" successfully as "MYPC.Workstations.Accounting.WidgetCo". But then a second Windows service also running in the "LocalSystem" logon session attempts to login to "MYTREE" as "AVUPDATE.Accounting.WidgetCo". Either the second login attempt will fail because the Windows logon session is already authenticated to "MYTREE" as "MYPC.Workstations.Accounting.WidgetCo", or the second Windows service will clear the existing authentication and successfully login as "AVUPDATE.Accounting.WidgetCo".
The functionality of one or both Windows services will be affected, since the access the Windows service thought it had established in the current Windows logon session will have been switched, removed or failed by the actions of the other service.
To avoid this situation, where possible run Novell-aware services in their own Windows logon session by specifying a specific Windows username and password for the Windows service to statup with, instead of using the default "LocalSystem" logon session that another Novell-aware Windows service is already using. By providing a specific Windows username and password for the Windows service to login and start with, this will create a Windows logon session unique to that service, and will thereby keep the eDirectory authentication and NCP connections for that Windows service separate from the other Windows logon sessions.
Network drives mapped by an interactive Windows user are not available to a Windows service:
The manner in which Windows maps network drives for any network client creates redirected drive letters that are unique to the Windows logon session in which the drive mapping was established. This is what allows, for example, one user on a Windows terminal server to map drive N: to "\\FS1\SYS" while another user logged on to the same terminal server can map drive N: to "\\FS2\DATA". The fact that these two users are running under unique Windows logon sessions also means that the drive mappings they create are unique to just their Windows logon session, too.
Because the Windows service is not running under the same Windows logon session(s) as the interactive user(s), the network drives that are mapped by the interactive Windows users have no meaning to the Windows service. From the above example, if the Windows service attempted to access drive N: from the default "LocalSystem" logon session, it would find that drive N: is not mapped, even though in the interactive Windows user logon sessions drive N: has been mapped to a network resource.
So a Windows service typically needs to reference network resources by UNC path, and not by a network drive letter, since there aren't any network drives mapped for Windows services, even when the interactive Windows user(s) have mapped network drives of their own.