Is there an equivalent of SU for Windows

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.

From serverfault CodeSlave

• 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.

  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.
  From Doug Luxem

• Yes, runas

  runas /user:waynesdomain\myadminaccount regedt32.exe

  Runas can be used to start any program, MMC console, or Control Panel item as long as the following requirements are met:

  You provide the appropriate user account and password information. The user account has the ability to log on to the computer. The program, MMC console, or Control Panel item is available on the system and to the user account.

  From: www.windowsnetworking.com/nt/nt2000/atips/atips12.shtml

  CodeSlave : This would require me to know their password or reset it, which I would like to avoid.
  From Jon Pospischil

• You can also right clicking on a program to get a GUI for the runas command.

  Kevin Kuphal : RunAs requires knowledge of the users' password which is not known
  From andymoe

• (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.)

  From grawity

• Runas.exe allows you to run programs as another user, but the big problem is it prompts you for the other user's password, which is the scenario you're trying to avoid in the first place. Yes it's inconvenient, but the user's perspective you're more secure if the admin of your computer network can't masquerade as you without your knowledge.

  Still, here's how to use the command:

  runas /user:other_user cmd.exe
  

  will prompt you for the other user's password and get you a command window with the other user's credentials and environment. You can see this in action if you issue a 'set' command, which will display the other user's home folder, and user-name among all the other environment variables.

  Runas.exe will also run GUI apps, though explorer.exe causes some issues. I did hear that it worked the way you expect if your options are set to view folder windows in separate processes, but when I tested it just now it did nothing.

  runas /user:other_user notepad
  

  runs notepad as the other user with the other user's settings and default folder for saving files.

  You can also set up a shortcut icon and at least in Vista there's an entry on the right-click menu to 'run as administrator'. I'm unsure if that runs as a different user or if it just temporarily promotes your account.

  From $pageUsers[$post.author].name

• 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.

  CodeSlave : Configuring e-mail is a good example. Typically you do that when you set up the account, but sometimes they end up needing to have an .pst created to archive mail when their mailbox starts to get full, etc. (but they are leaving for the day and can't wait for you to remote into, and they taking their laptop with them).

  CodeSlave : I also just had an incident where there is a pop-up blocker installed on the workstation, and I need to turn it off to so that a work related site will function properly for them, but the user is away today, so I have to wait until tomorrow to fix it and close the incident.

  Jim B : the outlook configuration issue was solved in outlook 2007, outlook will prompt the user to create an archive after a few weeks and and ask them to run th autoarchive wizard (which in my envronment is disabled by GPO as I dont; reccomend anyone use PST files in a corp env.) a GPO should alaso fix the pop up blocker issue.

  CodeSlave : Perhaps, its a third party pop-up blocker, But then again, this is a one time thing. I think it would take longer to create the GPO and target it than it would to remote in the workstation, and update the setting in the pop-up blocker

  Evan Anderson : It might take longer this time, but there won't ever be a "next time". I highly recommend taking a little extra time to end up doing work exactly once.

  Oskar Duveborn : http://blog.serverfault.com/post/1097492931/designing-for-scalability-of-management-and-fault
  From Dayton Brown

• Although I do not have personal experience with some of the sudo solutions mentioned on this site, I highly recommend nonadmin started by the excellent Aaron Margosis. It is a huge help as you roll out limited users. I mainly jumped with something since everyone else is saying use Runas. However, I think most or all of these so called sudo for windows deal more with elevation rather than acting as another user without their password.

  From Knox

• 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.

  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.

  Mystere Man : An admin can take over another user, by resetting their password. Then they can login as you. However, there is an evidence trail if you do this. First, the users password was changed so they'll know. Second, there will be audit logs (assuming auditing is enabled).

  CodeSlave : 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.

  CodeSlave : 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.

  Evan Anderson : 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.

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

  Mystere Man : 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.
  From Orihara

• 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.

  From Evan Anderson

• Process Explorer procexp.exe on http://live.sysinternals.com has a run as limited user (on the file menu) which will let you run a program using your current credentials, but with your ACL stripped down to that of a normal user (non-admin) user. Not what you wanted exactly, but good for testing.

  From Booji Boy

• runas will do as you asked, but be aware, that some applications do not play nicely when they spawn their own processes.

  EG. MSI installations have the ability to elevate their permissions when invoked (group/local policy permitting) - but if you invoke an msi installation with runas /user:mydomain\administrator (for example) the results are not always as you would hope for.

  From Iain