Усовершенствования Active Directory в Windows Server 2008

Разработчики операционной системы Windows Server 2008 внесли в службы Active Directory (AD) разнообразные улучшения. Самое заметное изменение функциональности AD — новый контроллер домена, доступный только для чтения Read-Only Domain Controller (RODC). Как видно из названия, это новшество заключается в появлении у контроллеров домена режима только для чтения, в котором на нем нельзя записать изменения в базу данных AD, а репликация может быть только односторонней (с других DC). Но, в отличие от резервных контроллеров домена (BDC) Windows NT Windows Server 4.0, RODC можно настроить на хранение только паролей определенных пользователей и компьютеров. Благодаря этому ограничению уменьшается риск для всей сети в случае успешной атаки против RODC. Режим RODC операционной системы Windows Server 2008 заметно повлияет на методы развертывания и управления DC в офисах филиалов и по периметру сети (в демилитаризованной зоне, DMZ) благодаря потенциальному сокращению площади атаки и, как следствие, повышению физической безопасности.

Прежде чем рассмотреть RODC, познакомимся с другими расширениями функциональности AD в Windows 2008. В статье будут представлены функциональные уровни AD: домена Domain Functional Level(DFL) и леса Forest Functional Level (FFL). Знакомство с ними позволит понять требования к развертыванию RODC и другие новые возможности, такие как политики паролей Fine-Grained Password Policies (FGPP) и репликация DFS для SYSVOL, также описанные в статье. Кроме того, будут рассмотрены изменения в DNS, благодаря которым служба DNS успешно работает с RODC.

В табл. 1 приведен список важных усовершенствований AD, в том числе и RODC.

Функциональные уровни AD

Для RODC необходим по крайней мере функциональный уровень FFL2 (все контроллеры леса на базе Windows 2003). Чтобы понять смысл этого требования, вспомним происхождение функциональных уровней AD. Функциональные уровни AD были введены в Windows Server 2003, чтобы избежать конфликтов между функциями AD, специфическими для разных версий операционной системы. Такие конфликты могут возникать, если на контроллерах в домене или лесе AD развернуты различные версии операционной системы. Функциональные уровни особенно важны, если нужно внести изменения, которые влияют на механизм репликации AD или другие функции в масштабе домена или леса, не поддерживаемые низкоуровневыми версиями Windows Server.

Например, если лес Windows 2000 с функциональным уровнем 0 обновляется до леса Windows 2003, то после обновления или замены всех доменов DC на контроллеры домена Windows 2003 функциональный уровень домена DFL можно повысить до DFL2 (все контроллеры домена Windows 2003). Уровень DFL2 позволяет воспользоваться такими дополнительными функциями, как переименование DC и запись метки времени последней регистрации пользователя. После того как все домены леса переведены на уровень DFL2, можно наконец повысить функциональный уровень всего леса FFL до FFL2 (все контроллеры леса на базе Windows 2003). Среди дополнительных возможностей FFL2 — транзитивное доверие между лесами, переименование доменов и репликация связанных значений Linked Value Replication (LVR). LVR — важное улучшение для репликации больших многозначных атрибутов, таких как членство в группах. Благодаря LVR при внесении изменений (например, добавление или удаление члена группы) в длинный список значений, на другие DC реплицируются только эти изменения, а не весь список значений со всеми изменениями списка, как на контроллерах домена Windows 2000.

Обратите внимание, что многие новые функции Windows Server 2008 AD не требуют DFL или FFL, но уровень DFL2 и FFL2 желателен. Компания Microsoft постаралась обеспечить внедрение RODC в доменах, содержащих контроллеры домена Windows 2003. В результате компании могут внедрять RODC без предварительного обновления всего домена или леса. Но, скорее всего, для эффективной совместной работы контроллеров двух версий в одном домене потребуется применить программные исправления к Windows 2003. Дополнительные материалы о развертывании RODC в лесе, содержащем контроллеры домена Windows Server 2003, перечислены во врезке «Учебная литература».

