Права доступа windows acl

ЦЕЛИ КУРСА

После прохождения этого курса вы получите следующие умения:

1. Понимание основных принципов использования Windows ACL с вашим ASUSTOR NAS.
2. Использовать Windows ACL для управления правами доступа к данным в вашем ASUSTOR NAS.

ПРЕДВАРИТЕЛЬНЫЕ УСЛОВИЯ

Предварительные условия курса:

NAS 106: Работа с NAS в Microsoft Windows

Слушатели должны получить следующие практические знания:

Общие папки, Управление доступом

ПЛАН КУРСА

1. Введение в Windows ACL

1.1 Должен ли я включить Windows ACL?

2. Конфигурирование Windows ACL

2.1 Включение Windows ACL

2.2 Настройка разрешений Windows ACL с Файловый менеджер ADM

2.3 Настройка разрешений Windows ACL с Проводником Windows

2.4 Правила разрешений и меры предосторожности Windows ACL

2.5 Перемещение объектов в ваш NAS с одновременным поддержанием разрешений ACL

1. Введение в Windows ACL

Windows ACL – это 13 разных типов прав доступа к файлам, разработанных Microsoft для файловых систем NTFS, которые могут быть применены к определенным пользователям и группам. В рамках этого типа инфраструктуры администраторы могут создавать более подробные и точные конфигурации прав доступа.

Кроме того, в доменной инфраструктуре AD Windows (широко используемой предприятиями), права доступа Windows ACL могут быть применены для всех пользователей и групп в домене. Пользователи для входа могут использовать любой компьютер в сети, и до тех пор, пока они используют одно и то же имя учетной записи, все права остаются прежними. ИТ-персоналу не нужно настраивать разрешения для каждого отдельного сервера и рабочей станции ПК, что существенно повышает эффективность управления.

Для того, чтобы более тесно интегрировать ASUSTOR NAS с доменами AD, упрощая управление ИТ и повышая производительность, ASUSTOR глубоко интегрировал систему разрешений Windows ACL с ADM, предоставляя следующие уникальные характеристики:

1. Возможность включить Windows ACL для отдельных общих папок.
2. Комплексная поддержка всех 13 типов разрешений Windows ACL.
3. Возможность просматривать действующие разрешения Windows ACL внутри ADM в деталях.
4. Поддержка сетевых пользователей и групп.
5. Возможность применить разрешения ACL к протоколам передачи файлов Samba, Файловый Менеджер, AFP, FTP, WebDAV, Rsync.

1.1 Должен ли я включить Windows ACL?

Как описано в предыдущем разделе, Windows ACL предоставляет до 13 различных настроек разрешений, которые могут быть применены ко всем пользователям и группам на NAS и на домене (если NAS была добавлена к домену Windows AD). В случае неправильного планирования или конфигурации разрешений существует вероятность того, что никто из пользователей не сможет получить доступ к определенной папке или файлу. Очевидно, этот тип ошибки может быть решен с помощью использования учетной записи администратора, но количество потраченного времени от момента возникновения до момента решения может быть рассмотрено как существенная нематериальная стоимость для предприятий.

ASUSTOR NAS разработан на основе операционной системы Linux, поэтому собственные настройки ADM используют механизм управления разрешениями Linux:

• Применимые разрешения: RW (Чтение и Запись), RO (Только чтение), DA (Запретить доступ)
• Разрешения могут быть применимы к: “Владельцу”, группе, где владелец является частью, и “Другие”.

Меньшее количество опций позволяет более простые конфигурации. Тем не менее гибкость и регулируемость разрешений очень ограничена. Например, при использовании механизма разрешений Linux нет возможности дать пользователю способность редактировать файл, при этом не давая им разрешение на удаление файла.

Если вы используете ваш NAS только между собой и ограниченным числом семьи и друзей, то рекомендуется использовать исходный механизм управления разрешениями ADM. Однако, если ваш NAS используется для хранения бизнес-данных предприятия, рекомендуется сначала проконсультироваться с вашим ИТ-персоналом, чтобы решить, уместно-ли включить разрешения для Windows ACL, и затем исполнить план развертывания разрешений, если вы решили его использовать.

Мы обеспечили вас гибкостью включения или отключения Windows ACL для отдельных общих папок, что очень полезно при оценивании и планировании. Вы можете создать общую папку для тестирования, включить Windows ACL, и затем настроить параметры разрешений. После этого вы можете проверить, отвечают ли результаты вашим ожиданиям. Как только вы получили требующиеся вам результаты, вы можете применить настройки к выбранной вами общей папке. Это позволит вам избежать каких-либо ошибок в планировании, что могут закрыть доступ к важным данным, и, таким образом, повлиять на работу вашего предприятия.

2. Конфигурирование Windows ACL

2.1 Включение Windows ACL

Создание новой общей папки:

• Войдите в ADM под учетной записью администратора с помощью веб-браузера.
• Выберите Общие папки в разделе Управление доступом.
• Нажмите Добавить.

Картинка с сайта: www.asustor.com

• Введите имя для новой папки. Нажмите [Далее].

Картинка с сайта: www.asustor.com

• После настройки прав доступа к общей папке отметьте галочкой [Включить Windows ACL] и нажмите [Далее].

  Примечание: Права доступа к общей папке — это первый слой проверки разрешений. Если пользователю или группе не были здесь даны разрешения «Чтение & Запись», то любые назначенные им права доступа для Windows ACL будут заблокированы. Поэтому рекомендуется в начале настроить более мягкие права доступа к общим папкам, имеющим включенный Windows ACL, и затем позднее использовать Windows ACL для дальнейшей настройки более конкретных разрешений.

Картинка с сайта: www.asustor.com

• Выберите [Пропустить] и нажмите [Далее].

Картинка с сайта: www.asustor.com

• Подтвердите настройки и нажмите [Завершить].

Картинка с сайта: www.asustor.com

Включение Windows ACL для уже существующих общих папок:

• Выберите Общие папки в разделе Управление доступом.
• Выберите общую папку, для которой необходимо включить Windows ACL, а затем нажмите [Редактировать]..

Картинка с сайта: www.asustor.com

• Выберите [Windows ACL].
• Выберите [Включить Windows ACL], а затем нажмите [Закрыть].

Картинка с сайта: www.asustor.com

2.2 Настройка разрешений Windows ACL с Файловый менеджер ADM

• На рабочем столе ADM выберите [Файловый менеджер].
• Выберите общую папку (или подпапку или файл) для которой вы включили Windows ACL. Нажмите правую кнопку мышки и выберите [Параметры].

Картинка с сайта: www.asustor.com

• Из окна параметров выберите вкладку [Права доступа]. Здесь вы сможете увидеть разрешения для папки, настроенные в настоящее время. Также, здесь можно управлять разрешениями для папки.

Картинка с сайта: www.asustor.com

После включения Windows ACL для общей папки система по умолчанию выдаст разрешение “Чтение и Запись, но нельзя Удалить” для учетных записей “Everyone”, “администраторов” и “admin”. Эти разрешения будут применяться только к общей папке и не будут наследоваться объектами ниже. Эти разрешения, установленные по умолчанию, могут быть изменены с помощью кнопки [Редактировать] или [Удалить].

