Access “Access Denied” Folders-Files Without Changing Security Settings

Topic

New Reply

There are folders and files in Windows that a user with administrative privileges is denied access to.  This is a safety feature to keep a user from accidentally deleting a file that is necessary for Windows or some app to function.  Malware and even well known software makers will use the security settings in a denied access folder to keep a user from deleting their software.  There are situations where an informed user needs to access a denied access folder or file.

The typical method involves changing ownership to the user, then adding that user to the security settings for that folder/file, and modifying the security settings to allow that user access.  This can be quite involved just to look into a denied folder.

The Administrator’s account in Windows has security settings beyond those of a user account that was created as an “Administrator”.  Many of these folders and files that deny access to that user will allow access in the Administrator account.

Thus a user can set up the Administrator account, switch to that Administrator account and view the folder or file that was denied  in the user account.  No ownership or security settings need to be changed.

This is not 100%.  Some folder/files will allow the Administrator’s account to delete it.  There will be folders and files that the Administrator account can view, but are not allowed control of (aka: cannot delete).  There are folders and files that even the Administrator account cannot access.  These are usually files that are protected and should be left alone.

There are other uses for the Administrator account.

For those that wish to set up and use their Administrator account, the attached PDF has detailed instructions.

Activate-Extra-Administrator-Powers

HTH, Dana:))

Reply | Quote

Replies

I have seen the assertion that the built-in Administrator account is more privileged than an account that is a member of the Administrators group.

On my Win10 22H2 system I enabled the built-in Administrator account and signed in. Then I ran the command “whoami /groups /priv” and captured the output to a file. I did the same thing for a logged on user that is a member of the Administrators group from an elevated command prompt.

When I compared the groups and privileges that were present in the token of the built-in Administrator account and the elevated token of the other user they were identical.

I haven’t comprehensively tested but I have observed that when the SYSTEM account and the Administrators group access has been restricted the security identifier that was needed in the token was that of NT SERVICE\TrustedInstaller.

Reply | Quote

EricB wrote:

I did the same thing for a logged on user that is a member of the Administrators group from an elevated command prompt. When I compared the groups and privileges that were present in the token of the built-in Administrator account and the elevated token of the other user they were identical.

That may appear to be the same, but the user account has to OK the UAC window to open that elevated command prompt but with the Administrator account typing cmd in a Run box opens an elevated command prompt without any UAC window. In a user account in order to run a .bat file that requires an elevated prompt you have to select to Run as Administrator and click the UAC window, but in Administrator just click to open the .bat file and it will run in elevated mode. The difference in the above is not a higher level of security, but rather one must get approval for each request (user) and the other is approval always on so no individual approval needed.

As far as access to folders/files denied to a user account, but accessible to the Administrator account has to do with the security settings on each folder/file. Some folders that deny user account access will have a security setting to allow Administrator account access.  This is a common practice by software makers.  Example: C:\Program Files\WindowsApps (File Explorer must be set to show hidden and system files to see this folder). Access denied to user account, but access allowed with the Administrator account.

Considering the administrative functions performed without individual approval and access to folder and files denied to a user account I would say the Administrator account is more privileged than a user account even if they have the same elevated token.

HTH, Dana:))

Reply | Quote

Drcard:)) wrote:

Example: C:\Program Files\WindowsApps (File Explorer must be set to show hidden and system files to see this folder). Access denied to user account, but access allowed with the Administrator account.

Actually, the Administrators Group has limited access.  Only the SYSTEM and TrustedInstaller have Full Control.

From an access control perspective an Administrator group elevated token is equivalent  to the Administrator account token unless a security descriptor allows access to the Built-in Administrator account specifically but does not otherwise allow access to the Administrators group.  I have not yet seen such a security descriptor.

In my view UAC is not relevant to the privilege issue.

 

 

Reply | Quote

EricB wrote:

From an access control perspective an Administrator group elevated token is equivalent  to the Administrator account token unless a security descriptor allows access to the Built-in Administrator account specifically but does not otherwise allow access to the Administrators group.

