WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

WinBatch
Functions

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

Netware wntRunAsUser and RunwithLogon Problem

I'm trying to install an app that resides on a netware drive. I have a Netware account that will have rights over the local machine, as well as rights on the share. My question was, do I use wntrunasuser() or do I use runwithlogon() to do the credentials\authentication.

You said... 

Regardless of whether you use wntRunAsUser() or RunWithLogon(), the process 
that you create under a different set of credentials is not going to be logged in to NDS/eDir because 
its security context will have changed. This means that you need to launch a *local* script under new 
credentials and then have that script authenticated to NDS/eDir before attempting to start the Oracle 
installation.
Can you help me out in understanding this more clearly?

Answer:

No user account in NDS/eDir is going to have rights over the local workstation. You have have an NDS/eDir account that has rights to directory services & file resources in the NetWare environment, and then you have a separate Windows account that has rights to the workstation.

The probem is very straight forward. As soon as you begin impersonation with wntRunAsUser(), or as soon as a process is started under a different set of credentials using RunWithLogon(), the process no longer has access to the same set of Novell Client services that were available under the original set of credentials.

Let's look at it like this:

Windows user "WinUserA" is logged on to the workstation and is logged on to eDir as "NWUserA". WinUserA begins impersonating "WinUserB" via wntRunAsUser(). When the impersonation begins, the the process is now "WinUserB" as far as the Novell Client is concerned, and "WinUserB" isn't logged in to eDir and doesn't have any access to NetWare resources. It is necessary for the process running under WinUserB's Windows credentials to authenticate to eDir. When the impersonation ends, the Novell Client authentication information for WinUserB is destroyed and the process reverts back to having access to the Novell Client environment that existed before it started impersonating WinUserB.

If we take the same scenario and use RunWithLogon(), things are pretty much the same but with one minor twist. The process that is created to run the program specified in RunWithLogon() is going to run under new Windows credentials, such as the WinUserB account mentioned in the first example. That's all well and fine. The process gets created under the new set of Windows credentials, and because it is in a new security context, the Novell Client environment that it is in is not authenticated to eDir. If RunWithLogon() was set up to run a program located on a local drive, then you only have to worry about WinUserB having permissions to execute that program. However, if the program was located on a remote server, then that's where things get trickier. If the remote server is a Windows server and WinUserB has rights to access the file, then RunWithLogon() will be successful. If the remote server is a NetWare server, then WinUserB doesn't have any authenticated NDS/eDir credentials and thus RunWithLogon() will fail as the process that was created cannot access the program that it was created to run.

Drive letter mappings are part of the security context, so not only do you have to deal with changes in access rights to UNC paths, you also have to deal with the disappearance of mapped drive letters as well regardless of what type of remote server the drive letters were mapped to. This can cause RunWithLogon() to fail of the program it was going to execute under a new process using new credentials is specified using a drive letter path instead of a UNC path.

Now, all of that discussion aside, the following things come to mind as being the "safe" way to handle impersonation, etc... and remote resources.

Have script "ScriptA" use RunWithLogon() to execute script "ScriptB" under new Windows credentials. Make sure that ScriptB is located on a local drive on the workstation. then, if "ScriptB" has to access resources on a NetWare server, it will be necessary for "ScriptB" to use the NetWareX extender to login to NDS using Netware credentials that will allow it to access file resources on a remote NetWare server. Once "ScriptB" does this, it can, in turn, execute any software installation programs that are required to perform a software installation. 

Article ID:   W16448

File Created: 2005:02:18:12:20:46
Last Updated: 2005:02:18:12:20:46