Примечание: Отдельным файлом или папкой используется не более 250 разрешений Windows ACL (включая унаследованные разрешения).

• Включить разрешения, наследуемые от родителя этого объекта:
  Эта опция включена по умолчанию. Система будет автоматически настраивать подпапки и файлы, чтобы унаследовать разрешения от вышестоящего объекта. Отключение этой опции отвергнет все наследуемые разрешения и сохранит только вновь добавленные разрешения.
• Заменить все разрешения дочернего объекта на наследованные разрешения от данного объекта:
  Включение этой опции заменит все разрешения подпапок и файлов на те, что исходят от родительского объекта.

Вы сможете использовать следующие функции управления:

Добавить:

• Нажмите кнопку [Добавить], чтобы создать новое разрешение для объекта.

Картинка с сайта: www.asustor.com

• Пользователь или группа:
  указать пользователя или группу, по отношению к которым вы хотите применить разрешение.

Картинка с сайта: www.asustor.com

Картинка с сайта: www.asustor.com

Картинка с сайта: www.asustor.com

• Тип:
  Выберите [Разрешить] или [Запретить], чтобы предоставить или запретить разрешение пользователю или группе.
• Применить к:
  Эта опция появится только при добавлении разрешений к папке. Из выпадающего меню вы можете выбрать, где будет применяться разрешение. Способ, по которому будет применяться разрешение, определится тем, отметите-ли вы галочкой [Эти разрешения применяются только к объектам и (или) контейнерам, которые находятся внутри контейнера], или нет.
• Эти разрешения применяются только к объектам и (или) контейнерам, которые находятся внутри контейнера:
  • Когда параметр не отмечен:
    

    Применить к	Применить разрешение к данной папке	Применить разрешение к подпапкам в данной папке	Применить разрешение к файлам в данной папке	Применить разрешение ко всем последующим подпапкам	Применить разрешение к файлам во всех последующих подпапках
    Только данная папка
    Данная папка, подпапки и файлы
    Данная папка и подпапки
    Данная папка и файлы
    Только подпапки и файлы
    Только подпапки
    Только файлы

  • Когда опция отмечена:
    

    Применить к	Применить разрешение к данной папке	Применить разрешение к подпапкам в данной папке	Применить разрешение к файлам в данной папке	Применить разрешение ко всем последующим подпапкам	Применить разрешение к файлам во всех последующих подпапках
    Только данная папка
    Данная папка, подпапки и файлы
    Данная папка и подпапки
    Данная папка и файлы
    Только подпапки и файлы
    Только подпапки
    Только файлы

Редактировать:

• Выбрав разрешение и затем нажав кнопку [Редактировать], вы сможете его модифицировать.

Картинка с сайта: www.asustor.com

Картинка с сайта: www.asustor.com

Удалить:

• Выбрав разрешение и затем нажав на кнопку [Удалить], вы удалите разрешение от данного объекта.

Действующие разрешения:

• При нажатии на кнопку [Действующие разрешения], и затем выбрав пользователя из списка, вы сможете просматривать эффективные разрешения пользователя по отношению к указанной папке или файлу. Действующие разрешения определяются комбинацией разрешений Windows ACL и правами доступа к общей папке.

Картинка с сайта: www.asustor.com

2.3 Настройка разрешений Windows ACL с Проводником Windows

Во-первых, используйте учетную запись администратора для отображения включенной общей папки под управлением Windows ACL в качестве сетевого диска. Для дальнейшей информации, пожалуйста, обратитесь к курсу NAS 106: Работа с NAS в Microsoft Windows.

Картинка с сайта: www.asustor.com

• Нажмите правую кнопку мышки на любой файл или подпапку внутри общей папки и затем выберите [Параметры].

Картинка с сайта: www.asustor.com

• Выберите вкладку [Безопасность]. Здесь вы сможете увидеть список пользователей и групп пользователей и их права доступа ACL для файла или подпапки.

Картинка с сайта: www.asustor.com

Если объект одновременно унаследовал разрешения от своего родителя и также явные разрешения, унаследованные разрешения будут выведены серым цветом, в то время, как явные разрешения будут выведены черным цветом.

• Нажмите [Редактировать] [Добавить].

Картинка с сайта: www.asustor.com

• В поле [Из этой локации:] вы должны увидеть следующую информацию:
  • Если NAS был добавлен к домену Windows AD, вы увидите имя домена AD.
  • Если NAS не был добавлен к домену Windows AD, вы увидите IP адрес NAS.

Картинка с сайта: www.asustor.com

• В поле [Введите имена объектов для выбора] введите следующую информацию:
  • Если NAS был добавлен в домен Windows AD, введите имя пользователя или группы пользователей домена и затем нажмите [Проверить имена] для того, чтобы подтвердить имя пользователя/группы. Затем нажмите [OK].
  • Если NAS не был добавлен в домен Windows AD, введите имя локального пользователя или группы ADM и затем нажмите [Проверить имена] для того, чтобы подтвердить имя пользователя/группы. Затем нажмите [OK].

Картинка с сайта: www.asustor.com

• Теперь вы можете увидеть вновь добавленного пользователя или группу в списке [Group or user names:]. Выберите пользователя или группу, и затем используйте флажки [Разрешить] и [Запретить] для настройки их прав доступа на данный объект. По завершении нажмите [Применить].

Картинка с сайта: www.asustor.com

2.4 Правила разрешений и меры предосторожности Windows ACL

Конфликтующие разрешения ACL:

• Если вы столкнулись с конфликтующими разрешениями Windows ACL, приоритет будет отдан явным разрешениям объекта. Например, если пользователь «testuser» наследует разрешения «Разрешить чтение и выполнение» для файла, но заданные явные разрешения для файла «Запретить чтение и выполнение», то «testuser» не сможет получить доступ к файлу.
• И наоборот, если «testuser» наследует разрешение «Запретить Чтение», но явным разрешением, данным для файла, является «Разрешить чтение», то «testuser» сможет получить доступ к файлу.

Картинка с сайта: www.asustor.com

Картинка с сайта: www.asustor.com

Правила перемещения файлов и папок:

Исключения: Когда данные удалены из общей папки с включенным ACL и перемещены в сетевую корзину, правила из «B3» в приведенной выше таблице не будут применяться. Это сделано для предотвращения ситуации, когда файлы с разрешением «Запретить доступ» могут быть удалены и перемещены в сетевую корзину, и затем стать полностью доступными для всех пользователей. Принимая во внимание конфиденциальность и безопасность, файлам, перемещенным в сетевую корзину из папки с включенным ACL, будет присвоено разрешение «Чтение и запись для владельцев, запретить доступ для всех других пользователей».

Разрешения удаления файлов:

Есть 2 разрешения, связанные с удалением файлов:

1. Пользователь имеет явное разрешение «Удалить» для файла.
2. Пользователь имеет разрешение «Удалить подпапки и файлы» для родительской папки файла.

