Older Questions

It's good to see a community forum talking about this subject. I know there a lot of users out there that will be surprised by some of the information on this page. I'm looking for something different though. I can't, for the life of me, figure out how to run a command as a different user when currently running as Administrator without knowing that user's password. Here's my situation:

• I'm in charge of a rather disorganized Active Directory and managers ask me to edit user's ACLs for some network volumes.
• I set everything correctly and use the effective permissions function to see what that user is allowed to perform on that directory.
• I then open explorer.exe using Run As to change to the user in question and do a final test to see if my ACL is correct.

The only documented way I've found to do this is by knowing that user's password, which would require me to keep a writen record of all the passwords , which is something I'm not willing to do. On my network, each user is authenticated with a acceptable level of security. Our policy is for user's to never tell their password to anyone else because that is their identity. As the administrator I should have the authority to run commands as different users without knowing their password.

As a side note, this functionality is acomplished very simply on UNIX systems with either the sudo or su utilities, where the root user can run any command as any other user for testing purposes without knowing their password.

Lee Azzarello

Lee -

Are you editing permissions for each individual user, or are you using groups instead? Groups are much easier to admin. You can assign file/dir/share (whichever is appropriate for you) level permissions to the group, then create a test user (obviously, with a password you know!) in that same group. If all your tests go the way you want them to, delete your test user and start adding real accounts to the group!

If there's some reason groups are impractical for you, the same concept still applies but is a little more work. Create a test user, then give it privs to your target file/dir/share. Once you have all that going the way you want, give the same privs to the real users.

You're right that it would be a little easier to sudo or su. But personally I think this goes against the security mind-set of Windows - even the root (or Admin) user should leave behind security log entries showing his/her accesses to a file, and should have no mechanism for circumventing the log mechanisms by posing as another user. It's true that su or sudo utils themselves (if properly designed) would leave behind log traces, but why make it twice as difficult for the human who audits the logs?

Good luck!

Well, this would be a very bad thing for any admin to know everyone’s PW. As for running under another user’s credentials w/o knowing it, well, you can’t. When you say ‘disoganized’, (w/o going into any detail), do you mean that your OU hierarchy is not valid for the Org? Do you mean that your Org is not using Groups effectively?

Normally in Windows, the rule for permissions on any resource is at the group level, not at the use level which allow for centralized management. Remember AGGDLP:

• Accounts are placed in Global Groups
• Global Groups are placed in Domain Local Groups
• Domain Local groups are assigned permissions to resources.

Trying to do what you asking outside of this rule described is a nightmare on so many levels.

I set everything correctly and use the effective permissions function to see what that user is allowed to perform on that directory.

This is fine but really should be done at a group level.

I then open explorer.exe using Run As to change to the user in question and do a final test to see if my ACL is correct.

Now for this, if I could not do this via an account I controlled that belonged to the appropriate groups, then I would:

• prepare a script (vbs, wsh, perl, python --whatever) that performed some function added it to the users’ logon script or added to the runonce key and;
• either wait for the user to log back in;
• request that the user re-log on or;
• force the user to re-logon.

The script itself would be written to perform some action and designed to create a log that could be viewed at some later time. It could even be written to notify you when it has run and report the results to you. See http://www.microsoft.com/technet/scriptcenter/default.mspx for many examples to get you started. This way the script will run with the credentials of the user in who logged on, but this is still not a good idea with this method or sudo/su. You would also have to rememer to remove the call to the script once you were done. Still a pain.

It would be best (and easiest) to;

• Create a group with the set of permission you need;
• Create a test account that you will use;
• Add this account to the group;
• Logon with the test account and perform the process you are trying to validate.

This is a lot of steps, I know, but from a LUA and users/corporate protection/non-repudiation position, it is better. However, once this is done you can add and remove test accounts (to the groups you have created) for whatever testing purpose you need.

