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

По сути, я храню закрытый ключ (Hash) в любом из атрибутов 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. Если вы удаляете права или даже отказываете, администратор домена может вступить во владение и добавить себя обратно. Это в отличие от NDS Novell, где администратор подразделения может безвозвратно заблокировать администраторов более высокого уровня.

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