При переходе на уровень DFL3 (все контроллеры домена Windows Server 2008) появляется четыре новые возможности. Две из них отражаются на структуре AD: возможность назначать различные политики паролей пользователям в одном домене и задействовать репликацию DFS для SYSVOL. Ни одна новая функция AD не активируется после перехода на FFL3 (все контроллеры леса Windows Server 2008), т. е. сразу после того, как все DC леса начинают работать на базе Windows Server 2008. Однако переход на FFL3 означает, что все домены леса должны работать с контроллерами Windows Server 2008 и в лес нельзя добавить домены или DC со старыми версиями операционных систем. Список новых возможностей AD на разных функциональных уровнях приведен в табл. 2.

Детальные политики паролей

Для версий операционной системы, предшествующих Windows Server 2008, в домене AD может существовать только одна политика паролей, применяемая к учетным записям пользователей домена. Политика паролей определяет правила, касающиеся длины пароля, срока действия и сложности, для каждой учетной записи домена. Эти параметры определяются объектом групповой политики (GPO, т. е. политикой домена по умолчанию), поэтому многие администраторы полагали, что можно применить несколько политик паролей, просто добавляя объекты GPO в разных организационных единицах (OU) домена. Однако эти объекты GPO применимы только к объектам компьютера, размещенным в соответствующих OU, и, таким образом, воздействуют только на локальные учетные записи этих компьютеров. Во многих компаниях такой подход считают запутанным и неудовлетворительным.

Это ограничение изменилось с появлением детальных политик паролей Fine Grained Password Policies (FGPP) в Windows Server 2008, но только если все DC в домене работают с Windows Server 2008 и домен переключен на функциональный уровень DFL3 (все контроллеры домена Windows Server 2008). На уровне DFL3 все же нельзя применять разные политики паролей к разным OU, но можно применить разные политики паролей непосредственно к учетной записи пользователя или группе. Обратите внимание, что эти политики также позволяют установить различные правила блокировки. Например, можно настроить особо защищаемые учетные записи на блокировку после меньшего числа неудачных попыток, нежели учетные записи обычных пользователей. Чтобы уменьшить общие трудозатраты на управление, рекомендуется задать политику на уровне группы, а не на уровне пользователя.

Пользователи могут быть членами многих групп, более чем одной из которых может быть назначена политика пароля, поэтому в Windows Server 2008 AD появилась возможность определить результирующую политику для любого пользователя. Если пользователю или группам, членом которых он является, не назначено никаких политик, применяется политика домена по умолчанию. В результате компании получают возможность гибко назначать политики паролей. Многие организации приспособились к свойственному операционным системам, предшествующим Windows Server 2008, ограничению «одна политика паролей для одного домена», но некоторым компаниям приходилось развертывать несколько разных доменов только для того, чтобы назначить различные политики. Владельцы Windows Server 2008 могут решить эту проблему с помощью FGPP. Компании могут консолидировать домены, в прошлом организованные для разных политик паролей, и избавиться от затрат на оборудование и обслуживание, связанных с дополнительными доменами. Большинству компаний должна понравиться возможность применить более строгие политики для особых учетных записей в домене, в частности административных и используемых для обслуживания.

Управление новыми политиками осуществляется через объекты параметров пароля Password Settings Object (PSO), созданных в контейнере параметров пароля в системном контейнере домена AD. В настоящее время компания Microsoft не предоставляет специализированного графического интерфейса или средств подготовки сценариев для управления объектами PSO. ADSI Edit — не самый удобный инструмент для этой цели, но он устанавливается на каждом DC и с его помощью не составляет труда управлять объектами PSO. В будущем Microsoft может выпустить другие инструменты для пользователя и новые команды PowerShell, но уже сейчас из Internet можно бесплатно загрузить различные инструменты для управления объектами PSO. Дополнительные сведения об этих инструментах содержатся в материалах врезки «Учебная литература».

Создание PSO с помощью ADSI Edit

С помощью ADSI Edit можно создавать объекты PSO за пять шагов.