Если какое-либо из вышеуказанных разрешений настроено как «Запретить», то пользователь не сможет удалить файл. Только если ни одно из вышеуказанных разрешений был сконфигурировано как «Запретить», и по крайней мере одно из них был сконфигурировано как «Разрешить», то пользователь сможет удалить файл.

Права Доступа объектов:

После того как Windows ACL включен для папки общего доступа, каждый объект (подпапки и файлы), содержащийся в папке, также будет иметь право доступа.

• Для того, чтобы увидеть права доступа к объекту, выберите его из Файлового Менеджера ADM, нажмите правую кнопку мышки и выберите [Параметры]. Там будет ссылка для редактирования в секции [Права доступа к общей папке] во вкладке [Общие сведения].

Картинка с сайта: www.asustor.com

Картинка с сайта: www.asustor.com

Человек, имеющий право доступа, сможет настраивать разрешения ACL. Например, пользователь admin в приведенном выше рисунке, является владельцем папки ACL_Test. Поэтому admin сможет настраивать разрешения ACL для папки и подпапки, и файлов, содержащихся в нем.
Для каждого вновь добавленного объекта права доступа для создателя объекта будет установлены по умолчанию. Кроме того, пользователи в группе администраторов смогут менять права доступа. Например, если мы хотели передать право владения папки ACL_Test другим пользователям (то есть, testuser), то admin и все пользователи в группе администратора будут иметь способность передавать право собственности. Как только testuser становится владельцем папки ACL_Test, он будет иметь возможность перенастраивать разрешения для подпапок и файлов, даже если первоначально она не имела права доступа к ним.

Картинка с сайта: www.asustor.com

2.5 Перемещение объектов в ваш NAS с одновременным поддержанием разрешений ACL

В момент, когда все ПК с ОС Windows и устройства NAS в сетевой среде были добавлены к тому же домену Windows AD, все учетные записи пользователей и разрешения к домену могут быть объединены вместе. Тем не менее, при перемещении файлов или папок с сервера ПК на NAS существующие разрешения ACL не будут сохранены (используя правила из предыдущего раздела). Это заставит ИТ-персонал перенастроить разрешения.

Если вы хотите сохранить существующие разрешения ACL при перемещении файлов или папок на NAS, вы можете воспользоваться Fastcopy–сторонним програмным обеспечением. В примере ниже показано, как пользоваться FastCopy.

• Во-первых, используйте учетную запись администратора для отображения включенной общей папки под управлением Windows ACL в качестве сетевого диска. Для дальнейшей информации, пожалуйста, обратитесь к курсу NAS 106: Работа с NAS в Microsoft Windows.

Картинка с сайта: www.asustor.com

• Откройте FastCopy.
• [Source]: Укажите исходную папку здесь.
• [DestDir]: Укажите здесь папку назначения (сетевой диск, отображенный на предыдущем шаге).
• Отметьте галочкой [ACL], чтобы гарантировать, что FastCopy сохранит исходные разрешения ACL ваших файлов при их перемещении.
• Нажмите [Execute], чтобы начать перемещение папки.

Картинка с сайта: www.asustor.com

• После того, как папка была успешно перемещена, все данные, перемещенные в место назначения, сохранят свои разрешения ACL от источника (включая все явные и наследуемые разрешения). Эти данные не будут наследовать разрешения от родительского объекта в источнике.

Картинка с сайта: www.asustor.com

Картинка с сайта: www.asustor.com

Пройти тест

Для управления доступом к файлам и папкам в Windows на каждый объект файловой системы NTFS (каталог или файл) назначается специальный ACL (Access Control List, список контроля доступа). В ACL объекта задаются доступные операции (разрешения), которые может совершать с этим объектом пользователь и/или группы . В большинстве случаев администраторы Window для управления NFTS разрешениями на файлы и папки используют графический интерфейс File Explorer (свойства папки/файла -> вкладка Security/Безопасность) или консольную утилиту icacls. В этой статье мы рассмотрим способы управления разрешениями на объекты файловой системы NTFS из PowerShell. Вы можете использовать эти команды в скриптах и для автоматизации управлением NTFS разрешениями на файловых серверах Windows.

Картинка с сайта: winitpro.ru

Встроенные командлеты для управления ACL в NTFS: Get-Acl и Set-Acl

В PowerShell v5 (Windows 10 / Windows Server 2016) для управления ACL имеется два отдельных встроенных командлета (входят в модуль Microsoft.PowerShell.Security):

• Get-Acl — позволяет получить текущие ACL для конкретного объекта на файловой системе NTFS;
• Set-Acl – используется для добавления/изменения текущих ACL объекта.

Мы не будем подробно останавливаться на этих встроенных командлетах, т.к. их функционал в большинстве случае недостаточен для управления NTFS разрешениями в реальных задачах. Рассмотрим лишь несколько типовых примеров их использования.

Выведем текущего владельца папки (файла) и список назначенных NTFS разрешений:

get-acl C:\Drivers\ |fl

Картинка с сайта: winitpro.ru

Path : Microsoft.PowerShell.Core\FileSystem::C:\Drivers\
Owner : WORKSTAT1\root


Group : WORKSTAT1\Отсутствует
Access : NT AUTHORITY\Authenticated Users Allow Modify, Synchronize
NT AUTHORITY\SYSTEM Allow FullControl
BUILTIN\Администраторы Allow FullControl
BUILTIN\Пользователи Allow ReadAndExecute, Synchronize
WORKSTAT1\root Allow Modify, Synchronize
Audit :
Sddl : O:S-1-5-21-3650440056-3766451173-3310994491-1001G:S-1-5-21-3650440056-766451173-3310994491-513D:PAI(A;OICI;0x 1301bf;;;AU)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)(A;OICI;0x1301bf;;;S-1-5-21-3650440056-37664 51173-3310994491-1001)

Как вы видите, текущие разрешения также представлены в виде SDDL строки – мы вкратце рассматривали этот формат описания доступа в статье Управление правами на службы Windows.

Можно вывести только списки NTFS разрешений в более понятном формате:

(get-acl C:\Drivers\).access

Картинка с сайта: winitpro.ru

С помощью следящей команды можно скопировать NTFS разрешения с одной папки и применить их на другую:

Get-Acl C:\Drivers | Set-Acl C:\Distr

Для выполнения этой операции учетная запись должна быть владельцем ресурса (Owner) и обладать правами Take Ownership.

Главная проблема при использовании Set-ACL – командлет всегда пытается сменить владельца ресурса, даже если вы просто хотите изменить NTFS разрешения. В результате, чтобы добавить права на объект нужно использовать такую конструкцию:

$path = "c:\drivers"
$user = "WORKSTAT1\user1"
$Rights = "Read, ReadAndExecute, ListDirectory"


$InheritSettings = "Containerinherit, ObjectInherit"
$PropogationSettings = "None"
$RuleType = "Allow"
$acl = Get-Acl $path
$perm = $user, $Rights, $InheritSettings, $PropogationSettings, $RuleType
$rule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList $perm
$acl.SetAccessRule($rule)
$acl | Set-Acl -Path $path

Чтобы убрать NTFS доступ к папке для пользователя или группы:

