Welcome to MSDN Blogs Sign in | Join | Help

RunAs with Explorer

This is the latest post in my series about how to run with limited user privileges on Windows XP and to use administrator privileges only as needed.  In my first post, I wrote “Unfortunately, Windows does not yet make running as non-admin as straightforward as it needs to be.”  This is probably nowhere more glaring than when trying to run Explorer in a different security context.  Many tasks in Windows are most easily performed in Explorer, and some can be performed only in Explorer.  But when you try to use Run As with explorer.exe with a default XP configuration, nothing happens.  This post is all about how to get it to work.

 

Needing Explorer as admin

 

Some of the scenarios in which you may want to run Explorer as admin include:

1)       Setting file/folder security settings (ACL editor).

2)       Sharing folders

3)       Control Panel applets/subfolders that are handled by Explorer, including:

a.       Folder Options, including viewing and setting file type associations, actions, and context menu options.

b.       Printers and Faxes, including installing a local printer

c.       Fonts

d.       Network Connections, including settings for the pre-SP2 Internet Connection Firewall.  (See side notes below)

e.       Scheduled Tasks

f.         Scanners and Cameras

Some of these tasks can be accomplished with command line utilities.  But you really need to get out more if you actually prefer to use subinacl.exe when the GUI ACL editor can do the job.

 

Two side notes about Network Connections:

            

  1. .cpl files are Control Panel extensions.  As I noted in "RunAs" basic (and intermediate) topics, you can use RunAs with .cpl files, or launch them directly from your admin cmd prompt.  In the system32 folder, the file properties of ncpa.cpl show that it is the “Network Connections Control-Panel Stub”.  So why doesn’t RunAs work with Network Connections?  Because that stub merely calls the ShellExecuteEx API to launch an item in the shell namespace, which appears as a folder within Explorer.

 

  1. With SP2, there is a new Windows Firewall control panel applet (firewall.cpl), so you no longer need to go through Explorer and Network Connections in order to manage the firewall settings.

 

 

 

Making it work

 

The reason RunAs doesn’t work with Explorer is because when explorer.exe starts, by default it looks to the current desktop for an already running instance of itself.  The new instance notifies the previous one, which performs the requested operation while the new process quietly exits.  Since explorer.exe also provides the interactive shell – the desktop and the taskbar – explorer.exe is always running except in unusual circumstances.

 

Creating such an unusual circumstance is one way to allow a new explorer.exe to run in a different security context.  The downside is that once you do that everything running within the new explorer.exe or started from it will run in that alternate context.  You still don’t have both contexts living side by side.

 

There are two viable options:

1)       Use Internet Explorer instead of (Windows) Explorer; and/or

2)       Set the flag that allows explorer.exe to work with RunAs.

 

Option 1.  Use Internet Explorer instead of (Windows) Explorer

 

I briefly discussed this in my post about RunAs, and Keith Brown also discusses it in his upcoming book.  Unlike explorer.exe, Internet Explorer is perfectly willing to work with RunAs.  Two ways you can get there are

1)       start iexplore.exe from an admin cmd prompt (see my “ie.cmd” tips in the earlier post); or

2)       right-click on an Internet Explorer icon and choose Run As.  This approach does not work with the IE icon on the desktop or at the top of the Start menu, but it does work with the one in the Quick Launch bar if that is displayed in your taskbar.

 

Once you have IE running, you are not restricted to browsing web sites.  Type a local address in the address bar, such as “C:\”, and all of a sudden, IE starts looking a lot like Explorer.  The toolbar and the menu options change, and you can easily browse your file system, Control Panel and its subfolders.

 

You can also type the names of certain shell folders in the address bar to browse them.  For example, try typing any of these in the IE address bar:  My Computer, Control Panel, or My Documents.  From Control Panel, Network Connections and the other subfolders become accessible.

 

To save steps, specify the target location on the IE command line.  E.g., with ie.cmd in your path:

C:\>ie.cmd c:\projects

Or to get really interesting, browse directly to shell namespace folders.  This command line will take you directly to Network Connections:

C:\>ie.cmd ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{7007ACC7-3202-11D1-AAD2-00805FC1270E}

 

 

Option 2.  Set the flag that allows explorer.exe to work with RunAs

 

It’s actually very simple.  The trick is to set the folder option to “Launch folder windows in a separate process”.  This is a per-user option, off by default, that needs to be set for the target user account.  That is, if you want to use RunAs to start explorer.exe as MyAdminAccount, then MyAdminAccount needs to have the “separate process” option set.  Once this flag has been set, you can start explorer.exe with RunAs, or from your admin cmd shell.

 

 

Why use explorer.exe instead of IE?

 

It’s just personal preference, but there are a few reasons I tend to use explorer.exe instead of Internet Explorer for admin tasks:

1)       explorer.exe is in the path, so it is easier to use from a command line.  The folder where iexplore.exe lives isn’t in the path.

2)       explorer.exe offers more flexibility through its command line options.  For example, I use /e,/root, all the time.  Explorer’s command-line options are supposed to be described in KB 314853 (“Explorer.exe Command-Line Options for Windows XP”), but the documentation is actually more accurate in KB 130510, even though the latter was written for Windows 95!

 

I have a handful of .cmd command script files that open rooted windows in various special folders such as Network Connections, Printers and Faxes, etc.  These make useful RunAs targets, and work well from the command line as well.

 

How do you set the “separate process” flag, then?

 

