wntRunAsUser RunWithLogon Security Context

keywords:  runwithlogon wntrunasuser 1932 mapping map network security context

Issues involved with RunWithLogon and wntRunAsUser when you change the credentials under which a program runs:

This all comes back to the concept called "Security Context" that exists on the WinNT platform family. A security context is nothing more than a sandbox in which programs can all play. When you are logged on to a NT platform system, your session consists of multiple processes, with each process running one program. When you connect a drive letter to a network resource, that drive letter only exists within your security context. Other sessions [e.g. other terminal sessions on a terminal server system, services running under separate user accounts different from your own] have separate security contexts and thus they don't see your drive letter mappings as they exist in their own private sandboxes.

When you use wntRunAsUser() or RunWithLogon() to make use of impersonation in one form or another, you are causing either your own process [e.g. via wntRunAsuser()] or another process [e.g. via RunWithLogon()] to run in a separate security context.

In the case of using wntRunAsUser(), it is obvious that your existing process continues executing your script, but the first time you attempt to access a resource on via mapped drive you get a failure because that drive letter doesn't exist in your process' security context.

In the case of using RunWithLogon(), things are tougher because the process gets created in a new security context, but when it tries to execute the program that it was created to execute, that program is not accessible as the drive letter for the program path doesn't exist in that process' security context.

Now, if your drive letters are on remote Windows servers, switching over to using UNC paths instead of mapped drives will cure the problem. You simply need to make sure that the user credentials used for impersonation have permissions for Read and Execute on those remote shares.

Note: If you are using NetWare servers, things are little worse off. When a process is created and it is in a new security context, or if an existing process begins impersonating another user, then the Novell Client's authentication information & mapped drive table changes when the security context changes. In a new security context, the Novell Client isn't authenticated to any servers and thus it has no drive letters mapped. It would be necessary for the program being executed to exist locally so that it could be accessed, and then the program would have to perform its own authentication to NDS/eDir before it could access any NetWare-related resources via either a UNC path or a mapped drive letter.

Under the Win9x platform family, there is no such thing as a security context. Or, to be more accurate, the entire system runs under one single security context so the problem associated with changing security contexts never becomes an issue.

Article ID:   W16532

File Created: 2005:02:18:12:21:18

Last Updated: 2005:02:18:12:21:18

Database Search

TechHome

wntRunAsUser RunWithLogon Security Context