Access control lists (acl) and access control entries (ace)
As mentioned earlier, an ACL contains a list of access control entries (ACEs). The maximum number of ACEs is not limited, but the size of the ACL is: it must not be larger than 64 KB. This may not seem much, but should in practice be more than sufficient.
ACEs come in three flavors:
- Access allowed ACE
- Access denied ACE
- System audit ACE
All three variants are similar and contain the following information:
- SID of a trustee to whom the ACE applies
- Access mask: the permissions to grant/deny/audit
- Inheritance flags: how to propagate the ACE’s settings down the tree
Each ACE constitutes a “rule” that defines how the system is supposed to react when an attempt is made to access the object. Each rule (ACE) applies to exactly one trustee. The type of access that is covered by the rule is specified in the access mask.
It is important to note that a trustee for whom no rule exists has no access whatsoever to an object.
Depending on the type of the ACE the bits stored in the access mask have a different meaning.
Capability sids
Windows 8 introduced capability SIDs. Windows 10 has several hundred of them. Capability SIDs are used to grant applications access to resources such as the camera, or the location (documentation).
Capability SIDs cannot be resolved to/from names, they are displayed as SID strings in permission listings. Windows ACL Editor cannot add capability SIDs, it can only delete them. To add them back use SetACL, specifying the SID string as trustee name.
Control information
The control information of an SD contains various bit flags, of which the two most important bits specify whether the DACL respectively SACL are protected. If an ACL is protected, it does not inherit permissions from its parent. Inheritance is discussed in more detail later.
Inheritance
In Windows 2000 the security model was supplemented with the concept of inheritance. Each ACE has inheritance flags that control how the ACE is to be propagated to child objects. The most common case is full inheritance: child objects inherit all ACEs from their parent and have therefore identical resulting permissions and auditing settings.
It is important to note here that an ACE that has been inherited from a parent is marked as being inherited, and cannot be modified on the child object! By means of this mark (or flag) the system is able to tell whether an ACE is set directly on the object or whether it has been inherited from a parent.
Inheritance flags
It is, of course, possible to specify exactly how an ACE is to be inherited by its children. The following inheritance flags can be used individually or in any combination:
- container inherit: child containers (e.g. directories) inherit the ACE
- object inherit: child objects (e.g. files) inherit the ACE
- inherit only: the ACE does not apply to the object itself, but can be inherited by children
- no propagation: the ACE may not be inherited by children
The settings available in Windows ACL Editor (see below) correspond to the following combinations:
- This folder only: no propagation
- This folder, subfolders and files: container inherit object inherit
- This folder and subfolders: container inherit
- This folder and files: object inherit
- Subfolders and files only: container inherit object inherit inherit only
- Subfolders only: container inherit inherit only
- Files only: object inherit inherit only
Now that i know about all this, what do i do with all the knowledge?
If you are looking for a powerful tool to manipulate all the stuff described here, check out my free tools SetACL Studio (GUI) and SetACL (command line).
Primary group
The primary group of an object is rarely used. Most services and applications ignore this property.
Privileges and rights
Privileges, or rights, as they are often called, are very different from permissions. A privilege allows the exertion of permissions (the right to log on makes it possible to access those files you have permissions for). Privileges are configured in the local security policy or a domain Group Policy object. Three privileges are noteworthy in this context:
| Privilege Name | Description |
|---|---|
| SeSecurityPrivilege | Read and write access to all SACLs |
| SeBackupPrivilege | Circumvent NTFS permissions and read (back up) every file and every folder |
| SeRestorePrivilege | Circumvent NTFS permissions and write (restore) every file and every folder |
| SeTakeOwnershipPrivilege | Set the owner of any securable object |
Securable objects
Among many others, the following object types are securable:
- Files and directories on NTFS volumes
- Registry keys (but not values)
- Network shares
- Printers
- Services
- Active Directory objects
- Processes
Of these types, some are hierarchical in nature (directories, registry keys, …), and some are not (printers, services, …).
Sid to name lookup
It is important to remember that trustees referenced in SDs are always stored as binary SIDs. This is true for the owner, the primary group, and any trustee in any access control list (ACL). This implies that there exists some mechanism that converts trustee names into SIDs and vice versa.
This mechanism is a central part of the security accounts manager (SAM) and of Active Directory (AD). The former manages the local account database on any NT-based system (Windows NT right up to Windows 10, including the server variants). The latter is only available on Active Directory domain controllers where it replaces the SAM.
What is a security descriptor (sd)?
A security descriptor is a binary data structure that contains all information related to access control for a specific object. An SD may contain the following information:
- The owner of the object
- The primary group of the object (rarely used)
- The discretionary access control list (DACL)
- The system access control list (SACL)
- Control information
Windows acl editor
The GUI provided by Windows to manipulate SDs is called ACL Editor. It can be accessed by right-clicking a file and choosing Properties > Security. I am not going to describe ACL Editor in detail, but rather point out some of its features and peculiarities.
Встроенные командлеты для управления acl в ntfs: get-acl и set-acl
В PowerShell v5 (Windows 10 / Windows Server 2022) для управления ACL имеется два отдельных встроенных командлета (входят в модуль Microsoft.PowerShell.Security):
- Get-Acl — позволяет получить текущие ACL для конкретного объекта на файловой системе NTFS;
- Set-Acl – используется для добавления/изменения текущих ACL объекта.
Мы не будем подробно останавливаться на этих встроенных командлетах, т.к. их функционал в большинстве случае недостаточен для управления NTFS разрешениями в реальных задачах. Рассмотрим лишь несколько типовых примеров их использования.
Выведем текущего владельца папки (файла) и список назначенных NTFS разрешений:
get-acl C:Drivers |fl
Проверка эффективных ntfs разрешений на объекты из powershell
Вы можете проверить эффективные NTFS разрешения на конкретный файл или папку с помощью командлета
Get-EffectiveAccess
. Допустим вы предоставили доступ на некоторую папку нескольким группам безопасности AD и теперь хотите понять, есть ли у конкретного аккаунта (SID) доступ к данной папке или нет.
Как это сделать, не выводя состав групп AD, в которых входит его учетная запись? В этой ситуации как раз поможет функция проверки эффективные NTFS разрешений. Допустим, нужно проверить эффективные права на все вложенные папки в каталоге для пользователя confroom.
Get-ChildItem -Path c:distr -Recurse -Directory | Get-NTFSEffectiveAccess -Account ‘WORKSTAT1confroom’ | select Account, AccessControlType, AccessRights, FullName
Либо вы можете проверить эффективные разрешения на конкретный файл:
Get-Item -Path ‘C:distrmstsc.exe.manifest’ | Get-NTFSEffectiveAccess -Account ‘WORKSTAT1confroom’ | Format-List
