8

I have a folder with permissions:

  • Administrators (group): Full.
  • J. Bloggs: Full.

I'm logged in as a member of the Administrators group.

I can't open the folder in Explorer because "you do not have permission".

I suspect this is because normal processes do not have the administrator permission token because of UAC, unless you also 'run as administrator'. But I can't do that for Windows Explorer, can I?

So my options seem to be: - Click the button to take ownership (ruins ownership, takes ages on large folders, doesn't solve for other administrators) - Add each individual administrator account with full permissions so it works without the admin token (administrative mess, what's the point in groups)

This is a really annoying design, I must be missing something. How is it supposed to work? What's the 'right' way for an administrator to get into a folder that administrators have access to?

TessellatingHeckler
  • 5,676
  • 3
  • 25
  • 44
  • 1
    I think Explorer only runs elevated when you are logged in as *the* local administrator of that machine. – john Jul 09 '13 at 15:10
  • 2
    This is one of the reasons why ms updated their security recommendations about using uac on servers. http://support.microsoft.com/kb/2526083 – tony roth Jul 09 '13 at 17:44
  • Tony, that's a complete surprise to me, after so long putting up with UAC prompts "for the greater good", to hear Microsoft say there is not, *and can never be*, any greater good on the server side. Quote: """When all the administrative user’s tasks require administrative rights, and each task could trigger an elevation prompt, the prompts are only a hindrance to productivity. In this context, such prompts do not and cannot promote the goal of encouraging development of applications that require standard user rights""". Brilliant. MS approval to turn UAC off! (in certain, limited situations). – TessellatingHeckler Jul 10 '13 at 12:52
  • this statement "UAC should also remain enabled if administrators run risky applications on the server such as web browsers, email clients, or instant messaging clients, or administrators perform other operations that should be performed from a client operating system such as Windows 7." is the key to all of this. – tony roth Jul 10 '13 at 14:06
  • 1
    You CAN run Explorer with Elevated privileges, First: `open Task Manager, go to details, kill the existing explorer running as your user.`(Note: your start menu and folders etc. will disappear), then, still in task manager: `Click File, Start New Process, Type Explorer, and select the "Run task with administrative privileges" checkbox, and hit OK` Your Start menu will re-appear, you are now able to continue on without needing to elevate each time you access a folder or file that you have permissions to only through the Administrative users' group. – Ben Personick Oct 16 '19 at 14:58

5 Answers5

6

The best way is to define a new group containing members that you consider to be administrators of that folder. If you have an AD domain, you can create this group in AD and then add that group to the Administrators group (of the local machine) and avoid having to administer two groups.

Note: If you're trying this locally, remember you have to log off and back in again for the new permissions to take effect.

Henry Rivera
  • 3
  • 1
john
  • 1,995
  • 1
  • 17
  • 30
  • I wish I'd considered this sooner. It's mildly annoying, but low administrative overhead and not likely to break anything else. – TessellatingHeckler Jul 09 '13 at 15:41
  • 1
    This is how we solved the problem. We have groups like "Billing-Dept", "IT-Dept", etc. Makes much more sense in the context of a single folder than "Domain Admins". – Dan Oct 30 '14 at 16:16
4

The solution is to simply manage the server remotely. The UAC filtering of the administrator privileges only applies when you are accessing the local system.

With the release of Server Core, Microsoft has been strongly encouraging people to remotely administer servers instead of connecting to them directly to manage them.

Of course if you have a really small network this may not be feasible, so disabling the UAC is fine, or adjusting the filesystem permissions so that another group is used instead of administrators to grant permissions.

