Evaluating Effective Access

This post is also taken from the “Understanding and Troubleshooting Dynamic Access Control” and serves as a good refresher for how to determine a users effective permissions.  This material is not new, but the concept is dated and finding this information on Microsoft’s web site is becoming increasingly more difficult.  This post only covers NTFS and share permissions.  It does not include evaluating permissions that use Central Access Policy or Dynamic Access control.  We’ll save that for another post.

There are a few concepts you should understand to set you up for success for evaluating effective access.  Let’s start with those.


Access Token

Windows creates an access token for each user that logs on to the computer.  The authentication token contains the security identifier (SID) of the user and SIDs of all the groups to which the user belongs, directly or indirectly as in the case of nested groups. Windows uses this access token to determine if a permission entry’s principal applies to the principal accessing the share by comparing the SIDs within the token against the SID of the principal of each permission entry in the permission list.

A permission list contains one or more permission entries.  Each permission entry contains a principal, type, and access.  The principal is a SID to which the permission entry applies– typically a user or group.  The permission entry type describes whether the permission entry allows or disallows access.  The access portion of the permission entry describes the permissions a user performs when trying to use the file.  Therefore, these three components define how Windows protects a given resource.

Applicability

Windows only cares about permission entries that are applicable to the user attempting to access the resource.  Windows determines if a permission entry applies to the user by comparing the principal SID in the permission entries with the SIDs in the access token.  If the principal SID is present in the access token, then the permission entry applies to the user.  Windows includes that permission entry when evaluating access to the resource.

Explicit Access

A user encounters two points of access policy when accessing a file share hosted on a Windows file server: Share access policy and File access policy.  These access policies collective represent the permissions Windows uses to determine access to files in the share.  You determine effective access for the user by comparing the applicable permission entries in the file permissions list with the applicable permission entries in the share permissions list. Windows grants the access common between both lists to the user.  If the access requested by the user matches the access extended to the user by Windows, then Windows applies the permission type to the user, which is either allow or disallow the requested access.  This concept is known as explicit access because a permission entry appears in both lists that explicitly applies the access type to the request.

Implicit Access

However, there are some circumstances where permission entries do not share common access.  Typically, this occurs when neither of the permission lists contains a common permission entry that is applicable to the user.  Windows cannot grant explicit access and prevents access to the resource.  This behavior is known as implicit access.  Implicit access is the common reason why users cannot access a resource when the resource does not explicitly deny them access.

Share Access Policy (Share Permissions)

Share access policy, also referred to as share permissions; represent the basic access you can grant on a shared folder.  On a share, you can control access to the share using Read, Change, and Full Control permissions.  Windows creates these categories of access through a list of basic permissions.  Basic permissions are a combination of advanced permissions.

permissionMappingTable

File Access Policy (NTFS Permissions)

Files and folders stored on NTFS volumes use permissions. The file system is a hierarchy of files and folders. Files and folders throughout the hierarchy share a parent-child relationship. This hierarchy supports the flow of permission entries from the top-most parent to the bottom-most child. This flow of permission entries is known as inheritance.

There are two categories of NTFS permission entries: explicit and inherited. Explicit file permission entries are permission entries that you assign directly to the file or folder. Inherited file permission entries are permission entries that a resource receives from its parent by virtue of inheritance.

A folder is unique in that it can be subordinate to its parent folder — thereby acting as the child in the parent-child relationship. At the same time, the folder can act as the role of the parent in the parent-child relationship. This dual relationship role enables you to configure explicit file permission entries on the folder. Those explicit permission entries flow down the file system and become inherited file permission entries on all child files and folders. You can change how Windows propagates inherited permissions using the Advanced Security Settings editor.

Files and folders stored on NTFS volumes contain explicit and inherited permission entries. You use file permissions to determine effective access when not accessing files and folders through a share. When all the file permission entries types are Allow permission entry types, you use the least restrictive permissions (permission entries that give the user the most access) among all the file permission entries to determine effective local file access. Therefore, you determine effective access by combining all the applicable allow permission entries for the user. However, determining local effective access changes when a deny permission entry type exists among the permission entries.

Effective NTFS Access Scenario

Three users access a folder locally on a workstation with the following permission entries.

NTFSPermissionsTable

The first user, Alejandra is a member of the Users and Marketing groups.  Therefore, permission entries two and three apply to her when she accesses the folder.  Her effective access to the folder is Full Control (1).  Allow permission entries, explicit or inherited are combined. In this scenario, Windows allows Alejandra Read permissions (Read & execute and Read) because she is a member of the Users group and because she is a member of the Marketing group.  However, Windows also allows her Full Control because she is a member of the Marketing group.  Windows grants the least restrictive access when evaluating multiple Apply permission entries.

