Windows Explorer and UAC: run elevated

Question

I am profoundly annoyed by UAC and switch it off for my admin user wherever I can. Yet, there are situations where I can't - especially if those are machines not under my continuous administration.

In this case, I am always challenged with the task of traversing directories using my administrative user via the Windows Explorer where regular users do not have "read" permissions. The possible two approaches to this problem so far:

1. change the ACLs to the directory in question to include my user (Windows conveniently offers the Continue button in the "You don't currently have permissions to access this folder" dialog. This obviously sucks since more often than not I do not want to change ACLs but just look into the folder's contents

2. use an elevated cmd.exe prompt along with a bunch of command line utilities - this usually takes a lot of time when browsing through large and / or complex directory structures

What I would love to see would be a way to run Windows Explorer in elevated mode. I have yet to find out how to do so. But other suggestions solving this problem in an unobtrusive way without changing the entire system's configuration (and preferably without the need for downloading / installing anything) are very welcome, too.

I have seen this post with a suggestion for altering HKCR - interesting, but it changes the behavior for all users, which I am not allowed to do in most situations. Also, some folks have suggested using UNC paths to access the folders - unfortunately this does not work when accessing the same machine (i.e. \\localhost\c$\path) as the "Administrators" group membership is still stripped from the token and a re-authentication (and thus the creation of a new token) would not happen when accessing localhost.

Answer 1

PRE-2012/8

(images and original idea from http://kb.cadzow.com.au:15384/cadzow/details.aspx?Print=Y&ID=2343)

1. Open an administrative command prompt.
2. Ctrl+Shift+Rt-click on Shutdown in the start menu.

3. Choose Exit Explorer
4. type explorer in the elevated command prompt and press enter.

Explorer is now running in the elevated context that the elevated command prompt had.

---

2012/8

1. Open an administrative command prompt.
2. Start the task manager and expand out More details
3. Rt-click Windows Explorer and choose End task
4. Type in explorer in to the elevated command prompt and press enter.

Explorer is now running in the elevated context that the elevated command prompt had.

---

Take note, once you do this you may have a hard time not running a program elevated. Any program you double click or open via file association will also run elevated.

---

Caveat

If Explorer is set to "Launch folder windows in a separate process" (Folder Options > View), the folder windows will not be elevated even though the main explorer process is. Workaround is to disable this option so that all folder windows are part of the elevated explorer process.

Answer 2

I don't think it is a good idea to turn off UAC or run the whole Windows Explorer shell in elevated mode.

Instead think about using a different tool to do your file management. I think Explorer is not a good tool to do serious work with many files anyways. A program with two panes side by side is much better suited for this.

There are many Explorer-replacement tools out there, some free, some commercial. All of them can be run elevated so permissions are no longer a problem. You may even want to use two different ones. One for normal usage, one for elevated administrative usage.

Also many of them run portable, so you don't need to install them, just copy a few files over and run it.

I'm not making a recommendation for a particular tool, that's a different question

Answer 3

This appears to be by design. See this thread for more information:

http://social.technet.microsoft.com/Forums/windows/en-US/1798a1a7-bd2e-4e42-8e98-0bc715e7f641/

According to poster Andre.Ziegler in that thread:

As I already told you Windows 7 Explorer uses a DCOM based start methode [sic] which prevents you from running windows explorer elevated.

One solution is to use the Explorer++ freeware file manager. Explorer++ has an option to show the current privilege level in its title bar, so you can easily see whether it is running elevated.

Another solution is to use Nomad.NET, another nice freeware file manager based on .NET.

Answer 4

I ran into this issue RDPing into servers to do stuff on them.

For me it is a case of don't do that. I can access the files from explorer on my home system and it gives me full access.

\\remote.com\c$ Gets me to the stuff I want as an administrator without restriction.

The remaining issue is that you are transferring files between systems while working on them, but for small files. I don't care.

-Larry

Answer 5

Use an elevated PowerShell ISE instance. The File dialog it provides is itself elevated, giving you the ability to traverse directories.

Answer 6

This was frustrating for me as well until I studied up on why UAC interrupts my traversal of folders that I have inherent access to as an administrator. There is a solution:

1. Leave UAC on
2. In your folder ACLs, add an ACE that gives the security principle "INTERACTIVE" the permissions to traverse folders and list folder contents.

If you add that to the folder ACLs, your admins will be able to browse the folder structure without getting hit with a UAC prompt.

Answer 7

Several people have contributed that this behaviour is one of the points of the UAC: to make you stop and think about what you are about to do. One response to this view, already stated, is that being asked once is fine, but not being asked every. single. time. during what might be a somewhat drawn-out procedure. It is somewhat analogous to not wanting to have to use your house key every time you went from one room to another within the house.

But I want to point out a semantic difference between OP's situation and the usual UAC prompt situation: The explorer message with the prompt "You don't currently have permissions to access this folder" is not conceptually the same as the standard UAC prompt.

When you OK a regular UAC request, you are permitting the program to run elevated (that is, with the credentials of the Administrators group); this granting ends when the program terminates. The only lasting effects are whatever the program may have done while elevated.

When you OK the explorer prompt produced when you try exploring into a folder that you don't have permission to view, you are not running anything elevated. Instead you are altering the file system permissions (ACLs) to grant your own user Full Control access to the folder. Not only is the granted permission far wider than the read/traverse folder permissions that exploring requires, this permission is essentially permanent (until someone explicitly removes it), rather than just for the duration of the explorer's visit to the folder.

If the prompt actually meant running the explorer using the Administrators group credentials, that would be a different matter and much more analogous to the regular UAC prompt (this appears to be what happens if you are prompted to use Administrator powers to view/edit permissions in the Advanced Security Settings form). This would, of course, only work if the Administrators actually had the required access as the Administrators group does not have carte blanche to bypass file system permissions. I haven't found a good explanation of this, but ultimately all the Administrators group seems to get is a default "allow full control", and file access is not assured because it can be denied using explicit "Deny" permissions.

As an aside, while testing out access permissions for this article, I observed that changing the ownership of an object will, at times, alter ACL entries for the OWNER built-in principal (which goes under various names depending on the Windows version) so that they apply to "Nothing" rather one of the usual choices (e.g. "this folder"). This occurred at least twice to ACLs that Deny access to the Owner.

One other observation is that is is very difficult to determine what behaviour is the bare behaviour of the file system, and what is added embellishments from the UI being used to modify the permissions (in this case the Advanced Security Settings form of the Windows Explorer). For instance at one point, the TAKEOWN command-line tool would (correctly) allow an unprivileged user who happened to be granted "Take Ownership" access to take ownership of a folder, which the Advanced Security Settings insisted that Administrators credential be entered before doing this.