Где я храню уязвимые данные в Active Directory?
Я не знаю, видели ли Вы их, но Mark Russinovich из Microsoft (раньше SysInternals, который первоначально записал, Проводник Процесса) пишет обычные статьи о его блоге о диагностировании проблем Windows с помощью инструментов Sysinternals.
Этот демонстрирует его процесс, поскольку он пытается разыскать неустойчивый Проводник, зависают (который, почти конечно, не является тем же как Вашим, но действительно показывает процесс, который он использует), http://blogs.technet.com/markrussinovich/archive/2005/08/28/the-case-of-the-intermittent-and-annoying-explorer-hangs.aspx
Он использует другие методы (включая захват символов с серверов MS) диагностирующий медленную производительность Windows здесь: http://blogs.technet.com/markrussinovich/archive/2008/09/24/3126858.aspx
Проблема, с которой большинство людей сталкивается, храня данные в AD,
Расширение Схемы (который часто имеет политические последствия компании),
Используя существующий атрибут и редактирование полномочий (который приводит к чрезмерному увеличению размера AD/ACL, которое увеличивает Ваш DIT и последующий размер репликации),
Существует альтернатива... лучший выбор в моем уме состоит в том, чтобы использовать эту менее известную функцию AD, чтобы взять существующий атрибут и отметить ее как Конфиденциальную.
Вот детали о процессе
Полномочия по умолчанию в Active Directory таковы, что у Аутентифицируемых Пользователей есть общий доступ для чтения ко всем атрибутам. Это мешает представлять новый атрибут, который должен быть защищен от того, чтобы быть считанным всеми.
Для смягчения этого Windows 2003 SP1 представляет способ отметить атрибут как КОНФИДЕНЦИАЛЬНЫЙ. Эта функция, достигнутая путем изменения searchFlags, оценивает атрибутом в схеме. SearchFlags содержит несколько битов, представляющих различные свойства атрибута. Например, бит 1 средство, что атрибут индексируется. Новый бит 128 (7-й бит) определяет атрибут как конфиденциальный.
Примечание: Вы не можете установить этот флаг на атрибутах основной схемы (полученные из "вершины", такие как общее название). Можно определить, является ли объект основным объектом схемы при помощи LDP для просмотра объекта и проверки systemFlags атрибута объекта. Если 10-й бит, установлен, это - основной объект схемы.
Когда Служба каталогов выполняет проверку доступа для чтения, она проверяет на конфиденциальные атрибуты. Если будет, то в дополнение к доступу READ_PROPERTY, Служба каталогов также потребует доступа CONTROL_ACCESS на атрибуте или его наборе свойств.
По умолчанию только у Администраторов есть доступ CONTROL_ACCESS ко всем объектам. Таким образом только Администраторы смогут считать конфиденциальные атрибуты. Пользователи свободны делегировать это право любой определенной группе, которую они хотят. Это может быть сделано с инструментом DSACLs, сценариями или версией R2 ADAM LDP. С этой записи не возможно использовать ACL Редактор UI для присвоения этих полномочий.
Процесс маркировки Конфиденциального атрибута и добавление пользователей, которые должны просмотреть атрибут, имеет 3 Шага
Определение, что атрибут отметить Конфиденциальный, или добавление атрибута для маркировки Конфиденциальный.
Отмечание его конфиденциальный
Предоставление корректным пользователям права Control_Access, таким образом, они могут просмотреть атрибут.
Для получения дополнительной информации и пошаговые инструкции, обратитесь к следующей статье:
922836, Как отметить атрибут как конфиденциальный в Пакете обновления Windows Server 2003 1
http://support.microsoft.com/default.aspx?scid=kb;EN-US;922836
Это значение нужно считать подобным паролю, где даже у администраторов не должно быть доступа (если возможный), точно так же, как текущий AD Пароль.
Это не корректно, это даже не неправильно. Пароль не хранится. Хеш хранится, и администраторы домена могут получить доступ к этому. На самом деле можно даже настроить AD для хранения пароля в обратимом шифровании, если Вы хотели.
Нет ничего, что можно не допустить администраторов домена от в AD. Если Вы удаляете права или даже Отклоняете, администратор домена может взять владение и добавить себя, въезжают задним ходом. Это в отличие от NDS Novell, где администратор OU мог безвозвратно заблокировать высокоуровневых администраторов.
Лучшее, которое можно сделать, использовать существующий или новый атрибут и ограничить доступ. Можно не допустить администраторов в него, и Вы могли позволить контролировать на атрибуте так, чтобы любое изменение доступа или полномочий было зарегистрировано.