You want to start explorer.exe as local admin, but you haven’t set the “separate process” flag for the local admin account yet.  The GUI you need for this is in Folder Options, which runs within Explorer.  Which you can’t run as admin, since you haven’t set the flag yet!  Here are a couple of ways to get around that chicken-and-egg problem without having to log out and log back in as local admin:

1)       Start IE as admin, enter a local address in the address bar to change the menus to those of Explorer, and choose Tools / Folder Options / View.  Check “Launch folder windows in a separate process.”

2)       Manipulate the setting directly in the registry.  Run regedit as admin, navigate to HKCU \ Software \ Microsoft \ Windows \ CurrentVersion \ Explorer \ Advanced.  Change the SeparateProcess DWORD value to 1.  Or just rename and run this .reg file from an admin cmd shell.

 

The setting takes effect immediately.

 

More info about Explorer’s Separate Process flag

 

I must point out that supporting RunAs is not the purpose for “Launch folder windows in a separate process”.  The fact that it does is merely a side effect, and an unintended one at that.  Without “separate process” enabled, all Explorer windows run in the same explorer.exe process that also hosts the desktop and the taskbar.  With the setting enabled, the desktop+taskbar gets its own explorer.exe process, and all Explorer windows share a separate explorer.exe.  There are some minor exceptions.  If you press Win+E, the new window that appears actually lives in the desktop+taskbar process, not the process that owns the other shell windows.  And every time you create a rooted Explorer window with the /root, command line option (a.k.a., “Explore from here”), it gets its own, brand-new process.  The real purpose behind the setting is to make it possible to isolate Explorer windows from the desktop+taskbar, so that if a bad shell extension is loaded which crashes or hangs an Explorer window, it is less likely to affect the desktop and the taskbar.

 

How do I tell my admin windows from my normal windows?

 

Once you have IE and/or Explorer windows running in different security contexts, it becomes important to be able to tell them apart – particularly since in certain odd scenarios, a new window will actually run in a different security context from that which you intended.  As mentioned in my "RunAs" post, the easiest way is to run TweakUI as admin and change the admin’s background bitmaps for IE and for Explorer.  (This bitmap works nicely.)

 

However, in an upcoming post I will show you how you can temporarily elevate your normal User account for admin tasks.  You could then have two Explorer windows running as the same user, one with normal User privileges and one with admin privileges.  Since the background bitmaps are associated with a user account, rather than a privilege level, they won’t help you tell them apart!  I’ll also present a solution for that.

 

Published Wednesday, July 07, 2004 1:34 PM by Aaron Margosis
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# RunAs with Explorer

Thursday, July 08, 2004 2:21 AM by Sergey Simakov blog

# re: RunAs with Explorer

Thursday, July 08, 2004 3:39 PM by Steve
This is the best blog ever. I have tried and failed to run as non admin for years. Now using your tips its practical. I admit since I use windows 2003 server as my desktop I also have a WTS session open as admin, but I find I am using it less and less. With your latest tip in explorer one of my last reasons to have WTS will have gone! Great work. I wish MS had done it years ago though.

# re: RunAs with Explorer

Thursday, July 08, 2004 4:07 PM by Aaron Margosis
Steve - thanks. But if you're using Server 2003 and can use remote desktop (terminal services) for multiple simultaneous security contexts, you're actually much better off for several reasons: First, the Windows desktop - and Explorer in particular - was not designed with support for multiple security contexts in mind, so "odd things" will happen from time to time. Also, the Windows desktop is kind of its own security boundary - anything can send messages to any other window on the same desktop. If the target window is running in an elevated context, it can be very easy for an unprivileged caller to run code at an elevated priv level through the target window. This is the basis of so-called "shatter" attacks, and why it can be very dangerous for system services to host windows on the interactive desktop.
If I could use Remote Desktop on XP to connect back to the same XP box in a different security context, I would probably use RunAs much less often.

# re: RunAs with Explorer

Friday, July 09, 2004 6:14 PM by Marty
Is there any way to use RunAs with Explorer to remotely connect to Scheduled Tasks on another machine?

# re: RunAs with Explorer

Friday, July 09, 2004 10:05 PM by Aaron Margosis
Marty - very interesting question. I assume you need RunAs because you need a different account from the one you're logged in under?

You can use RunAs, but it's probably easier to NET USE instead. First, this is the basic Explorer command I would use for all the below examples:
explorer /e,/root,\\servername
Then browse to "Scheduled Tasks" from the Folders toolbar. If you want to skip that extra step of starting at the server root and instead browse directly to the remote Scheduled Tasks folder, you can use this command line:
explorer /e,/root,\\servername\::{D6277990-4C6A-11CF-8D87-00AA0060F5BF}

Now, in order to get the necessary remote access permissions if you don't already have them, there are three ways I can think of:

1. Just run the above command. You'll get a dialog prompt for username/password. Enter them in the dialog.

2. Do a NET USE ahead of time:
NET USE \\servername /u:domain\username *
The * at the end says "prompt me for the password before attempting the connection. This saves waiting for the timeout using the wrong pwd. Then run the Explorer command.

3. Use RUNAS /NETONLY:
RUNAS /NETONLY /u:domain\username "explorer /e,/root,\\servername"
/NETONLY creates a new logon session with your existing token, but with the account you specify for all SSPI-based network access. Because Explorer needs to run in this new logon session instead of that of your desktop, you need to set the SeparateProcess flag for your *current* account to make this work.

# re: I quit running as an administrator on my new box!

Wednesday, July 14, 2004 10:02 PM by Yves Dolce

# re: RunAs with Explorer