$path = "c:\drivers"
$acl = Get-Acl $path
$rules = $acl.Access | where IsInherited -eq $false
$targetrule = $rules | where IdentityReference -eq "WORKSTAT1\user1"
$acl.RemoveAccessRule($targetrule)
$acl | Set-Acl -Path $path

Чтобы отключить наследование для папки из PowerShell:

$path = 'C:\dist'
$acl = Get-ACL -Path $path
$acl.SetAccessRuleProtection($True, $True) # первый $True указывает, является ли данный каталог защищенным, второй $True – нужно ли скопировать текущие NTFS разрешения
Set-Acl -Path $path -AclObject $acl

Используем модуль NTFSSecurity для управления разрешениями из PowerShell

Как я уже говорил, встроенный модуль для управления ACL на объекты в PowerShell не самый удобный. Для управления NTFS правами на файлы и папки в Windows лучше использовать отдельный модуль их галереи PowerShell – NTFSSecurity. Последнюю версию модуля NTFSSecurity (4.2.4 на данный момент) можно установить командой
Install-Module -Name NTFSSecurity
, или скачать вручную (линк). При ручной установке достаточно распаковать содержимое архива модуля в каталог C:\Windows\System32\WindowsPowerShell\v1.0\Modules\NTFSSecurity (не забудьте разблокировать скачанные файлы).

Импортируйте модуль NTFSSecurity в сессию PowerShell:

Import-Module NTFSSecurity

Выведем список команд, доступных в модуле (доступно 36 командлетов):

Get-Command -Module NTFSSecurity

Картинка с сайта: winitpro.ru

Выведем текущие NTFS разрешения на каталог:
Get-Item 'c:\distr' | Get-NTFSAccess

Как вы видите, текущие разрешения представлены в более удобной форме.

Картинка с сайта: winitpro.ru

Чтобы предоставить конкретному пользователю и группе группе полные права на папку, выполните команду:
Add-NTFSAccess -Path C:\distr -Account 'WORKSTAT1\confroom','BUILTIN\Администраторы' -AccessRights 'Fullcontrol' -PassThru

Совет. По умолчанию командлеты модуля NTFSSecurity не возвращают никаких данных, чтобы команда после выполнения выводила новые ACL, используйте параметр PassThru.

Чтобы предоставить права только на верхнем уровне и не изменять разрешения на вложенные объекты (только на папку), используйте команду:

Add-NTFSAccess c:\data\public -Account corp\aaivanov -AccessRights Modify -AppliesTo ThisFolderOnly

Удалить назначенные NTFS разрешения:

Remove-NTFSAccess -Path C:\distr -Account 'WORKSTAT1\confroom' -AccessRights FullControl -PassThru

Следующей командой можно лишить указанную учетную прав на все вложенные объекты в указанной папке (наследованные разрешения будут пропущены):

Get-ChildItem -Path C:\distr -Recurse | Get-NTFSAccess -Account 'WORKSTAT1\confroom' -ExcludeInherited |Remove-NTFSAccess -PassThru

Следующей командой можно назначить учетную запись Administrator владельцем всех вложенных объектов в каталоге:

Get-ChildItem -Path C:\distr -Recurse -Force | Set-NTFSOwner -Account 'Administrator'

Чтобы очистить все разрешения, назначенные на объекты каталога вручную (не будет удалены унаследованные разрешения):

Get-ChildItem -Path C:\distr -Recurse -Force | Clear-NTFSAccess

Включить NTFS наследование для всех объектов в каталоге:

Get-ChildItem -Path C:\distr -Recurse -Force | Enable-NTFSAccessInheritance

Чтобы вывести все разрешения, которые назначены вручную, исключая унаследованные разрешения:

dir C:\distr | Get-NTFSAccess –ExcludeInherited

Можно вывести разрешения, назначенные для определенного аккаунта (не путайте с эффективными разрешениями, речь о них ниже):

dir C:\distr | Get-NTFSAccess -Account corp\aaivanov

Проверка эффективных NTFS разрешений на объекты из PowerShell

Вы можете проверить эффективные NTFS разрешения на конкретный файл или папку с помощью командлета
Get-EffectiveAccess
. Допустим вы предоставили доступ на некоторую папку нескольким группам безопасности AD и теперь хотите понять, есть ли у конкретного аккаунта (SID) доступ к данной папке или нет. Как это сделать, не выводя состав групп AD, в которых входит его учетная запись? В этой ситуации как раз поможет функция проверки эффективные NTFS разрешений. Допустим, нужно проверить эффективные права на все вложенные папки в каталоге для пользователя confroom.

Get-ChildItem -Path c:\distr -Recurse -Directory | Get-NTFSEffectiveAccess -Account 'WORKSTAT1\confroom' | select Account, AccessControlType, AccessRights, FullName

Либо вы можете проверить эффективные разрешения на конкретный файл:

Get-Item -Path 'C:\distr\mstsc.exe.manifest' | Get-NTFSEffectiveAccess -Account 'WORKSTAT1\confroom' | Format-List

Картинка с сайта: winitpro.ru

Уровень сложностиСредний

Время на прочтение25 мин

Количество просмотров12K

Введение

В данной статье я постарался максимально полно и глубоко рассказать про построение и внутреннее использование ACL (Access Control List) внутри Active Directory. В этой статье нет рассказов про «null DACL» и «empty DACL» и тому подобного. Если читатель хочет изучить все более простые нюансы использования ACL, то рекомендую почитать другую мою статью или лучше сразу почитать комментарии к моему тестовому коду для этой статьи.

Что будет в этой статье:

• Расскажу про все 22 различных типа ACE, а также разделю их на 4 различных вида;

• Расскажу, почему прав вида «GENERIC» не существует;

• Покажу, как именно флаги из ACCESS_MASK работают при проверках в Active Directory;

• Расскажу почему вы не сможете «сделать RBCD» имея AllExtendedRights на «computer»;

• Расскажу и дам ссылку на программу для получения всех «control access rights» (extended rights, validated writes, property sets);

• Покажу, как получить полный список всех атрибутов, связанных control access rights и подчинённых классов для любого объекта в домене;

• Расскажу про каждое «validated write» в отдельности и покажу как можно обойти их контроль;

• Как именно хранятся security descriptors в NTDS.DIT и почему их там мало;

• Дам таблицу для всех «extended access rights» со ссылками на алгоритмы их использования;

Статья предполагает, что у читателя уже есть какие-то знания по построению ACL. Никаких «основ» в данной статье нет, только hardcore.

Виды ACE

На самом деле существует 22 различных типа ACE, вроде ACCESS_ALLOWED_ACE_TYPE или ACCESS_ALLOWED_CALLBACK_OBJECT_ACE_TYPE. Но их можно объединить во всего лишь 4 общих вида «access control entity».

Первый вид ACE объединяет следующие типы: ACCESS_ALLOWED_ACE_TYPE, ACCESS_DENIED_ACE_TYPE, SYSTEM_AUDIT_ACE_TYPE, SYSTEM_MANDATORY_LABEL_ACE_TYPE и SYSTEM_SCOPED_POLICY_ID_ACE_TYPE. В данном виде ACE можно устанавливать права только на основе ACCESS_MASK и только для субъекта, определяемого посредством SID. Этот вид ACE является наиболее простым и наиболее часто используемым.