1. Убедитесь, что все DC в домене работают с Windows Server 2008 и включен функциональный уровень домена Windows Server 2008 (например, из оснастки AD Users and Computers консоли MMC).
2. Запустите Adsiedit.msc и подключитесь к контексту именования по умолчанию (DC=<домен>), затем перейдите к контейнеру CN=Password Settings Container, CN=System, DC=<домен>.
3. Щелкните правой кнопкой мыши на объекте Password Settings Container и выберите пункты New, Object.
4. Используйте мастер Create Object, чтобы создать новый объект msDS-PasswordSettings. Создайте объект со значениями атрибутов, показанных в табл. 3. Полученный новый объект параметров пароля, My-Windows ServerAdmin-PSO (наряду с другими параметрами), требует, чтобы указанные пользователи вводили 15-символьный пароль, который нужно менять через каждые 30 дней. Объект PSO вступает в силу после того, как будет применен к объектам пользователей и групп (на следующем этапе).
5. Примените вновь созданный объект PSO, просматривая свойства объекта My-Windows ServerAdmin-PSO в программе ADSI Edit и изменяя атрибут msDS-PSOAppliesTo. Введите учетные записи пользователей или группы (членами которых должны быть пользователи), чтобы применить политику к целевым пользователям. Например, я создал группу с именем My-Windows ServerAdmins.

Применение репликации DFS для SYSVOL

Важным улучшением Windows Server 2003 R2 была новая служба репликации файлов. Служба репликации под названием DFS Replication (DFSR) более удачно, нежели предыдущий вариант, интегрирована с DFS. Важным новшеством оказалась возможность ограничить трафик репликации между двумя копиями DFS только изменениями файлов. Если в файле размером в несколько мегабайтов изменилось лишь несколько байтов, технология DFSR обеспечивает пересылку многочисленным партнерам по репликации лишь изменившихся байтов. Ранее при использовании системы NT File Replication System (NTFRS) любые изменения в файле (в том числе изменение атрибутов, таких как разрешения NTFS) приводили к репликации всего файла. В Windows Server 2008 репликация DFS стала еще более масштабируемой, в частности увеличилось число параллельных потоков репликации файлов и устранен порог 5000 целевых объектов DFS для корневых элементов DFS, интегрированных с AD. Отныне корневые элементы DFS могут иметь неограниченное число целевых объектов DFS.

С момента появления DFSR в Windows 2003 R2 администраторы AD надеялись использовать новую службу для SYSVOL после обновления всех DC до Windows 2003 R2. Однако это было невозможно; приходилось по-прежнему использовать неэффективный механизм NTFRS для репликации изменений групповой политики и содержимого папки сценариев (общий каталог NETLOGON). Неэффективность NTFRS была одной из причин, по которым архитекторы AD иногда проектируют многодоменные леса, чтобы сократить трафик NTFRS, если в крупной компании много медленных сетевых соединений, через которые необходимо реплицировать данные с контроллеров домена.

В Windows Server 2008 технологию DFSR наконец можно применить для репликации SYSVOL между контроллерами домена. Все DC в домене должны работать с Windows Server 2008 и домен должен быть переведен на функциональный уровень DFL3 (все контроллеры домена Windows Server 2008). Однако, в отличие от некоторых других функций, относящихся к репликации, при переходе на DFL3 метод репликации SYSVOL не изменяется автоматически с NTFRS на DFSR. В результате довольно громоздкой процедуры, в которой используется новая утилита DfsrMig.exe, имеющаяся на каждом DC, удается создать новый корневой элемент DFS для содержимого SYSVOL. Новый корневой элемент задействует DFSR, а собственно SYSVOL по-прежнему использует NTFRS. В ходе миграции первоначальное содержимое SYSVOL копируется в новую папку SYSVOL, именуемую по умолчанию SYSVOL_DFSR.

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

Изменения DNS

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

