11

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.

the-wabbit
  • 40,319
  • 13
  • 105
  • 169
  • 1
    Agree with the frustration. I know of a pre-2012/8 way...see here: http://kb.cadzow.com.au:15384/cadzow/details.aspx?Print=Y&ID=2343 – TheCleaner Nov 05 '13 at 14:29
  • 1
    @TheCleaner that method still works in 2012, you just need to use task manager to close Explorer. – Scott Chamberlain Nov 05 '13 at 15:49
  • @TheCleaner nice find. Too bad Scott has stolen it and is taking credit for it :) – the-wabbit Nov 06 '13 at 12:40
  • @syneticon-dj - no worries here, I even upvoted his answer. I'm secure in my SFhood. :) – TheCleaner Nov 06 '13 at 14:10
  • 2
    Perhaps I'm missing something but why would _anyone_ want to disable UAC? MS have _finally_ added a level of protection to the system that makes it as secure as other OSes which is pretty unintrusive. Maybe I just use Windows differently but it's rare to get a UAC prompt if I'm not installing anything, and if I do, it's a single click. In exchange, I get an assurance that malware can't do anything serious unless I approve a UAC prompt I wasn't expecting. Do you think that malware won't ever target you? Do you not care? Or am I missing something obvious? – Basic Aug 24 '14 at 00:09
  • @Basic because I am a *system administrator*. If I am logged on to a system interactively with an administrative account, it exclusively is for troubleshooting purposes or for performing planned changes. If I can't do my job efficiently due to restrictions, I am annoyed. And UAC has enough rough edges to frequently impede my work - see the "use Explorer to browse directories without read rights" use case as described in my question. – the-wabbit Aug 24 '14 at 14:59
  • @Basic and incidentally, this is an insight which indeed has arrived at the software manufacturer's as well: [*"Under certain constrained circumstances, disabling User Account Control (UAC) on Windows Server can be an acceptable and recommended practice."* (MSKB 25260823)](http://support.microsoft.com/kb/2526083). – the-wabbit Aug 24 '14 at 15:03
  • @the-wabbit Yep, I'm also an administrator. We're fairly small so I only have to bother with ~100 windows servers and ~50 desktops. I have to admit I find IE's "safe" mode far more irritating (you'd think MS downloads would function without having to add exceptions every time). That said, I take your point. You're looking for the windows equivalent of `sudo -i`, which I admit I use on linux quite a lot to do admin tasks. I suppose the difference is that in Linux, it's a single instance of the shell that's elevated not a shared process used by many other processes. – Basic Aug 24 '14 at 16:18
  • Another year later ... possible duplicate of [my July 2013 same question](http://serverfault.com/questions/521921/windows-folder-permissions-administrators-and-uac-whats-the-right-way-to-de) ;-) - and it came to the same answer with that MSKB article, but the wider conclusion I came to is that Microsoft's ideal would be using an administrative workstation, connecting remotely with [RSAT](https://www.microsoft.com/en-gb/download/details.aspx?id=45520) or PowerShell or classic management tools, and running server core with no GUI on the servers. – TessellatingHeckler Nov 25 '15 at 20:04

7 Answers7

11

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.

enter image description here

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.

zedex
  • 3
  • 2
Scott Chamberlain
  • 1,445
  • 2
  • 21
  • 37
7

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

Peter Hahndorf
  • 13,763
  • 3
  • 37
  • 58
  • for me, turning off UAC or continuously running in an elevated shell would be exactly what I need to have. Most management consoles break without elevation too - having them covered is a nice gimmick. I know about the various commanders out there, but I really like the "out-of-the-box" character of Scott's answer as I would not need to have anything but my hands at the keyboard for it to work. – the-wabbit Nov 06 '13 at 12:43
2

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.

Bill_Stewart
  • 258
  • 1
  • 7
2

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.

SamErde
  • 3,324
  • 3
  • 23
  • 42
1

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

Draghon
  • 111
  • 3
1

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

Larry
  • 11
  • 1
0

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.

Kevin Martin
  • 11
  • 1