Второй вид ACE объединяет следующие типы: ACCESS_ALLOWED_OBJECT_ACE_TYPE и ACCESS_DENIED_OBJECT_ACE_TYPE. В данном виде ACE права можно устанавливать как на основе ACCESS_MASK, так и на основе использования «расширенных прав» на основе GUID. Кроме того возможно устанавливать права на типы объектов, которые могут создаваться как подчинённые к текущему объекту (inherited). Данный вид ACE наиболее часто используется в Active Directory.

Третий вид ACE объединяет следующие типы: ACCESS_ALLOWED_CALLBACK_ACE_TYPE, ACCESS_DENIED_CALLBACK_ACE_TYPE, SYSTEM_AUDIT_CALLBACK_ACE_TYPE и SYSTEM_RESOURCE_ATTRIBUTE_ACE_TYPE. Данный вид является, как бы, «расширением» вида №1: здесь права доступа также определяются посредством использования ACCESS_MASK и SID, однако в данном виде добавляется использование «conditional expressions». Использование «conditional expressions» позволяет строить логические правила, которые будут определять, применяется ли текущее правило к данному конкретному access token или нет. Например, можно добавить правило типа ACCESS_ALLOWED_CALLBACK_ACE_TYPE и дать в нём права все права на какой-то объект для SID, который представляет какую-то группу, и затем в «conditional expression» задать дополнительное ограничение для доступа только с определённых компьютеров (ограничение с применением так называемых «device claims»).

Четвёртый вид ACE объединяет следующие типы: ACCESS_ALLOWED_CALLBACK_OBJECT_ACE, ACCESS_DENIED_CALLBACK_OBJECT_ACE, SYSTEM_AUDIT_CALLBACK_OBJECT_ACE и SYSTEM_AUDIT_OBJECT_ACE_TYPE. Здесь всё также, как и во втором виде: в дополнение к ACCESS_MASK можно использовать также и «расширенные» права на основе GUID. Но в четвёртом виде в дополнение ко всем возможностям второго вида тут, также как и в третьем виде ACE, можно применять «conditional expressions». Однако необходимо сказать, что на самом деле в четвёртом виде ACE возможность работы с «conditional expressions» отсутствует. То есть «conditional expressions» можно создавать, однако все функции проверки их не учитывают.

Почему прав вида «GENERIC» не существует

Основные права доступа для того или иного ACE определяются посредством поля ACCESS_MASK, представляющего собою 32-х битное значение, каждый бит которого устанавливает то или иное право доступа. И можно увидеть, что в описании стандартных битов доступа в ACCESS_MASK присутствуют биты GENERIC_READ, GENERIC_WRITE и GENERIC_ALL. Однако дело в том, что на самом деле внутри security descriptor не может быть никаких ACE с какими-либо установленными GENERIC_* битами. Почему же так происходит, и зачем на самом деле нужны биты GENERIC_*? Дело в том, что существует два вида операций с security descriptor, при котором система использует ACCESS_MASK. Первая операция это собственно добавление в security descriptor новых ACE. Установка GENERIC битов при создании новых ACE запрещена: в данном документе описывается, что установка данных битов может привести к «unintended results» (непредвиденным результатам). Да и установка этих битов, скорее всего, пройдёт незамеченной: данные биты не учитываются в алгоритме проверки авторизации (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/4f1bbcbb-814a-4c70-a11e-2a5b8779a6f9 — псевдокод для алгоритма проверки авторизации). Второй же операцией является проверка прав доступа на основании какого-либо access token текущего security descriptor. И при второй операции существует понятие «отображения» прав вида GENERIC на набор битов, которые обычно являются битами из object-specific rights. То есть в функциях проверки прав доступа, вроде AccessCheckByTypeResultListAndAuditAlarmByHandle, есть отдельный параметр GenericMapping, который определяет, что на какую комбинацию битов будут «отображаться» биты GENERIC. Напрямую использовать биты GENERIC в параметре DesiredAccess нельзя — система просто не будет их учитывать в алгоритме проверки доступа.

Таким образом, получается, что несмотря на то, что во многих источниках приводят примеры, что «кто-то имеет права GENERIC_ALL на какой-то объект», на самом деле этот «кто-то» имеет просто набор битов из «object-specific rights», которые система стандартно «отображает» на GENERIC_ALL. Например для объектов из Active Directory «отображения» прав типа GENERIC определяются в этом документе. Для объектов из обычной файловой системы это уже будут другие комбинации битов, для прав на сервисы — третьи комбинации битов, и так далее. Кстати, я в своей библиотеке постарался документировать, какие именно биты означают для каждого из типов объектов, мой список можно найти тут. Для каждого типа объектов биты в ACCESS_MASK будут означать совершенно различные права, и нельзя напрямую поставить бит GENERIC_ALL в ACE для какого-то объекта чтобы получить все-все права на его использование.

Флаги и control access rights

RIGHT_DS_CREATE_CHILD и RIGHT_DS_DELETE_CHILD: в качестве object GUID выступает schemaID для компонента, который может создавать принципал в качестве подчинённого текущему (то есть если текущий объект это OU=Computers, а objectGUID=computer, то для SID из ACE это означает, что этот SID может создавать/удалять только объекты типа «computer» внутри OU=Computers). Если в текущем ACE нет элемента objectGUID, то это означает, что данному SID разрешено создавать/удалять подчинённые объекты любых типов.

RIGHT_DS_LIST_CONTENTS: просто выдаёт право какому-то SID на просмотр подчинённых объектов. Параметр objectGUID никак не влияет, однако потенциально можно применять RIGHT_DS_LIST_CONTENTS вместе с «conditional expression».

RIGHT_DS_WRITE_PROPERTY_EXTENDED: в качестве objectGUID используется значение для одного из validated writes. Однако на самом деле в этом случае objectGUID может быть абсолютно любым, при проверке влияет ли имя того атрибута, который пользователь пытается изменить.

RIGHT_DS_READ_PROPERTY и RIGHT_DS_WRITE_PROPERTY: в качестве objectGUID используется либо property set, либо schemaID для отдельно property конкретного объекта. Если в текущем ACE нет элемента objectGUID, то это означает, что данному SID разрешено читать/писать по отношению ко всем свойствам данного объекта.

RIGHT_DS_DELETE_TREE: влияет только в случае, когда идёт попытка удалить всё дерево объектов (головной объект вместе со всеми его дочерними объектами).

RIGHT_DS_LIST_OBJECT: определяет права на видимость конкретно этого объекта для выбранного SID. Параметр objectGUID никак не влияет, однако потенциально можно применять RIGHT_DS_LIST_CONTENTS вместе с «conditional expression». Использование данного флага имеет смысл только в случае использования специального режима «List Object», который устанавливается отдельным битом в dSHeuristics (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/4a7705f7-c61e-4020-86a7-41a44fb233e5).

RIGHT_DS_CONTROL_ACCESS: в качестве objectGUID используется «extended rights». Если в ACE элемент objectGUID отсутствует, то это означает, что данный SID имеет все «extended rights».

