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

Есть еще некоторые особенности, касающиеся безопасности, о которых стоит упомянуть. Контроллеры домена только для чтения не являются доверенными с позиции доверительных отношений в домене, они трактуются как рядовые серверs. Более того, вы не найдете таких контроллеров в группах «Контроллеры домена» и «Контроллеры домена предприятия». RODC является центром распространения ключей Kerberos только для своего филиала. Это возможно из-за того, что он использует собственную учетную запись KrbTGT и собственные ключи. Для системы DNS появилась возможность создания зоны только для чтения на контроллере RODC. Динамическая регистрация записи компьютера в такой зоне невозможна, взамен этого на DNS-сервер с возможностью записи посылается запрос на регистрацию, и уже после репликации происходит обновление зоны в филиальном сервере DNS.

Для развертывания контроллера RODC необходимо иметь в домене хотя бы один основной (то есть в режиме чтение/запись) контроллер домена под управлением Windows Server 2008. Плюс к этому домен должен находиться на уровне не ниже Windows Server 2003 (смотри врезку «Функциональные уровни домена и леса»). Понятно, что и сам RODC должен работать под управлением серверной ОС последней версии. Использование RODC в варианте установки Server Core дает возможность держать в удаленном филиале безопасный сервер, имеющий небольшие требования по производительности.

Новые политики паролей

Очень часто на технических форумах можно было встретить вопросы, касающиеся политик паролей и блокировки учетной записи. Проблема состояла в том, что многие администраторы не могли понять, как при помощи групповых политик назначить ограничения параметров паролей для отдельных групп или организационных единиц. Такая возможность до выхода Windows Server 2008 отсутствовала, и, если было необходимо выделить группу со специфичными настройками для политик паролей, нужно было создавать отдельный домен, так как они могли быть применены только к уровню домена.