The second user, Kim is a member of the Users group.  Permission entry two is the only applicable permission entry.  Therefore, her effective access to the folder is Read (2).

LocalEffectiveAccess

The last user to access the folder is Harvey.  Harvey is a member of the Marketing group.  Permission entry one and three apply to Harvey when he accesses the folder.  Permission entry one is applicable because the trustee is Harvey.  Permission entry three applies as well because Harvey is a member of the Users and Marketing group.  However, Windows orders the permission entries so that deny permission entries occur before allow permission entries.  In this scenario, permission entry one denies access.  The access denied by the permission entry is Full Control.  Based on permission entry order, Windows denies Harvey access to the folder.  Harvey’s membership in the Marketing group is irrelevant because the explicit deny permission entry has precedence over all other permission entries (3).

Effective Share Access Scenario

Understanding effective access to the file system is a prerequisite to under understanding effective access when accessing files through a shared folder. When accessing a shared folder, Windows considers the file permission entries and share permissions to determine a user’s effective access to the folder.

ShareAndNTFSPermissionsTable

Effective access through shares evaluates file and share permissions together.  First, you evaluate the effective file permission entries.  Then, you evaluate the effective file permissions with the share permissions.  Permissions entries common between the effective file permission entries and the share permissions become the effective access when accessing the share.  If the permission entry exists in the file permissions list or the share permission list, but not both; then, Windows does not grant the access to the user.

The permissions lists in the previous table reflect both file permission entries and share permissions.  The first user, Alejandra accesses a file through a shared folder.  Alejandra is a member of the users and Marketing group.  The last example determined her effective file system access was Full Control.

To determine effective access through the share, evaluate the share and file permission entries together. Permission entries common between both lists are applicable to the user. Permission entries that appear in one list or the other are not applicable. The share permissions provide Alejandra Full Control access (1). These permissions are the same as the effective file permissions. The permission entries common in both permission lists are equivalent to Full Control; therefore, Alejandra’s effective access using the shared folder is Full Control (2).

ShareEffectivePermissions

Next, Kim accesses the files through the shared folder.  Kim is a member of the users group.  The effective file system access for her is Read.  Users have Change permissions on the share (3).  Noticeably, the permissions between the two lists are not identical.  You must translate the share permission into basic permission to determine the permission entries in common between the two lists.

The previous table indicates the Change share permission is a combination of basic permissions.  Those permissions include Modify, Read & execute, Read, and Write.  The effective file system access Read includes the Read & execute, and Read basic permission entries.  A comparison of the two lists shows permission entries common between both lists are Read and execute, and Read.  Modify and write permissions entries exist only in the file permissions list.  Windows determines these permissions are not applicable to Kim because they do not exist in both lists, given Kim’s group membership.  This results in Kim’s effective access as Read when using the shared folder (4).

Lastly, Harvey accesses the file through the shared folder.  Harvey is a member of the users and Marketing group.  The last example identified that Harvey’s effective file access denied Full Control.  Again, you compare permission entries from the user’s file system effective permissions and the permission entries on the share that are applicable to the user (share permissions or permission entries where the principal is the user or a group of which the user is a member).

The share permissions list includes a permission entry that allows everyone Change access and another permission entry that allows Marketing Full Control access (5).  A deny permission entry wins against any allow permission entries except when the deny permission entry is inherited and the allow permission entry is explicit.   Therefore, Harvey’s effective share access is deny Full Control (6).  The Marketing group’s Full Control share permissions are not applicable because of the explicit deny.


That’s it for evaluating effective permissions when NTFS and when combining NTFS and shared permissions.  I’ll break out one more to complete the series, which will take into account Central Access Policies when using Dynamic Access Control.

–Mike Stephens

How Windows orders Access Control Entries

After watching a good friend of mine do an excellent job at teaching file and folder permissions for Windows,  I thought it would be a good idea to share an excerpt of the “Understanding and Troubleshooting Dynamic Access Control” white paper I wrote in February 2013, that serves as a great refresher for understanding how Windows orders access control entries.


It is good to understand how to determine effective access across multiple points of access control. To determine effective access you compare information from the access token against each point of access control (Central Access Policy, share permissions, and NTFS permissions). The result of this comparison is the user’s effective access. Predicting the effective access of a resource helps you plan and configure permissions for those resources.

Precedence and Canonical Ordering

Precedence

The Windows authorization sub system follows a set of rules that gives the appearance of preferring a permission entry type or access over a different permission entry type or access. However, the perception of precedence does not occur real-time— the rules of precedence are not enforced when the user access the resource. The permission entries are evaluated in order and access is allowed or disallowed based on that order. The Security settings or Advanced Security Settings editor accomplishes permission entry precedence by saving the permission entries in a specific order. The specific order in which permission entries are saved is known as canonical order.

