NTDS Quota и Trust Quota – защитные механизмы Active Directory

NTDS Quotas - нужный и практичный защитный механизм Active Directory.

Привет.

В Active Directory много защитных механизмов – и некоторые из них, хоть и являются эффективными, незаслуженно прозябают в тени. В основном это относится к двум классам технологий – “чё-то сходу не разобрался, значит ну её нах” и “да вроде и без неё работает”. Оба вышеприведённых тезиса практически гарантируют вечное нахождение в статусе эникейщика (или заслуженного эникейщика, или многократно переименованного эникейщика) – что, в условиях текущего положения IT-рынка, совершенно неприемлемо.

Одним из таких механизмов, существующих с самого рождения Active Directory, является механизм квотирования – реализованный в виде NTDS quotas и Trust Quota.

Разберёмся с ними на примере Windows Server 2016 – для этого вам потребуется представление о работе Active Directory на уровне хотя бы курсов Microsoft 20410D и Microsoft 20411D; больше – лучше.

Защитные механизмы квотирования – NTDS Quotas и Trust Quota

  • Принцип действия и назначение NTDS Quotas
  • Настройка NTDS Quotas на уровне Active Directory partition
    • Общие настройки NTDS Quotas
    • Атрибут msDS-DefaultQuota
    • Атрибут msDS-TombstoneQuotaFactor
  • Настройка персональных NTDS Quotas
  • Операции обслуживания NTDS Quotas
    • Проверка целостности таблицы NTDS Quotas
    • Ремонт таблицы NTDS Quotas
  • Принцип действия и назначение Trust Quota

Начнём.

Принцип действия и назначение NTDS Quotas

NTDS quota – это, по сути, то же самое, что классическая квота NTFS, только не на уровне логического раздела, а на уровне active directory partition. То есть, также составляется таблица всех владельцев объектов, и отслеживается, не влечёт ли создание очередного объекта нарушение какого-либо ограничения. В NTFS отслеживался суммарный размер файлов у SID’а – в случае NTDS будет отслеживаться количество объектов, у которых данный security principal является владельцем.

Такой механизм эффективно решает ситуацию вида “региональному админу разрешили в его OU создавать объекты – он сошёл с ума и написал скрипт, который генерит бесконечное множество учётных записей, чем вызвал огромный объём репликации на всём предприятии” и подобные ей. Обычно предполагается, что это можно побороть, просто поднимая в регионах RODC – с них не идёт репликация, да и создать объект на них трудновато. Но – ничего не помешает злоумышленнику, обладая правами на создание объектов (где угодно, в любом контейнере), просто подключиться к другому DC и создать объекты на нём. NTDS-квоты решают задачу защиты от таких действий эффективно и без особых изменений существуют с Windows 2000 Server – давайте посмотрим, как их грамотно настроить.

Настройка NTDS Quotas на уровне Active Directory partition

Квоты NTDS можно будет задавать для любого раздела Active Directory – что стандартных domain partition и configuration partition, что для созданных дополнительных application partition. Исключение – только schema partition; там квоты не работают.

Сами объекты NTDS-квот будут находиться в контейнере NTDS Quotas (замечу, что это не просто контейнер, а специальный объект msDS-QuotaContainer), который находится в корне каждого раздела Active Directory, поддерживающего квотирование:

Рассмотрим общие настройки механизма NTDS-квот на уровне отдельного раздела Active Directory.

Общие настройки NTDS Quotas

На функционирование механизма квотирования будут влиять два атрибута контейнера NTDS Quotas – это msDS-DefaultQuota и msDS-TombstoneQuotaFactor.

Общие настройки NTDS QuotasОбщие настройки NTDS Quotas
(кликните для увеличения до 414 px на 462 px)
Учебный центр Advanced Traininginfo@atraining.ru

За что будет отвечать каждый из них?

Атрибут msDS-DefaultQuota

