Контроллеры домена Windows Server 2008 R2: Тщательное планирование RODC

В отсутствие физической безопасности становится жизненно важным сконцентрироваться на безопасности данных. Windows Server 2008 и R2 предоставляют новые способы обеспечить безопасность, которые кажутся специально адаптированными для удаленных офисов, где физическая безопасность может быть не очень надежной. Контроллеры домена только для чтения (RODC) – новая функция доменных служб Active Directory в системах Windows Server. Они представляют собой фундаментальное изменение по сравнению с прежнем использованием контроллеров домена.

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

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

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

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

Расширение филиалов с помощью RODC

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

Филиалам, уже имеющим полноценные контроллеры домена, возможно, не нужно развертывать RODC. Однако в данной ситуации RODC не просто могут соответствовать требованиям, связанным с AD DS. Они могут даже превзойти их с отношении более строгой безопасности, улучшенного управления, упрощенной архитектуры и более низкой стоимости приобретения и эксплуатации. Для местоположений, где требования к безопасности или управляемости запрещают использовать контроллеры доменов, RODC могут помочь в введении контроллеров доменов в среду, а также предоставить некоторые удобные локализованные службы.

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

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

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

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

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

Предварительное планирование

Перед началом какого-либо формального планирования RODC следует проявить должное внимание и выполнить фундаментальное предварительное планирование AD DS. Это планирование должно включать в себя ключевые задачи, такие как проверка существующей логической структуры AD DS, а также проверку того, что модель администрирования и физической структуры AD DS поддерживает существующие технические требования и бизнес-требования. Кроме того, следует учесть требования к оборудованию, стратегии по обновлению ПО, а также применимые известные проблемы операционной системы, а также оценить обязательные требования RODC AD DS. Эта информация будет критически важной в процессе планирования и развертывания. Эта информация подробно задокументирована в проверочных списках по развертыванию.

Установка и управление

В RODC есть важная функция управления, которая называется Administrator Role Separation (ARS). Она передает администраторам, не являющимся администраторами службы, возможность установки и администрирования серверов RODC, не предоставляя при этом прав Active Directory. Это значительное изменение традиционного подхода к разработке сервера контроллера домена, передаче прав администрирования и процедурам развертывания. Разделение полномочий становится все более важным, когда критически важные приложения требуют установки на контроллерах домена, или для местоположениях, где размещены одиночные многоцелевые серверы.

Дополнительные полномочия сервера

Общее правило – следует убрать с сервера все роли, которые не нужны для функционирования RODC. Следовательно, единственные роли, которые следует добавить к RODC – это роли DNS и глобального каталога сервера. Роль сервера DNS необходимо установить на каждом RODC, чтобы местные клиенты DNS могли выполнять ее разрешение, когда сетевое подключение к полноценному контроллеру домена недоступно. Тем не менее, если роль сервера DNS не установлена через Dcpromo.exe, ее необходимо установить. Следует использовать Dnscmd.exe для перечисления RODC в разделах каталога приложений DNS, в которых находятся интегрированные зоны Active Directory. Следует также настроить RODC как серверы глобальных каталогов, чтобы они могли выполнять проверку подлинности и запросы глобальных каталогов, используя только RODC. Если роль глобального каталога не подходит, можно использовать универсальное групповое кэширование. Успешная проверка подлинности RODC может полностьюд зависеть от настройки PRP RODC.

Размещение RODC

С момента введения PRP RODC размещение контроллеров домена претерпело существенные изменения. RODC должны уметь выполнять репликацию раздела домена с полноценного контроллера домена, при запущенном Windows Server 2008 или Windows Server 2008 R2 на том же домене, поскольку только контроллеры домена могут привязать PRP к RODC. Чтобы гарантировать нормальную репликацию, полноценный контроллер домена необходимо разместить на сайте AD DS, который имеет минимальную по затратам связь с сайтом, содержащим RODC.

Если не удается установить эту настройку, репликация RODC должна будет зависеть от параметра Bridge all site links или связи между ссылками сайта: сайта, ссылки которого содержат сайт RODC, и сайта полноценного контроллера домена. Если транзитивность сайта или координация ссылок сайта – это не тот вариант, которые можно использовать, можно создать новые ссылки сайта, чтобы непосредственно соединить сайт RODC и сайт полноценного контроллера домена.

