Следующая версия Windows Server под кодовым названием "Longhorn" содержит многочисленные улучшения в Active Directory. Некоторые из этих изменений значительны и открывают восхитительные новые возможности для улучшения управляемости и эффективности. Одно из наиболее очевидных изменений в Active Directory – это наименования возможностей и функций. Все, относящееся к управлению идентификацией, теперь сгруппировано под заголовком Active Directory®. То, о чем вы и я думали как об Active Directory в Microsoft® Windows Server® 2003, теперь называется Active Directory Domain Services (ADDS), вместе с набором дополнительных служб, включая Active Directory Federation Services (ADFS), Active Directory Lightweight Directory Services (ADLDS, ранее Active Directory/Application Mode, или ADAM), Active Directory Certificate Services (ADCS), и Active Directory Rights Management Services (ADRMS).
Каждая из этих служб представляет серверную роль — новую концепцию в Windows Server "Longhorn". Вы можете выбрать, использовать ли компьютер для одной серверной роли или нескольких, и вы можете администрировать серверные роли, используя диспетчер сервера Server Manager, показанный на рис. 1. Из него вы можете добавлять роли, находить подсказки или выполнять другие необходимые административные задачи.
Рисунок 1 Server Manager
Можно видеть, что такой подход организует ежедневно выполняемые функции и возможности в логические группы, которые доступны в Server Manager.
Функциональные уровни
Windows Server "Longhorn" вводит новый функциональный уровень для лесов доменов и доменов. Функциональный уровень леса доменов в Windows Server "Longhorn" (который будет переименован после выпуска) не добавляет никаких новых функций сам по себе, а служит для того, чтобы все домены в лесу находились на функциональном уровне домена Windows Server "Longhorn", что делает возможными два новых улучшения. Первым является новейший движок репликации распределенной файловой системы (DFS) для общей папки SYSVOL, которая более устойчива, гранулирована и эффективна. Вторым улучшением является добавление поддержки 256-битного шифрования Advanced Encryption Services (AES) для протокола аутентификации Kerberos. Использование новейшего функционального уровня улучшает производительность, однако вы можете продолжать использовать более низкие функциональные уровни при переходе на Windows Server "Longhorn."
Введены также многочисленные расширения схемы для поддержки различных возможностей, причем все они полностью совместимы с существующими схемами, используемыми сегодня. Контроллеры доменов, на которых работает Windows Server "Longhorn", могут благополучно сосуществовать и взаимодействовать с контроллерами, на которых работает Windows Server 2003.
Поддержка ядра сервера
Служба Active Directory Domain Services является одной из серверных ролей, которая работает в варианте инсталляции Server Core (ядро сервера) Windows Server "Longhorn". Server Core, не рассматриваемое подробно в этой статье, является минимальным вариантом инсталляции, когда устанавливаются только функции ядра сервера. Server Core не инсталлирует оболочку Windows и не использует графический пользовательский интерфейс, сберегая весьма значительные ресурсы.
Контроллер домена только для чтения
Для некоторых организаций наиболее важной возможностью службы ADDS (Active Directory Domain Services) в Windows Server "Longhorn" является контроллер домена только для чтения (Read-Only Domain Controller, RODC), который позволяет вам легко создавать контроллеры доменов, которые несут реплику базы данных домена, доступную только для чтения. Это удобно для помещений, где физическая безопасность контроллера домена не может быть гарантирована, или на контроллере домена должны выполняться и поддерживаться администратором (который в идеале не является членом группы администраторов домена, Domain Admins Group) другие приложения. Оба эти сценария вполне обычны для установки в удаленных офисах.
Контроллер домена только для чтения инсталлируется простой установкой флажка в мастере установки, как показано на рис. 2.
Рисунок 2 Установка контроллера домена только для чтения
До выпуска Windows Server "Longhorn", если пользователи нуждались в аутентификации контроллером домена, находясь в другом месте, трафик должен был идти через глобальную сеть (WAN). Участки WAN медленнее и дороже нежели соединения локальных сетей (LAN), и иногда более подвержены перерывам в работе. Одним возможным решением было размещение контроллера домена в удаленном подразделении или офисе. Однако это вызывает другие проблемы, включая трафик репликации и необходимость поддержки физической безопасности контроллера домена в офисе отделения – то, что слишком часто отсутствует в малых и удаленных подразделениях. В других случаях офисы отделений имеют слабую пропускную способность подключения к узловому сайту, что увеличивает время, необходимое для входа в сеть.
За исключением паролей учетных записей (если явно не сконфигурировано иначе), RODC содержит все объекты и атрибуты Active Directory Domain Services, которые содержит контроллер домена с возможностью записи. Однако изменения, происходящие локально, не могут быть сделаны в реплике, сохраненной на RODC. Вместо этого изменения делаются на контроллере домена с возможностью записи и реплицируются обратно на RODC. Это не позволяет изменениям, сделанным в удаленных офисах, потенциально замусоривать или портить лес при репликации, тем самым исключая возможный способ атаки.
Локальные приложения, которые требуют доступ на чтение информации из каталога домена, могут получить его напрямую от RODC, в то время как приложения Lightweight Directory Access Protocol (LDAP), которые требуют доступ на запись, получают ответ со ссылкой на LDAP. Ответ со ссылкой направляет их на контроллер домена с возможностью записи, обычно на узловом сайте.
Поскольку никакие изменения не записываются напрямую в RODC, никакие изменения не исходят из RODC. Соответственно, контроллеры доменов с возможностью записи, являющиеся партнерами по репликации, не нуждаются в получении изменений с RODC. Это снижает рабочую нагрузку на серверы-мосты в узле и усилия, требуемые для отслеживания репликации. Однонаправленная репликация RODC применима как к репликации ADDS, так и к репликации распределенной файловой системы (DFS). RODC же выполняет нормальную входящую репликацию для изменений в ADDS и DFS.
В базе данных домена каждый участник - субъект безопасности – имеет набор из примерно десяти паролей или «секретов», называемых данными доступа. RODC не хранит данные доступа пользователей и компьютеров, кроме своей собственной учетной записи компьютера и специальной учетной записи "krbtgt" (учетная запись, используемая для аутентификации Kerberos) для каждого RODC. RODC рекламируется, как Центр распределения ключей (Key Distribution Center, KDC) для своего местоположения (обычно офис отделения). Когда RODC подписывает или шифрует запрос разрешения на получение разрешения (ticket-granting ticket, TGT), он использует другую учетную запись krbtgt и пароль, нежели KDC на контроллере домена с записью.
Когда учетная запись впервые используется для аутентификации на RODC, RODC посылает запрос к контроллеру домена с возможностью записи, находящемуся в узловом офисе. При успешной аутентификации RODC также запрашивает копию соответствующих данных доступа. Контроллер домена с записью распознает, что запрос пришел от RODC, и сверяется с Политикой репликации паролей (Password Replication Policy), которая используется для данного RODC.
Политика репликации паролей определяет, разрешено ли реплицировать данные доступа и сохранять их на RODC. Если да, контроллер домена с записью посылает данные доступа на RODC, а RODC кэширует их, как показано на вставке "Как работает контроллер домена только для чтения".
После того, как данные доступа кэшированы на RODC, в следующий раз, когда пользователь пытается войти, запрос обслуживается напрямую на RODC, пока данные доступа не изменятся. Когда TGT подписан от имени собственной учетной записи krbtgt контроллера RODC, RODC распознает, что у него имеется кэшированная копия данных доступа. Если TGT подписан другим контроллером домена, RODC перенаправит запрос к контроллеру домена с записью.
Ограничение кэширования данных доступа только данными пользователей, которые прошли аутентификацию на RODC, ограничивает потенциальное разглашение данных доступа в случае захвата RODC.
По умолчанию RODC не кэширует пользовательских паролей, но это необязательно самый эффективный сценарий. В норме лишь немногие из общего числа пользователей домена нуждаются в том, чтобы их данные доступа были кэшированы на каком-то конкретном RODC. Вы можете использовать Политику репликации паролей для указания, какие группы пользователей могут вообще рассматриваться на предмет кэширования. Например, ограничивая кэширование на RODC только пользователями, которые часто находятся в удаленном офисе, или, предотвращая кэширования данных доступа высокой ценности, например, администраторов, вы можете снизить риск потенциального разглашения.
Таким образом, в случае, если RODC украден или как-то еще скомпрометирован, лишь те данные доступа, которые были кэшированы, нуждаются в замене и, как будет обсуждено далее, вы будете точно знать, какие учетные записи были украдены, как показано на рис. 3.
Рисунок 3 Информация о кэшированной записи
Разделение роли администратора
Во многих удаленных офисах контроллеру домена поручаются дополнительные серверные роли или задачи, такие, как функции файлового сервера или сервера печати. В других случаях на контроллере домена по необходимости могут быть установлены бизнес-приложения. Это создает проблему: для того, чтобы администрировать все эти приложения и серверы, работник отделения должен иметь данные доступа администратора. А каждый, кто может администрировать один контроллер домена Windows Server 2003, может администрировать весь домен.
В Windows Server "Longhorn" администратор может иметь разрешение на администрирование только одного конкретного RODC, не имея доступа, позволяющего ему управлять другими контроллерами домена, и не будучи включенным в группу администраторов безопасности домена без необходимости.
Улучшения пользовательского интерфейса и инструментария
Для поддержки функций RODC и чтобы облегчить наблюдение за репликацией паролей, на странице свойств контроллера домена в Active Directory Users и Computers введена новая закладка Политики репликации паролей, как показано на рис. 4.
Рисунок 4 Закладка Политики репликации паролей
Нажав кнопку Advanced, вы можете увидеть, какие пароли были посланы RODC, какие были там сохранены, и какие учетные записи были аутентифицированы этим RODC, как показано на рис. 5. Поскольку список включает учетные записи, которые были аутентифицированы, даже если они вне групп, для которых разрешена репликация паролей, вы можете использовать эту информацию для решения, какие группы следует включить в Политику репликации паролей.
Рисунок 5 Дополнительная политика репликации паролей
Ряд изменений был также сделан в старой утилите dcpromo, официальное название которой мастер установки Active Directory Domain Services. Эта утилита может быть запущена как полное графическое приложение путем выбора команды Add Roles на странице Initial Configuration Tasks, (ICT, Задачи начального конфигурирования), которая появляется сразу после установки операционной системы. Выберите Add Roles, а затем ADDS в диспетчере Server Manager или запустите dcpromo из командной строки или окна Run.
Запустив эту утилиту в графическом режиме, вы заметите улучшенную организацию элементов и пунктов меню, поскольку взаимосвязанные элементы сгруппированы вместе. Также стало больше опций. Для выполнения таких задач, как создание нового дерева домена, установка с носителя (для сокращения первоначальной репликации через глобальную сеть) или выбор исходного контроллера домена для начальной репликации, можно вызвать расширенный режим из пользовательского интерфейса без использования переключателя /adv.
Чтобы сделать вашу работу проще и уменьшить количество раздражающих ошибок, были сделаны некоторые улучшения. Например, если вы используете эту утилиту для создания нового контроллера домена в существующем домене или лесе, вы можете просмотреть существующие домены вместо того, чтобы набирать имя NetBIOS.
Чтобы позволить вам сконфигурировать контроллер домена как глобальный сервер каталогов, сервер DNS или RODC, были добавлены новые страницы для указания дополнительных опций. В этой утилите вы также можете сконфигурировать выбор сайта, установить функциональные уровни, создать политику репликации паролей для RODC и сконфигурировать DNS-делегирование.
Как средство командной строки, dcpromo может запускаться полностью без человеческого участия. В отличие от той же утилиты в Windows Server 2003, установка без участия человека не требует действий в ответ на запросы пользовательского интерфейса, например, таких, которые нужны для перезапуска компьютера. Это делает использование ADDS на Windows Server "Longhorn", установленном в варианте Server Core, проще.
Аудит ADDS
В Windows Server "Longhorn" компания Microsoft добавляет много новых функций к аудиту службы каталогов. В Windows Server 2003 вы могли включить или выключить аудит доступа к каталогам, но даже если вы включили полный аудит успешного доступа, журнал аудита не показывал, какая информация была изменена. Теперь он может это делать.
В Windows Server "Longhorn" политика аудита для ADDS имеет следующие четыре подкатегории:
- Directory Service Access (Доступ к службе каталогов) - Directory Services Changes (Изменения в службе каталогов) - Directory Service Replication (Репликация службы каталогов) - Detailed Directory Service Replication (Детализированная репликация службы каталогов)
Большинству IT-специалистов нужно запомнить два ключевых факта об этих изменениях. Прежде всего, аудит Directory Service Access дает, по сути, ту же информацию, которую он давал в Windows Server 2003, но идентификатор события (Event ID) изменен с 566 на 4662. Обратите внимание на это изменение, если вы используете автоматические средства для того, чтобы читать журнал событий безопасности. А во-вторых, новая категория Directory Services Changes записывает как старые, так и текущие значения измененных атрибутов.
Чтобы реализовать аудит в ADDS, используется Глобальная политика аудита (Global Audit Policy), Системные списки контроля доступа (System Access Control Lists (SACLs)) и схема ADDS. Вместе эти компоненты создают гибкую и полную среду аудита.
Глобальная политика аудита определяет, должен ли проводиться какой-либо аудит для ADDS. Если аудит включен, Глобальная политика определяет, какие из четырех подкатегорий доступа, указанных ранее, подвергаются аудиту. Глобальная политика аудита обычно применяется в рамках объекта групповой политики Default Domain Controllers Group Policy, так что она действительна для всего каталога на контроллере домена.
Хотя средства групповой политики могут включать или выключать Глобальную политику аудита, вам придется использовать средство командной строки Auditpol.exe для просмотра и конфигурирования этих подкатегорий. Они не представлены в графическом пользовательском интерфейсе.
SACL является частью дескриптора безопасности объекта. При задании записей в SACL вы сообщаете системе две вещи: какие действия и какие пользователи (или субъекты безопасности) вас интересуют. Другими словами, вы указываете, попытки каких пользователей произвести какие действия должны записываться в журнале событий. Так что если вы желаете записывать изменения для объектов пользователей, сделанные администраторами домена, но не самими пользователями, вы можете управлять этим при помощи SACL. SACL применяется к объектам (и может быть определен для новых объектов и унаследован от объектов-контейнеров.)
Вы можете также сконфигурировать схему ADDS таким образом, чтобы ограничить аудит изменений конкретными атрибутами. Поскольку SACL применяются к объекту по умолчанию, доступ к любому атрибуту или его изменения записываются. Это может привести к созданию множества записей в журнале, и возможно, вовсе не все атрибуты вас интересуют. Так что вы можете установить флажок на уровне атрибута, который предотвращает запоминание изменений этого атрибута.
SearchFlags является атрибутом, определенным в классе, который определяет атрибуты, так что он является атрибутом атрибута. Он также является битовой маской, в которой каждый бит однобайтного значения представляет отдельную установку включить/выключить. Для простоты можете считать его свойством атрибута. В Windows Server 2003 семь из этих значений используются для управления различными настройками, включая индексирование и GC-репликацию атрибута. В Windows Server "Longhorn" восьмой бит (со значением 128) используется для управления тем, будут или нет записываться изменения. Если этот бит установлен, ADDS не будет записывать события изменений, когда изменения производятся над этим атрибутом. Это применимо ко всем объектам, которые содержат этот атрибут. В версии Beta 2 нельзя использовать графический интерфейс, чтобы установить восьмой бит.
По умолчанию в Windows Server "Longhorn" Глобальная политика аудита включена, и параметр Directory Service Changes установлен на запись успешных изменений.
Перезапускаемая ADDS
В Windows Server "Longhorn" ADDS является перезапускаемой службой. Это попросту означает, что службы ADDS могут быть остановлены и запущены без перезагрузки всего контроллера домена. Это позволяет администраторам легче и без переключения в режим восстановления Directory Services Restore Mode осуществлять функции, которые не могут быть выполнены, пока служба работает (такие, как автономная дефрагментация базы данных.)
Контроллер домена, на котором работает Windows Server "Longhorn", может быть в одном из трех состояний: ADDS Started (ADDS запущен), ADDS Stopped (ADDS остановлен), и режим восстановления Directory Services Restore Mode. Давайте рассмотрим каждое из этих состояний.
ADDS Started Контроллер домена работает нормально.
ADDS Stopped Сервер имеет характеристики одновременно контроллера домена в режиме Directory Services Restore Mode и сервера, являющегося членом домена.
Как и в режиме Directory Services Restore Mode, база данных ADDS (Ntds.dit) выключена. Если другой контроллер домена недоступен, для локального входа можно использовать пароль режима Directory Services Restore.
Как и с сервером-членом домена, сервер присоединен к домену. Пользователи могут входить интерактивно или через сеть, используя другой контроллер домена для входа в домен. Однако контроллер домена не должен долго находиться в этом режиме, поскольку он не может обслуживать запросы на вход или производить репликацию с другими контроллерами домена.
Directory Services Restore Mode Этот режим (или состояние) не изменилось по сравнению с Windows Server 2003.
Диаграмма на рис. 6 показывает, как контроллер домена, на котором запущен Windows Server "Longhorn", может переходить из одного из этих трех состояний в другое.
Рисунок 6 Контроллер домена, на котором запущен Windows Server Longhorn, может переходить из одного из этих трех состояний в другое
Хотите подробностей?
Невозможно объяснить в одной короткой статье всю глубину новых возможностей ADDS в Windows Server "Longhorn." Однако, как видите, новые возможности Active Directory решают ряд проблем, которые раньше приходилось пытаться обойти или просто мириться с ними. Поскольку выпуск финальной версии продукта приближается, вам захочется узнать больше. Можете быть уверены, что дополнительная документация будет опубликована. Пока же лучшим местом для поиска обновлений в ходе бета-фазы является веб сайт
