Как устроен ntds.dit?

Все данные каталога Active Directory хранятся в БД в файле ntds.dit. Подавляющее большинство приложений взаимодействуют с каталогом через прослойку DSA реализованную в ntdsa.dll. В свою очередь функции из ntdsa.dll не работают напрямую с ntds.dit, их функционал ограничен потребностями службы каталогов и они не могут дать нам представление о внутреннем устройстве БД Active Directory. Тем не менее ntds.dit представляет собой не что иное как БД JET Blue. В каждой версии windows (начиная с Windows 2000) есть всё необходимое для работы с этой БД.

В статье ниже я попробую осветить следующие вопросы:

• Какова структура БД?
• Как данных в ntds.dit получается «дерево»?
• Как реализовано членство в группах?
• Каков формат атрибута replPropertyMetaData и с какой точностью в метаданных репликации хранятся временные метки?

Что нужно, чтобы заглянуть в ntds.dit ?

Как минимум: esent.dll
Для «комфортного» использования из различных языков программирования над ESENT API имеются различные «обёртки». Я использовал Meneged Esent в связке с C#. На сайте проекта имеется много примеров — поэтому далее я постараюсь сконцентрироваться именно на содержимом ntds.dit.

Также следует обратить внимание, что у БД JET Blue есть такой параметр как PageSize. По-умолчанию, он равен 4096 (для тех версий esent.dll, с которыми я сталкивался). Так вот в ntds.dit размер страницы равен 8192 и этот параметр следует корректно установить до открытия БД.
У API ESENT есть несколько версий. Эти версии несовместимы! Так ntds.dit из Windows Server 2008 R2 на windows xp не откроется, только на Windoes 7. (Обратную совместимость я не проверял)

Вопрос первый: Какова структура БД?

Функция GetTableNames возвратит список таблиц в базе:
datatable — основная таблица со всеми данными каталога
hiddentable
link_table — согласно статье на technet таблица с информацией о связанных атрибутах (например MemberOf)
quota_rebuild_progress_table
quota_table
sdpropcounttable
sd_table — согласно статье на technet таблица содержит информацию о наследованных правилах доступа для каждого объекта каталога.

Остановимся подробнее на таблице datatable. Список её столбцов имеет вид (на скриншоте первые несколько строк):

Тупик? Нет!
Имена большинства колонок имеют формат ATT<одна латинская буква><цифровой код>. Так вот этот цифровой код — уникальный идентификатор атрибута Active Directory. В таблице есть одна строка, в которой значение цифрового кода столбца совпадает с его значением. Если вывести все значения типа Text из этой строки, то мы увидим, что это определение атрибута «attributeID».

Остался один «нерасшифрованый» атрибут ATTc0 — это ссылка на «objectClass».
Обратите внимание — все колонки, хранящие атрибуты каталога Active Directory заведены как Multi-value в не зависимости от схемы.

Вопрос второй: Как данных в ntds.dit получается «дерево»?

Название столбца «DNT_col» провоцирует предположить, что он как-то связан с distinguishedName объекта (как позже выяснилось — они равны)
Значения колонки DNT_col начинаются с 1, причём строка с DNT_col=1 соответствует интересному объекту со значенем атрибута name="$NOT_AN_OBJECT1$"
Строка с DNT_col=2 содержит в себе атрибуты объекта с именем "$ROOT_OBJECT$" (Не путать с RootDSE)
С DNT_col=6 начинаются определения objectClass’ов
Опять тупик? Опять нет!
Пойдём другим путём.
Поиск по колонке ATTm589825 (name) значения типа Text «Administrator» вернул запись с DNT_col=3841 и PDNT_col=1951
Поиск по колонке ATTm589825 (name) значения типа Text «Users» (контейнер, в котором расположена учётная запись стандартного администратора) вернул запись с DNT_col=1951 и PDNT_col=1944
Вот она связь! столбец PDNT_col содержит идентификатор DNT_col родительского объекта.
В строке с DNT_col=1944 ( PDNT_col=1943) — оказался объект домена второго уровня (ntds.dit был взять с тестового контроллера домена второго уровня)
В строке с DNT_col=1943 ( PDNT_col=2) — объект домена первого уровня.

Если вы когда-нибудь задавались вопросом: «Почему в при подключении к dc=contoso,dc=com не отображаются объекты из cn=Configuration,dc=contoso,dc=com?» то вам следует обратить внимание на колонку NCDNT_col — она содержит ссылки на объект контекста именования. (причём, объект домена первого уровня не имеет контекста именования — моэет по этому он и не виден?). Для Объектов в контекстах именования «dc=contoso,dc=com» и «cn=Configuration,dc=contoso,dc=com» значение этой колонки отличается.

Не менее интересно как из этих чисел получается полное distinguishedName объекта? Какой аттрибут обекта является относительным уникальным именем (RDN) и используется для построения полного distinguishedName.
Колонка RDNtyp_col содержит идентификатор атрибута (attributeID), содержащего RDN.
В колонке CNT_col содержится количество объектов, связанных с текущим. Эта колонка используется механизмом Link Cleaner
Если бит в колонке OBJ_col установлен в 1, значит данная строка описывает объект каталога. Иначе — это объект-фантом.

