Настройка контроллера домена Active Directory для чтения RODC в Windows Server 2008R2

Всем привет, в предыдущей статье я рассказывал, Как установить контроллер домена для чтения RODC Active Directory в Windows Server 2008 R2 и для чего его используют. Теперь давайте посмотрим его настройки и поймем как его эксплуатировать. Уверен, что прочитав данную статью, вы для себя почерпнете уйму полезной информации, которую вы сможете легко применить у себя в инфраструктуре, для ее модернизации и улучшения безопасности.

Открываем 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 можно настроить на кэширование паролей, это делается с помощью политики репликации паролей (Password Replication Policy). Политика репликации паролей определяет, разрешено ли копирование с контроллера с доступом записи на RODC для мандатов данного пользователя или компьютера. Если определенному пользователю разрешен доступ, его мандаты кэшируются на RODC при входе.

Когда учетная запись успешно аутентифицирована вопреки RODC, он пытается связаться с контроллером домена, имеющим доступ записи, на HUB сайте. Если пароль не кэширован, RODC направит запрос аутентификации на контроллер с доступом записи. Контроллер, получивший запрос, распознает, что запрос направлен с RODC и сверяется с политикой репликации паролей.

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

Кэширование мандатов можно оставить отключенным, это снизит возможный риск, но с другой стороны это увеличит объем WAN трафика, поскольку все запросы аутентификации будут направляться на контроллер с доступом записи на головном HUB сайте.

Видим, учетные данные которые хранятся на данном контроллере.

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

Переходим на вкладку Результирующая политика, она может показать какое состояние кэширования у выбранной учетной записи. Жмем Добавить.

Выбираем учетку.

Видим, что моей учетной записи запрещено кэширование на данном DC.

Еще есть функция предварительные пароли. Смысл ее заключается в том чтобы заранее сохранить пароль учетной записи которая будет проходить авторизацию через rodc, и не будет запроса на пишущий контроллер.

Добавим пользователя ivanov.i

Вас спросят отправить на текущий контроллер, жмем да

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

Видим, что все успешно передано

Давайте теперь попробуем подключиться через ADUC к нашему контроллеру для чтения. Правым кликом по текущему домену и выбираем сменить контроллер.

Вы увидите предупреждение Выбранный контроллер домена доступен только для чтени. Выполнение операций записи невозможно.

Попробуйте теперь открыть свойства любой учетной записи, как можете заметить все неактивно для редактирования.

У групп тоже самое

В дополнение к RODC, можно также устанавливать службу DNS. DNS сервер, запущенный на RODC не поддерживает динамических обновлений. Однако клиенты могут использовать DNS сервер для запроса разрешения имени.

Поскольку служба DNS доступна только для чтения (Read-Only), клиенты не смогут обновлять в ней записи. Однако если клиент хочет обновить свои записи DNS, RODC отправит запрос на сервер DNS с доступом записи. Обновленная запись затем будет скопирована с сервера DNS с доступом записи на DNS сервер на RODC. Это специальная репликация одного объекта (DNS запись), позволяющая обновлять серверы RODC DNS. Клиенты офисов филиалов получают более быстрые разрешения имен благодаря этой репликации.

Службы Restartable Active Directory Domain Services. В Windows Server 2008 службы Active Directory Domain Services теперь можно останавливать и перезапускать. Это означает, что вы можете остановить AD DS, чтобы выполнить определенные задания и обслуживание, что в предыдущих версиях Windows Server требовало перезагрузки в режиме Directory Services Restore Mode (DSRM). Это отличная характеристика для прописывания сценариев и автоматизации этих заданий.

Заходим в DNS и видим, что отредактировать записи невозможно

И создать тоже ничего нельзя

В оснастке Active Directory тоже по действиям все пусто

Немного о безопасности RODC.

Есть несколько категорий угроз, с которыми приходится считаться при развертывании систем филиалов. Первая ситуация — контроллер домена украден. Кто-то просто унес контроллер или его диск. Кроме того что локальные службы не могут работать, существует вероятность того, что злодей в конце концов получит доступ ко всем именам и паролям пользователей в домене, сможет повысить уровень собственных привилегий и воспользоваться ресурсами компании или вызвать отказ в обслуживании. В целях борьбы с такого типа угрозами в RODC по умолчанию хэшированные пароли не хранятся в дереве DIT. Когда пользователсь в первый раз проходит проверку подлинности на данном контроллере RODC, контроллер передает запрос полному контроллеру домена (FDC). FDC обрабатывает запорс и, если все проходит удачно, контроллер RODC отправляет запрос репликации для получения хэшированного пароля.

