Windows Permissions - Access Control Lists
Originally published February 12, 2007
Recently, the question was posed on a mailing list: What does it mean 'Propagate inheritable permissions to all subfolders and files' when you change file permissions with GPO?
Key to answering this question is understanding the Windows NT Security Descriptor. To work with any types of permissions in modern Windows operating systems, you need to understand this. So, below you will find the answer I wrote. It applies equally well to file system security descriptors and to Exchange object security descriptors.
========================================================
I kept thinking Bob would pop in here and detail the response to this. But he didn't....so, lots of background is required to answer the question in full:
Allain Lissoir's books cover this, as does the "NT Bible" -- "Inside Windows NT" by Helen Custer and David Solomon.
Every securable object is assigned a SD (security descriptor) when it is created by Windows. This doesn't matter if it's an object in A/D, a file on an NTFS disk, an Exchange mailbox, or whatever - in NT it gets a SD.
A SD includes, among other things, the owner's SID and the DACL (Discretionary Access Control List). The DACL, like any ACL, is made up of zero or more entries called ACEs - Access Control Entries.
If there are ZERO entries in the ACL, then there is an implied ACE called the Creator/Owner ACE that gives Full Control to an access token with a SID that matches the owner's SID and no access to any other access token. (This was a change from NT 4 and betas of 2000 - they gave no access to ANYONE in this situation.)
Each ACE is either explicit or inherited. An explicit ACE has been defined on this object and on this object only. An inherited ACE was set by the parent object AND COPIED TO THIS OBJECT (more on this later).
Each ACE is also either ALLOW or DENY. Each ACE also defines HOW it applies (this object, this object and all subobjects, all subobjects, etc.). ACEs are processed in the order in which they are contained in the ACL. The first ACE that applies, wins. This requires that ACEs are placed in a VERY specific order within the ACL:
1) Explicit ACEs
a) access DENY for object
b) access DENY for subobjects
c) access ALLOW for object
d) access ALLOW for subobjects
2) Inherited ACEs
a) access DENY for object
b) access DENY for subobjects
c) access ALLOW for object
d) access ALLOW for subobjects
This leads up to 8 possible "buckets" of permission for any object access. Evaluating this on each object access would be extraordinarily expensive. Thus, access is evaluated when an object is opened. If a DACL changes after an object is opened, the change does not apply to the already opened object. (This is why, for example, you must log out of your workstation in order to for new security groups to be added to your domain access token.)
If you have a good memory you may remember that right after Windows 2000 was released and again right after Exchange 2000 was released, ADUC would often report that "Access Control Entries are mis-matched. Should I correct?" That's why - ACEs weren't in the right order (prior to NT 4, NT 4 didn't enforce this - so poorly behaved programs [including Exchange 5.5] would sometimes get the sort-order wrong).
Exchange has had issues with permissioning forever (and they continue, in my mind, into current service packs of Exchange 2003 and 2007). Regardless, that's beside the point of this discussion.
Two more facts you need to know, to be able to answer questions like this with confidence:
1) NTFS is a transaction-based filesystem, just like MS-SQL, just like Exchange, etc. This means that if the system crashes, or power faults, etc. during an update operation, or any number of safe-guarded update operations, then the changes will roll back out and the filesystem will still be stable.
2) When designing a hierarchical permission system you have a choice about how to deal with inherited permissions - you either require that every object open check every object up to the root to determine what permissions are inherited (which is what NetWare and HPFS do) or you require a copy of those permissions to exist on every object in the hierarchy (which is what NTFS does). Both methods have their advantages and disadvantages.
So, with all that background you can fully answer the question.
Propagate inheritable permissions to all sub-folders and files means that you will copy all relevant permissions from a parent object to all children. The standard GUI does this with a "replace" operation (i.e., all old ACEs are removed and copies are made and marked "inherited" for all new ACEs). Other tools (CACLS, iCACLS, XCACLS, SUBINACL) allow you to do this in a more intelligent way (e.g., only add a particular ACE).
You can always (assuming you have permission to write security properties on a object) adjust the permissions on an object that has inherited permissions. You must go to the "Advanced" tab of the GUI to see the order in which they are actually applied. The standard dialog merges all the permissions in the display.
From the advanced tab of the GUI and applying the hierarchy I've described above, you can evaluate the resultant permission quite easily.
Normally, things aren't this complicated of course. :-)