Have you actually tried to open this folder in a user account and Administrator account? It is denied access in a user account no matter what security token is assigned. Try to open with the Administrator account it opens and lists all the items there. Once the folder is open, some items are not accessible to the Administrator account yet others you can access and delete thru the Administrator account without changing any security settings. From an access control perspective access to this folder there is different for Administrators account and a user account regardless of the token level each has. This difference comes from the security settings for that folder.

HTH, Dana:))

Reply | Quote

Drcard:)) wrote:

Once the folder is open, some items are not accessible to the Administrator account yet others you can access and delete thru the Administrator account without changing any security settings.

Emphasis added.
That’s an interesting claim since the Administrators group only has List Folder Contents permission in the security descriptor!  Perhaps a different security descriptor for the folder/items you are referring to.

Reply | Quote

Drcard:)) wrote:

It is denied access in a user account no matter what security token is assigned.

Access is denied because the ACE in the WindowsApps folder security descriptor is a conditional ACE and in order to access the folder the token must include the security attribute specified in the security descriptor.  Explorer’s token doesn’t have the attribute (WIN://SYSAPPID). This is simply to make it difficult for a standard user account to mess with things.

However, if a standard user knows the file system location of a subfolder then it can be accessed in Explorer by virtue of bypass traverse checking.  For example,

And the folder’s security descriptor contains an ACE for the Users group that grants Read access. Again, only SYSTEM and TrustedInstaller have Full Control while Administrators have List Folder Contents which were inherited from WindowsApps.

Finally, to bring this back on point my initial post was about Administrator access with an elevated token compared to the Built-in Administrator account.  All of the discussion about standard user accounts and UAC may be interesting but it is not germane to my point.

Reply | Quote

EricB wrote:

That’s an interesting claim since the Administrators group only has List Folder Contents permission in the security descriptor!

That is not a claim, it is a fact. I don’t post things that I did unless I actually did it. Here are screenshots of the deletion while in the Administrator account.
Screen shot one is accessing and viewing the contents of the WindowsApps folder that a user account is denied access to:

Note that I have selected a folder (Priceline…)

The next screenshot is of the Advanced Security settings for that folder.

Notice that SYSTEM is still the owner
That Users have Read only access
That Administrator has full control

The final screenshot is that folder in the Recycle bin after I deleted it.

These screenshots prove my “claim” of deleting a folder without changing ownership or security setting simply by using the Administrator account. There are many other folders/files I have deleted this way. As I pointed out in my original post there will be folders and files that the Administrator account can’t delete or view. The Administrator’s account is a much easier way to get rid of these space hog, unnecessary software files.

I totally understand your point in theory, but in actual practice many software makers have written their security settings to allow only the Administrator’s account full control and users accounts no access to those folders/files. While the Administrator and user accounts have the same security level in theory, current practical application of security settings does give access to some folders and files to the Administrator account which actually gives the Administrator account an access advantage that the user account doesn’t have. Not theory, but actual fact.

HTH, Dana:))

Reply | Quote

For some  reason the ACE in the security descriptor in the image that you posted gave Administrators group Full Control for Priceline.  Just so that we are working from the same page can you please check the descriptor for the Photos App as shown in my image?

I see no reason why an Administrator group elevated token wouldn’t have the same access (Full control) as the Built-in Administrator account.

In any event I did go back and take a look at the security descriptors for several UWP app folders.  I did not find any that gave the Administrators group Full control.  So that is a significant difference between your experience and mine.

And my earlier comment did note that perhaps you were working with a different security descriptor. 🙂

Reply | Quote

EricB wrote:

For some  reason the ACE in the security descriptor in the image that you posted gave Administrators group Full Control for Priceline.  Just so that we are working from the same page can you please check the descriptor for the Photos App as shown in my image?

The descriptor for that file on my system is the same and the Administrator account can only view. All the Microsoft folders in the WindowsApps folder will have those security settings. The folders and files I refer to are not Microsoft, but rather other software makers. Besides the PricelineBooking folders I’ve found Cyberlink, Amazon, Spotify, and others that have the Administrator account set at Full Control and thus accessed and deleted using the Administrator account.

EricB wrote:

In any event I did go back and take a look at the security descriptors for several UWP app folders.  I did not find any that gave the Administrators group Full control.  So that is a significant difference between your experience and mine.