Thursday, July 22, 2004 4:38 PM by Michael Meyers-Jouan
Aaron,

You mention that you will be addressing how to temporarily elevate your normal User account for admin tasks. PLEASE, PLEASE, PLEASE -- as soon as you can!

My biggest beef is installation and activation processes that require Admin privileges, but that also require that the User ID be the ID of the user who will be running the application later:
Activating Microsoft Reader
Installing Pocket PC apps where the installer requires Admin privileges, but the scheduling of the download via ActiveSync fails when using RunAs.

The only solution I've been able to find so far is to log off my normal, Non-Admin account, log in as Admin, add the normal account to the Admins, log off as Admin, log in as the normal (now Admin) account, run the process, log off the normal account, hit Ctrl+Alt+Del to get the Windows Classic login dialogue so I can log in as Admin, remove the normal account from the Admin group, log off as Admin, and log back in to the normal (Non-Admin) account. Whew!

Therefere, any procedure that can TEMPORARILY elevate my normal (Non-Admin) account to successfully complete installations and activations would be a HUGE benefit.

# MakeMeAdmin -- temporary admin for your Limited User account

Saturday, July 24, 2004 1:24 AM by Aaron Margosis' WebLog

# MakeMeAdmin -- temporary admin for your Limited User account

Saturday, July 24, 2004 1:26 AM by Aaron Margosis' WebLog
How to quickly and temporarily give your non-admin account administrator privileges, without having to log out.

# re: RunAs with Explorer

Saturday, July 24, 2004 1:28 AM by Aaron Margosis
Michael M-J -- OK, it's posted:
http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx
Sorry for the delay. Thanks for your patience!

# re: RunAs with Explorer

Friday, July 30, 2004 10:33 PM by Junior
Hi,

I really need a way of making the ncpa.cpl applet work with RunAs. We want to have delegated access to helpdesk personnel, so that they can disable/enable the network card on our servers. Their accounts are user level accounts. I'd like to write an encrypted script to run the ncpa.cpl applet with admin credentials.

Is this possible?

Thank you in advance.

Junior
junlad@hotmail.com

# re: RunAs with Explorer

Sunday, August 01, 2004 3:44 AM by Martin Sauter
Just what I was looking for! I was reading an article in a German computer magazine but they forgot to point out how to make the explorer work with runas.

Thanks a lot!
Martin

# re: RunAs with Explorer

Tuesday, August 03, 2004 2:08 AM by Aaron Margosis
Junior - it might be easier and safer to make the helpdesk people members of the local "Network Configuration Operators" group. This granularly gives them the ability to configure network settings, without giving them the keys to the castle.

# re: RunAs with Explorer

Wednesday, August 04, 2004 1:04 PM by Junior
The group you mentioned is only available in Windows 2003. We're running a Windows 2000 domain and I need to give the helpdesk operators access to change the network settings on DCs.

Is there a way to get this to work?

# RunAs with Explorer

Saturday, August 14, 2004 7:04 AM by Sergey Simakov blog

# Excellent LUS/non-admin resource

Friday, August 27, 2004 6:09 PM by Franci Penov

# IE Security

Saturday, October 23, 2004 7:11 AM by Digging .NET
IE Security

# PrivBar - An IE/Explorer toolbar to show current privilege level

Monday, October 25, 2004 2:53 PM by Lockergnome's IT Professionals
Aaron Margosis is a Microsoft employee who is writing a weblog on running Windows with least privilege on the desktop. If you are having trouble running applications under an account with less privileges than administrator, there are many useful suggestions...

# MBA

Saturday, December 18, 2004 1:48 PM by MBA
Helpful For MBA Fans.

# Eric Johansen Malware Research » A Cure for your IE Blues?

Saturday, January 15, 2005 11:25 AM by TrackBack
Eric Johansen Malware Research » A Cure for your IE Blues?

# Table of contents, Aaron Margosis' non-admin blog

Monday, April 18, 2005 8:22 PM by Aaron Margosis' WebLog
Complete list of Aaron Margosis' non-admin / least privilege posts, for easy lookup.

# Least Privilege and Explorer

Wednesday, April 27, 2005 2:36 PM by .net <i>DE</i>lirium
As I prepare for an upcoming talk at Tech-Ed 2005 on Least Privilege for Developers, it's worth reviewing...

# Spread the LUA joy

Friday, June 10, 2005 12:12 PM by tonyso
Get your friends and family, all those folks that come to you for computer help once their machines have...

# re: RunAs with Explorer

Friday, July 15, 2005 10:09 AM by Josh
found this by mistake, and have always been wondering how to do what you talk about. MUCH THANKS!!!!!!!!!!!!!!!!!

# re: RunAs with Explorer

Friday, July 15, 2005 10:43 AM by Josh
I do have a couple questions.

1) Through the internet explorer route, you can get into Control Panel but lets say you want to change someone's background. I couldn't get it to work. Lets say you want to change a file association, you can't because your now running as an admin. I've found a work-around for this, just open the image in IE and use set as background.

2) Is it possible to be logged in as a normal user and use the runas command like you have indicated but also be able to change file associations?

Thanks,

Josh

# re: RunAs with Explorer

Monday, July 18, 2005 12:16 PM by Aaron Margosis
Josh-
Re background: Why not just set the background while running as the regular user? That's not a privileged operation, so RunAs would just get in the way.

File association is completely different - file associations are global to the computer (stored in HKCR --> HKLM\Software\Classes). You need to run Explorer as admin (or IE as admin then browse to the file system) to get to Tools / Folder Options so that you can set those.

