У моїй попередній статті я пояснив основні причини, за якими Microsoft вирішила повернутися до технології RODC в Windows Server 2008. Ця стаття продовжує серію, і ми перейдемо до вивчення деяких практичних аспектів роботи з Read Only Domain Controllers.
Облікові дані користувача
У попередній статті я сказав, що на RODC контролери домени не передається вся інформація про всіх користувачів домену. Насправді інформація про облікові записи користувачів все-таки зберігається на RODC, на такий контролер домену просто не виконується реплікація паролів користувачів. І якщо хтось вкраде контролер домену з філії, він не зможе використовувати інформацію з бази даних Active Directory для отримання паролів користувачів.
атрибути користувачів
За замовчуванням паролі, це єдиний атрибут користувачів, що не реплікуються на Read Only Domain Controller. Проте, існує можливість ручного налаштування Windows, що дозволяє заборонити реплицироваться і інші атрибути користувачів.
Так в яких випадках можна використовувати цю функцію? Якщо ви використовуєте Active Directory тільки в якості механізму аутентифікації, то найімовірніше, вам вона не знадобиться. Однак майте на увазі, що є організації, які сильно залежать від бази Active Directory, яка застосовується не тільки для аутентифікації.
Досить часто у великих організація, в яких використовуються різні користувальницькі додатки і бази даних, для зменшення кількості помилок і дублювання інформації користувачів, вважають за краще використовувати єдине місце зберігання всієї інформації про співробітників (телефони, адреси, контакти і т.д.), і відмінним місцем для цього є Active Directory.
Наприклад, я знаю одну організацію, яка розробила додаток для управління кадрами, яке вони застосовують всередині свого периметра. І хоча основна частина даних зберігається в базі даних SQL, але такі речі, як імена співробітників, посади, номера телефонів і т.д. зберігаються в Active Directory, як атрибути облікового запису. А в базі SQL Serverа зберігаються такі дані, як номери ІПН, інформація про зарплату, і в цій базі не містяться імена співробітників. Єдино, що пов'язує бази даних AD і SQL - це номер співробітника, який присутній в обох базах даних.
Я навів вам цей приклад для того, щоб було зрозуміло, що в ряді організацій в атрибутах користувача AD може міститися конфіденційна інформація. І в тому випадку, якщо така інформація не потрібна в філії, ви можете заблокувати її реплікацію на контролер домену філії.
Ще однією особливістю технології Read Only Domain Controller є те, що такий контролері також може бути налаштований як DNS сервер, доступний тільки на читання. По суті це означає, що якщо зловмисник отримає доступ до сервера Read Only Domain Controller, він не зможе паралізувати роботу корпоративного DNS.
адміністративні питання
Я впевнений, що до теперішнього часу у вас з'явилося безліч питань про адміністрування rodc. Спробую відразу відповісти на частину з них.
Як же автентифіковані користувачів, якщо на контролері домену немає інформації про їх паролі?
Тут є хитрість. Як ви знаєте, і з обліковим записом користувача і з обліковим записом комп'ютера асоційований пароль. За замовчуванням, Read Only Domain Controller зберігає тільки свій власний пароль (пароль учеткі комп'ютера) і пароль спеціального аккаунта, під назвою «krbtgt», який використовується протоколом Kerberos.
Оскільки паролі локально не зберігається, все запити на аутентифікацію перенаправляються на звичайний контролер домену, запис на який дозволена. У тому випадку, якщо ви хочете, щоб користувачі могли зайти в системи, навіть якщо жоден звичайний контролер не доступний, вам необхідно включити функцію кешування паролів. При включеному кешуванні в кеші будуть зберігатися паролі тільки тих учеток, які пройшли перевірку автентичності на контролері домену. І навіть якщо ваш домен контролер буде скомпрометований, ви з іншого контролера можете завжди виявити ті облікові записи, паролі яких були кешованими на rodc.
Адміністративна робота з rodc
У багатьох філіальних офісах найчастіше контролер домену використовується ще і як сервер додатків. І в тому випадку, якщо в такому офісі немає окремого ІТ фахівця, ви можете призначити когось із співробітників офісу в якості адміністратора rodc контролера, котрі дають йому прав адміністратора всього домену (можете почитати пост про делегування прав управління контролером домену rodc). Таким чином, він буде мати права тільки на локальне адміністрування такого сервера, і не буде мати можливості щось змінити або зіпсувати в Active Directory. В результаті такої користувач матиме права на установку оновлень ПО і виконання інших повсякденних завдань з адміністрування та обслуговування сервера. Призначення когось адміністратором Read Only Domain Controller схоже на процедуру призначення певного користувача або групи в якості локального адміністратора рядового або автономного сервера.
Посилання на всі матеріали цієї серії:
Робота з контролерами домену Read-Only (RODC) (частина 1)
Робота з Read Only Domain Controller (частина 2)
Робота з Read Only Domain Controller (частина 3)