I can only assume that you don’t have any of those non-Microsoft folders in your WindowsApps folder. I am seeing more of these kind of software hiding in the WindowsApps folder. I posted this way to get rid of these files to help those that have a hard time messing with ownership and adjusting security settings; and, as my screenshots have shown works quite well for these files which are ones you can safely delete.

HTH, Dana:))

Reply | Quote

Thanks for looking at the other folders.  The non-Microsoft UWP app folders that I checked did not grant the Administrators group Full control.

I have noticed that although the Priceline security descriptor refers to the Administrators group you consistently refer the Administrator account.  This distinction is important.

An elevated Administrators group token should be able to exercise Full control on your system for Priceline and presumably the others like it.

As I previously said, a security descriptor that has an ACE for the Administrator account but not for the Administrators group will not allow access to an elevated Administrator group token.  I have not seen such a security descriptor.

This may be a fine point, but it does have a bearing on whether or not an elevated token will be equivalent to the Built-in Administrator for access checks. In my experience they have been equivalent.

Reply | Quote

I’ve been following this discussion.  In my experience, the only place that the (normally dormant) Administrator account has greater privileges than the Administrators group is in the registry, and even there, only a few specific registry entries.

For the past few years I have been using Process Hacker (scroll down that page a bit) to run as TrustedInstaller for most things that need that level of privilege elevation, and just leave the built-in Administrator account dormant.  I use the plugins shown on that same page.

Always create a fresh drive image before making system changes/Windows updates; you may need to start over!

We all have our own reasons for doing the things that we do with our systems; we don't need anyone's approval, and we don't all have to do the same things.

We were all once "Average Users".

Computer Specs

Reply | Quote

@bbearren,

Your observation about the registry was spot-on.  I’m still a fan of cmd.exe and was annoyed to find that in Win10 the context menu for folders was changed to offer Powershell instead of a Command Prompt.  This can be corrected by editing the registry at HKCR\Directory\shell\cmd and HKCR\Directory\Background\shell\cmd to change a value name from HideBasedOnVelocityId to ShowBasedOnVelocityId.  When this change is made the context menu item to open a Command Prompt is restored.

Happiness turned to sadness when regedit.exe failed to save the changes.  It turns out that even the SYSTEM account and the Administrators group only have Read access to the keys.  The keys are owned by TrustedInstaller and it has Full Control in the security descriptors.

I didn’t want to hassle with taking ownership, changing the security descriptor and then restoring old values.  So with a bit of Visual Studio magic I was able to start regedit.exe with the TrustedInstaller SID in its token.  Then it obediently saved my changes.

Reply | Quote

EricB wrote:

have noticed that although the Priceline security descriptor refers to the Administrators group you consistently refer the Administrator account.  This distinction is important. An elevated Administrators group token should be able to exercise Full control on your system for Priceline and presumably the others like it.

That refers to an Administrator account on that PC.  If this applies to an  Administrators group that all accounts with elevate tokens can use then a user account with an elevated token should open the WindowsApps folder.  The user account even with an elevated token can’t open that folder.  That Administrators descriptor specifically denotes the Administrator account(s) (yes, you can have more than one Administrator account).

Here’s another example of Administrator account having full control:

Should of saved more files before I deleted them to show you even more examples.

HTH, Dana:))

Reply | Quote

Another folder that is accessible only to the Administrator account is the C:\Recovery folder. It’s Advanced security is:

Like I keep saying, there are folders and files accessible thru the Administrator account that are not available to a user account (even if the user account has elevated privileges).

My goal is to provide users that are not familiar with taking ownership and setting up security settings to view the contents of a folder or delete a software file that they don’t want and don’t want it wasting space on their drive. The WindowsApps folder can range from 7 to 15 GBs on most systems. For these users any folder or file that they can’t delete thru the Administrator account is one they should leave alone. The ones that can be deleted in the Administrator account are usually safe to delete.

HTH, Dana:))

Reply | Quote

I’m sorry, but I believe you are mistaken.

Following is an application that is NOT running as the Built-in Administrator but has an elevated Administrator groups token.  As you can plainly see, it displays the content of the WindowsApps folder.

You can see that the User account is “Bozo” and I have highlighted the relevant groups in the token that result from elevation.  You can clearly see the membership in the Administrators group.

Reply | Quote