Что означают «control access rights» и почему вы не сможете «сделать RBCD» имея AllExtendedRights на «computer»

Есть следующие типы «control access rights»:
— Extended Rights;
— Validated Writes;
— Property Sets;

Extended Rights это права, которые проверяются в каких-то определённых алгоритмах. Вроде «если пользователь запрашивает синхронизацию домена, то у него должны быть права на синхронизацию». То есть extended rights это права на определённые действия. Кстати, ниже в статье я привожу все найденные мною ссылки на описание алгоритмов, где используются все extended rights.

Validated Writes представляют собой «расширенные права» модификации определённых атрибутов. То есть они работают только для определённого набора атрибутов (ниже в статья я расскажу более подробно) и только при их модификации.

Property Set представляют собой право доступа к набору атрибутов объекта. Объединение атрибутов в наборы позволяет избежать увеличения размеров ACL (вместо кучи однотипных ACE в ACL добавляется только один элемент). Права на property set это права на модификацию/чтение набора атрибутов. Ниже я дам ссылку на программу, с помощью которой можно получить полный состав атрибутов для всех property sets.

Почему же нельзя записать в атрибут msDS-AllowedToActOnBehalfOfOtherIdentity если у вас есть все extended rights на computer? Ещё раз: extended rights это права на определённые действия. А запись в атрибуты контролируется либо отдельными ACE с правами записи для нужного нам атрибута, либо получением прав на соответствующий property set (в нашем случае это «User-Account-Restrictions», GUID=4c164200-20c0-11d0-a768-00aa006e0529).

Наследование правил доступа

Практически каждый элемент в Active Directory является частью какого-то «дерева», то есть имеет «предка» и «наследников». И для возможности автоматического наследования применяются «inherited ACEs»: ACE с установленными флагами OBJECT_INHERIT_ACE, CONTAINER_INHERIT_ACE, NO_PROPAGATE_INHERIT_ACE, INHERIT_ONLY_ACE и INHERITED_ACE. В случае, если ACE имеет простые типы (ACCESS_ALLOWED_ACE_TYPE или ACCESS_DENIED_ACE_TYPE) и установлен, например, флаг CONTAINER_INHERIT_ACE, то данное ACE автоматически перейдёт в ACL для нового подчинённого объекта, который будет являться контейнером, причём тип этого контейнера никак не ограничен. Если же используется ACE с указанием GUID (ACCESS_ALLOWED_OBJECT_ACE_TYPE и ACCESS_DENIED_OBJECT_ACE_TYPE), то в этих ACE может присутствовать значение InheritedObjectType. В этом случае наследование этого ACE ограничивается только тем типом, который упомянут в InheritedObjectType. В InheritedObjectType может быть только значение GUID, равное значению атрибута schemaIDGUID из пространства имён «CN=Schema».

Получение всех атрибутов для любого объекта в Active Directory

Для того, чтобы проверить доступ ко всем элементам какого-либо объекта в Active Directory необходимо, прежде всего, получить эти самые элементы. И, на самом деле, вопрос получения всех необходимых для проверки элементов является достаточно интересным.

Для начала найдём все возможные элементы, к которым может быть предоставлен доступ, если мы рассматриваем отдельный объект в Active Directory. Во-первых, доступ может быть предоставлен к самому объекту. Однако на самом деле при проверке доступа учитывается не идентификатор какого-то конкретного объекта, а GUID его основного класса. Далее в Active Directory есть так называемые «control access rights»: специальные права, идентифицируемые отдельными GUID. Также нужно понимать, что каждое «control access right» относиться только к определённому набору типов объектов, и при проверке надо найти только необходимые»control access right». Также в Active Directory есть понятие «property sets»: один из типов «control access rights», позволяющий выдавать права не просто на отдельные атрибуты объекта, а сразу на набор таких атрибутов. Причём при проверке доступа необходимо учитывать, что каждый «property set» также относиться только к определённым типам объектов. Кроме того, так как «property set» может относиться сразу к нескольким типам объектов, то при проверке доступа к определённому объекту необходимо включить только те атрибуты, которые относятся именно к данному типу.

Ещё одним немаловажным моментом является то, что в правилах ACE могут указываться права не только на элементы, относящиеся к текущему типу объекта, но также могут присутствовать и права на подчинённые типы объектов. Так что для получения полной картины доступа необходимо найти всех возможных потомков данного типа.

В итоге для определения полной картины доступа ко всем элементам какого-либо объекта нам будет необходимо получить картину доступа ко всему «дереву» подчинённых элементов. Для построение подобного «дерева» в Windows применяется массив элементов специального типа OBJECT_TYPE_LIST. В данном типе всего два свойства: Level и ObjectType. Свойство Level имеет тип WORD и обозначает «номер уровня» данного элемента в «дереве». Для нужд проверки доступа в Active Directory существует всего три таких уровня: ACCESS_OBJECT_GUID (нулевой уровень, здесь может быть только один элемент), ACCESS_PROPERTY_SET_GUID и ACCESS_PROPERTY_GUID. Свойство ObjectType имеет тип GUID и обозначает идентификатор элемента в схеме Active Directory.

Теперь распишем более подробно, какие именно элементы могут находиться на каждом уровне «дерева»:

• ACCESS_OBJECT_GUID

  • В массиве может быть только один элемент с таким значением Level. Значение ObjectType данного элемента будет соответствовать идентификатору основного типа данного объекта;

• ACCESS_PROPERTY_SET_GUID

  • Все «control access rights» (extended rights, validated writes, property sets);

  • Все атрибуты, не вошедшие ни в один «property set»;

  • Все дочерние типы классов;

• ACCESS_PROPERTY_GUID

  • На данном уровне «дерева» могут находиться только отдельные атрибуты, принадлежащие конкретным «property sets»;

Теперь перейдём к алгоритмам получения каждого из типов элементов. Для начала необходимо получить GUID для основного класса текущего объекта. В Active Directory каждый объект имеет набор классов, от которых он наследует свои свойства. Такой набор классов находится в атрибуте «objectClass» любого объекта в AD. Для целей проверки доступа «основным классом» считается тот класс, имя которого стоит последним в атрибуте » objectClass». Для получения GUID «основного класс» необходимо получить значение атрибута schemaIDGUID из пространства имён LDAP «CN=Schema».

Кроме «основного класс» для определённого объекта есть и общий набор классов. То есть на самом деле текущий объект наследует атрибуты из всех классов, упомянутых в «objectClass». А каждый из этих классов будет иметь свой набор родительских классов со своими атрибутами и так далее. Таким образом, для получения всех атрибутов и «control access rights» необходимо последовательно находить все атрибуты и «control access rights», относящиеся к каждому из родительских классов текущего объекта. К каждому такому классу могут относиться свои атрибуты и «control access rights», однако по правилам их свойства наследуются всеми его потомками. Все получившиеся значения записываются в общее «дерево» на соответствующем уровне.

Получение всех «control access rights» я опишу в отдельном разделе данной статьи, так что здесь на этом останавливаться не буду.

Для получения всех возможных потомков «основного класс» необходимо получить значение вычисляемого атрибута «possibleInferiors». Данный атрибут присутствует только в пространстве имён «CN=Schema».

