共用方式為

Troubleshooting "Access Denied" errors

  • 發行項

Anyone who has used Windows has encountered the dreaded "Access Denied" error.  (AKA error code 5 or 0x5). This error typically implies you can't do something like open or save a file.  The error implies that you have encountered some type of security issue.

In the past, an "Access Denied" issue came down to 2 things in Windows:

  1. Token
  2. DACL (Discretionary Access Control List)

A token represented a user and Windows compared it to the DACL of the secured object that the user was accessing.  Windows was answering the basic question, "Does the user have the requested access to the secured object?".  Once you dig into these 2 items, explaining an "Access Denied" error is easy but understanding whether this is the expected result is much more difficult.  (I may discuss this further in a future BLOG post).

Lately, solving "Access Denied" issues have become more complex due to a new security feature which was introduced in many years ago (Windows VISTA), Mandatory Integrity Control (Integrity Levels).  The purpose of Integrity Levels was to add an extra security check where a user running untrustworthy code is attempting to do something malicious.  See the following for more information:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb648648(v=vs.85).aspx

There are 4 levels of integrity in Windows.  Different users in Windows have a different default integrity level.

  • Anonymous - Anonymous User
  • Low
  • Medium - Normal User
  • High - Elevated User (Administrator)
  • System - LocalSystem

The best example of Integrity Level Usage is Internet Explorer's Protected Mode (See https://msdn.microsoft.com/en-us/library/bb250462%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 ) Basically, Internet Explorer is running in a Low Integrity Level.  What this means is that even though a user may have the appropriate access to a file, the file cannot be accessed from Internet Explorer.  I mentioned above that an access check was based on the system comparing the user's token with the secured object's DACL.  Well, we need to check one more thing, the integrity level of the user's token and what level can access the secured object.  A user can only access objects that have the same or lower integrity level.  In the case of IE, most files and directories in Windows have a medium or higher integrity level and since IE Is running at a low integrity level, any code running in IE will not be able to access any files or directories even if the user has the appropriate permissions to the file or directory.  The above article goes into details on finding the default low integrity level directory which IE can access.  Integrity levels also impact the registry as well.

The integrity level for the user is stored in the token.  The integrity level for a secured object is actually stored in the SACL but the ACEs are not System Aces but they are called System Mandatory Label ACEs.  The Access Check is still the same but there is an additional check that needs to be made from the token and from the Security Descriptor.

So the next time you are dealing with an "Access Denied" error, do not forget to check the integrity levels of the user and the secured object.  You'll save yourself a lot of time.

Follow us on Twitter, www.twitter.com/WindowsSDK.

Comments

  • Anonymous
    October 27, 2015
    Would this show itself intermittently?  I'm troubleshooting the 0x5 error with some shared printers and stumbled on this article.