Please perform this test for me.
Using your user account Bozo go to C:\Recovery and open that folder.
Please let me know what happened.

HTH, Dana:))

Reply | Quote

On my own systems I leave the Built-in Adminstrator account disabled.  In almost all cases that I can think of using a command prompt running under the SYSTEM account (courtesy of PSExec) has been adequate when Administrators group access has not been sufficient.

Reply | Quote

On my system the security descriptor for C:\Recovery contains a Deny ACE for any token containing the SID for a local account.  However, the security descriptor also contains an inheritable Allow ACE providing Full control to the Administrators group.

So, similar to what we saw for Users in the WindowsApps folder, an elevated Administrators group token does have Full control for subfolders and their files through bypass traverse checking.  Because a Deny ACE takes precedence over an Allow Ace the C:\Recovery folder itself is not accessible.

Reply | Quote

EricB wrote:

So, similar to what we saw for Users in the WindowsApps folder, an elevated Administrators group token does have Full control for subfolders and their files through bypass traverse checking.  Because a Deny ACE takes precedence over an Allow Ace the C:\Recovery folder itself is not accessible.

As shown above there is no Deny ACE in my C:\Recovery folder…only descriptor for Administrators at full control. My user account (only account on the PC until the Administrator account was activated) had the highest security level and is part of the Administrator’s group. The user account can’t access the C:\Recovery folder. If the Administrators descriptor is for Administrator’s group, then my user account as part of the Administrator’s group should open the folder, but it doesn’t. However the Administrator account can open the folder. Since the Administrator account has control and the user account doesn’t that descriptor applies to the Administrator account. The blocking of accounts with an SID of a local account doesn’t make sense because the Administrator account is a local account with a SID and that Administrator account isn’t blocked from opening that folder.

The result is the same; the Administrator account can access folders that a user account can’t. Going around that folder to internal folders doesn’t change the fact that the Administrator account can access folders a user account with highest security level can’t.

HTH, Dana:))

Reply | Quote

When you refer to your user account being a member of the administrators group are you working with the elevated token or the limited token for the account? Without elevation the limited token has a SID for the Administrators group that is only used for access control Deny checking.

Reply | Quote

EricB wrote:

When you refer to your user account being a member of the administrators group are you working with the elevated token or the limited token for the account? Without elevation the limited token has a SID for the Administrators group that is only used for access control Deny checking.

Per Microsoft: The first account set up in Windows will get the highest security levels possible and automatically become part of the Administrator’s group. You can set up accounts with lower levels, but not on the first account. As far as limited token only used for Deny checking still doesn’t match the results. Your Bozo user account has an elevated token and is part of the Administrator’s group and was denied access to that folder. The Denies you are seeing are Microsoft’s system that Denies any account not specifically allowed thru the descriptors, which in this C:\Recovery folder is only the Administrator account.

Elevated or limited tokens for a user account doesn’t allow the account access to that folder and becomes a mute point when facing the security descriptors for that folder. You have tested and shown on your system that your elevated user account cannot access the WindowsApps or Recovery folder, yet both folders have a security descriptor that allow Administrators access. An Administrator account can access both folders. The security level (tokens) of an account doesn’t determine access, the folder’s security settings (descriptors) determines access. The Administrators descriptor allows Administrators accounts access, but doesn’t apply that descriptor to the Administrator’s group or any account that is part of the Administrator’s group resulting in those accounts being denied access.

You can use the elevated status of a User account to bypass or change security settings but this whole topic is about using the Administrator account to access those folders without have to bypass or change security settings. Note that the C:\Recovery folder is set up by Windows and Windows has set the security settings to allow only the Administrator accounts access. The Administrator account having access to these (and others) folders/files that a user account with the highest level of security can’t access gives the Administrator account an access advantage and is above a user accounts access level.

HTH, Dana:))

Reply | Quote

You have a fundamental misunderstanding about the presence of an ACE for the Administrators group in a security descriptor.  It does NOT allow access only to the Built-in Administrator account.  Windows checks the groups in a token when performing an access check.  Because an elevated token includes a SID for the Administrators group access is allowed if permitted by the security descriptor.

You have also ignored the fact that a Deny ACE takes precedence over an Allow ACE.