Реализацию алгоритма поиска всех элементов для любого объекта в Active Directory вы можете найти по этой ссылке.

Также хочу добавить, что в Active Directory существует набор атрибутов, которые просто невозможно получить, несмотря на то, какие права вам будут на них выданы. В число «секретных» входят следующие атрибуты:

• unicodePwd;

• dBCSPwd;

• currentValue;

• initialAuthIncoming;

• initialAuthOutgoing;

• lmPwdHistory;

• ntPwdHistory;

• priorValue;

• supplementalCredentials;

• trustAuthIncoming;

• trustAuthOutgoing;

• msDS-ExecuteScriptPassword;

• pekList;

Значение подобных атрибутов всё-таки можно получить, но только путём прямой работы с «базой данных» — файлом NTDS.DIT.

Общее правило проверки ACE

Общие правила проверки ACE описаны в официальной документации от Microsoft. Ниже я даю более простое описание этих же правил.

Первоначально условимся, что для каждого элемента дерева из «object list» существует два отдельных значения с типом DWORD: Deny(v) и Grant(v). В начале выполнения проверки оба этих значения для всех узлов устанавливаются в 0. Корневой узел «object list» будем обозначать root.

Далее проверяем все ACE последовательно. Условимся, что поле ACCESS_MASK для каждого ACE будем обозначать M.

Если текущее ACE имеет тип ACCESS_ALLOWED_ACE, то устанавливаем значение Allow(root) как «Allow(root) |= ~Deny(root) & M» (то есть устанавливаем в Allow(root) только те биты из M, которые не установлены в Deny(root)). Далее устанавливаем Allow(v) для каждого подчинённого узла v. Правила установки Allow(v) такие же, как и для Allow(root) (то есть устанавливаются только те биты из M, которые отсутствуют в Deny(v)).

Если текущее ACE имеет тип ACCESS_DENIED_ACE, то добавляем значение M в Deny(root), а затем в Deny(v) для каждого потомка v.

Если текущее ACE является ACCESS_ALLOWED_OBJECT_ACE и у него отсутствует значение в поле ObjectType, то приравниваем данное ACE к ACCESS_ALLOWED_ACE и выполняем соответствующие ACCESS_ALLOWED_ACE действия.

Если текущее ACE является ACCESS_ALLOWED_OBJECT_ACE и у него установлено значение в поле ObjectType, однако это значение не соответствует ни одному GUID из «object list», то пропускаем данное ACE.

Если текущее ACE является ACCESS_ALLOWED_OBJECT_ACE и у него установлено значение в поле ObjectType, которое соответствует какому либо GUID из «object list» то устанавливаем значение Allow(v) для текущего узла и всех его подчинённых узлов по общему правилу «Allow(v) |= ~Deny(v) & M». Если на каком-то уровне «object list» получиться, что все значения Allow(v) равны, то тогда добавляем значение Allow(v) в Allow(p), где «p» является корневым узлом для текущего уровня. Другими словами если у какого-то узла правила Allow для всех его листьев одинаковы, то тогда это правило переносится в Allow для самого корневого узла.

Если текущее ACE является ACCESS_DENIED_OBJECT_ACE и у него отсутствует значение в поле ObjectType, то приравниваем данное ACE к ACCESS_DENIED_ACE и выполняем соответствующие ACCESS_DENIED_ACE действия.

Если текущее ACE является ACCESS_DENIED_OBJECT_ACE и у него установлено значение в поле ObjectType, однако это значение не соответствует ни одному GUID из «object list», то пропускаем данное ACE.

Если текущее ACE является ACCESS_DENIED_OBJECT_ACE и у него установлено значение в поле ObjectType, и оно соответствует одному из GUID из «object list», то добавляем значение M во все Deny для всех подчинённых и родительских узлов.

Проверка ACE с «control access rights»

Основной документ от Microsoft. Ниже я даю более простое описание этих же правил.

Основным условием для отнесения ACE к «control access rights» является наличие установленного бита RIGHT_DS_CONTROL_ACCESS в ACCESS_MASK.

Если ACE является ACCESS_ALLOWED_OBJECT_ACE и поле ObjectType отсутствует, то это означает, что для данного SID разрешены все «control access rights».

Если ACE является ACCESS_ALLOWED_OBJECT_ACE и поле ObjectType содержит какой-то GUID, то права у данного SID есть только на «control access right» с соответствующим GUID.

Если ACE является ACCESS_DENIED_OBJECT_ACE и поле ObjectType отсутствует, то это означает, что для данного SID запрещены все «control access rights».

Если ACE является ACCESS_DENIED_OBJECT_ACE и поле ObjectType содержит какой-то GUID, то права у данного SID отсутствуют (явно) только на «control access right» с соответствующим GUID.

Проверка ACE с «validated write»

Основной документ от Microsoft. Ниже я даю более простое описание этих же правил.

Основным условием для отнесения ACE к «validated write» является наличие установленного бита RIGHT_DS_WRITE_PROPERTY_EXTENDED. Права типа «validated write» являются «дополнительными», и проверяются только если для данного SID ранее отсутствовали ACE явно разрешающие или запрещающие модификацию соответствующих атрибутов объекта.

Если ACE является ACCESS_ALLOWED_OBJECT_ACE и поле ObjectType отсутствует, то это означает, что данный SID имеет право на все «validated write».

Если ACE является ACCESS_ALLOWED_OBJECT_ACE и поле ObjectType содержит какой-то GUID, то данный SID имеет право только на «validated write» с соответствующим GUID — так написано в документации. На деле же GUID для «validated write» может быть произвольным, само правило «validated write» сработает только при модификации соответствующего атрибута соответствующего объекта.

Если ACE является ACCESS_DENIED_OBJECT_ACE и поле ObjectType отсутствует, то это означает, что данный SID не имеет никаких «validated write».

Если ACE является ACCESS_DENIED_OBJECT_ACE и поле ObjectType содержит какой-то GUID, то это означает, что для данного SID запрещено только одно конкретное «validated write».

Алгоритм получения всех «control access rights»

В «control access rights» Microsoft включает все три следующих группы: extended access rights, validated writes, а также property sets. Под «extended access rights» понимается GUID, обозначающий дополнительное право доступа, которое может быть проверено системой при определённых условиях. Более подробно про все «extended access rights» я напишу позже в этой статье. Под «validated writes» понимается специальное право на «проверяемую» модификацию определённых атрибутов внутри ActiveDirectory. Под «property sets» понимается некий GUID, который позволяет давать права на чтение или запись сразу для группы атрибутов.

 Все «control access rights» можно получить из LDAP для текущего домена. Необходимо сказать, что набор «control access rights» не является фиксируемым и в будущем он может быть изменён. Для нахождения всех «control access rights» во-первых необходимо выполнить LDAP запрос с фильтром «rightsGuid=*» по отношению к «configuration namespace» (это пространство имён начинается с  «CN=Configuration»). В этом запросе нам будут нужны следующие атрибуты:

• name (для короткого наименования «control access right»);

• displayName (для полного описания «control access right»);