Благодаря другому новшеству DNS, относящемуся к AD, клиенты могут обнаруживать контроллеры домена на ближайшем сайте, если не удается подключиться к DC в собственном сайте. Это позволяет избежать соединений с удаленными DC по потенциально медленным линиям во время аварийного переключения. Новая возможность клиентов DNS в операционных системах Windows Vista и Windows Server 2008 основывается на информации о топологии сайтов и стоимости связей между сайтами, хранящейся в AD для определения ближайшего сайта перед направлением в DNS запроса о предоставлении адреса DC в соответствующем сайте. Данная функция была внесена в новейший пакет обновления для Windows XP. Ее можно активировать через объект групповой политики GPO.

Путь к нему: Computer Configuration Administrative Templates SystemNet LogonDC LocatorDNS Records

Включить параметры Try next closest site

Основные преимущества RODC

Проблемой любого развертывания AD с операционными системами Windows 2000 или Windows 2003 всегда было размещение контроллеров домена в удаленных местах (например, офисах филиалов), физическая защищенность которых зачастую ниже, чем у информационного центра компании.

За исключением специальных ролей хозяев операций, таких как Schema Master и PDC-эмулятора, все контроллеры домена, предшествующие Windows Server 2008, в основном равноценны. Администраторы любого DC Windows 2000 или Windows 2003 могут записать изменения в базу данных AD и реплицировать эти изменения в другие DC того же домена или леса AD. Поэтому изменения, внесенные в один DC, могут воздействовать на весь домен или даже целый лес. Злоумышленник с физическим доступом к DC, например в офисе филиала, может без труда предпринять атаку с повышением прав, изменив или даже уничтожив весь лес AD и зависимые службы.

Рисунок 1. Контроллеры домена офиса филиала Windows 2000/2003 могут нанести вред всему лесу AD

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

Windows Server 2008 RODC спроектирован специально для того, чтобы снизить риск «похищения» DC. RODC можно использовать в местах, которые физически защищены не так хорошо, как информационный центр компании, но требуют быстрой и надежной проверки подлинности, даже если отсутствует сетевое соединение с информационным центром. Компаниям, которым необходима проверка подлинности такого качества в офисе филиала, более не требуется развертывать обычные DC с возможностью записи в таких местах. Теперь у компаний есть возможность развернуть контроллеры RODC, которые по умолчанию не реплицируют локальные изменения на все остальные DC. У контроллеров RODC имеется соглашение об односторонней репликации с партнерским DC. Различные изменения в базовой архитектуре репликации Windows Server 2008 обеспечивают неизменность этого соглашения. Например, контроллеры RODC не являются членами группы безопасности Enterprise Domain Controllers, которая дает DC с возможностью записи различные разрешения на запись в базу данных AD.

Политики паролей репликации Password Replication Policies (PRP) определяют, какие пароли реплицируются в RODC. Ключевая проблема управления RODC — определить, как настроить политики PRP. Управление политиками PRP выполняется отдельно для каждого RODC; PRP содержит список учетных записей групп, пользователей или компьютеров, которым предоставлено право (или отказано в разрешении) кэшировать пароли на RODC. Политики PRP хранятся в объекте учетной записи компьютера соответствующего RODC в AD, как показано на экране 1.

Развертывание контроллеров RODC — чрезвычайно удобный способ повысить безопасность в офисах филиалов и демилитаризованной зоне (DMZ). Как показано на рис. 2, в инфраструктуре Windows Server 2008 AD контроллеры домена с возможностью записи размещаются только в полностью доверенных сетях (центрах обработки данных). RODC можно безопасно размещать в периферийных сетях. В результате атака на инфраструктуру AD, показанная на рис. 1, ограничена RODC в офисе филиала. А поскольку RODC по умолчанию не хранит никаких секретных данных администратора (паролей) и обычно кэширует только пароли пользователей сайта RODC, компания подвергается меньшей опасности при поражении RODC, чем полноценного записывающего DC.

Рисунок 2. Использование Windows Server 2008 AD для размещения DC с возможностью записи только в доверенной сети

RODC также может быть глобальным каталогом только для чтения Read-Only Global Catalog (ROGC). Но, хотя каталоги ROGC можно использовать в качестве серверов с адресными списками GAL для клиентов Outlook, они не могут быть глобальными каталогами для серверов Exchange. Это не пройдет без последствий для администраторов, желающих развернуть RODC в офисе филиала и сохранить локальный сервер Exchange.

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

