Disabling the prompt to "Click Continue to permanently get access to this folder" (e.g. via GPO)

Question

http://support.microsoft.com/en-us/kb/950934 describes the manner in which, when a member of the Administrators group uses Explorer to navigate to a folder to which the Administrators group has permission, the user will be prompted to "Click Continue to permanently get access to this folder".

When they do this, Explorer alters the ACL of the folder to grant that specific user Full Control to the folder. The MS link describes exactly the design constraint that requires it to be this way.

However, it ruins the permission set for that folder and makes central management of permissions effectively impossible. For example, if the named user is later removed from the Administrators group, that ACL entry still exists to permit them access to that folder.

I'm not looking to disable UAC (I actually like the distinction between elevated and non-elevated), and I am happy to use alternative tools to navigate and view files in an elevated fashion.

The eventual intent is to run one of the workarounds described in the MS link (either using a separate file navigator that can run elevated, or defining a separate group to control access to the whitelisted folders) but, all the time Explorer continues to clobber the ACLs of the folder, at will, it makes it impossible to identify where these workarounds need to be applied (short of regularly auditing every folder for ACL changes).

I would simply prefer to have the standard "access denied" message, if I attempt to access a restricted folder when running non-elevated in Explorer.

Is there a setting (either one-time on each box, or via GPO) that removes this "permanently get access" prompt, while retaining the other facilities of UAC?

NB: I fully understand why this prompt exists, what it means and why the behaviour is as it is (although I don't necessarily agree with the design decision). However, I should point out that I am not looking to discuss workarounds relating to the working practice of my users, nor the merits/pitfalls of UAC or Administrators group membership.

Answer 1

No, there is not.

The only real solution is using something other than Windows Explorer for file browsing (and to run it elevated, of course).

The problem comes from the fact that explorer.exe is initially launched with a non-administrator access token (in order to display the GUI), and any new sessions, even those launched as an administrator, inherit this limited access token behavior. There is a workaround to launch that initial Explorer instance with an administrative token, but then anything you launch from the GUI inherits the administrative access token, effectively nullifying UAC.

Answer 2

There actually IS a safe way around this prompt for administrative users who are logged on locally.

1. Open the Properties > Security dialog of the folder in question to edit its ACL.

2. Then add the INTERACTIVE security principal and give it permissions for "List folder contents" which will automatically enable the following permissions:

   • Traverse folder / execute file
   • List folder / read data
   • Read attributes
   • Read extended attributes

The reason this works is because Windows is no longer relying on your privileged/administrator credentials for traversing the folder structure and listing folder contents. Since "authenticating" as INTERACTIVE does not need to evaluate privileged credentials in order to enumerate the folder, it therefore does not need to kick the UAC prompt.

Answer 3

TL;DR: Create another group in parallel with the local Administrators group and add everyone authorized to be an Administrator to both groups. Then, allow that second group to be in the ACL for all files and folders. Do not log on or operate as the built-in Administrator user.

This problem has been bothering me for quite a while. It gets frustrating to constantly have to remove myself from folder ACLs (as well as other users who didn't clean up after themselves) as I browse through various folder structures. So, I read through the article mentioned in the question. It gave me the understanding I needed to write this answer, and I recommend reading it before continuing.

The point of the original question that bothered me was the authors' assertion that it "makes central management of permissions effectively impossible." Initially, I agreed with that, but after thinking about it, I remembered the whole point of the principle of "Least Privilege". One of the purposes of the local Administrator account as well as the local Administrators group is to violate that Principle. Ultimately, you can't take away anything from that user or members of that group. Yes, in the immediate term they can be denied, but they still have the ability (without using exploits) to defeat the denial by granting themselves access to whatever resource was denied. So, it would seem that Microsoft believes that there must always be at least one user who can always access everything, somehow. Fair enough. That argument is beyond the scope of this answer.

So, how does this impact the "central management of permissions"? It would seem that to conform to the Principle, you need to half-pretend (I will explain the half- later) that the local Administrator and local Administrators group don't exist. Remember, they can't have their privileges limited, which means they violate the Princple. That's why the password for that account is held so secretly and membership in that group is so coveted. So if you want the same effective access, at the root of each drive you need to have your own user or group that has Full Control which would (ideally) be inherited by all subfolders and files thereof.

We know, however, that in practice that user or group will be routinely denied access, but that's part of the point. The "Administrator" should be the final arbiter of who does and does not have access to any given file or folder. The "Administrator" is embodied in that fixed user. Yes, many of us operate as "Administrator" as a matter of convenience, but when we do that, we are violating the Principle. So to deal with this, we can conveniently remember (this is the half- of the pretend part) that the Administrators group exists and that we may be members of it. We can grant the group (or user) mentioned above (which may be ourselves) access to the resource (that should have inherited the permission in the first place) and not worry about compliance or security requirements because that group (or user) already has authorization to that resource because they are already authorized to act as "Administrator".

There's a catch to this, however. I still didn't want to give up the convenience of logging in as "Administrator", so I added that user to the group - and it still didn't work. That user is a fixed user and it's special, and without disabling UAC, there's no way to remove that "special" quality from it. But, that's the point. Microsoft is trying to drive us more toward compliance with the Principle. By adding my user to both groups, I was able to grant myself access to the resource, remain both compliant and secure and avoid the annoying dialog.

Answer 4

You can simply run CMD or PowerShell as Administrator.

dir *.* /w /s

cmd result

or in PowerShell as Administrator :

Folders :

Get-ChildItem -Recurse -Directory | Measure-Object | %{$_.Count}

Files :

Get-ChildItem -Recurse -File | Measure-Object | %{$_.Count}

PS: Get-ChildItem is not working with paths longer than 260 caracters