# RunAs with Explorer

Wednesday, July 27, 2005 11:56 AM by Marco
and it works with the password encrypt tool Runasspc.

Thanks,
Marco

# Least privileged user access for developers

Friday, July 29, 2005 5:55 PM by Nigel Watling
OK, the last entry was a teaser for a blog entry or two on what developers can and IMHO should do regarding...

# re: RunAs with Explorer

Saturday, July 30, 2005 2:18 PM by Scott Crawford
Thanks much for the service you're doing for the community. I'm a sys admin for a small school and for several years we've not allowed our users to run as anything other than normal users, but this year we've started forcing our IT staff to do the same, albeit they have access to an admin account.

ANYWAY...the problem I'm having that I don't see mentioned anywhere is that when running explorer with alternate credentials, there is no longer an automatic refresh. For instance if I delete a file, it will still show in the explorer window until I hit F5. Similarly, when copying a file to an explorer window, the new file doesn't show up until F5.

Granted, this is only a nuisance with a simple workaround, but it gets rather aggravating when browsing files. Is anyone else seeing this? And if not, any ideas why we are? We running XP SP2 with all the patches and its happened for everyone so far.

Thanks

# How to run Windows Explorer as a different user (so I can do admin work)

Saturday, September 17, 2005 4:57 AM by Florin Lazar's WebLog
As you probably know from my old posts, I log into my Windows computers with a normal user account (I’m...

# How to run Windows Explorer as a different user (so I can do admin work)

Saturday, September 17, 2005 5:05 AM by Florin Lazar's WebLog
As you probably know from my old posts, I log into my Windows computers with a normal user account (I’m...

# How to run Windows Explorer as a different user (so I can do admin work)

Saturday, September 17, 2005 5:06 AM by Florin Lazar's WebLog
As you probably know from my old posts, I log into my Windows computers with a normal user account (I’m...

# using start iexplore

Wednesday, October 19, 2005 11:13 PM by cheeze
I noticed that "start iexplore" seems to resolve IE's path. Easy to remember and launch.

Thanks for the good info.

# re: RunAs with Explorer

Sunday, November 06, 2005 5:54 AM by Marc Denton
Just like Scott Crawford I'm experiensing the same problem with refreshing te explorer window when run with diffrent credentials.

Ik there is a workarourond for that problem I would like to know what it is...

Very helpfull blog by the way.

# re: RunAs with Explorer

Thursday, November 10, 2005 5:07 PM by Pascal Roy
Juste like Scott Crawford and Marc Denton, I'm experiencing the same "Explorer not automatically refreshing" problem and telling customers to remember to hit F5... If anyone finds a solution to this, posting it here would be greatly appreciated.

# re: RunAs with Explorer

Sunday, December 04, 2005 5:49 PM by Thomas
Hi, After stumbling on this article, i tried your suggestions with success, but i noticed that everytime i start an (i)explorer via my admin-cmdshell, the folders for cookies, temp internet files and history are created, not in the admin's profile path, but inside the temp folder!
Any ideas why?

# re: RunAs with Explorer -shell namespace folders not working

Thursday, December 08, 2005 10:33 AM by Marcel

I am very interested in this RUNAS trick. I use RunAs very often from within encrypted VBScript to allow my mobile users to attempt certain tasks. The trick for IE with shell namespace folders doesn't seem to work with me.
I have realised the same exact options as mentioned:
C:\>ie.cmd ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{7007ACC7-3202-11D1-AAD2-00805FC1270E}

However when run from command-line, IE starts but with error:
################
Cannot find file:
file:///::%7B20D04FE0-3AEA-1069-A2D8-08002B30309D%7D\::%7B21EC2020-3AEA-1069-A2DD-08002B30309D%7D\::%7B7007ACC7-3202-11D1-AAD2-00805FC1270E%7D. Internet address incorrect.
################

somehow the '{'-character gets transformed into %7B and the '}'-character gets transformed into %7D.

Any idea why? Has this something to do with character page?


# Running Explorer : yet another (usable) way

Monday, December 12, 2005 9:08 AM by Guillaume
I have this setting in both my user and admin profiles :

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer]
"DesktopProcess"=dword:00000001

It will create one Explorer.exe for the shell and another one for everything else. If you set this flag it will behave just like the "separate process", but will be usable when you do log interactively as an admin.

You gessed it, I have little memory on some machines !

# re: RunAs with Explorer

Tuesday, December 13, 2005 10:57 PM by Aaron Margosis
Guillaume, from what I'm told, DesktopProcess really doesn't do anything different from SeparateProcess. SeparateProcess is recommended.

# Rename explorer.exe to xplorer.exe, or anything else

Monday, January 02, 2006 10:31 PM by MikeL
Why not just rename explorer.exe to xplorer.exe, or something similar? That is how I publish folders, etc through Citrix and it works fine. Rename explorer.exe to whatever, then launch that. Any reason that won't work?

# With IE7?

Tuesday, January 17, 2006 12:53 PM by Romain
Hi!

Good article, really!
However, I have noticed that in IE7 Beta 1, it is not possible (well, in fact I didn't find out how to...) to "run as" iexplore, and then type "C:\" in the address bar to view local folders in Administrator mode.
As you said, this tip works fine with IE6 (I was using it before), but with IE7, a new window is created, and it runs in the current user's context, not in the administrator's context.
I think this kind of issue will be removed in later releases... I hope so.

# re: RunAs with Explorer

Friday, January 27, 2006 12:42 PM by yecril
Romain: It seems this change is a deliberate security patch. I hope it will stay. Using Internet Explorer as Computer Explorer is an abuse anyhow. The two guys should be split.

# re: RunAs with Explorer

Wednesday, February 01, 2006 8:12 PM by Martin O' Donnell
The Explorer refresh problem is really the most irritating thing I have encountered about running as non-admin. Is there any hope for a reg hack or patch to resolve this? Can anyone even explain why exactly this happens? Aaron, very grateful for your work, indispensable source of information.

# re: RunAs with Explorer

Monday, February 06, 2006 2:03 AM by jib
Not a fix or anything, but other programs like the excellent Total Commander works very good with RunAs. Total Commander even displays its current user context in the main window title.

# re: RunAs with Explorer

Wednesday, February 08, 2006 6:02 AM by Tom Holden
Just a note but for those of you that are using runas on iexplore (either through command prompt or through right click).... you are going to hate IE7, if you attempt to browse a file area (i.e. not a web page) then it spawns a new explorer window looking at that location.

And if you are running IE7 as your admin account and do the same then you will find that the newly spawned window isn't running under your admin account any longer but has dropped down to the currently logged on users permissions! So once Vista comes along (and probably just XP next year) you are going to be stuffed without taking this chaps advice.

And that is why I had to find this web page yesterday... and a bloody good find it is too! Cracking stuff. Thankyou.

# re: RunAs with Explorer

Wednesday, February 15, 2006 2:36 PM by badri
Oddly enough i always used RunAs with IE, but recently found out that just a /separate switch with launches explorer in a seperate process with using Lauch as seperate process set

runas /user:Username "explorer /separate,c:\Path\To\Dir"

# re: RunAs with Explorer

Wednesday, February 15, 2006 7:10 PM by Aaron Margosis
Romain & Tom Holden:  I just got confirmation that by design IE7 on XP will no longer browse the file system.  If you try to, it will send a DDE message to Explorer, which opens a new window in the current user context.

# re: RunAs with Explorer

Saturday, February 18, 2006 9:16 AM by flipdoubt
None of these tips work for me on a ThinkPad T43 with XP Pro SP2.

I get a silly runtime error when I try the /separate trick:

Microsoft Visual C++ Runtime Library
Runtime Error!

This application has requested the Runtime to terminate in an unusual way.

Using Aaron's ie.cmd works without runas, but with runsas results in the same message described above.

# re: RunAs with Explorer

Saturday, February 18, 2006 1:59 PM by Aaron Margosis
flipdoubt - That may be coming from a toolbar or BHO.  Try disabling extensions like Adobe, MSN, Yahoo, etc. and see if the problem goes away.  If you are comfortable with SysInternals' Process Explorer, take a look at the call stack generating that error message and see if it points to a particular DLL.

# RunAs with Explorer

Tuesday, February 21, 2006 5:42 AM by Martin O' Donnell
Aaron,
I realise this is a presumtuous request but no harm in asking, right? You're a software developer and you have an unrivaled understanding of LUA on MS operating systems and the OS infrastructure. Do you think you could write something that would make Windows Explorer automatically refresh when running in profiles other than the currently logged in user?

# re: RunAs with Explorer

Sunday, March 05, 2006 2:36 PM by OAS
Aaron, You save my brain from eruption !
You are a genius, continue !!!
Thanks
OAS

# re: RunAs with Explorer

Monday, March 20, 2006 8:56 AM by Hugo Bonilla
Since I can fulfil a scrips with Run seize in which(whom) it(he,she) includes the user and the password in the same Scrips

# re: RunAs with Explorer

Monday, March 20, 2006 9:05 AM by Hugo Bonilla
Since I can realize a scrips with RunAs in which it includes the user and the password in the same Scrips

# re: RunAs with Explorer

Monday, March 20, 2006 9:32 AM by Aaron Margosis
Hugo Bonilla - if the question is, "Can I write a script that uses RunAs and gives it the password to use," the answer is no.  RunAs accepts passwords only from the keyboard.  It was designed this way to help people avoid the unsafe practice of putting passwords in script files.

# re: RunAs with Explorer

Tuesday, March 21, 2006 9:59 PM by Qingzi Bu
Rahh! I can't believe the IE team decided IE7 isn't going to let me browse local directories (under the correct user context)!
The option #2 as you say, works because of a mere unintended side effect. There's no telling when they might decide to 'fix' it, too!

*mumble mumble* It's better that IE and explorer are now separate you say?  *mumble mumble* But but... aww damn you for being right.

# Fixing &amp;quot;LUA Bugs&amp;quot;, Part II

Monday, March 27, 2006 12:34 PM by Aaron Margosis' WebLog
A systematic approach for working around LUA bugs that avoids unnecessary exposure - &quot;the rest of the story&quot;

# re: RunAs with Explorer

Monday, April 10, 2006 6:33 PM by PaulL
Having recently implemented the secondary account principle across my IT support organisation, I've found this information invaluable.

One of the tech support team came up with this tip for adding a "OpenExplorerAsAdmin" option to the Limited User's context menu in Explorer.  This allows you to find a folder you need to manage, right-click, fill in your password for your admin account, and bingo! an elevated Explorer opens. Combined with Privbar, the whole thing becomes straight foward...

Modify the text below (inserting your admin user details, save as a .reg file, and import into your workstation's Registry...
----  reg file starts here  ---
    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\OpenAsAdminUser]
    @="Open An Explorer Window as Admin User"

    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\OpenAsAdminUser\command]
   @="runas.exe /user:DOMAIN\ADMINUSER  \"explorer.exe  /SEPARATE,%L\""

----  reg file ends here  ---



As a further tip, we use the same username for the secondary account as the user has for the primary account, but with a "!" prefix. This allows me to create standardised "admin" cmd files or shortcuts for the team, using %UserDomain%\!%UserName% variables; the team can use the shortcuts without modification.

# re: Savecred switch?

Tuesday, April 18, 2006 3:09 AM by Martin O' Donnell
I'm aware that there are security issues with using the /savecred switch with runas because the credentials are essentially saved for the runas command rather than the specific shortcut or exe that one would intend, which means the saved credentials can then be manipulated to run any shortcut or exe on the system, but can anyone tell me how the credentials are saved? i.e. is there any encryption involved? Is the password hashed in the registry or is it just stored as plain text?

# re: RunAs with Explorer

Tuesday, April 18, 2006 11:19 AM by Aaron Margosis
Martin O'Donnell:  The password is stored in the credentials manager, encrypted with a DPAPI key (which is based indirectly on your own account password).  It remains there until you remove it.  You can also lose access to it if your account password is reset (as opposed to changed).

You can "unsave" it by going to the "Stored User Names and Passwords" UI, selecting the account and removing its password.  To get to that UI, run the following command:

"%windir%\system32\rundll32.exe" shell32.dll,Control_RunDLL keymgr.dll

# re: RunAs with Explorer

Thursday, April 20, 2006 5:13 PM by Tom
It's a good idea to use the variable %programfiles% instead of c:\program files so that you get a path to the correct folder regardless of which drive it is on.

This is mainly for instances where you are creating batches for many computers to run.

# re: RunAs with Explorer

Thursday, April 20, 2006 6:31 PM by Aaron Margosis
Tom - good advice.  Is there a violation here that I hadn't noticed?

# re: RunAs with Explorer

Thursday, May 11, 2006 6:05 AM by Martin O' Donnell
Hopefully someone can help me with this. I'm trying to create a reg file very similar to the one described by PaulL but it modifies HKEY CURRENT USER instead of HKEY LOCAL MACHINE. I also want the reg file to find the current %username% and append the letter "a" to the end of it to run explorer in the admin user's context. I've found the following syntax works fine from a command prompt :

runas.exe /user:domain\%username%"a" "explorer.exe  /SEPARATE ,%L\"

It requests the password for the admin account e.g. usera and then it runs explorer in a separate process exactly as I want. But if I use this syntax in the reg file and then try to browse a folder as admin, it requests the password for usernamea instead. Can someone tell me how I can make the registry find the %username% value or is there some other way I can achieve this?

PaulL thanks for that reg file, very useful.

# re: RunAs with Explorer

Tuesday, May 16, 2006 7:10 AM by entity
RunAs with Explorer works fine with me. My final problem is to prevent users from typing commands in the address bar and run them as administrator.
Is there a way to call explorer.exe and hide the address bar, navigation bar and menu bar?

Thanks for any reply.

# re: RunAs with Explorer

Tuesday, May 16, 2006 1:03 PM by Aaron Margosis
entity - Why do you need to give untrusted users an Explorer running as admin?  There are all kinds of things they could do from there.

# re: RunAs with Explorer

Thursday, May 18, 2006 4:59 AM by tekNerd
Actually I was looking for an explanation why WIN+E doesn't start explorer in a separate process.
I see that this is normal behavior and is nothing wrong with my windows.
Thanks!

Peace out!

# re: RunAs with Explorer

Thursday, May 18, 2006 6:16 AM by entity
Aaron - My intension was to run explorer.exe using admin permissions calling "Network Connections" directly. This is primarily for non-privileged roaming users who need to change NIC-Settings (speed, etc.) depending on their location. Members of the "Network Configuration Operators" group do not have the right to change hardware-settings. To prevent users from running other stuff from this particular explorer.exe-instance i thought about hiding 'address bar', 'navigation bar' and 'menu bar'.Any hint to make this work? Thanks!

# re: RunAs with Explorer

Friday, May 19, 2006 12:55 AM by Aaron Margosis
entity -- it's not clear to me 1) how you're getting them the admin window in the first place, or 2) exactly what it is they'd need to change - don't NICs/drivers usually determine speed fine by themselves?

But assuming those two items are resolved:  is it something that could be accomplished with netsh scripts instead?  There's a lot less trouble you can do with netsh than with Explorer.

# Adding LUA to "Network Configuration Operators" on XP Home

Monday, June 05, 2006 1:30 AM by Ajay
XP Home doesn't have the "Local Users and Groups" option under Control Panel->Adminstrative Tools->Computer Management.  Is there another way to make an LUA account on an XP Home installation a member of the "Network Configuration Operators" group?  This is on a laptap that needs to be able to repair the wireless network connection when needed.

# re: Adding LUA to "Network Configuration Operators" on XP Home

Monday, June 05, 2006 1:38 AM by Ajay
My workaround is using what you describe in this article to open the Network Connections and repair it that way.  Until reading these comments I wasn't even aware that the Network Config Operators group existed and it sounds like a much more convenient way to do what I need.  Keep up the excellent work Aaron!

# re: RunAs with Explorer

Monday, June 05, 2006 11:02 AM by Aaron Margosis
Ajay - I don't have a Home Edition box handy at the moment.  I don't know for certain whether this would work, but I think it would - run the following from a CMD prompt running as admin:

net localgroup "Network Configuration Operators" %COMPUTERNAME%\account /ADD

That should be on one line, of course, and "account" should be replaced with the name of the user account you want to add.  If there is a space in the name, then put quotation marks around %COMPUTERNAME%\account.

HTH, and thanks for the kind words.

# re: RunAs with Explorer

Monday, June 05, 2006 12:26 PM by Ajay
It looks like the "Network Configuration Operators" group doesn't exist on XP Home.  I typed:

net localgroup

just to see what groups exist and the list came back.

*Administrators
*Guests
*HelpServicesGroup
*Users

Doing the same on my XP Pro desktop shows a much longer list of groups including the Network Config Operators.  Thanks for the suggestion, I'll do a Google search to see if there is a way to add that group to XP Home

# re: RunAs with Explorer

Monday, June 05, 2006 12:44 PM by Aaron Margosis
Ajay - Don't bother searching - if the group isn't defined, then the objects that are ACLed for NCO on XP Pro won't be ACLed so on XP Home.  Adding the group won't have any meaning on Home.

# re: RunAs with Explorer

Monday, June 05, 2006 1:32 PM by Ajay
Thank for your help on this.

# ?????????????????????????????? &raquo; Tip: RunAs with Explorer

# re: RunAs with Explorer

Monday, June 19, 2006 5:39 PM by Larry

Does anyone know why the following behavior occurs?  We have RUNAS disallowed in a user lockdown (Software Restrictions) - both the path and the hash.  

Anyway, if you ran RUNAS from the Run command it fails.  But, if you click on Start/Programs an then right click on IE you can run "RUN AS".  Does anyone know what causes this to work?

Thank you.

Larry

Larry, what exactly are you disabling through SRP?  Are you disabling RUNAS.EXE?  The dialog interface doesn't use RUNAS.EXE.  -- Aaron

# re: RunAs with Explorer

Monday, June 19, 2006 10:11 PM by Larry

Aaron - In the software restrictions policy I am using c:\windows\system32\runas.exe.  Am I incorrect?  If so, what does the dialog interface use?  Thanks very much.

Larry

RUNAS.EXE is a console application.  The dialog interface just runs within Explorer.exe.  There might be a supportable policy-based way to remove it from the interface, but off the top of my head I can't say for certain.  You can disable the Secondary Logon service.  That will prevent use of other accounts, but should still allow the use of the "Run As..." dialog with the "protect my computer" option.

Out of curiosity, why do you want to block the use of RunAs?

-- Aaron

# re: RunAs with Explorer

Tuesday, June 20, 2006 9:03 AM by Larry

Aaron,

We want a user to be able to do work in a limited fashion and keep him or her from dropping the file anywhere but in their local profile.  Data in the profile will only be accessible using this account and prevents other accounts from getting to the data.  Doing this is one of about 10 steps we have in place to safeguard sensitive info.

Thanks very much for the great feedback.

Larry

Assuming all users running as LUA, the primary defense has to be the prevention of User A from getting User B's credentials or accessing User B's desktop while User B is logged on.  Use of hardware tokens and/or user education re strong passphrases will be much more powerful than preventing RunAs.  RunAs shouldn't even be a real risk.  Note that if User A has User B's password but no RunAs, User A can simply log on to the computer as User B...

HTH

-- Aaron

# RunAs for Windows Explorer

Monday, July 10, 2006 2:03 PM by Network Security Blog

# re: RunAs with Explorer

Friday, July 21, 2006 9:44 AM by McoreD
Many thanks for Option 2.  Set the flag that allows explorer.exe to work with RunAs

I've been doing it in Option 1:

runas /user:administrator "\"%programfiles%\Internet Explorer\iexplore.exe\" E:\\"

which restricted me using IE7. Now I can use IE7. :)

