Ядро сервера 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 Автор: Пол Ю • Иcточник: TechNet Magazine •
Мой блог находят по следующим фразам