Назад | Перейти на главную страницу

Где хранить конфиденциальные данные в Active Directory?

По сути, я храню закрытый ключ (хэш) в любом из атрибутов OctetString в Active Directory.

У меня вопрос: какой атрибут защищен по умолчанию и имеет смысл хранить там личные данные? Это значение следует рассматривать как аналог пароля, к которому даже администраторы не должны иметь доступа (если возможно), как и текущий пароль AD.

Вот начало списка атрибутов, которые включены по умолчанию в домене Windows 2008R2 + Exchange 2010.

Обновить:

Кто-нибудь знает об атрибуте Octet String, который по умолчанию не предоставляет разрешения на "чтение" всем пользователям в домене? Я не хочу публично хранить свой хэш и позволять кому-то создавать радужную таблицу на основе хешей.

Проблема, с которой сталкивается большинство людей при хранении данных в AD:

  • Расширение схемы (что часто имеет политические последствия для компании)

  • Использование существующего атрибута и редактирование разрешений (что приводит к раздуванию AD / ACL, что увеличивает ваш DIT и последующий размер репликации)

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

Вот подробности о процессе


Разрешения по умолчанию в Active Directory таковы, что прошедшие проверку пользователи имеют полный доступ для чтения ко всем атрибутам. Это затрудняет введение нового атрибута, который должен быть защищен от чтения всеми.

Чтобы смягчить это, Windows 2003 SP1 представляет способ пометить атрибут как КОНФИДЕНЦИАЛЬНЫЙ. Эта функция достигается путем изменения значения searchFlags атрибута в схеме. SearchFlags содержит несколько битов, представляющих различные свойства атрибута. Например. бит 1 означает, что атрибут проиндексирован. Новый бит 128 (7-й бит) обозначает атрибут как конфиденциальный.

Примечание: вы не можете установить этот флаг для атрибутов базовой схемы (производных от «top», таких как common-name). Вы можете определить, является ли объект объектом базовой схемы, используя LDP для просмотра объекта и проверив атрибут systemFlags объекта. Если установлен 10-й бит, это объект базовой схемы.

Когда служба каталогов выполняет проверку доступа для чтения, она проверяет конфиденциальные атрибуты. Если да, то в дополнение к доступу READ_PROPERTY службе каталогов также потребуется доступ CONTROL_ACCESS к атрибуту или его набору свойств.

По умолчанию только администраторы имеют доступ CONTROL_ACCESS ко всем объектам. Таким образом, только администраторы смогут читать конфиденциальные атрибуты. Пользователи могут делегировать это право любой конкретной группе по своему желанию. Это можно сделать с помощью инструмента DSACL, сценариев или версии LDP R2 ADAM. На момент написания этой статьи невозможно использовать редактор пользовательского интерфейса ACL для назначения этих разрешений.

Процесс пометки атрибута как конфиденциального и добавления пользователей, которым необходимо просмотреть атрибут, состоит из 3 шагов.

  1. Определение того, какой атрибут помечать как конфиденциальный, или добавление атрибута для пометки как конфиденциальный.

  2. Отметка как конфиденциальная

  3. Предоставление правильным пользователям права Control_Access, чтобы они могли просматривать атрибут.

Для получения дополнительных сведений и пошаговых инструкций обратитесь к следующей статье:

922836 Как пометить атрибут как конфиденциальный в Windows Server 2003 с пакетом обновления 1

http://support.microsoft.com/default.aspx?scid=kb;EN-US;922836

Вы всегда можете расширить Active Directory с помощью нового поля для этой цели.

Вот документ который включает инструкции по добавлению нового атрибута и ограничению разрешений на атрибут.

Это значение следует рассматривать как аналог пароля, к которому даже администраторы не должны иметь доступа (если возможно), как и текущий пароль AD.

Это не правильно, это даже не так. Пароль не сохраняется. Хэш сохраняется, и администраторы домена могут получить к нему доступ. Фактически, вы даже можете настроить AD для хранения пароля в обратимом шифровании, если хотите.

В AD нет ничего, от чего можно было бы не допустить администраторов домена. Если вы удалите права или даже запретите, администратор домена может взять на себя ответственность и снова добавить себя. Это отличается от Novell NDS, где администратор подразделения может безвозвратно заблокировать администраторов более высокого уровня.

Лучшее, что вы можете сделать, - это использовать существующий или новый атрибут и ограничить доступ. Вы можете не допустить к нему администраторов и включить аудит для атрибута, чтобы любое изменение доступа или разрешений регистрировалось.