# re: RunAs with Explorer

Friday, July 21, 2006 2:33 PM by Les

Where can I find the GUID for other things like the scheduled tasks in the post's example? Is this something you've just 'picked-up' over the years or is there a library on Technet?

Les:  the identifier for Scheduled Tasks is

::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{D6277990-4C6A-11CF-8D87-00AA0060F5BF}

(BTW, this is already in the collection of scripts referenced in the post.)  They might be publicly documented somewhere.  The way I found them is by right-clicking on them in Explorer and choosing "Explore from here" after installing that little trick into the registry.  Then the address bar shows the namespace identifier instead of "Scheduled Tasks".  Again, this is most likely a side effect of implementation, rather than by intentional design.

Add this to the registry to get "Explore From Here":

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Folder\shell\rootexplore]
@="Explore From Here"

[HKEY_CLASSES_ROOT\Folder\shell\rootexplore\command]
@="Explorer.exe /e,/root,/idlist,%I"

HTH

-- Aaron

# re: RunAs with Explorer

Tuesday, July 25, 2006 3:34 AM by TerDale
@Les: you can find a reference for such GUIDs at:
http://www.winguides.com/registry/display.php/61/
HTH

@Aaron: thanks for the "Explore from here" tip, still really fruitful to monitor all your posts! ;-)

