Ядро сервера Windows Server 2008 R2: Безопасное подключение филиала

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

Удаленные филиалы часто охватывают значительное пространство, таких филиалов немного, в каждом находится небольшая часть «пользовательского населения», они связаны с сайтами, где расположены центры данных, по медленным сетевым соединениям и как правило в сайтах редко находится квалифицированный ИТ-администратор. Каждая из перечисленных особенностей сама по себе сильно усложняет задачу администратора, а вместе они в состоянии гарантировано отравить жизнь даже самому матерому специалисту по ИТ.

Хотя большинство сред филиалов обычно схожи (их особенности мы только что перечислили), существуют также особые корпоративные требования, определяющие, как должна работать среда. Важность безопасности или степени централизации технологических ресурсов может отличаться в разных удаленных филиалах. Независимо от того, как работает тот или иной филиал, Windows Server 2008 R2 представляет новые возможности развертывания обновленных технологий, которые в корне меняют порядок развертывания и защиты контроллеров доменов в удаленных средах.

Безопасное решение

Обеспечение безопасности развернутого филиала — стандартная задача, выполняемая доменными службами Active Directory (Active Directory Domain Services, ADDS). Службы ADDS прекрасно справляются с уникальными характеристиками и ограничениями удаленных сред. В Windows Server 2008 R2 появилось значительное число новых функций и значительно усовершенствована процедура развертывания ADDS. Давайте познакомимся, как безопасно развертывать Windows Server 2008 R2 в такой среде. Наш рассказ охватит характеристики типичного филиала, ключевые элементы проекта и рекомендованные для Windows Server 2008 R2 варианты развертывания.

Наибольший интерес в Windows Server 2008 R2 представляют контроллеры домена только для чтения (RODC). Вообще говоря, RODS развертывают там, где требуются службы контроллера домена, но невозможно обеспечить надлежащую физическую безопасность полноценного контроллера домена. Может оказаться, что благодаря улучшенной защите и расширенным возможностям управления замена существующих контроллеров доменов на RODS вполне удовлетворит потребности в службах ADDS во многих филиалах. А там, где сейчас нет контроллеров домена, RODS сможет обеспечить наличие в среде служб ADDS.

Другая важная особенность — обновленная версия ядра сервера, варианта установки Windows Server 2008 R2, в котором предоставляется минимально необходимая среда для выполнения особых поддерживаемых ролей сервера, например роли «контроллер домена».  При развертывании ядра сервера устанавливается часть двоичных файлов, необходимых для определенной роли сервера — в нашем случае это RODC. Такой минималистский подход к установке позволяет сократить возможности проведения атак, а также снизить требования и упростить управление. Также такой подход позволяет снизить требования к ресурсам, необходимых для размещения сервера RODC.

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

Такая конфигурация очень популярна, хотя и не всегда отвечает требованиям к филиалам всех и каждой организации.В частности, самые главные особенности этой конфигурации уже описаны в текущих рекомендациях для пакета Windows Server 2008 Security Compliance Management Toolkit.

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

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

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

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

Ядро сервера устанавливается на чистую машину — нет способа обновления до ядра сервера при установке. Что касается ролей сервера, то в общем случае с точки зрения безопасности рекомендуется удалить с сервера все службы и роли сервера, которые непосредственно не нужны для нормальной работы RODC. Данное решение на базе RODC не предусматривает размещение на ядре сервера RODS на базе Windows Server 2008 R2 никаких дополнительных служб или ролей сервера кроме глобального каталога и DNS-сервера.И такой подход исповедуют все большее число предприятий.

Порядок развертывания контроллеров доменов — еще один критически важный аспект проекта. Рекомендованный порядок таков:сначала устанавливаются службы ADDS в центрах данных на предварительно созданных в каждом домене рядовых серверах с установленной ОС Windows Server 2008 R2, начинают с корня леса, постепенно передавая все роли хозяев операций в каждом домене на соответствующие контроллеры доменов. Далее продолжают развертывать сайты центров данных, полностью удаляя все унаследованные контроллеры доменов в этих сайтах. Это позволяет обеспечить надежность и хорошую управляемость служб ADDS, а также способствует упрощению самого процесса развертывания RODC  После замены контроллеров доменов в центрах данных запускают контроллеры доменов филиалов.

Лес Windows Server 2008 R2 и подготовка домена

Перед развертыванием в существующей среде отдельного контроллера домена под управлением Windows Server 2008 R2 нужно подготовить лес Active Directory и домены утилитой Adprep.exe. Сначала надо обновить схему леса на контроллере домена, обладающем ролью «хозяин схемы» командой adprep /forestprep. На этом этапе модно обновить лес командой adprep /rodcprep, которая подготовит лес к установке RODC. Чтобы подготовить все дочерние домены, надо выполнить команду adprep /domainprep /gpprep на контроллере домена, хозяине инфраструктуры.

Наконец, надо развернуть по крайней мере один поддерживающий запись контроллер домена под управлением Windows Server 2008 R2 в домене, где предполагается разместить RODS. Стоит заметить, что в средах, где выполнялась предназначенная для Windows Server 2008 версия команды Adprep.exe, после обновления до Windows Server 2008 R2 придется повторно выполнить все команды, используя версию Adprep.exe для R2 версией.Единственное исключение — команда adprep /rodcprep, которая не выполняет ничего нового по сравнению с Windows Server 2008.

Размещение RODC

