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.


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.

  • There is...see my solution, which works great on file servers that are being managed by sysadmins. – SturdyErde Jul 26 '18 at 18:58
  • @SturdyErde Not sure your answer works within the OP’s constraints, and it really just moves the problem to managing ACLs and AD groups. Poor product design/architecture on Microsoft’s part. FWIW, my preferred solution is to manage files and folder over SMB, which doesn’t trigger UAC... but OP wanted to be logged into the server as an admin, so that limits his options. That being said, your answer does provide a reasonable alternative, so I’ve upvoted it. – HopelessN00b Jul 26 '18 at 19:09
  • I think you may have read the wrong answer--the solution that we use does not require creating a single security group (neither local nor AD) and does not require UAC to be disabled. The built-in INTERACTIVE security principal being granted permission to traverse folders and list contents perfectly meets the need for a logged on administrator to be able to traverse the folder structure without having UAC hammer in explicit ACEs. Security is not compromised because the admin first has to authenticate to get on the sever, and second, will still be prompted with UAC if they try to delete/modify. – SturdyErde Jul 26 '18 at 19:22
  • @SturdyErde I stand corrected. – HopelessN00b Jul 26 '18 at 23:20

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.


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.

  • Yes, changing the ACL is possible. Changing the ACL for a folder you care about is reasonable, in which case you could just add Users/Read and be done with it. Changing the out-of-the-box ACLs is not so reasonable, as you have to keep up with every folder/ACL that ever gets added, by every install ever. If, somehow, having Administrators membership automatically inferred List/Traverse without having to elevate, then this would be viable. – jimbobmcgee Jul 26 '18 at 21:57
  • Automatically inferring list/traverse will be accomplished for all current and future folders if you add this ACE at a top-level folder/drive ACL, and do not break inheritance on sub folder ACLs. – SturdyErde Jul 27 '18 at 15:33
  • Not if a subsequent installer (ahem, SQL Server) then goes and creates folders that do not inherit ACLs from parent, which is entirely possible to do. – jimbobmcgee Jul 27 '18 at 19:17

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

  • 1
    Thanks, but the question is not about how to access folders that have an ACE for Administrators without prompting -- I can already do that. It's how to stop the Explorer interface that automatically adds a Full Control ACE for the current user, if they click Continue on that "permanently get access" prompt. – jimbobmcgee Oct 3 '16 at 13:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.