Home > Storage > PowerScale (Isilon) > Product Documentation > Security and Compliance > Access Control Lists on Dell EMC PowerScale OneFS > ACL on Windows NTFS and SMB
Windows has an access-control model that determines who can access resources in the operating system. Windows applications call access control functions to set who can access specific resources, or to control access to resources provided by the application. See the Microsoft article on Access Control for more details.
An ACL is a key part of the Windows access model. In Windows, ACLs can provide access control to an Active Directory service object. Routines for ACL creation and modification of ACLs are included in Active Directory Service Interfaces (ADSI). The Windows ACL can also provide access control to NTFS file system objects, and the ACLs associated with these file system objects can be managed through Windows Explorer and the command-line tool.
Because SMB is designed for the Windows environment, the SMB ACL is compatible and has the same concepts and definitions as the Windows NTFS ACL. This section discusses the Windows NTFS ACL to show how ACL technology is designed and implemented on the Windows platform.
A security descriptor contains the security information associated with a file system object, including the owner and primary group, DACL, and SACL of an object.
Run the get-acl PowerShell cmdlet to view the security descriptor of a file-system object.
Figure 39 displays the following details:
A Windows security descriptor contains two types of ACLs (DACL and SACL) for a file system object.
The ACE is an element in an ACL, and an ACL can have zero or more ACEs. Each ACE controls access to a file-system object by a specified user or group. There are two types of ACEs in a DACL: the first is the access-allow ACE and the second is the access-deny ACE, and both contain the following information:
ACE inheritance
An ACE can be explicitly set on an object or it can be inherited. Inheritance allows permissions to be layered or overridden as needed in an object hierarchy and allows for simplified permission management.
There are five flags to indicate ACE inheritance. An ACE only applies to the current file or directory if no ACE inheritance flag is specified. Table 13 shows the five ACE inheritance flags and meanings.
ACE inheritance flag keyword | Flag set on file or directory | Description |
(OI) Object inherit | Directory only | Indicates that an ACE applies to a current directory and files within the directory |
(CI) Container inherit | Directory only | Indicates that an ACE applies to a current directory and subdirectories within the directory |
(IO) Inherit only | Directory only | Indicates that an ACE applies to subdirectories only, files only, or both within the directory |
(NP) No propagate inherit | Directory only | Indicates that an ACE applies to the current directory, only the first-level contents of the directory, or both, but not to the second-level or subsequent contents |
(I) Inherited | File or directory | Indicates that an ACE is inherited from the parent directory |
Windows Explorer provides a UI to configure ACE inheritance, as highlighted in Figure 40. To access the UI, right-click a directory and click Properties > Security > Advanced > Permissions > Add.
Table 14 shows the relationship between each UI option and the exact flags contained.
Windows Explorer UI option | Contained ACE inheritance flags |
This folder only | No flags, an ACE applies only to the current directory |
This folder, subfolders, and files | (OI) (CI) |
This folder and subfolders | (CI) |
This folder and files | (OI) |
Subfolders and files only | (OI) (CI) (IO) |
Subfolders only | (CI) (IO) |
Files only | (OI) (IO) |
Only applies these permissions to objects, containers within this container, or both | (NP) |
Order of ACEs in a DACL
When users or groups access a file-system object, the system iterates through the ACEs in the object's DACL until it finds ACEs that allow or deny the requested access.
The access rights that a DACL allows a user could vary depending on the order of ACEs in the DACL. In Windows, a specific ordering of ACEs (a canonical ordering) is enforced. The ordering impacts how permissions are applied, and the rules for ordering are as follows:
Access rights
An access right corresponds to a set of operations that a user or group can have on a file-system object. The Windows DACL can be associated with many different Windows system objects, not just files and directories.
Table 15 to Table 17 show Windows NTFS access rights and their associated options in the Windows Explorer UI. To access this UI, right-click a directory and click Properties > Security > Advanced > Permissions > Add.
Constant | Keyword | Windows Explorer UI option | Description |
GENERIC_ALL | GA | Full control | All possible access rights; maps to Full Control (F) |
GENERIC_EXECUTE | GE | N/A | Execute access; maps to RC, S, X, RA |
GENERIC_READ | GR | Read | Read access (R); contains permissions RD, RC, RA, REA |
GENERIC_WRITE | GW | Write | Write access (W); contains permissions WD, AD, WA, WEA |
Constant | Keyword | Windows Explorer UI option | Description |
DELETE | DE | Delete | The right to delete the object |
READ_CONTROL | RC | Read permissions | The right to read the information in the object's security descriptor, not including the information in the system access control list (SACL); Read permissions |
SYNCHRONIZE | S | N/A | The right to use the object for synchronization, which enables a thread to wait until the object is in the signaled state; some object types do not support this access right |
WRITE_DAC | WDAC | Change permissions | The right to modify the discretionary access control list (DACL) in the object's security descriptor; change permissions |
WRITE_OWNER | WO | Take ownership | The right to change the owner in the object's security descriptor. Take ownership. |
Constant | Keyword | Windows Explorer UI option | Description |
FILE_READ_DATA | RD | Read data | The right to read data from the file |
FILE_LIST_DIRECTORY | List folder | The right to list the contents of a directory | |
FILE_WRITE_DATA | WD | Write data | The right to write data to the file |
FILE_ADD_FILE | Create files | The right to create a file in a directory | |
FILE_APPEND_DATA | AD | Append data | The right to append data to the file. |
FILE_ADD_SUBDIRECTORY | Create folders | The right to create a subdirectory in a directory | |
FILE_READ_EA | REA | Read extended attributes | The right to read extended attributes |
FILE_WRITE_EA | WEA | Write extended attributes | The right to write extended attributes |
FILE_EXECUTE | X | Execute file | The right to execute a file |
FILE_TRAVERSE | Traverse folder | The right to traverse a directory | |
FILE_DELETE_CHILD | DC | Delete subfolders and files | The right to delete a directory and all the files it contains (its children), even if the files are read-only |
FILE_READ_ATTRIBUTES | RA | Read attributes | The right to read file attributes |
FILE_WRITE_ATTRIBUTES | WA | Write attributes | The right to change file attributes |
Windows Explorer UI basic and advanced permissions mapping
For the convenience of routine permissions management, Windows defines several basic permissions that contain a set of individual advanced permissions. To view these options through the Windows Explorer UI, right-click a file and click Properties > Security > Advanced > Permissions > Add. Table 18 shows the mapping between the permissions.
Advanced permissions | Basic permissions | ||||
Full control | Modify | Read and execute | Read | Write | |
Traverse folder/ execute file | | | |
|
|
List folder/read data | | | | |
|
Read attributes | | | | |
|
Read extended attributes | | | | |
|
Create files/write data | | |
|
| |
Create folders/append data | | |
|
| |
Write attributes | | |
|
| |
Write extended attributes | | |
|
| |
Delete subfolders and files | |
|
|
|
|
Delete | | |
|
|
|
Read permissions | | | | |
|
Change permissions | |
|
|
|
|
Take ownership | |
|
|
|
|
Synchronous | | | | | |
The following examples use the Windows Explorer UI to set permissions and the icacls command-line tool to check the exact permissions applied.
Example 1: Windows NTFS ACL’s ACE inheritance
This example removes all inherited ACEs from the top-folder and adds four new ACEs, shown in Figure 41 Error! Reference source not found. The following ACEs are added:
Use the iscacls command to check the inheritance flags on the folder’s ACL, as shown in Figure 42:
Now, verify the ACE inheritance on the first-level folder and second-level folder under the top-folder.
As Figure 43 shows, ACE 1 is not inherited to the folder-level-1. The rest of ACEs are inherited as expected.
As Figure 44 shows, ACE 1 is not inherited to the folder-level-2 and ACE 3 is also not inherited because it is applied a (NP) flag on top-folder. The rest of ACEs are inherited as expected.
Example 2: Order of ACEs in a DACL
Add access-allow ACEs and access-deny ACEs on both top-folder and folder-level-1 as shown in Figure 45
As mentioned in section A.1.1, the order of ACEs on folder-level-2 is as expected. Shown in Figure 46, a group of all the explicit ACEs (highlighted in red) are placed before any other inherited ACEs, and then a group of ACEs (highlighted in blue) inherited from the parent folder folder-level-1 come first, then ACEs (highlighted in yellow) are inherited from the grandparent folder top-folder. Meanwhile, in each group of ACEs, access-deny ACEs are always placed before access-allow ACEs.