С точки зрения проектирования архитектуры рекомендации по размещению RODC изменились с появлением политики репликации паролей (Password Replication Policy, PRP). Например, RODS может поддерживать репликацию разделов домена с полноценным контроллером домена под управлением Windows Server 2008 R2. Поскольку в большинстве сред филиалов поддерживается сетевая топология «звезда», сайты ADDS с RODC скорее всего будут подключены к центру данных, где размещены полноценные контроллеры доменов под управлением Windows Server 2008 R2, с помощью одной связи сайтов с самой низкой стоимостью.

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

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

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

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

Управление мобильными пользователями — еще одна сложность проекта многих сред филиалов. Часто среды филиала включают пользователей и ресурсы, которые нуждаются в кешировании своих учетных записей на некотором сервере RODS, чтобы получать доступ к службам. Лучше всего создавать эти учетные записи заранее, как они создаются для новых сотрудников компании. Однако из-за случайности и непредсказуемости маршрутов перемещения мобильных сотрудников этот вариант часто невозможен, особенно если много сотрудников активно перемещаются между многими сайтами RODC.

Решить эту проблему можно созданием дополнительных учетных записей в соответствующей политике PRP на RODC. В особых случаях, когда группе учетных записей требуется доступ ко всем политикам PRP на RODC, можно использовать стандартную группу разрешенной репликации паролей контроллера домена только для чтения (Allowed RODC Password Replication Group).  Однако использовать эту группу надо с осторожностью, так как учетные записи членов этой группы кешируются на всех RODS.

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

Это может быть особенно важным в процессе начального развертывания RODC, когда все учетные данные учетных записей в сайте RODC должны кешироваться. После настройки PRP и определения кешируемых учетных записей можно использовать предварительно загруженные на RODC пароли. Однако важно иметь в виду, что у использования двух традиционных средств для предварительной загрузки паролей есть некоторые ограничения. На данный момент при использовании консоли «Active Directory – пользователи и компьютеры» (Active Directory Users and Computers) или команды repadmin нельзя работать с группами безопасности.

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

For /F %%a in ('"dsquery group dc=corp,dc=contoso,dc=com -name <Groupname>| dsget group -members"') do (Repadmin /rodcpwdrepl <RODCname> <RWDCname> %%a)

Предварительная установка RODC

Из двух доступных в Windows Server 2008 R2 методов установки контроллеров домена для непосредственной установки предпочтительнее вариант с предварительной установкой. Альтернативная возможность — традиционный процесс, существующий в предыдущих версиях Windows. В предварительной установке используется имеющаяся в Windows Server 2008 R2 функция разделения ролей администратора (Administrator Role Separation, ARS), которая позволяет делегировать администраторам, не занимающимся управлением службами, способность устанавливать и управлять серверами RODC, не предоставляя прав на управление Active Directory.

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

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

Источник повышения RODC

В качестве источника повышения RODC используется вариант с использованием параметра «Установить с носителя» в связке с предварительной установкой. Это позволяет значительно сократить объем данных, реплицируемых на RODC в процессе установки ADDS. При использовании Ntdsutil.exe на доступном для записи контроллере домена Windows Server 2008 R2 доступны четыре типа установочных носителей, из которых для нашего случая подходят только два: RODC и RODC с SYSVOL.

Носители RODC аналогичны носителям полной установки, но не содержат в кеше секреты, например пароли. Это очень важно с точки зрения безопасности филиала. Использовать носители RODC можно только, кода имеется доступный для записи контроллер домена Windows Server 2008 R2. Однако носители установки второго вида, RODC с SYSVOL, предъявляют существенно большие требования к инфраструктуре. Утилита Ntdsutil.exe сумеет создать RODC с использованием носителя SYSVOL, но для использования этих носителей в процессе установки требуется репликация распределенной файловой системы (DFS-R) для репликации SYSVOL, для чего в свою очередь нужен режим работы домена Windows Server 2008 R2.

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

Выполнение DCPROMO

При развертывании описываемой конфигурации Мастер установки контроллера домена Active Directory будет недоступен, потому что для него нужен RODS под управлением ядра сервера Windows Server 2008 R2. Этот мастер нельзя использовать для фактического повышения RODC. Поэтому в дополнение к промежуточной установке с носителя автоматическая установка средствами Dcpromo.exe с файлом ответов установит роль «контроллер домен». С точки зрения безопасности и управляемости эта особенность решения обеспечивает безопасное и согласованное создание контроллеров домена, что в свою очередь гарантирует безопасность ADDS и согласованность конфигурации во всех филиалах.

Кроме того, автоматизированный, предсказуемый и воспроизводимый порядок развертывания позволяет снизить вероятность внесения на сервер постороннего ПО, служб и конфигураций в процессе ручного развертывания. Вот пример команды dcpromo и простого файла ответов:

DCPROMO /unattend:c:\unattend.txt

[DCINSTALL]

ReplicaDomainDNSName=corp.contoso.com

UserDomain=corp

UserName=corp\<delegated RODC security group>

Password=*

ReplicationSourcePath=C: \IFM

Safemodeadminpassword=<password>

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

Репликация

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

RODS также обеспечивает автоматическое равномерное распределение объектов исходящих подключений среди серверов-плацдармов центрального сайта в модели «звезда» — в Windows Server 2003 для этого требовался дополнительная утилита, такая как Adlb.exe. Поэтому до начала развертывания каких-либо серверов RODS рекомендуется обновить ОС всех контроллеров доменов центров данных до Windows Server 2008 R2. Это обеспечит балансировку нагрузки входящей репликации и избавит от необходимости дополнительных мер по предотвращению перегрузки сервера-плацдарма центра данных в процессе развертывания серверов RODC.

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