Хранение приватной «строки октетов» в Active Directory;что защищено по умолчанию?

Question

Я по сути храню закрытый ключ (Hash) в любом из атрибутов OctetString в Active Directory.

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

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

Обновление:

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

Answer 1

Вот ответ для парня, который проголосовал за мой вопрос ... это довольно интересно:

Разрешения по умолчанию в 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

Answer 2

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

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

Answer 3

Если вы не планируете полностью блокировать себя в AD, я бы предложил просто добавить класс Aux с вашим атрибутом Octet String и использовать его. (Т.е. не все другие схемы могут иметь один и тот же атрибут с одинаковым синтаксисом. Просто столкнулся с этим с destinationIndicator. SunOne и eDirectory имеют разные синтаксисы схемы.)

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