# Windows Security &raquo; Running as a Limited User, Part 2

Wednesday, August 02, 2006 3:35 AM by Windows Security » Running as a Limited User, Part 2

# re: RunAs with Explorer

Friday, August 04, 2006 10:29 PM by dolf vm

After absorbing and applying this very useful blog (thanks Aaron!), I cannot resolve a probably minor but very annoying problem. Already addressed by some others but there was no reaction to it yet.

Using explorer with administrative rights in the way you explained, does the job just right except one thing. Explorer doesn't refresh. So I have to press F5 after each action (and then scroll back to the place I came from). That can become very cumbersome when I have a lot of filemanaging to do. Of course I refuse to login to admin as stubbern as I am.

Is there a solution or at least an explanation to this problem? To me it feels like a bug because it seems that explorer just sends it's refresh event to the user's original explorer process in stead of the process from where the filehanding was done. I tried the separateprocess flag as well as using the /separator switch and even MakeMeAdmin (the c't magazine version) but the result is the same.

So theoretically I could think of a solution: first a new explorer process must me launched from the original user with the original limited rights, using the /separate switch so that a real new process is lauched (which isn't the case using the flag as I can see with the taskmanager). Then that process' rights should be altered using a program that is run with administrative rights of course. I have no idea if Windows has such a possibility of altering a process' rights without killing it first. Moreover, I am not able to write such a program (in the first coming 10 years or so).

Hopefully someone found a simpler solution or workaround.

The idea of Explorer running in multiple simultaneous security contexts was not considered in the design of Explorer.  What you're seeing is another side effect of that (like the fact that getting multiple simultaneous contexts doesn't happen easily).  Don't forget that Explorer was originally designed to run on systems with as little as 4MB of RAM (yes, 8MB was the lowest you'd want to go, but 4MB was within spec).