Как реализован SubTree поиск?
Понятно, что при такой структуре для поиска OneLavel достаточно поискать среди записей с PDNT_col равной DN базы поиска, а вот как поискать по SubTree? Обходить все ветви? Нет это слишком сложно.
Присмотримся к значениям в колонке с говорящим именем Ancestors_col. В глаза бросается, что чем глубже в иерархии расположен объект, тем длиннее значение в этой колонке. Каждый уровень вложенности добавляет к длине 4 байта. Это не что иное как список родительских объектов в порядке очерёдности.
Причём список начинается с dn=2, т.е. с "$ROOT_OBJECT$"
Кто занимается поддержанием Ancestors_col в актуальном состоянии? Согласно документу при перемещении объекта в новое место изменяется только его PDNT_col, а значение Ancestors_col обновляется механизмом SDProp заодно с пересчётом новых правил доступа к объекту.

Вопрос третий: Как реализовано членство в группах?

Почему c 2003-го сервера появилась возможность влючать в группу брактически неограниченное число прользователей, и при этом в строковый или числовой multi-value атрибут не удастся записать боле ~1200 значений?
Да потому, что «member» и «memberOf» определены как ссылки. В таблице datatable нет столбцов, соответствующих этим атрибутам. Значения этих атрибутов реализованы как соответствия в отдельной таблице link_table.
Быть может именно поэтому при удалении группы (без использования RecucleBin) мы теряем сведения о её членах — объект удалённой группы получает новый идентификатор в DNT_col при перемещении в контейнер удалённых объектов (а связь группы и её члена построена именно по этому идентификатору)

Названия и тип столбцов намекают, а анализ содержащихся в них данных подтверждает, что:
link_DNT — Содержит идентификатор dn (соответствует DNT_col из datatable) объекта, связь которого описывается (например, объекта группы)
backlink_DNT — Содержит идентификатор dn связанного с ним объекта (например, объекта пользователя)
link_ncdnt — Содержит идентификатор dn контекста именования, в котором расположены участники связи.
link_usnchanged — Содержит USN последнего изменения всязи
link_data — Я видел это поле заполненным только для связей объектов NTDS Settings. Да! Объекты NTDS Settings имеют связи с объектами разделов каталога повидимому посредством этих связей задаются параметры репликации различных разделов каталога.
link_deltime — Содержит время удаления связи.
link_metadata — содержит метаданные, необходимые для репликации внесённых изменений. Заполеннными значения этой колонки я видел только на Windows 2012. Christoffer Andersson пишет, что колонка содержит структуру DS_REPL_VALUE_META_DATA и здесь я с ним категорически не согласен. Структура DS_REPL_VALUE_META_DATA используется на более высоком уровне — её возвращают вызовы ntdsa.dll. Данные, содержащаеся в этой колонке имеют размер меньше, чем необходимо под структуру DS_REPL_VALUE_META_DATA. Пока данная колонка остаётся для меня загадкой. Впринципе метаданные репликации для аттрибутов-связей можно получить из построенного атрибута msDS-ReplValueMetaData, но это не раскрывает внутреннего механизма обработки и хранения этих данных.

Вопрос четвёртый: Каков формат атрибута replPropertyMetaData и с какой точностью в метаданных репликации хранятся временные метки?

В этом атрибуте хранятся метаданные репликации в двоичном виде:

Что хранится в первых 8-ми байтах данной структуры я пока не разобрался.
Следует обратить внимание на тот факт, что в структуре replPropertyMetaData перечисляются только реплицируемые атрибуты со значениями. Так, например, вы не увидите в replPropertyMetaData идентификатора атрибута logonTimestamp.
Тут есть интересный момент: в структуре replPropertyMetaData для объектов безопасности Active Directory (пользователей, групп и компьютеров) присутствует атрибут objectSid.
Кстати, чтобы расшифровать значение этого атрибута — не обязательно так напрягаться — существует построенный атрибут msDS-ReplAttributeMetaData — он собой предстваляет не что иное как разобранное значение replPropertyMetaData.

Временные метки в Active Directory это 64-битные беззнаковые целые числа, указывающие количество секунд, прошедших с 00:00 1 января 1601 года. Отсюда вытекает интересный нюанс: при правке одного атрибута одного и того же объекта на двух контроллерах домена в течение 1 секунды (например при пакетной обработке большого числа пользователей) можно получить неожиданный результат.
По данным статьи на technet выигрывает версия атрибута от контроллера с меньшим GUID.

Использованная информация:

technet.microsoft.com/en-us/library/cc772829%28v=ws.10%29.aspx
blogs.chrisse.se/2012/02/20/how-the-active-directory-data-store-really-works-inside-ntds-dit-part-1
blogs.chrisse.se/2012/02/20/how-the-active-directory-data-store-really-works-inside-ntds-dit-part-2
blogs.chrisse.se/2012/02/20/how-the-active-directory-data-store-really-works-inside-ntds-dit-part-3
blogs.chrisse.se/2012/02/20/how-the-active-directory-data-store-really-works-inside-ntds-dit-part-4
gexeg.blogspot.ru/2009/12/active-directory.html
www.ntdsxtract.com/

Все эксперименты ставились над ntds.dit из Windows Server 2012 Eng