The Basics of ACL Inheritance

A: ACL inheritance is a mechanism that lets container objects (e.g., a file system folder or an Active Directory (AD) organizational unit (OU)) pass access control information to their child objects. A container’s child objects can be non-container objects (e.g., a file or in AD a user or a computer object) as well as other container objects.

From an administrator point of view, ACL inheritance simplifies access control management. An administrator can set the ACL on a parent object and, if inheritance is enabled, he shouldn’t need to set ACLs on each child object.

From a software logic point of view, ACL inheritance makes access control evaluation much more complex. The software needs to consider multiple ACLs: not just an object’s proper ACLs (also known as explicit ACLs), but also all its inherited ACLs. Inherited ACLs can come from an object’s immediate parent, but also from parent objects that are higher up in the object hierarchy. Table 1 compares the ACL inheritance implementation in NT 4.0 versus the implementation in Windows 2000, Windows Server 2003, and Windows Server 2008. NT 4.0 clearly offers no or very limited means to control ACL inheritance. As in NT 4.0 and Win2K, Windows 2003 and Windows 2008 still use static ACL inheritance. Static inheritance means that an object inherits permissions from its parent object when the object is created and when the permissions on the parent object are changed. In NT 4.0, the administrator had to select “Replace Permissions on Subdirectories and Replace Permissions on Existing Files” in the NT4 Folder Permissions dialog box to apply permissions to child objects when they were changed at the parent object. The main concern with this approach was that all existing ACLs on subfolders and files, which may have had customized ACLs themselves, were overridden with the new ACLs set on the parent. Win2K and Windows 2003 will automatically update the child’s ACLs when an administrator changes a parent object’s ACLs and clicks Apply in the ACL editor.

Static inheritance obviously takes some storage space and processor power while the permissions are copied to all child objects. But the impact of this is almost negligible when compared to the impact of dynamic inheritance. With dynamic inheritance, which is, for example, used in Novell Netware Directory Services (NDS), each opening of an object requires not only checking of the explicit permissions on the object itself but also of the permissions of all its parent objects.

Another important difference is that Win2K and later OSs do not overwrite the child’s proper explicit Access Control Entries (ACEs) with the inherited parent ACEs. The OS simply adds inherited ACEs to the child’s ACLs and tags them with a special inherited flag. You can observe the presence of this flag in the advanced view of the ACL editor (as Figure 1 shows); inherited permissions cannot be viewed from the ACL editor’s basic view.

To stress the fact that inherited ACLs cannot be edited in the ACL editor of a child object, Microsoft grays out the key icons in the type column. Also, Microsoft added an explanatory text in the dialog box telling the user “this permission is inherited” and “you can edit the permission only at the parent object…”. The latter two features are only used in Win2K. In Windows 2003 and Windows 2008, these were replaced with an “Inherited From” column (as Figure 2 shows), showing from which parent object a child object inherits a particular permission.

In NT4, inherited permissions could be edited on the child object, because both the child object’s proper ACLs and the inherited ACLs were merged, making the inherited ACLs unrecognizable.

An interesting detail, from both an ACL inheritance and an AD replication point-of-view, is the way ACL changes on AD container objects are replicated in AD. Because AD is a multi-master database, ACL changes made on one instance of AD also need to be replicated to every other instance of the AD database. To limit the bandwidth impact, Microsoft only replicates the explicit permissions—and not the inherited permissions—between AD instances. This feature, combined with the static inheritance, means that when the permissions are evaluated on an AD child object, it should always have the latest ACL information—unless some permission change on another AD instance hasn’t yet replicated to the child object’s AD instance.

An important change in the way inherited ACEs are stored in AD in Windows 2003 and Windows 2008 is that starting with Windows 2003, Microsoft introduced Single-Instance storage for ACEs. Single-instance storage for ACEs basically means that child objects just contain a pointer to the inherited ACEs that are stored in the parent object’s explicit ACEs—the actual inherited ACEs are not copied to each child object.

Single-Instance Storage for ACEs significantly reduces the space required in the AD database for ACE storage. The internal HP AD, for example, shrank from 12GB down to 7GB when upgrading from Win2K to Windows 2003 DCs, because of this feature. You won’t be able to regain this disk space from an upgraded Win2K DC until you perform an offline database defragmentation (which requires booting each DC to Directory Services Restore Mode and starting the offline defrag\ using the NTDSUTIL tool).

Table 1: Comparing NT 4.0 and Windows 2003 Inheritance

NT 4.0	Windows 2000 Windows 2003 Windows 2008
Static inheritance	Static inheritance
ACL inheritance can be configured on file system objects	ACL inheritance can be configured on file system, registry, and AD objects
ACL inheritance can be enforced	ACL inheritance can be blocked and enforced
Inherited ACLs overwrite existing ACLs	Inherited ACLs do not overwrite existing ACLs
No way to remove inherited ACLs	ACLs can be removed from child objects
Inherited ACLs are not recognizable	ACLs are recognizable: they are displayed differently in the ACL editor

End of Article