The main Explorer process is the single collection point for capturing the change notification events.  It pushes that information to the processes that own other Explorer windows.  That "push" requires access to the process which is typically blocked when it's in a different security context.  One could write code to run within all Explorer processes to open the access up, but that increases security risk.

-- Aaron

# re: RunAs with Explorer

Friday, August 04, 2006 11:04 PM by dolf vm
Sorry, mailadres wasn't right, hopefully this is better.

# re: RunAs with Explorer

Sunday, August 06, 2006 7:19 PM by dolf vm
Thx Aaron, you cleared me up. Especially the fact that the event push fails due to the different security context makes sense.

As do all your explanations on this blog. I wonder how many computers on this earth have become a safer place thanks to this blog. Lots I guess :)

Working with limited rights is in fact the base of all protection. Which is a known fact for decades already and slowly MS starts to realize this. I 've red that multi user functionality in Vista is more mature and that indeed the default security context for users is limited. At last!

I also changed security of the autostart locations that can still be accessed by a LUA. Using the little program gavu.exe that came with the c't MakeMeAdmin. So now I feel so safe that I almost feel the urge to disable all my malware scanners and firewall and surf around the most dangerous sites, downloading and opening all the suspicious files and attachments I can think of. Just to see how much harm can be done apart from messing up my LUA itself.