Canonical Ordering

Canonical ordering describes the ordering the Security settings or Advanced Security Settings editor uses to ensure access to resources observes a defined behavior with regard to the permission entry’s lineage and access type.

Lineage

The permission entry’s lineage is the origin of the permission entry. Windows recognizes two types of permission entries that describe the permission entry’s lineage: explicit and inherited.

Explicit

Permission entries that originate on the current resource are known as explicit permissions. Explicit permission entries are permission entries that you manage directly on the file or folder. The Security Settings and Advanced Security Settings editor orders explicit permission entries to the top of the permission entry list. All explicit permission entries are ordered before any other permission entry type.

Inherited

Permission entries that originate higher in the resource’s lineage are known as inherited permissions. Inherited permission entries are explicit permission entries granted at some higher point in the resource’s hierarchy that propagate to the file or folders lower in the resource’s hierarchy. The Security Settings and Advanced Security Settings editor orders inherited permission entries after explicit permission entries.

Lineage order

Windows orders inherited permission entries in lineage order. Lineage order describes the order of inherited permissions where inherited permissions closest to the current folder are ordered before inherited permissions furthest from the current folder. Lineage ordering results in inherited permissions from the parent ordered before the grandparent. Inherited permissions from the grandparent are ordered before the great-grandparent. This ordering continues to traverse up the resource’s lineage until it reaches the end of the resource’s hierarchy or inheritance stops. Do not confuse lineage ordering with canonical ordering. Canonical ordering describes the entire ordering process Windows performs when saving permission and audit entries. Lineage ordering is a subset of canonical ordering that refers specifically to the way Windows orders inherited permissions based on position in the resource’s lineage.

Access Type

Windows recognizes two access types for permission entries: Deny and Allow.

Deny access types

Deny access type permissions disallow users from performing the access configured in the permission entry. Access configured in permission entries typically characterizes as specific action a user performed on the resource such as read, modify, or delete.

The Security Settings and Advanced Security Settings editors order deny permission entries before allow permission entries when saving permissions. This order ensures that Windows evaluates deny permission entries first followed by allow permission entries. This ordering is combined with lineage ordering, which results in explicit deny permission entries ordered before explicit allow permission entries.

Windows orders inherited deny permissions before inherited allow permission entries at each point of inheritance in the resource’s lineage. Therefore, inherited parent permission entries are ordered together (inherited deny and inherited allow), and then inherited grandparent permission entries are ordered together (inherited deny and inherited allow), after inherited parent permission entries.

Allow access types

Allow access type permissions permit users to perform the access configured in the permission entry. Access configured in permission entries typically characterizes as specific action a user performs on the resource such as read, modify, or delete.

The Security Settings and Advanced Security Settings editors order allow permission entries after deny permission entries when saving permissions. This order ensures that Windows evaluates deny permission entries first followed by allow permission entries. This order is combined with lineage ordering, which results in explicit deny permission entries

Results of Canonical Ordering

Canonical ordering of permission entries accomplishes gives the perception of precedence when a user accesses a file or folder. Windows uses this precedence to establish deterministic behaviors with regard to authorization decisions. Well-defined behaviors allow you to determine effective permissions of a resource manually, without using the Effective Access tab.

CononicalOrderingTable

Information from previous shows the order in which Windows saves permission entries. This order determines effective permissions based on how Windows handles each permission type (allow or deny).  In summary, conical ordering yields the ordering in the earlier table.  The ordering combined produces the following precedence you can use to determine effective permissions for a resource.

  • An explicit deny permission entry always denies access to a resource
  • An explicit allow permission entry permits access unless combined with an explicit deny permission entry, which then denies access to the resource.
  • An inherited deny permission entry disallows access unless combined with an explicit allow permission entry or an inherited allow permission entry that is closer in lineage to the resource than the inherited deny, which then permits access to the resource.
  • An inherited allow permission entry permits access unless combined with an explicit deny permission entry, or an inherited deny permission entry that is closer in lineage to the resource than the inherited allow, which then disallows access to the resource.

IMPORTANT
Windows canonically orders permission entries when saving the permission list. When Windows evaluate access to a resource, it evaluates each permission entry in list order.

ConaicalOrdering-ACL-Editor


The canonical ordering of access control entries is the heart of how IT professionals predict a user effective access to a resource. It is the reason why we have rules like “explicit wins over inherited” and many of the others phrases you hear when learning Windows access control.   As a follow up, be sure to read the “Evaluating Effective Access” post.

–Mike Stephens