The proof is in the example I posted above where even the Built-in Administrator fails to access a folder that contains a Deny Ace for a Local Account.

Reply | Quote

In a test system I set the security descriptor on the C:\Recovery folder so that it was identical to your own –

With this security descriptor a user account that is a member of the Administrators group was able to access the folder from an elevated command prompt.

Then I added the same Deny ACE for local accounts that I mentioned earlier.  Now the security descriptor looks like this –

To test if the Built-in Administrator account has super powers I enabled it, logged on and attempted to access the C:\Recovery folder.

The result was the same as for an elevated Administrators group user account — Failure.

Reply | Quote

EricB wrote:

With this security descriptor a user account that is a member of the Administrators group was able to access the folder from an elevated command prompt.

Yes it would. You stumbled on an old trick. It’s not just an elevated command prompt, it is the “Administrator” command window as shown in the title bar. The Administrator command window uses the Administrator account’s command window and as such has the Administrator account security clearance. Example: My user account in an Administrator Command window allows access as below

So having a user account access that folder in an Administrator Command window really is using the Administrator account’s access.
Remove that Deny descriptor so the Administrators is the only descriptor and try to access the C:\Recovery folder in your user account using File Explorer or a Run box for C:\Recovery. You get what my user account gets.

That Deny descriptor is very strange in that it is not on any of my Windows 10 PCs and if it stops the Administrator account too, then there is no descriptor to allow any access to the folder which doesn’t make sense. Have no idea how it got there, but without it it takes an Administrator account or the Administrator account’s Command window to access that folder. The user account can’t access that folder.

HTH, Dana:))

Reply | Quote

That windows puts the “Administrator” title on an elevated command prompt does not mean that the disabled Built-in Administrator account is being used.

Reply | Quote

Drcard:)) wrote:

Remove that Deny descriptor so the Administrators is the only descriptor and try to access the C:\Recovery folder in your user account using File Explorer or a Run box for C:\Recovery. You get what my user account gets.

Did you do that?  Did the user account get denied in File Explorer or the Run box with Administrators as the only descriptor?

If the user account gets denied thru File Explorer or the Run box (or even a normal user command prompt), then that continues to prove my point.

 

HTH, Dana:))

Reply | Quote

I said above in an earlier post that without the Deny ACE that a user that is a member of the Administrators group can successfully access the folder from an elevated command prompt.

Reply | Quote

To further clarify the distinction between the Built-in Administrator account, the Administrators group and elevated tokens I performed another test.

I created a folder with the following security descriptor –

Note that the folder is owned by SYSTEM which also has Full control.  The other ACE in the descriptor grants Full control to the Built-in Administrator account, not to the Administrators group.

Now, when attempting to access that folder from a user account that is a member of the Administrators group from an elevated command prompt access was denied –

Note the “Administrator” information in the window caption.  It is meaningless. Because the elevated token for the account only contains a SID for the Administrators group it is not sufficient to satisfy the access check.  There was no behind the scenes use of the Built-in Administrator account.

Reply | Quote

EricB wrote:

I said above in an earlier post that without the Deny ACE that a user that is a member of the Administrators group can successfully access the folder from an elevated command prompt.

As I said the elevated Command window uses the settings in Administrator account for a command window and access based upon those settings (or can be said it uses the same exact command window that the Administrator account uses).

So easy to prove me wrong. Without the Deny ACE and using your user account open a Run box and type in C:\Registry and press the Enter key. If I’m wrong your member of the Administrator group user account will open the folder. So easy do that step and end this debate. I await your report of what happens when you do this simple test.

HTH, Dana:))

Reply | Quote

Your test is flawed.  By definition when UAC is enabled a user account that is a member of the Administrators group is logged on with what is called  split token.  Technically, the system creates two LSA logon sessions and two tokens for the user.  These two tokens are linked to each other. One token is a limited token that has had Administrator privileges filtered out and the groups contained in the token that reference the Administrator group are only used for Deny access checks.  The other token is the elevated one that contains full Administrator privileges and whose groups identify the user as a member of the Administrator group for all access checks.

Following image is from an unelevated, limited token for a member of the Administrators group.  Note the Flag column that indicates “Deny” for the Administrator group sids and that the integrity level is Medium.  Also note the small number of privileges contained in the token.