Even though the use of this functionality is controlled by an administrator and is logged. It has always disturbed me from a security standpoint, specifically ‘non repudiation’. Any administrator with the privilege (or bone to pick with a user) can run a process against any resource using another user’s credentials and then the user can get blamed for it. Now, as the CISO or auditor, this means I have to track whether the user actually did it or some rogue admin, if it is ever called into question. Either way, if something major happened from a security perspective, that required criminal action, using sudo / su would taint the issue, making it heresay in court and therefore even more inadmissible in court.

"As the administrator I should have the authority to run commands as different users without knowing their password."

This is indeed trivial in Unix - but is it right ? In the new world of Sarbox and other legislation worldwide, should an individual be able to run something, apparently as someone else - sounds like a real, bad plan for the audit trail to me!

When I went to setup our family computer I started with this approach. If all I wanted my children to do is surf the web then it works fine. As soon as I want to install educational games I found the following problems:

1. Many children's games (especially if they are a little older) don't install for all users, and cannot be installed without admin privs.
2. "Run As" doesn't always work.
3. Many games required admin privs to run (don't ask me why).

I ended up making shortcuts that launched some applications with admin privilages to launch games. To install I usually had to bump the account to admin to do the install, then down grade it.

Overall I found Linux and Unix's su to be far superior to Run As.

Maybe a better alternative would be to always launch Internet Explorer with non-admin privilages. So create an account just to launch IE in the guest category and then create a short-cut to it. Either that or use FireFox. That works really well.

Jim, check out Aaron Margosis' MakeMeAdmin utility. It does a good job of handling those times that you need to install something that is finicky about the profile you're installing it from, because it allows you to open a command prompt with admin credentials, but which is linked to the user profile from which you launch it. So you could log into your kids' account, launch MakeMeAdmin (supplying your admin credentials), and then launch the installer from the command line. It should then install for the correct user profile, and as long as the game itself doesn't require admin credentials to run, you should be fine.

My biggest problem so far and I might be stupid but I found no solution yet:

I have a separate partition (Data Partition) for all my data: music, documents, logs, etc. I want my limited user to have full access to this partition (literally, he owns it, my Admin account only works inside its My Documents). Of course, I only have read access but it seem there's no ACL in WinXP but only this stupid shared folders.. I don't get the point, how could I allow my LU to literally 'own' that partition?

Thanks,
RGabo

RGabo, Check http://nonadmin.editme.com/RunAsAdminExplorer. You logon as administrator, but RunAsAdmin reduces privileges on your shell (and any program started from your shell) to normal user. And you continue to own all your documents (including all your EFS encrypted files).

-Valery

OK, was that fast or what?? You guys are da bomb, thanks for the tip. Wiki at its best, thanks to Valery!

RGab

The SetSAFER page discusses a policy tool written by Michael Howard and says you can download it from here. However I see nowhere on that page where one can download any software. I also checked his blog post at which the article also mentioned, but saw neither there either.

I did seen the "DropMyRights" tool that Michael had written for Part 1 of that article, but nothing on the SetSAFER policy-setting tool itself. Can anyone direct me to where might download it? I'd certainly prefer writing some XML policy files to editing the Windows registry.

Can anyone refer me to where the SetSAFER tool can be downloaded? Thanks!

P.S.- This is my first try of editing with this particular Wiki environment/tool, so please forgive this post if I didn't do it quite right.

Kevin - the tool itself is one level deep, in his MSDN article. I'll fix the wording to make that clearer. Your post was fine, except that you also renamed the page. I fixed that too :)

Hello, I guess you could describe me as the "person who fixes the computers for my family and friends", meaning that i have no programming experience, but spend a lot of time reading and learning about windows security.

I recently set up a WinXP Pro PC for a friend and created an LUA (user) account. I confirmed his username was in the Users group, so it looked fine. when logged in as his LUA account, I quickly discovered that I could run regedit and access (see, open, etc.) the Local Machine root of the registry, along with all of the other areas of the registry. Additionally, I could access (open, etc.) the system32 Windows directory in Explorer.

Shouldn't I be prohibited from doing this while logged in with an LUA account? 

Thank you for all your help...