Відкриваємо Active Directory Користувачі і комп'ютери. Бачимо, наш список контролерів і в їх числі RODC.
RODC забезпечує нормальну вхідну реплікацію Active Directory і змін розподіленої файлової системи DFS з HUB сайту. RODC буде отримувати всі дані Active Directory крім незахищеною інформації; за замовчуванням, такі облікові дані як Domain Admins, Enterprise Admins і Schema Admins виключені з процесу реплікації в RODC.
Якщо додатку потрібно мати дозвіл на запис в Active Directory, RODC відправляє відповідь по протоколу LDAP, який автоматично перенаправляє додаток на контролер домену з доступом записи, розташований на головному HUB сайті. При необхідності RODC також здатний запускати роль глобального каталогу (Global Catalog Role) для більш швидкої реєстрації.
Це велика перевага для офісів філій компанії, оскільки якщо хто-небудь отримає фізичний доступ до сервера, або навіть вкраде його, він зможе зламати персональні паролі облікових записів в Active Directory, але не зможе отримати доступ до незахищених даними, оскільки вони знаходяться не на RODC .
Це також означає, що ці незахищені облікові записи адміністраторів не зможуть зареєструватися в RODC, якщо відсутня WAN з'єднання з головним HUB сайтом.
Перейдемо в контейнер Users і бачимо, що є дві групи, перша Група з заборона реплікації паролів RODC і друга Група з дозволом реплікації паролів RODC.
Як видно з назви кожна несе в собі функції задані в назві, одна дозволяє кешувати всіх хто в неї входить, друга навпаки забороняє.
Подивимося властивості групи з заборона реплікації паролів RODC, і бачимо список людей і груп на вкладці Члени групи, хто за замовчуванням не повинен реплицироваться на контролер для читання.
Взагалі хорошим тоном в плані безпеки краще створювати окремі групи для кожної філії, члени яких можуть реплицироваться на RODC. Створимо для прикладу rodc_cache.
Тепер давайте більш детально подивимося властивості RODC. Переходимо в властивості облікового запису комп'ютера RODC, перейдіть на вкладку Член груп. Бачимо, що він входить до групи Контролери домену - для читання.
Переходимо на вкладку Політика реплікації паролів, бачимо групи яким заборонено або дозволено кешування на rodc.
Натискаємо Додати і занесемо в цей список нашу створену групу rodc_cache.
Ще інтерес представляє вкладка Управляється, бачимо якраз нашу групу яку ми вказували при установці, при бажанні можна змінити.
Переходимо на вкладку Політика реплікації паролів і натискаємо кнопку Додатково
За замовчуванням RODC не зберігає будь-яких призначених для користувача або комп'ютерних мандатів за винятком облікового запису самого RODC і спеціальної облікового запису 'krbtgt', яка є на всіх RODC.
Перевага кешування мандатів полягає в тому, що воно допомагає захистити паролі в офісах філій та зводить до мінімуму незахищеність мандатів в разі, якщо RODC підданий ризику. При використанні кешування мандатів в разі крадіжки RODC, паролі облікових записів і комп'ютерів можна відновити, в залежності від того, яким RODC вони належать.
Кешування мандатів можна залишити відключеним, це знизить можливий ризик, але з іншого боку це збільшить обсяг WAN трафіку, оскільки всі запити аутентифікації будуть направлятися на контролер з доступом записи на головному HUB сайті.
Бачимо, облікові дані які зберігаються на даному контролері.
Так само можна відобразити хто пройшов перевірку автентичності на даному DC. Бачимо, що я логін.
Переходимо на вкладку Результуюча політика, вона може показати який стан кешування у вибраного облікового запису. Тиснемо Додати.
Бачимо, що мого профілю заборонено кешування на даному DC.
Додамо користувача ivanov.i
Вас запитають відправити на поточний контролер, тиснемо та
Якщо вилізе попередження Спочатку необхідно додати обліковий запис в групу з дозволом кешування і перевірити чи не входить вона в забороняє, так як явний заборону сильніше дозволу.
Бачимо, що всі успішно передано
Давайте тепер спробуємо підключитися через ADUC до нашого контролера для читання. Правим кліком по поточному домену і вибираємо змінити контролер.
Ви побачите попередження Обраний контролер домену доступний тільки для читання. Виконання операцій записи неможливо.
Спробуйте тепер відкрити властивості будь-якого облікового запису, як можете зауважити все неактивно для редагування.
У груп теж саме
На додаток до RODC, можна також встановлювати службу DNS. DNS сервер, запущений на RODC не підтримує динамічних оновлень. Однак клієнти можуть використовувати DNS сервер для запиту дозволу імені.
Оскільки служба DNS доступна тільки для читання (Read-Only), клієнти не зможуть оновлювати в ній записи. Однак якщо клієнт хоче оновити свої записи DNS, RODC відправить запит на сервер DNS з доступом записи. Оновлена запис потім буде скопійована з сервера DNS з доступом записи на DNS сервер на RODC. Це спеціальна реплікація одного об'єкта (DNS запис), що дозволяє оновлювати сервери RODC DNS. Клієнти офісів філій отримують більш швидкі дозволу імен завдяки цій реплікації.
Заходимо в DNS і бачимо, що відредагувати записи неможливо
І створити теж нічого не можна
В оснащенні Active Directory теж по діям все порожньо
Трохи про безпеку RODC.
Якщо контролер RODC зламаний, він теоретично може запросити хешірованного пароль до облікового запису, що дає доступ до конфіденційної інформації. Щоб запобігти такій ситуації, адміністратор може налаштувати політику реплікації паролів для кожного контролера RODC. Політика реплікації є два атрибути об'єкта-комп'ютера контролера RODC. Атрибут msDS-RevealOnDemandGroup містить розрізняються імена груп, користувачів, комп'ютерів, паролі до облікових записів яких можна хешірованного на контролері RODC (зазвичай це користувачі і комп'ютери, що входять в той же сайт, що і сам контролер RODC). Атрибут msDS-NeverRevealGroup містить розрізняються імена груп, користувачів, комп'ютерів, паролі яких хешірованного на контролері RODC не можна (наприклад, пароль адміністратора ні в якому разі не слід хешірованного на контролері RODC). Коли RODC запитує хешірованного пароль до тієї чи іншої облікового запису, FDC оцінює запит згідно з політикою реплікації паролів і визначає, можна створити репліку пароля на RODC або не можна. У разі крадіжки контролера домену це дозволяє знизити вразливість тих паролів, які були хешірованного на RODC в момент його відключення від мережі, і усунути ризик злому важливих паролів.
Об'єкт-комп'ютер контролера RODC має ще два атрибути, що дозволяють визначити, які саме паролі потрібно хешірованного. Атрибут msDS-AuthenticatedAtDC містить список облікових записів, що пройшли перевірку автентичності на контролері RODC, а атрибут msDS-RevealedList - список облікових записів, паролі яких в даний момент зберігаються на контролері RODC.
На повному контролері домену контролери RODC не вказуються як довірені. З точки зору довірчих відносин, контролер FDC відноситься до контролерів RODC так само, як до інших серверів, що входять в домен. Контролери RODC не входять в групу «Контролери домену підприємства», ні в групу «Контролери домену». За допомогою облікового запису RODC взагалі мало що можна оновити в каталогах, тому навіть якщо зловмисник зламає обліковий запис RODC, він практично ніяких корисних для себе привілеїв не отримає.
Контролери RODC навіть не включаються в звичайну топологію реплікації DS. Оскільки RODC зовні нічим не відрізняється від інших серверів домену, засіб перевірки узгодженості знань (або KCC - цей процес є на кожному контролері домену, що відповідає за розрахунок топології реплікації DS) не створює для контролерів RODC об'єктів з'єднань. Ні повний контролер домену, ні контролер RODC не стане проводити реплікацію на основі контролера домента тольео для читання. З іншого боку, контролер RODC створює об'єкт з'єднання, що представляє собою угоду про вхідну реплікації з повного контролера домену, але цей об'єкт зберігається тільки в репліці самого контролера RODC - на інші контролери домену він не копіюється. З точки зору реплікакціі, контролер RODC те саме пасток для тарганів: всіх впускати, нікого не випускати.
Очищення кешованих паролів
Механізм очищення кешованих паролів даного користувача на RODC відсутня. Якщо потрібно очистити пароль, що зберігається в RODC, адміністратор повинен скинути його на вузловому сайті. В цьому випадку кешированний в підрозділі пароль стане недійсним для доступу до ресурсів вузлового сайту або інших підрозділів. У разі порушення захисту RODC переустановите паролі, які кешованими на даний момент, а потім перебудуйте RODC.