Если контроллер RODC взломан, он теоретически может запросить хэшированный пароль к учетной записи, дающей доступ к конфиденциальной информации. Чтобы предотвратить такую ситуацию, администратор может настроить политику репликации паролей для каждого контроллера RODC. Политика репликации представляет собой два атрибута объекта-компьютера контроллера RODC. Атрибут msDS-RevealOnDemandGroup содержит различающиеся имена групп, пользователей, компьютеров, пароли к учетным записям которых можно хэшировать на контроллере RODC (обычно это пользователи и компьютеры, входящие в тот же сайт, что и сам контроллер RODC). Атрибут msDS-NeverRevealGroup содержит различающиеся имена групп, пользователей, компьютеров, пароли которых хэшировать на контроллере RODC нельзя (например, пароль администратора ни в коем случае не следует хэшировать на контроллере RODC). Когда RODC запрашивает хэшированный пароль к той или иной учетной записи, FDC оценивает запрос согласно политике репликации паролей и определяет, можно создать реплику пароля на RODC или нельзя. В случае кражи контроллера домена это позволяет снизить уязвимость тех паролей, которые были хэшированы на RODC в момент его отключения от сети, и устранить риск взлома важных паролей.

Объект-компьютер контроллера RODC имеет еще два атрибута, позволяющие определить, какие именно пароли нужно хэшировать. Атрибут msDS-AuthenticatedAtDC содержит список учетных записей, прошедших проверку подлинности на контроллере RODC, а атрибут msDS-RevealedList — список учетных записией, пароли которых в данный момент хранятся на контроллере RODC.

Хэшированные пароли пользователей и компьютеров — не единственный секрет контроллера домена. Учетная запись KrbTGT содержит ключи Центра распространения ключей Kerberos — службы, работающей на каждом контроллере домена. Обычно все службы KDC в домене используют одну и ту же учетную запись KrbTGT, поэтому есть опасность, что злоумышленник сможет извлечь ключи из украденного контроллера и взломать оставшуюся часть домена. Контроллеры RODC используют собственные учетные записи KrbTGT и собственные ключи, поэтому такая возможность отпадает.
Кроме всего прочего, приложения нередко хранят пароли и другую секретную информацию в DIT. Если злоумышленник украдет контроллер домена, он может воспользоваться сохраненными паролями и получить доступ к приложениям. Чтобы снизить риск такого развития событий, службы доменов в Windows Server 2008 позволяют администраторам определить набор атрибутов контроллеров доменов только для чтения (RO-FAS). Атрибуты, входящие в набор RO-FAS, не реплицируются на контроллеры RODC, и поэтому не могут быть обнаружены на украденном контроллере домена. Атрибуты RO-FAS назначаются путем настройки 9 бита (0×0200) в атрибуте searchFlags, в соответствующем объекте attributeSchema.

Еще одна категория опасностей, с которыми сталкиваются контроллеры доменов в филиалах, выглядит следующим образом: администратор локального сервера несанкционированно расширяет собственные права, пользуясь привилегиями контроллера домена, и получает доступ к дополнительным ресурсам домена или пытается провести атаку типа «отказ в обслуживании». Опять же, если локальный администратор физически имеет доступ к контроллеру, вы вряд ли сможете ему помешать, однако вы можете не позволить ему взломать остальные контроллеры домена.

На полном контроллере домена контроллеры RODC не указываются как доверенные. С точки зрения доверительных отношений, контроллер FDC относится к контроллерам RODC так же, как к прочим серверам, входящим в домен. Контроллеры RODC не входят ни в группу «Контроллеры домена предприятия», ни в группу «Контроллеры домена». При помощи учетной записи RODC вообще мало что можно обновить в каталогах, поэтому даже если злоумышленник взломает учетную запись RODC, он практически никаких полезных для себя привилегий не получит.

Контроллеры RODC даже не включаются в обычную топологию репликации DS. Поскольку RODC внешне ничем не отличается от остальных серверов домена, средство проверки согласованности знаний (или KCC — этот процесс имеется на каждом контроллере домена, отвечающем за расчет топологии репликации DS) не создает для контроллеров RODC объектов соединений. Ни полный контроллер домена, ни контроллер RODC не станет проводить репликацию на основе контроллера домента тольео для чтения. С другой стороны, контроллер RODC создает объект соединения, представляющий собой соглашение о входящей репликации с полного контроллера домена, но этот объект хранится только в реплике самого контроллера RODC — на другие контролеры домена он не копируется. С точки зрения репликакции, контроллер RODC сродни ловушкам для тараканов: всех впускать, никого не выпускать.

Очистка кэшированных паролей

Вот так вот просто производится настройка контроллера домена Active Directory для чтения RODC в Windows Server 2008R2.

Материал сайта pyatilistnik.org