Zoredache
  • 128,755
  • 40
  • 271
  • 413
  • So would eg. \\localhost\c$ allow administrators to view as administrator? Think I've seen this done before. – john Jul 09 '13 at 19:06
  • But that isn't a solution at all, because I'm not logged in as an administrator on my desktop. (I'm not even logged in on the same domain, and there's no trust relationship between them)). – TessellatingHeckler Jul 10 '13 at 12:24
  • You don't have to access the remote system using the credentials you used to login. Connect to the remote system as administrator. `net use \\server\share /user:adminuser`. – Zoredache Jul 10 '13 at 18:39
  • This is the correct general answer but there are still too many Microsoft and OEM server products which require desktop interaction to manage or reconfigure them effectively. The original question is valid and a solution for the "Windows" server desktop is required. It's strange that the defaults of Microsoft do not support this without granting all local users access to read and create everything from the root. I added a lot of detail in a suggested edit to the answer from @PaGeY so I hope he accepts that because currently I believe that's the best alternative when core admin is not possible. – Tony Wall Sep 26 '18 at 12:06
2

There are two options to work around this limitation easily:

Martin Binder
  • 231
  • 1
  • 2
  • 1
    The first is a pragmatic suggestion from you for how to work around this, but it *cannot* be Microsoft's intention for how to deal with this, that would be ridiculous. The second is clever and interesting, but I'm not doing that kind of registry bodging on live servers. – TessellatingHeckler Jul 09 '13 at 15:39
1

Grant Read/Execute permission at the drive root the built-in principal called "Interactive". Then no change to UAC is required.

Interactive drive root permissions dialog.

This way people logged into the desktop remotely or "locally" (VM console or physical screen and keyboard) can still browse files and run programs even with UAC enabled.

For example, you could remove the default "Users can read and create everything from the root" permission to lock down the server sensibly, but avoid the inability to effectively logon, browse files and navigate to where you want to change settings as administrator.

As soon as you open the security dialog and want to change permissions, a button appears to change the settings as administrator. So you get the best of both worlds:

  1. No restriction to "local" admin/operator browsing of the structure and content of the disks.
  2. Protection against changes by non-administrators.

The only difference to the standard permissions, is we are not saying that only local "Users" accounts can read everything, but only people granted access to the Windows console, i.e. that logically means "physical" (or virtual) "interactive" server access, which is not just granted to anybody. This may not work for terminal servers unless there is a better way to distinguish between those types of sessions (suggest edit if you know that).

Of course the first advice is use server core/remote admin whenever possible. But when not, this helps avoid the common end-effect that a server were the default users permissions are removed end-up with dozens of personal user account permissions applied all over the place. And it's not really the fault of the administrator, they are just trying to do their job with standard tools without any special complexity (just use File Explorer normally).

Another positive effect of this solution, is by being able to lock-down the root drive permissions and still have the server "usable" for the administrator logged onto the desktop, the need to disable inheritance to remove unwanted permissions from above often disappears. The fact that all users can read and create whatever they want below your shared path by default is a common reason to disable inheritance when nobody wants to deal with the "root" cause ;-)

Tony Wall
  • 145
  • 5
PaGeY
  • 21
  • 1
0

can't open the folder in Explorer because "you do not have permission".

I suspect this is because normal processes do not have the administrator permission token because of UAC, unless you also 'run as administrator'. But I can't do that for Windows Explorer, can I?

Yes, you CAN run Explorer with Elevated privileges to solve your issue!

To do so, you must:

  • open Task Manager
    • Go to the Details tab
    • Kill the existing "Explorer.exe" running as your user.
      • Note: your start menu and folders etc. will disappear, this is normal
    • Click File
    • Select "Start New Process"
      • This pops up a "Create New Task" Dialog.
    • Type Explorer.exe in the "Open:" Drop-down.
    • Check the Checkbox Next to "Run task with administrative privileges"
    • Click OK
      • If the elevation prompt appears, click accept.

Voila!

Your Start menu re-appears, and Windows explorer is Elevated!

You are now running Explorer as an elevated process so any explorer actions which required elevation will work without needing to elevate each time.

So you can Delete a folder or traverse a folder or check permissions or read a file without needing to run elevated for each individual action.

I ran into this because we use admin approval mode to elevate without prompting, however for deleting folders and files and sometimes for accessing them, this is causing us trouble when the user is a member of the local administrator's group instead od having express permissions, elevating Explorer resolved that issue.

Ben Personick
  • 119
  • 6