NTDS Quota и Trust Quota – защитные механизмы 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.

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

Атрибут 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):

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

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

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

Удач!