Now look at the elevated token for the same user containing Administrator privileges.  The Flag column no longer contains “Deny” for the Administrator group sids and the integrity level is High.   Also note the large number of privileges the token contains.

Finally, if you compare the highlighted identifiers for the Logon session in the two tokens you can see that they are different.

The test you proposed doesn’t prove anything because the unelevated limited token is, by definition, not able to pass an access check that tests for the Administrators group.

Furthermore, if your belief that the “Administrator” notation on a command prompt window indicates that the Built-in Administrator account is being used then my test above where the security descriptor allowed access to the Built-in Administrator but not to the Administrators group would have produced a different result.

 

Reply | Quote

EricB wrote:

Your test is flawed.

Your said that a user account with elevated privileges could access the same file as the Administrator account. If that is so then that user account should open the C:\Recovery folder in the RUN box or File Explorer. The test is not flawed and just how the user account has a split token that prevents the folder from opening doesn’t change the final outcome that that user account cannot open that folder. Your reluctance to just try to open the folder indicates you know it won’t open.

That account not being able to open that folder in anything other than an Administrator Command prompt proves:
1) The Administrator account can access some folders that a user account with elevated privileges can’t.
2) The Administrators descriptor in the Recovery security settings applies to Administrator accounts and not to the Administrator group.
3) The user account needs to access settings of an Administrator command prompt to access the folder because it can’t do it on its own.

As long as that user account can’t access that folder without using an Administrator command prompt ALL the above is true.

HTH, Dana:))

Reply | Quote

Why don’t we just agree to disagree. I believe that your understanding of administrator  privilege, UAC and Windows access control is flawed and you think the same of me. I suggest we drop the whole thing at this point since pursuing it any further seems to be futile

Reply | Quote

EricB wrote:

Why don’t we just agree to disagree. I believe that your understanding of administrator  privilege, UAC and Windows access control is flawed and you think the same of me

My understanding of administrator privilege, UAC and Windows access control may or may not be flawed; but that understanding, right or wrong, doesn’t change the physical fact that on a Windows system (yours included) the Administrator account has access to folders that a user account can’t unless the user account uses an Administrator Command window, by passes, or changing security settings (all non normal ways a user to access a folder), which is what this discussion was about.
I agree that further discussion is unnecessary, as how the Windows access system works doesn’t change how Windows is setup and is actually functioning to allow/not allow access.

HTH, Dana:))

Reply | Quote

I had hoped that we could end this without further assertions but I am compelled to make one more post to prove my points without using an elevated command prompt window.

Security Descriptor for C:\Recovery showing only the Administrators group has Full Control

UAC elevated token used to run notepad.exe under a user account that is a member of the Administrators group.  The built-in Administrator account is disabled.

Notepad Open File Dialog accessing C:\Recovery

Case closed.

Reply | Quote

EricB wrote:

The built-in Administrator account is disabled.

Yet the Builtin\Administrators is the Owner and hence has the Administrators access rights just like the Administrator Command window. I wonder how many users open Notepad to access a file or use another bypass method that taps the Administrators access rights to open a file?
If the user account has access of its own, then that user account could access that folder in a Run box or File Explorer just like all the other folders the user account has access to. Coming up with different ways to by pass and tap into the Administrator access rights doesn’t change that fact.
Like I said, further discussion appears useless; so post all the work around examples you think prove your point, I will not respond showing it flaws. Until you show that the user account has access to that folder in the Run box or File Explorer just like that user accesses their other folders you have proved nothing.

HTH, Dana:))

Reply | Quote

I’m not bothering to post further examples since you insist on a test that, by definition, cannot succeed.  Under UAC when a user account that is a member of the Administrators group logs on Explorer.exe runs with the limited token.  That fact alone makes the proposed test pointless.  One might even say it is rigged to fail. And I never asserted that an unelevated, limited token provided Administrator privileges.

Currently supported versions of Windows even prevent a user from starting explorer as an elevated process.  You can read more about the notepad proof and explorer elevation at articles written by a highly respected Microsoft developer at –

Explorer is a single-instance application, but you can find other ways to get the effect of running a separate instance

What is the CreateExplorerShellUnelevatedTask scheduled task?

Reply | Quote