• appliesTo (для получения всех атрибутов, к котором применяется текущее «extended right»);

• validAccesses (для получения типа «control access right»);

• rightsGuid (для получения уникального идентификатора «control access right»);

Для получения информации о том, какие именно атрибуты включаются в тот или иной «property set» необходимо выполнить запрос к «schema namespace» (имя начинается на «CN=Schema») с LDAP фильтром «schemaIdGuid=*». Если у атрибута есть элемент с именем «attributeSecurityGUID», то его значение будет соответствовать rightsGuid для определённого «property set». 

Программу для получения списка всех «control access rights» из Active Directory вы можете найти по этой ссылке.

Про Validated Writes

Права вида «Validated Writes» выделяются путём включения в access mask флага RIGHT_DS_WRITE_PROPERTY_EXTENDED. В Windows Server 2019 существуют следующие вида Validated Writes:
• Self-Membership;
• Validated-DNS-Host-Name;
• Validated-SPN;
• Validated-MS-DS-Behavior-Version;
• Validated-MS-DS-Additional-DNS-Host-Name;
• DS-Validated-Write-Computer;

Self-Membership

Проверяет запись в атрибут «member» для объектов типа «group». Для прохождения проверки необходимо, чтобы выполнялась операция либо добавления, либо удаления, чтобы добавлялось/удалялось единственное значение и чтобы это значение совпадало с SID пользователя, от имени которого выполняется данная операция.

Validated-DNS-Host-Name

Проверяется запись в атрибут «dNSHostName». Проверка выполняется только для класса «computer» и его наследников. Проверяется то, что новое значение атрибута будет являться объединением значения атрибута «sAMAccountName» (без последнего «$») и имени текущего домена (вроде «computer.domain.lan»).

Validated-SPN

Проверяется запись в атрибут «servicePrincipalName». Проверка выполняется только для класса «computer» и его наследников. Проверяется, что новое значение:

• Состоит только из двух частей;

• Последняя часть совпадает с одним из следующих атрибутов: dnsHostName, samAccountName или msDS-AdditionalDnsHostName;

Validated-MS-DS-Behavior-Version

Проверяет запись в атрибут «msDS-Behavior-Version». Возможна модификация значения только для классов «domainDNS» и «crossRefContainer». Новое значение этого атрибута должно быть больше текущего. Новое значения для класса «domainDNS» должно быть меньшим, либо эквивалентным значениям атрибутов «msDS-Behavior-Version» для всех классов типа «nTDSA» в текущем домене.

Validated-MS-DS-Additional-DNS-Host-Name

Проверяется запись в атрибут «msDS-AdditionalDnsHostName». Проверка выполняется только для класса «computer» и его наследников. Проверяется, что окончание нового значения совпадает с разрешёнными суффиксами DNS (значение текущего DNS суффикса + атрибут msDS-AllowedDNSSuffixes).

DS-Validated-Write-Computer

Проверяет запись в атрибут «msDS-KeyCredentialLink». Проверка выполняется только для класса «computer» и его наследников. Каких-то полных данных что именно проверяется и как найти не удалось.

В процессе исследования выяснились две особенности, относящиеся к Validated Writes. Первая особенность состоит в том, что на самом деле правило Validated Write будет выполняться только в том случае, когда у вас нет никаких других прав на данный атрибут. То есть если у вас есть ACE явно разрешающее доступ к атрибуту servicePrincipalName, то вы сможете записать в него всё, что вам захочется. Вторая особенность состоит в том, что если в ACE установлен флаг RIGHT_DS_WRITE_PROPERTY_EXTENDED, то нет никакой разницы какой именно GUID стоит в поле ObjectType. Так или иначе правило Validated Write просто будет проверять в какой атрибут вы собираетесь писать и в зависимости от имени этот атрибута будет вызывать соответствующее правило. Как следствие — если у вас есть право на Validated Write для какого-то одного атрибута, то вы сможете писать в любой атрибут, который проверяет любое из Validated Write.

Работа с security descriptor внутри NTDS.DIT

Наверняка многие знают, что значение «security descriptor» для каждого объекта хранится в специализированном атрибуте «nTSecurityDescriptor». Наверное, некоторые даже знают, что этот атрибут является «вычисляемым», то есть для его получения необходимо выполнить отдельный LDAP запрос с указанием только этого атрибута в качестве результирующего. Но почему же «nTSecurityDescriptor» как-то «вычисляется» внутри Active Directory?

Изначально все security descriptors действительно хранились в отдельном атрибуте, связанном с каждым объектом в Active Directory. Однако такой способ хранения привёл к чрезмерным размерам базы данных AD. Почему же это произошло? Дело в том, что в Active Directory объекты обычно входят в состав какого-то «дерева» объектов, где всегда есть «родитель» и «наследники». И если, например, изменяется одно ACE в «родительском» security descriptor, то оно должно (если имеет соответствующие флаги) быть добавлено также в security descriptors для всех «наследников». Предположим, что меняется одно ACE для корневого элемента домена, в котором миллион элементов. Если один ACE, в среднем, имеет размер в 15Кб, то внесение его во все security descriptors для всех наследников приведёт к увеличению общей базы данных на более чем 1Гб.

Однако было предложено простое решение: выделить все security descriptors в отдельную таблицу базы данных. Это оказалось гораздо более выгодно так как в Active Directory очень много однотипных элементов с одинаковыми правами, а также потому, что изменение прав на объекты обычно выполняются достаточно редко. Например, у меня в тестовом домене таблица «datatable» из NTDS.DIT содержит 3764 элемента, тогда как количество всех security descriptors равно всего 120. И причём из 120-ти SD есть всего 2 SD, которые в сумме используются в 3111 элементах. То есть 82 процента всех элементов в моём тестовом домене используют всего 2 стандартных SD. А из всех 120-ти SD есть 72, которые используются только в одном элементе домена. Оставшиеся 46 SD используются в разном количестве элементов, но ни для одного из этих SD количество использующих его элементов не превышает 100.

Внутри NTDS.DIT за хранение security descriptors отвечает таблица «sd_table». Внутри этой таблицы есть следующие поля:

• sd_hash — значение MD5 для всего бинарного значение security descriptor;

• sd_id — идентификатор данного security descriptor (именно это значение на самом деле хранится в атрибуте nTSecurityDescriptor);

• sd_refcount — количество элементов Active Directory, в которых используется данный security descriptor;

• sd_value — собственно бинарное значение security descriptor;

Также в NTDS.DIT есть ещё одна таблица — «sdproptable». Информация в данной таблице нужна для осуществления «propagation» (распространения) изменений в security descriptor. Похоже, что информация в неё записывается только по мере необходимости так как в моём тестовом NTDS.DIT таблица «sdproptable» пустая. Предположу, что в Active Directory существует какой-то отдельный процесс, который запускает изменение «дочерних» SD при изменении в «родительском» SD.

Информация по всем «extended rights»

Ниже я привожу таблицу, где я постарался для каждого из «extended rights» найти все возможные ссылки на использование. Таким образом, можно понять, где именно и в каких случаях проверяется наличие каждого из «расширенных прав». Приведены ссылки только на официальную документацию Microsoft.