Де я зберігаю конфіденційні дані в 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 Як позначити атрибут конфіденційним у пакеті оновлень 1 для Windows Server 2003

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

Ви завжди можете розширити Active Directory для нового поля для цієї мети.

Ось документ, який містить інструкції щодо додавання нового атрибута та обмеження дозволів на атрибут.

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

Це не правильно, це навіть не так. Пароль не зберігається. Хеш зберігається, і адміністратори домену можуть отримати доступ до цього. Насправді ви навіть можете налаштувати AD для зберігання пароля в оборотному шифруванні, якщо цього хочете.

Немає нічого, з чого не можна було б утримувати адміністраторів домену в AD. Якщо ви видалите права або навіть заборонити, адміністратор домену може взяти на себе право власності та додати себе назад. Це на відміну від NDS Novell, де адміністратор OU може безповоротно заблокувати адміністраторів вищого рівня.

Найкраще, що ви можете зробити, це використовувати наявний або новий атрибут та обмежити доступ. Ви можете утримувати адміністраторів від нього, і ви можете ввімкнути аудит атрибуту, щоб будь-які зміни доступу чи дозволів реєструвалися.