У RODC есть и другие достоинства, которые отличают его от DC с возможностью записи: например, можно делегировать права (или другие роли) локального администратора пользователям или группам домена конкретного RODC, не предоставляя пользователям специальных прав в собственном домене AD. Это достигается с помощью атрибута managedBy объекта компьютера RODC или назначением локальных ролей с помощью утилиты NTDSUTIL. В результате не требуется использовать доменную учетную запись администратора для задач обслуживания DC в офисе филиала, которые могут быть выполнены пользователями с низкими правами. К ним относится и задача повышения уровня новых DC. Эта возможность ограничена контроллерами RODC.

Дальнейшее изучение

В данном обзоре представлено несколько важных улучшений AD, которые появились в Windows Server 2008. Очевидно, что программисты Microsoft потратили много усилий на проектирование RODC. В этом можно убедиться, взглянув на изменения в базовой архитектуре репликации, которые пришлось сделать для RODC. В материалах врезки «Учебная литература» содержится дополнительная информация об улучшениях в AD и RODC.

Гвидо Грилленмейер (guido.grillenmeier@hp.com) — главный специалист по технологиям в подразделении Advanced Technology Group компании Hewlett-Packard. MVP по Microsoft Directory Services и Microsoft Certified Architect

Редакции Windows Server 2008 для RODC

Режим RODC предусмотрен во всех версиях x86 (32-разрядная) и x64 Windows Server 2008 (Standard, Enterprise и Datacenter). Но, поскольку версия Windows Server 2008 Itanium не поддерживает службы AD Domain Services, в ней нет и RODC. Во всех версиях Windows Server 2008 можно развернуть RODC в режиме Windows Server Core.

Таблица 2. Новые функции AD по функциональным уровням

Таблица 3. Значения атрибутов параметров паролей

Изменение имен служб AD в Windows Server 2008

Потребуется время, чтобы привыкнуть к одному небольшому, но важному изменению Active Directory (AD) в Windows Server 2008. Чтобы лучше различать версии AD, в Windows Server 2008 введены новые имена для основных служб. Эти имена приведены в таблице.

Учебная литература

Ресурсы MICROSOFT

AD DS: Read-Only Domain Controllers
technet2.microsoft.com/windowsWindowsServer2008/en/ library/ce82863f-9303-444f-9bb3-ecaf649bd3dd1033.mspx?mfr=true

Domain Controllers Running Windows Server 2003 Perform Automatic Site Coverage for Sites with RODCs
technet2.microsoft.com/windowsWindowsServer2008/en/ library/c0ec828b-7da2-4627-91a8-2a5312a3ceaa1033.mspx?mfr=true

Identity and Access in Windows Server 2008
microsoft.com/windowsWindowsServer2008/ida-mw.mspx

Manage Windows Server 2008 DNS role
forums.microsoft.com/TechNet/ ShowPost.aspx?PostID=1916586&SiteID=17&pageid=0

RODC Features
technet2.microsoft.com/windowsWindowsServer2008/en/ library/0e8e874f-3ef4-43e6-b496-302a47101e611033.mspx?mfr=true

RODC Frequently Asked Questions
technet2.microsoft.com/windowsWindowsServer2008/en/ library/e41e0d2f-9527-4eaf-b933-84f7d3b2c94a1033.mspx?mfr=true

Инструменты для управления PSO

ADSIedit Overview
technet2.microsoft.com/WindowsWindowsServer/en/ library/ebca3324-5427-471a-bc19-9aa1decd3d401033.mspx?mfr=true

PSOMgr
joeware.net/freetools/tools/psomgr/

View a Resultant PSO for a User or a Global Security Group (команда desget с ключом pso)
technet2.microsoft.com/windowsWindowsServer2008/en/ library/21a35cbb-398d-4ab4-a6f8-39b76fb0323b1033.mspx?mfr=true

Таблица 1. Усовершенствования в AD Windows Server 2008