Is there an equivalent of SU for Windows

Question

Is there a way (when logged in as an administrator, or as a member of the administrators group) to masquerade as a non-privileged user? Especially in an AD environment.

e.g., in the Unix world I could do the following (as root):

# whoami
root
# su johnsmith
johnsmith> whoami
johnsmith
johnsmith> exit
# exit

I need to test/configure something on a user's account, and I don't want to have to know their password or have to reset it.

Edit:
runas won't cut it. Ideally, my whole desktop would become the user's, etc. and not just in a cmd window.

Solution 1

I'm pretty certain there is no supported way to run as a different user without having that user's credentials. It's a non-repudiation measure. Someone can't say: "I didn't do it", because either they did it, or someone with their credentials did it. And for the second they'd have to give the other person the credentials.

Normally how I do what I need to do while logged in as another user is to use remote assistance to essentially RDP into the session, and have them grant me control. Then I do whatever while they're watching (presumably, anyway).

Anything else can usually be done with GPO/scripts.

Solution 2

I've noticed a lot of other people mentioning variations on the runas command and how you need to know the users password, which is true, but I don't think that anyone has quiet answered the question. of "wanting the whole desktop would become the user's, etc. and not just in a cmd window". Here's the way I go about it:

Note: I'm going to refer to this first Command Prompt as CP1 to eliminate confussion later.

Under your admin account, open Command Prompt

For local account

runas /profile /user:computernamehere\username cmd

For domain account

runas /profile /user:domainname\username cmd

OR the way that I prefer it

runas /profile /user:username@domainname cmd

Note: A new command prompt will open (CP2), this is the user who are you trying to login as.

Open CP1 and type:

taskkill /f /IM explorer.exe

Open CP2 and type:

explorer.exe

Depending on the computer, it may create a profile for the user if they have never logged onto there before. You can save yourself the hassel later by keeping the command prompt windows open for later use.

When you're done with your work, just do the same thing in reverse.

In CP2 type:

taskkill /f /IM explorer.exe

Open CP1 and type:

explorer.exe

You should now be back into the orginal administrator account. You can do a quick check by tapping the Windows key and looking for the current user panel.

Hope this helped.

Solution 3

There's no built-in mechanism in Windows to do this. It can be done, but you're going to have to have something written to do what you want, and you're probably going to have to muck around with undocumented APIs.

One of the posters here, grawity, has it right w/ calling CreateProcessAsUser(), but you'll need to create a token with the undocumented native API zwCreateToken first. If you killed off Explorer and fired up a new Explorer instance w/ CreateProcessAsUser() I'm fairly certain you'd get want you want.

Microsoft doesn't make what you want to do easy because it's not the way they want you using NT. If you need to be logged-on as a user to troubleshoot their issues, in most cases you're going about it in a sub-optimal way.

You can make changes to the user's registry w/o logging-on as them (by attaching their registry hive and manipulating it that way). You can make changes to files in their user profile w/o being logged-on as the user. If you need to "setup email" or other such activities "as the user", you should be writing scripts or taking advantage of built-in functionality (Group Policy Administrative Templates, preferences, etc) to do your dirty work for you.

If you have to do this, have a look at RunAsEx on Code Project. That code should give you a fairly good idea of what you'll need to do. I haven't tried the program, but it looks like it's going about everything in the right way.

Solution 4

You can use the following command on Windows XP and later:

RunAs.exe

The command line options are available here.

This will not work without knowing the users password. I do not believe there is a way in Windows to operate under a users account without the password due to how the Security Identifiers are loaded.

Solution 5

(Just a guess.) If your account has SeCreateTokenPrivilege, you could write a small program to create a process using CreateProcessAsUser() or a similar function... (But not even administrators have the privilege by default.)

View more solutions

Comments

[Dayton Brown]

Just curious, but why do you need to login as the user? I would usually only need to do this to configure email. However, I've found that most of the time I can configure everything via Group Policy/Scripts/etc.

[Kevin Kuphal]

I believe the RunAs program still requires you to know the users' password which I believe the original question states is not known

[Doug Luxem]

You are correct...I had forgot about that.

[tomjedrz]

I believe this is correct. And, IMHO this is a security improvement over the UNIX world. I like the idea that not even an admin can be me without my password.

[BIBD]

This is typically how I operate as well. However, there's points that I say "It would be so much easier to do this for Bob if I was Bob", but Bob went home an hour ago.

[BIBD]

As far as "non-repudiation" goes, making me reset their password first doesn't stop me from committing malicious/stupid acts as another user. It just means I'd have to do more work to cover up who was responsible.

[Oskar Duveborn]

Well it means that 1) your admin account needs to have the ability to actually reset passwords and 2) hopefully the system is set up to provide an audit trail you cannot forge unless you're some kind of master admin... I'd say domain account password handling could easily be delegated to the helpdesk and require even admins to go through them - just as an example... I won't say this is better than being able to freely masquerade as any domain user - but it doesn't feel too stupid to try and prevent.

[Spence]

This functionality is considered a non-repudiation mechanism because you would, in most circumstances, generate an audit-trail of activities related to the attempted "coverup" (as Oskar states). The stark reality is that if you have physical access to a computer you can subvert whatever operating system security controls exist and render such mechanisms pointless. Nonetheless, the functionality was designed with non-repudiation in mind.

[BIBD]

I understand what they are trying to do. I just think it's more security-theater than actual security.

[Sonicsmooth]

The non-repudiation strategy is designed with the assumption that you do not have physical access to the server, because the #1 tenant of security is that if you have physical access, all bets are off. The idea is that you create a situation where the admin cannot obtain private physical access. And, because all log files are "locked" while the OS is running, you cannot modify them outside of their normal means.

[mskfisher]

That is some deep magic.

[BIBD]

Well 4 years later I was reminded of this question and when I had time to test this. WOW!

[TheAmigo]

On Windows 10, using runas prompts for the user's password.