Данный атрибут не обладает значением по умолчанию – это и обозначает, что разово делегировав право на create child objects, вы потенциально рискуете подпасть под атаку. Выставляя это значение, учитывайте, что это именно квота по умолчанию – если SID конкретного security principal’а подпадёт под личную NTDS-квоту, этот параметр будет игнорироваться.

Атрибут msDS-TombstoneQuotaFactor

Квоты действуют не только на живых – на удалённые объекты, которые пока ещё не стёрты из Active Directory (т.е. находятся в состоянии tombstone), она действует так же. Данный параметр указывает соотношение разрешённых к владению обычных объектов к удалённым – то есть, если он равен 100 (а считается он в процентах), а квота, фактически действующая на этого пользователя, равна 5, то у пользователя может быть 5 живых объектов и 5 удалённых. Учитывайте, что при удалении любого объекта – что своего, что чужого – он засчитывается в квоту удалившего его security principal’а. Поэтому если Вы удалите свой объект, то он не сменит владельца – просто перейдёт из категории “засчитывается в обычную квоту” в “засчитывается в некроквоту”.

Если данный атрибут меньше 100, то это обозначает, что вы можете владеть большим количеством удалённых объектов. Например, если он равен 10%, а ваша квота – 3 объекта, это обозначает, что каждый ваш tombstone считается как 10% от обычного, т.е. вы сможете удалить 30 объектов.

Менять данный параметр имеет смысл, если у вас возможны сценарии “региональный админ не может создать много учёток, потому что у него офис на 5 человек, но может за день сто раз ввести-вывести комп из домена, удаляя его учётку вручную, потому что он так привык все проблемы решать” – только учитывайте, что это глобальная настройка, подействует на всех.

ОК, с глобальными настройками разобрались – теперь создадим квоту для конкретного security principal’а.

Настройка персональных NTDS Quotas

Квоты создаются крайне просто – с древних времён для этого есть команда dsadd. Синтаксис будет выглядеть так:

dsadd quota -rdn Quota1 -part DC=atraining,DC=lab -qlimit 100 -acct CN=Vasya,CN=Users,DC=atraining,DC=lab

Параметры тривиальны – вначале указывается имя будущего объекта в контейнере NTDS Quotas (у Microsoft ошибка – параметр называется RDN, то есть подразумевается Relative Distinguished Name, “весь компонент DN”, а по факту надо указывать только CN), после указывается раздел, в контейнер NTDS Quotas которого будет прописываться новый объект квоты (DC=atraining,DC=lab), указывается квота (я указал 100; можно указать -1, тогда у объекта будет бесконечная квота – это удобно, когда на разделе глобально вводится квота для всех, а одиночные учётки админов исключаются), а потом указывается, на какой объект квота действует (можно указать имя учётки, можно DN). Результат будет выглядеть так:

Можно будет создать несколько квот, действующих на одного пользователя – тогда из них, для подсчёта результирующей, будет выбрана максимальная.

Квоту можно создать и на группу – однако учитывайте, что логика обработки будет “нельзя создать больше объектов, у которых собственником является эта группа, чем указано”, а не “это квота для всех тех, кто входит в эту группу”. Квота при создании преобразует заданный в -acct параметр в SID security principal’а (сохраняя в свой атрибут msDS-QuotaTrustee), и просто отслеживает, сколько объектов имеют этот же SID в поле Owner. Т.е. нельзя выстроить хитрую систему квот на группы – вы встретитесь с ситуацией, когда группа становится владельцем объекта, разве что для группы Administrators – в Group Policy был такой параметр, “кто будет собственником объекта, созданного участником группы BUILTIN\Administrators – тот, кто создавал или группа”, на данный момент отсутствующий.

Просмотреть свою квоту можно достаточно оригинальным способом – зайдя во вкладку Attributes у объекта NTDS Quotas на нужном разделе Active Directory и, включив отображение Constructed-атрибутов, посмотреть на появившиеся атрибуты

msDS-QuotaEffective (сколько по факту составляет квота для просматривающего) и msDS-QuotaUsed (сколько использовано).