Общий совет: не нужно размещать другие контроллеры домена на том же сайте AD DS , что и RODC, поскольку операции клиента могут стать непоследовательными, а поведение клиента – непредсказуемым. Базовые операции, такие как проверка подлинности, чтение и запись LDAP, а также изменение паролей, могут вести себя по-разному в зависимости от разрозненных настроек RODC, версии полноценных контроллеров домена Windows, а также в зависимости от того, доступно ли подключение по сети к другому полноценному контроллеру домена.  Все пользователи и ресурсы не должны находиться на одном домене сайта RODC. RODC не сохраняют надежных паролей. Они требуют междоменной авторизации для передачи запросов на проверку подлинности различным контроллерам домена в каждом домене. Исходя из предположения, что все полноценные контроллеры домена находятся на отдельных сайтах, все междоменные запросы на проверку подлинности будут зависеть от подключения к сети и не будут работать в случае сбоя этого подключения.

Масштабируемость и репликация

RODC также предоставляет преимущества, связанные с масштабируемостью, которые пригодятся для более крупных или более сложных реализаций AD DS. Например, RODC обеспечивают репликацию по всем каталогам. Следовательно, развертывание RODC в филиалах сокращает нагрузку производительности на серверах узлового соединяющего сайта, который обычно обрабатывает входящую репликацию для контроллеров домена филиала. С точки зрения стоимости владения это сокращает количество объектов подключения, которые нужно создавать и администрировать. Это может также сократить необходимое количество контроллеров домена узлового сайта.

RODC также содержит ряд улучшений по сокращению нагрузки, что позволяет автоматически и равномерно распространять исходящие объекты подключения по серверам узлового сайта. В более ранних версиях ОС Windows для этого требовалось выполнять рутинную работу вручную. Теперь же, когда средство KCC на RODC обнаруживает, что промежуточный сервер добавлен к узловому сайту или удален из него, оно определяет, следует ли переключить партнера по репликации на новый промежуточный сервер. Это выполняется путем запуска алгоритма и вероятностной балансировки нагрузки. Если RODC добавлены в местоположениях филиалов, KCC будет также выполнять балансировку входящих подключений на промежуточных серверах существующего узлового сайта.

Кэширование учетных данных

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

Серьезно рассмотрите этот шаг, поскольку изменения PRP могут повлиять как на безопасность, так и на доступность служб. Например, результатом отсутствия кэшированных учетных записей может стать высокая безопасность, но любой автономный доступ в случае сетевого подключения к полноценному контроллеру домена становится доступным. И наоборот – при большом процентном соотношении кэшируемых учетных записей (например, группа пользователей домена) безопасность становится гораздо ниже, но при этом уровень доступности службы для кэшируемых учетных записей – гораздо выше. Разработки PRP будут различаться в организациях по причине индивидуальных бизнес-требований и технических требований.

После создания модели PRP придется настроить PRP на каждом RODC, чтобы выполнять кэширование нужных учетных записей.  Рекомендуется настроить PRP с явными разрешениями и не изменять список запретов по умолчанию. Список запретов является критически важным, посколько предотвращает кэширование критически важных учетных данных (таких как данные администраторов службы AD DS) на RODC.

Еще один ключевой аспект разработки PRP – определение того, будут ли кэшируемые учетные записи распространяться заранее с паролями. По умолчанию учетные данные кэшируемых учетных записей не кэшируются до изначального входа в RODC, когда запрос на проверку подлинности передается на полноценный контроллер домена Windows Server 2008 или Windows Server 2008 R2 и клиенты реплицируются в RODC. Это значит, что при отсутствии сетевого подключения к полноценному контроллеру домена до того, как кэшируемые учетные записи пройдут проверку подлинности в RODC, произойдет сбой входа в систему, даже несмотря на том, что учетные записи настроены как кэшируемые.

Для решения этой проблемы можно вручную предварительно распространить кэш пароля сразу после настройки PRP и маркировки учетных записей как кжшируемых.  Для выполнения этой операции также требуется сетевое подключение между полноценным контроллером домена Windows Server 2008 или Windows Server 2008 R2 и RODC. Можно выполнить эти действия заранее, во время развертывания, задолго до того, как кэшируемые пользователи впервые войдут в систему.

Вы можете пользоваться этим фундаментальным руководством по разработке архитектуры в планировании RODC. Рассмотрев ключевые соображения разработки, эта статья содержит эффективное руководство по началу разработки подробного и полного решения RODC. Это процесс непрост; он требует значительного времени на рассмотрение новых функций и соображений разработки в соответствии со спецификой среды и с требованиями организации.