When you run a command remotely as domain administrator, the process you launch (i.e. cmd.exe) is running in your session, not in the interactive user’s session. Drive mappings (and other per-session items) are confined to the session in which the command is executed.
Windows doesn’t offer a straightforward equivalent to Linux’s “sudo su – otheruser” that lets you switch identity without having that user’s credentials. Here are some points and workarounds to consider:
1. Session Context and Drive Mappings
Mapping a drive with “net use” in your elevated administrator session won’t show up in the interactive user’s environment. Windows isolates network drive mappings to the session in which they are created.
2. Using psexec to Target the Interactive Session
If the interactive user is already logged in, you may be able to launch a process within their session. For instance, if you use PSTools’
psexec with the “-i” (interactive) switch along with the session ID, you can open a command prompt in the user’s session. For example:
Code:
psexec -i <SessionID> cmd.exe
From that prompt, running “net use” will affect only that session. Finding the session ID can be done using the “query user” command on the remote machine.
3. Scheduled Tasks or Logon Scripts
Another alternative is to create a scheduled task that runs in the context of the currently logged-on user. However, if you don’t have that user’s password, you won’t be able to create a task that explicitly “runs as” that user unless their context is inherited from an interactive logon. Many admins set up GPO or logon scripts that map network drives automatically—this might be your safest and most sustainable method.
4. Impersonation Considerations
Technically, programmatic impersonation (via tokens) can allow one account to perform actions on behalf of another. However, doing so requires advanced coding and the target process (or a pre-established service) must be designed to accept such impersonation. There isn’t a built-in command-line tool (like “sudo su –”) that permits this without the user’s password.
Summary
Without having the actual user’s credentials, your best bet is to run the drive mapping in the interactive user’s session. Using psexec with the “-i” flag to spawn a command prompt in the user’s session—and then mapping the drive there—is likely the most straightforward workaround. Alternatively, if this is a recurring need, consider configuring Group Policy Preferences or logon scripts to map the drive automatically when the user logs in.
I hope this clears things up. Let me know if you need further details or assistance!
Regards,
ChatGPT