Операции обслуживания NTDS Quotas

Этих операций будет две – проверка целостности таблицы квот и восстановление этой таблицы в случае найденной проблемы. Операции производятся на уровне файла ntds.dit у контроллера домена – то есть не для отдельного partition, а для всех разделов Active Directory, которые есть на проверяемом контроллере.

Делается всё это несложно.

Проверка целостности таблицы NTDS Quotas

Первым делом – надо остановить сервис ADDS. В Windows Server 2008 и старше – просто остановите его через services.msc, в Windows Server 2003 R2 и младше – перезагрузитесь в DSRM-варианте. Далее запустите ntdsutil.exe и:
  1. Укажите командой Activate Instance, что работа идёт с текущим экземпляром Active Directory – ac in NTDS (команды можно сокращать до первых букв).
  2. Зайдите в контекст Semantic Checker – Semantic database analysis.
  3. Включите подробный режим вывода сообщений – verbose on.
  4. И, наконец, запустите проверку – check quota.

Нормальный вариант завершения операции выглядит как-то так: Integrity-checking the quota-tracking table... The quota-tracking table was successfully integrity-checked. No corruption was detected.

Ремонт таблицы NTDS Quotas

Если же найдены проблемы, то можно запустить quota rebuild – для этого надо сделать всё так же, как в предыдущем варианте, только разве что команда будет rebuild quota. В этом случае будет инициирован процесс перепостроения таблицы квот: The quota-tracking table has been successfully scheduled for asychronous rebuild.

Он запустится, когда вы опять включите Active Directory – учитывайте, что процесс этот не сильно шустрый, т.к. подразумевает поэлементное чтение почти всей Active Directory. Запускать его на нескольких контроллерах не имеет смысла – таблица квот не реплицируется и ломается на локальном контроллере. Т.е. имеет смысл её проверять на всех и чинить только на нужных (хотя портится она в экстремально редких ситуациях).

Теперь перейдём к другому типу квот – квотам на forest trust’ы.

Принцип действия и назначение Trust Quota

Механизм квотирования создания трастов известен ещё менее, чем NTDS Quota, однако достаточно интересен. Принцип его действия – ограничить количество создаваемых входящих forest trust’ов. Начиная с Windows Server 2003, в Active Directory можно создавать доверительные отношения между лесами Active Directory – для этого нужно обладать Create-Inbound-Forest-Trust extended right, что обычно реализуется через членство во встроенной группе Incoming Forest Trust Builders (она BUILTIN, с коротким SID’ом S-1-5-32-557):

Группа Incoming Forest Trust BuildersГруппа Incoming Forest Trust Builders
(кликните для увеличения до 414 px на 480 px)
Учебный центр Advanced Traininginfo@atraining.ru

Данное ограничение устанавливается атрибутом msDS-AllUsersTrustQuota, который есть у каждого корневого домена леса Active Directory (а также у любого Domain Context’а – например, у DC=DomainDnsZones, но не используется в этом варианте) и, по умолчанию, равен 1000. Очень часто данный атрибут относят к механизму NTDS Quotas – это неправильно, он к нему никак не относится.

Атрибут msDS-AllUsersTrustQuotaАтрибут msDS-AllUsersTrustQuota
(кликните для увеличения до 423 px на 153 px)
Учебный центр Advanced Traininginfo@atraining.ru

Если этот функционал не используется (нет специальных пользователей, которым надо срочно создавать входящие трасты с чужими лесами Active Directory), имеет смысл понизить его до разумных масштабов – например, до 10. Параметр влияет только на forest trust’ы, учитывайте это – т.е. подъём нового домена в пределах леса, или установка shortcut trust не будут ограничены данным параметром.

В общем, на этом всё – надеюсь, что данные механизмы квотирования стали понятнее. Применять их можно и нужно, т.к. надо защищаться от атак на переполнение Active Directory.

Удач!

Возможно, вам будет также интересно почитать другие статьи про на нашей Knowledge Base

Ruslan V. Karmanov

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