with regards,
dolfff@yahoo.com

# re: RunAs with Explorer

Thursday, September 07, 2006 7:19 AM by Martin O' Donnell

It seems a shame that Microsoft can offer no solution to the auto-refresh problem. Many organisations would use the secondary logon service with windows explorer to mitigate the risk of accidentally deleting or corrupting critical or restricted data. This flaw actually increases that risk rather than reducing it. There must be a secure way of accomplishing auto-refresh with Windows Explorer, many third party companies provide file manager applications that work fine under the secondary logon service and even display the current user context in the title bar (e.g. Total Commander www.ghisler.com/). It seems Microsoft are either unable to produce a file manager that is compatible with the secondary logon service, or else they are using XP flaws as Vista selling points.

Regards,
Martin O' Donnell

As I mentioned earlier, Explorer was designed with very different goals in mind from what we're talking about here, and with very different constraints.  Clearly a file manager with that refresh capability can be built, but it would require significant rearchitecting to achieve this goal with Explorer on XP, and with high likelihood of application compatibility impact on all users -- including the vast majority that never use secondary logon.  Remember also that Explorer is much more than just a file manager.

-- Aaron

# re: RunAs with Explorer

Monday, September 11, 2006 5:28 AM by Martin O' Donnell
I understand that Explorer was originally designed for systems with very limited memory and that the concept of multiple simultaneous security contexts had not yet emerged, but this just seems like another way of saying that it runs on an archaeic foundation that Microsoft never developed or restructured sufficently to provide compatibility with modern security principles and requirements. After all, it's not like the secondary logon service was introduced post XP and hence we can't expect compatibility with Explorer, they were packaged together in the same OS, they just don't work properly together.

# re: RunAs with Explorer (Refresh problematic)

Wednesday, September 27, 2006 11:22 PM by Henrik Jensen
re. the Refresh in Explorer
The automatic refresh problem is not a specific Explorer problem. All applications that uses the CommonDialog component inherits this problem. Try doing a save as/open in any program that uses the standard CommonDialog component and, try to create a new folder in the dialog box. Nothing seems to happen until you've refreshed the Dialogbox, and now there's a "New Folder" created. This is even true if you use the new WinForms classes in .NET VS2005. Just tested it. What a shame :(

Henrik

# re: RunAs with Explorer

Friday, October 20, 2006 6:00 PM by Don

This method to launch another explorer instance with Admin level access has been very helpful and I've applied it on WinXP running IE7. However, is there a way for this to work on Vista as well? When I attempt it, I find that another process is loaded into memory (although I need to use an Admin account to display the second, elevated instance in Task Manager), however the window never displays on screen. This is the case whether my currently logged on account is a member of the local admins group on the machine or not.

# re: RunAs with Explorer

Monday, November 20, 2006 2:51 PM by Ubirajara

I'm another user that suffer with the refresh problem...