Вместе с Windows 2000 Майкрософт дала миру Active Directory. В следующей версии системы, Windows Server 2003, в Active Directory были снесены изменения, однакоособых потрясений они не произвели. На сегодняшний день Active Directory® превратилась в полноценную, надежную службу каталогов. И несмотря на это в последней версии системы специалисты по разработке Active Directory добавили еще несколько существенных функций, способных укрепить безопасность и упростить управление службой каталогов.
На пороге второго тысячелетия служба Active Directory отвечала за проверку подлинности пользователя, входящего в операционную систему, применение политик к компьютерам и пользователям и всячески помогала пользователю (находила нужный принтер, к примеру). Уже пару лет спустя Майкрософт выпустила отдельный вариант службы каталогов — Active Directory Application Mode (ADAM).
К 2006 году все полностью изменилось. Служба Active Directory перестала быть какой-то конктерной технологией. Теперь под этим названием объединяется несколько служб управления удостоверениями и доступом, встроенных в Windows®
То есть, правильно говорить, что эта статья посвящена службам домена, но на самом деле это все та же старая добрая служба Active Directory, которая известна нам с 2000 года.
Диспетчер серверов в Windows Server 2008
Первые два улучшения в Active Directory, которые я собираюсь обсудить, в действительности не являются изменениями в доменных службах Active Directory Domain Services (ADDS); это, скорее, изменения в Windows, которые повлияют на способ управления Active Directory. Первое, новый диспетчер серверов, появляется при первой загрузке сервера Windows Server® 2008. (Второе –– установка Server Core, о которой я расскажу чуть позже.)
Диспетчер сервера, возможно, покажется вам похожим на мастер настройки сервера, который появлялся по умолчанию сразу после установки Windows Server 2003. Впрочем, он был не слишком полезен для повседневного администрирования: у всех, кого я знаю, флажок «Не показывать эту страницу при входе в систему» был установлен.
А вот диспетчер сервера в Windows Server 2008, напротив, весьма полезен (краткий обзор функций диспетчера есть в статье Байрона Ханза (Byron Hynes) в этом выпуске журнала TechNet Magazine). Вопервых, как видно из рис. 2, диспетчер сервера из HTML-приложения (HTA) превратился в консоль управления (MMC). В результате он обрел знакомый полнофункциональный, настраиваемый пользовательский интерфейс. Диспетчер сервера позволяет управлять установкой серверных ролей (крупных служб вроде DNS, ADDS, IIS) и функций (компонентов программного обеспечения, например платформы Microsoft .NET Framework, функции шифрования дисков BitLockerTM, оболочки Windows PowerShellTM). Диспетчер не только позволяет устанавливать и удалять программы — он представляет собой единый пульт управления, позволяющий запускать средства диагностики (срество просмотра событий, PerfMon) и служебные программы для настройки системы (диспетчер устройств, брандмауэр Windows). Если добавить в консоль управления оснастки Active Directory, например «Пользователи и компьютеры», «Домены и доверие», «Сайты и службы», получится неплохой интерфейс, позволяющий выполнять повседневные операции, связанные с обслуживанием контроллера домена Windows Server 2008.
Рис. 2 Диспетчер серверов в Windows Server 2008
Windows Server 2008 Server Core
Windows Server Core — это новый режим установки Windows, дающий в результате урезанную версию системы, в которой содержатся только те компоненты, которые необходимы для установки и исполнения определенных серверных ролей, в частности для работы служб доменов Active Directory. (На рис. 3 перечислены роли, включенные в вариант установки Server Core.) Хотя в режиме Server Core имеется графический интерфейс, оболочка рабочего стола Windows в нем отсутствует, равно как и многие графические средства настройки Windows (см. рис. 4). Вместо них вам обеспечена командная строка и отвратительное чувство где-то в глубинах желудка, подтверждающее тот факт, что вы понятия не имеете, что же делать дальше. Как изменить имя компьютера? Как настроить статический IP-адрес?
Рис. 4 Интерфейс в режиме Server Core разнообразием не блещет
Первые несколько минут перед экраном в режиме Server Core кого угодно могут выбить из колеи, но как только вы вспомните WMIC, NETSH и NETDOM, вы сможете без труда выполнить все стандартные операции по установке и настройке. А тягу к графическим средствам отчасти облегчают Regedit и Блокнот.
Главным преимуществом режима Server Core является то, что вы избавляетесь от большей части кода, включенного в стандартный вариант установки Windows, который иногда вовсе и не нужен. Тем самым сужается потенциальный фронт атак вредоносного программного обеспечения (что уже хорошо) и снижается количество исправлений и перезагрузок контроллеров доменов (что просто великолепно). Кроме того, уменьшается размер места, занимаемого системой на диске, и снижаются требования к оборудованию — обычно это не очень важно, но в виртуализованных серверных средах может пригодиться.
Усложняется ли управление службами ADDS в отсутствие графических средств? Отнюдь. Практически все операции по управлению можно выполнять удаленно: вы подключаетесь к контроллеру домена через сеть, а служебные программы запускаете на своей рабочей станции. Смею предположить, что через некоторое время подавляющее большинство контроллеров доменов будет работать в режиме Server Core.
Изменения в DCPROMO
Первое изменение, которое вы обнаружите в самих службах ADDS, — это новый мастер DCPROMO. Работает он точно так же, как мастер DCPROMO в Windows Server 2003, но он был полностью переписан, и теперь им удобнее пользоваться. Например, не нужно вводить учетные данные администратора домена — DCPROMO способен при повышении роли сервера использовать данные, которые были введены при входе в систему. Не приходится прибегать к команде DCPROMO /ADV, если нужен расширенный режим DCPROMO: в первом диалоговом окне DCPROMO есть флажок, активирующий соответсвующие функции. В расширенном режиме можно также выбрать контроллер домена, с которого будет выполняться репликация. Это означает, что всю работу по репликации, выполняемую DCPROMO, можно провести без дополнительной загрузки производственных контроллеров доменов.
При переводе контроллера в другой домен или в другой лес DCPROMO предлагает настроить сразу настроить функциональный уровень соответствующего домена или леса, чтобы не делать это после. В ходе перевода можно указать, в какой сайт Active Directory нужно поместить контроллер домена, что очень удобно при работе DCPROMO без участия пользователя. DCPROMO даже предложит наиболее подходящий сайт исходя их IP-адреса контроллера домена.
В новом DCPROMO все параметры собраны на одной странице, и вы сразу можете определить, какую роль будет играть новый контролер домена: глобального каталога, DNS-сервера или контроллера домена только для чтения. И чтобы сделать контроллер глобальным каталогом, не нужно продираться сквозь дебри сайтов и служб Active Directory.
Но, пожалую, лучшей особенностью нового DCPROMO является возможность сохранить все параметры DCPROMO в файле ответа непосредственно перед запуском процесса перевода. Это гораздо проще — и намного надежнее — чем стряпать файл ответа вручную. Файл ответа можно использовать при выполнении процедуры DCPROMO без участия пользователя на других серверах. И еще радостная весть для фанатов сценариев: все параметры DCPROMO теперь доступны при работе в командной строке.
Контроллеры доменов только для чтения
На заре существования Active Directory в компаниях контроллеры домена развертывались в каждом подразделении, сотрудники которого должны были входить в систему. Ярким примеров являются банки: у них контроллеры доменов были в каждом филиале. Обоснование выглядело так: даже если произойдет сбой WAN, сотрудники филиала смогут войти в систему и использовать ресурсы локальной сети.
В те времена физической безопасности контроллеров особого значения не придавали. Мне доводилось видеть контроллеры доменов, просто задвинутые под рабочий стол — и любой проходящий мимо мог без труда ими воспользоваться. Лишь спустя несколько лет специалисты по архитектуре Active Directory осознали всю степень риска и ИТ-организации взялись за объединение контроллеров доменов в центрах обработки данных. Сотрудники филиалов при таком раскладе вынуждены проходить проверку подлинности, но это разумная цена повышения безопасности данных.
Active Directory в Windows Server 2008 внесла разнообразие в развертывание систем филиалов: появились контроллеры доменов только для чтения (RODC). Это самое главное изменение, внесенное в службах доменов Windows Server 2008.
При создании RODC группа разработки Active Directory все внимание сосредоточила на требованиях, предъявляемых к системам филиалов; их девизом стало: «Что в филиале произойдет, то в филиале и останется». Дело в том, что если нет возможности обеспечить физическую безопасность контроллеров, установленных в филиале, то вы, в общем-то, никак не сможете предотвратить взлом контроллера (и компьютеров, на которых установлено доверие данному контроллеру), однако вы в силах сделать так, чтобы этот взлом не сказался на остальной части домена.
Контролеры RODC, хотя и являются главным нововведением, связанным со службами ADDS, довольно просты в использовании. Домен должен находится на функциональном уровне леса Windows Server 2003, и в домене должен быть хотя бы один контроллер под управлением Windows Server 2008. Контроллеры RODC можно использовать не только в филиалах; их также имеет смысл устанавливать в средах, имеющих выход в Интернет, и на периферии сети.
Если контроллер сделал ноги
Есть несколько категорий угроз, с которыми приходится считаться при развертывании систем филиалов. Первая ситуация — контроллер домена украден. Кто-то просто унес контроллер или его диск. Кроме того что локальные службы не могут работать, существует вероятность того, что злодей в конце концов получит доступ ко всем именам и паролям пользователей в домене, сможет повысить уровень собственных привилегий и воспользоваться ресурсами компании или вызвать отказ в обслуживании. В целях борьбы с такого типа угрозами в RODC по умолчанию хэшированные пароли не хранятся в дереве DIT. Когда пользователсь в первый раз проходит проверку подлинности на данном контроллере RODC, контроллер передает запрос полному контроллеру домена (FDC). FDC обрабатывает запорс и, если все проходит удачно, контроллер RODC отправляет запрос репликации для получения хэшированного пароля.
Если контроллер RODC взломан, он теоретически может запросить хэшированный пароль к учетной записи, дающей доступ к конфиденциальной информации. Чтобы предотвратить такую ситуацию, администратор может настроить политику репликации паролей для каждого контроллера RODC. Политика репликации представляет собой два атрибута объекта-компьютера контроллера RODC. Атрибут msDS-RevealOnDemandGroup содержит различающиеся имена групп, пользователей, компьютеров, пароли к учетным записям которых можно хэшировать на контроллере RODC (обычно это пользователи и компьютеры, входящие в тот же сайт, что и сам контроллер RODC). Атрибут msDS-NeverRevealGroup содержит различающиеся имена групп, пользователей, компьютеров, пароли которых хэшировать на контроллере RODC нельзя (например, пароль администратора ни в коем случае не следует хэшировать на контроллере RODC). Когда RODC запрашивает хэшированный пароль к той или иной учетной записи, FDC оценивает запрос согласно политике репликации паролей и определяет, можно создать реплику пароля на RODC или нельзя. В случае кражи контроллера домена это позволяет снизить уязвимость тех паролей, которые были хэшированы на RODC в момент его отключения от сети, и устранить риск взлома важных паролей.
Объект-компьютер контроллера RODC имеет еще два атрибута, позволяющие определить, какие именно пароли нужно хэшировать. Атрибут msDS-AuthenticatedAtDC содержит список учетных записей, прошедших проверку подлинности на контроллере RODC, а атрибут msDS-RevealedList — список учетных записией, пароли которых в данный момент хранятся на контроллере RODC.
Хэшированные пароли пользователей и компьютеров — не единственный секрет контроллера домена. Учетная запись KrbTGT содержит ключи Центра распространения ключей Kerberos — службы, работающей на каждом контроллере домена. Обычно все службы KDC в домене используют одну и ту же учетную запись KrbTGT, поэтому есть опасность, что злоумышленник сможет извлечь ключи из украденного контроллера и взломать оставшуюся часть домена. Контроллеры RODC используют собственные учетные записи KrbTGT и собственные ключи, поэтому такая возможность отпадает.
Кроме всего прочего, приложения нередко хранят пароли и другую секретную информацию в DIT. Если злоумышленник украдет контроллер домена, он может воспользоваться сохраненными паролями и получить доступ к приложениям. Чтобы снизить риск такого развития событий, службы доменов в Windows Server 2008 позволяют администраторам определить набор атрибутов контроллеров доменов только для чтения (RO-FAS). Атрибуты, входящие в набор RO-FAS, не реплицируются на контроллеры RODC, и поэтому не могут быть обнаружены на украденном контроллере домена. Атрибуты RO-FAS назначаются путем настройки 9 бита (0×0200) в атрибуте searchFlags, в соответствующем объекте attributeSchema.
Варвары в городе
Еще одна категория опасностей, с которыми сталкиваются контроллеры доменов в филиалах, выглядит следующим образом: администратор локального сервера несанкционированно расширяет собственные права, пользуясь привилегиями контроллера домена, и получает доступ к дополнительным ресурсам домена или пытается провести атаку типа «отказ в обслуживании». Опять же, если локальный администратор физически имеет доступ к контроллеру, вы вряд ли сможете ему помешать, однако вы можете не позволить ему взломать остальные контроллеры домена.
На полном контроллере домена контроллеры RODC не указываются как доверенные. С точки зрения доверительных отношений, контроллер FDC относится к контроллерам RODC так же, как к прочим серверам, входящим в домен. Контроллеры RODC не входят ни в группу «Контроллеры домена предприятия», ни в группу «Контроллеры домена». При помощи учетной записи RODC вообще мало что можно обновить в каталогах, поэтому даже если злоумышленник взломает учетную запись RODC, он практически никаких полезных для себя привилегий не получит.
Контроллеры RODC даже не включаются в обычную топологию репликации DS. Поскольку RODC внешне ничем не отличается от остальных серверов домена, средство проверки согласованности знаний (или KCC — этот процесс имеется на каждом контроллере домена, отвечающем за расчет топологии репликации DS) не создает для контроллеров RODC объектов соединений. Ни полный контроллер домена, ни контроллер RODC не станет проводить репликацию на основе контроллера домента тольео для чтения. С другой стороны, контроллер RODC создает объект соединения, представляющий собой соглашение о входящей репликации с полного контроллера домена, но этот объект хранится только в реплике самого контроллера RODC — на другие контролеры домена он не копируется. С точки зрения репликакции, контроллер RODC сродни ловушкам для тараканов: всех впускать, никого не выпускать.
Делегирование прав администратора на контроллере RODC
В офисах филиалов контроллером домена нередко управляет местный администратор серверов: он сам все делает, и резервные копии контроллера создает, и клавиатуры тряпочкой протирает. Однако было бы опасным предоставлять администратору удаленного офиса права, необходимые для всех операций по обслуживанию контроллера домена, поскольку администратор теоретически может расширить собственные привилегии в домене. Контроллеры RODC позволяют бороться и с этой угрозой: они предлагают два способа делегированя прав администратора.
В первом варианте администратор домена может либо перевести контроллер RODC обычным способом (при помощи DCPROMO), либо воспользоваться двухчастной процедуров и безопасно делегировать права, необходимые для перевод контроллера, администратору офиса филиала, не предоставляя ему прав администратора домена. Администратор домена создает заготовку учетной записи RODC в домене при помощи оснастки «Пользователи и компьютеры Active Directory», как показано на рис. 5.
Рис. 5 Создание заготовки учетной записи компьютера RODC
При выборе варианта «Создать заранее учетную запись контроллера домена только для чтения» запускается урезанная версия мастера DCPROMO, которые выполняет все действия, требующие наличия прав администратора домена: создает учетную запись компьютера, привязывает RODC к сайту, назанчает роли контроллеров домена, задает политику репликации паролей и определяет пользователя или группу, которым понадобятся права, необходимые для завершения работы мастера DCPROMO на контроллере RODC. Выбранный администратор или группа изписываются в атрибут managedBy объекта компьютера RODC.
Затем администратор, получивший права, может запустить мастер DCPROMO непосредственно на сервере. DCPROMO обнаружит заготовку учетной записи и преобразует сервер в контроллер домена только для чтения. При таком запуске мастера DCPROMO права администратора домена не требуются.
Во втором варианте делегирования прав администратора роли администратора создаются на самом контроллере RODC. Внешне эти роли ничем не отличаются от локальных групп: они хранятся в реестре контроллера RODC и оцениваться могут только данным контроллером. Для управления локальными ролями RODC администратор использует не оснастку «Управление компьютером», а программу NTDSUTIL.
Странности RODC
Из-за того что контролеры RODC предназначены только для чтения и на другие контроллеры данные с них не реплицируются, контроллеры RODC иногда ведут себя странно. Взять, к примеру, устаревшие объекты — объекты, которые были удалены везде кроме данного контроллера домена, поскольку ему не удавалось выполнить репликацию в течение переода времени, превышающего время жизни захоронения в лесу — обычно такие объекты удаляются в момент исходящей репликации на партнеров данного контроллера домена. Но поскольку контроллеры RODC на такую репликацию не способны, устаревшие объекты в них не обнаруживаются.
Контроллеры RODC не проводят операции по обновлению LDAP (добавление, изменение, удаление, переименование, перемещение). Вместо этого контроллер RODC возвращает обычному контроллеру домена (способному выполнять такие операции) сообщение об ошибке с указанием ссылки на LDAP. Если приложение, запросившее обновление LDAP, некорректно работает со сслыками, оно может дать сбой.
Наконец, чтобы выполнить проверку подлинности пользователя другого домена, входящего в тот же лес, контроллер RODC должен иметь доступ к полному контроллеру собственного домена для получения пароля доверия и передачи запроса на проверку подлинности контроллеру того домена, к которому относится пользователь. Если сетевое подключение между контроллером RODC и полным контроллером домена, в который он входит, недоступно, провести проверку подлинности не удастся.
Подробные политики паролей
Возможность настроить сразу несколько политик паролей в одном домене была, пожалуй, самым востребованным нововведением Windows Server 2008 ADDS. Как известно служба Active Directory в Windows 2000 и Windows Server 2003 допускала не более одной политики паролей на каждый домен, применявшейся ко всем участникам ситемы безопасности. Если для какой-то группы пользователей нужно было настроить отдельную политику, приходилось создавать отдельный домен. В Windows Server 2008 ADDS появилась новая функция — «Подробные политики паролей» — позволяющая настроить несколько политик в одном домене.
В новой стратегии для применения разных политик используются группы. Вы сначала определяете политику паролей — создаете новый объект msDS-PasswordSettings в контейнере CN=Password Settings Container, CN=System, DC=<домен>. Объект msDS-PasswordSettings (сокращенно PSO) имеет атрибуты, отождествляющие политику паролей с определенными настройками групповой политики.
Затем вы включаете созданную политику для пользователей и групп путем добавления имени пользователя или группы в атрибут mDS-PSOAppliesTo объекта PSO (атрибут может иметь несколько значений одновременно). Если смириться с мыслью, что политики паролей применяются не к подразделениям, все довольно просто. Правда, некоторые трудности все же встречаются.
Пользователи обычно входят сразу в несколько групп. Что произойдет, если к двум группам, в которые входит пользователь, применить разные политики паролей, противоречащие друг другу? В таком случае службы ADDS для выбора политики применяют анализ очередности. Происходит это следующим образом:
- Если политика паролей привязана к объекту пользователя напрямую (а не посредством членства в группе), применяется эта политика.
- Если к объекту пользователя напрямую привязано несколько политик, используется политика с наименьшим значением очередности (оно определяется значением атрибута msDS-PasswordSettingsPrecendence в объекте PSO).
- Если существует несколько объектов PSO с одним и тем же значением очередности, используется объект, имеющий самый маленький идентификатор objectGUID.
- Если нет объектов PSO, привязанных к пользователю напрямую, службы ADDS анализируют объекты PSO, привязанные к группам, в которых состоит пользователь. Если существует несколько объектов PSO, используется объект с наименьшим значением атрибута msDS-PasswordSettingsPrecedence.
- Если существует несколько объектов PSO с одним и тем же значением очередности, используется объект, имеющий самый маленький идентификатор objectGUID.
- Если к пользователю не привязано ни одного объекта PSO, применяется политика паролей, настроенная для домена.
У объектов пользователей появился новый атрибут msDS-ResultantPSO, помогающий точно определить, какой объект PSO должен применяться к пользователю. Этот атрибут содержит различающееся имя объекта PSO, определяющего политику паролей для данного пользователя.
Подробные политики паролей дают запас гибкости на все случаи жизни, однако обращаться с этими политиками следует осторожно и лучше слишком их не усложнять. Специальной служебной программы для управления подробными политиками паролей нет — для этого используется либо программа ADSIEdit, либо программы сторонних разработчиков.
Возможность перезапуска службы Active Directory
При каждом отключении контроллера домена на время обслуживания DIT вы так или иначе нарушаете уровни обслуживания сети. В Windows Server 2008 появилась новая функция, позволяющая остановить службу каталогов, не отключая контроллер домена полностью.
Команда NET STOP NTDS останавливает работу служб ADDS на контроллере домена под управлением Windows Server 2008. При этом процесс LSASS на контроллере не останавливается — он выгружает все библиотеки DLL, связанные с работой служб ADDS, и служба каталогов становится недоступна. После этого LSASS на контроллере домена дествует так, как дествовал бы, быдь он установлен на обычном сервере: пересылает запросы на проверку подлинности в домене на другой контроллер домена. Поскольку библиотеки DLL, участивующие в работе служб ADDS, выгружены, вы можете установить исправления для служб домена или дефрагментировать DIT в автономном режиме. Чтобы запустить службы ADDS, нужно использовать команду NET START NTDS. А вот для восстановления DIT из резервной копии состояния системы все же придется загрузить службу каталогов в режиме восстановления.
Важно понимать, что служба каталогово по сути своей не является службой Windows. Это неотделимый компонент процесса LSASS, а его невозможно остановить, не выключая компьютер. И все же возможность остановливать и запускать служюбу каталогов в Windows Server 2008 весьма удобна.
Резервное копирование и восстановление
В Windows Server 2008 механизм резервного копирования и восстановления был полностью пересмотрен. Все изменения мы здесь перечислять не будем — коснемся тех, которые имеют отношение к службам ADDS.
«Система архивации данных Windows Server» позволять создать резервную копию всего тома сразу. Кроме того, она обслуживает только диски (и устройства, идентичные им) — ленточные носители не поддерживаются.
Для команды WBADMIN, используемой в версии средства архивации с интерфейсом командной строки, существует параметр, который позволяет создать резервную копию состояния системы. При помощи команды WBADMIN START SYSTEMSTATEBACKUP создается образ резервной копии, содержащий все важные системыные файлы, необходимые для восстановления службы Active Directory на контроллере домена. Теоретически набор резервных копий может содержать до пяти томов, однако включить в них можно те файлы, которые будут нужны для восстановления состояния системы. Еще больше огорчает тот факт, что в Windows Server 2008 (по крайней мере в сборке RC0) резервную копию состояния системы нельзя сохранить на сетевом ресурсе. Должен обязательно быть том токального диска, на котором будут храниться образы резервных копий, причем этот том не должен входить в набор томов, участвующих в резервном копировании состояния системы. Иногда приходится добавлять по одному тому на каждый контроллер домена, на которых выполняется резервное копирование состояния системы.
В самом процессе восстановления состояния системы ничего сложного нет. Контроллер домена загружается в режиме восстановления службы каталогов, и задается команда WBADMIN START SYSTEMSTATERECOVERY. В результате имеем неполномочно восстановленное дерево каталогов, в котором нужно полномочно восстановить конкретные объекты при помощи программы NTDSUTIL, точно так же как в Windows Server 2003.
Одну особенность системы архивации данных Windows Server стоит отметить особо: образы резервных копий сохраняются в формате VHD (виртуальный жесткий диск). Этот же формат используется в Microsoft Virtual Server 2005 для хранения образов виртуальных дисков. Из этого следует, что образ резервной копии, созданный системой архивации, можно монтировать в качестве жесткого диска на виртуальную машину под управлением Microsoft Virtual Server. Содержимое резервной копии можно будет просмотреть, как будто это обычный жесткий диск.
Еще одно изменение, коснувшееся резервного копирования служб ADDS, — это возможность при помощи службы теневого копирования томов созждавать снимки службы каталогов Active Directory на конкретный момент времени. Снимок создается при помощи программы NTDSUTIL; служба теневого копирования томов сохраняет предварительный образ каждого блока дерева каталогов, прежде чем заменить его в процессе обновления. Если объединить предварительный образ и текущую версию дерева каталогов при помощи службы теневого копирования, можно без особых усилий получить полный моментальный снимок дерева каталогов. Обычно на создание снимка уходит пара секунд — независимо от размера дерева каталогов.
Возможность эта сама по себе любопытна, но не очень полезна. Однако в Windows Server 2008 службы ADDS включают в себя программу командной строки под названием DSAMAIN. Она позволяет монтировать образ мгновенного снимка в режиме «только для чтения». При этом создается самостоятельный сервер LDAP наподобие экземпляра ADLDS, в котором хранится все содержимое каталога на момент создания мгновенного снимка. Содержимое каталога можно просматривать при помощи служебной программы LDP или иного средства LDAP; кроме того, вы можете получить предыдущую версию объектов каталога.
Репликация SYSVOL с использованием механизма DFS-R
Распределенная файловая система (DFS) в Windows Server 2003 R2 была полностью пересмотрена; в ней появился совершенно новый механизм репликации файлов DFS-R. Этот механизм использует удаленное разностное сжатие, что значительно сокращает трафик репликации файлов: указываются блоки целевых файлов, требующие репликации для синхронизации с исходными файлами. А вот в Windows Server 2003 R2 для репликации SYSVOL между контроллерами домена по-прежнему используется служба репликации файлов (а не DFS-R). По этой причине репликация SYSVOL, как и прежде, вызывает немало проблем у администраторов Active Directory.
Если система Windows Server 2008 работает на функциональном уровне домена, она позволяет выполнить репликакцию SYSVOL с использованием механизма DFS-R, что повышает скорость и надежность репликации SYSVOL. Кроме того, имеет смысл разместить объемные файлы в SYSVOL, чтобы сделать их доступными для всех контроллеров доменов. Прежде чем применять механизм DFS-R к SYSVOL, необходимо перенести данные из старого SYSVOL при помощи служебной программы DFSRMIG. Процесс этот проходит в четыре этапа:
* Создание объектов Active Directory, необходимых для DFS-R.
* Создание новой структуры файлов каталога SYSVOL на каждом контроллере домена.
* Переключение всех контроллеров домена на новый SYSVOL.
* Удаление старого каталога SYSVOL.
В некоторых случаях (в зависимости от размера каталога SYSVOL и количества контроллеров доменов) этот процесс может занять определенное время, но в конечном итоге повышение производительности и надежности стоит этого.
Изменения в функциях аудита
Система аудита в Active Directory для Windows Server 2003 — и счастье, и несчастье. С одной стороны, это достаточно полное, гибкое и надежное средство отслеживания изменений в каталоге. С другой, у него есть несколько существенных недостатков в сфере удобства использования.
Включение аудита изменений каталогов на контроллере домена Windows Server 2003 — штука довольно прямолинейная: аудит дибо включен, любо нет. При определенной активности использования контроллера домена в организации объем трафика аудита может сделать его малоэффективным. Настроить систему аудита так, чтобы она выдавала действительно полезные сообщения, сложно и рискованно. Сами сообщения аудита временами непросто расшифровать, и в большинстве случаев они не содержат нужной информации (то есть старых и новых значений измененных атрибутов). Кроме всего прочего, собрать, связать и заархивировать сообщения, полученные с нескольких контроллеров доменов, при помощи собственных средств Windows не представляется возможным.
В Windows Server 2008 часть этих проблем была решена. Во-первых, появиличь четыре новые подкатегории аудита службы каталогов: «Доступ к службе каталогов», «Изменения службы каталогов», «Репликация службы каталогов» и «Подробная репликация службы каталогов». Если нужно проверить только изменения каталогов, не нужно просматривать все события стения и репликации. Если случаи удаления объектов тоже нужно включить в журнал аудита, придется включить еще и категорию «Доступ к службе каталогов». При этом создается большое количество сообщений, связанных с доступом объектов службы каталогов, то есть мы, по сути, возвращаемся к прежним огромным объемам ненужных сообщений. Также вы по-прежнему можете настраивать дескрипторы системы безопасности, чтобы получать сообщения только о тех объектах, которые вас интересуют.
Сообщения аудита были в значительной степени подправлены: они стали более удобочитаемыми, и в них появилась полезная информация. В частности, при использовании категории «Изменения службы каталогов» в журнал аудита заносятся сообщения, содержащие старое и новое значение измененных атрибутов. Это действительно огромное достижение. Единственное, что огорчает: старое и новое значение указываются в разных записях, и их приходится сопоставлять, чтобы выявить изменение. Многие дополнительные средства для работы с журналом аудита, в том числе и службы ACS, умеют сопоставлять такие записи.
Изменения пользовательского интерфейса
Оснастки консоли управления «Пользователи и компьютеры», «Узлы и службы», «Домены и доверие» с самого момента появления были достаточно удобными для управления службой каталогов Active Directory. В Windows Server 2008 были подправлены основные средства администрирования, в них появились новые функции. Если включить «Дополнительные возможности», в диалоговм окне свойств для каждого объекта отображается еще одна вкладка — «Редактор атрибутов». Эту же самую вкладку использует программа ADSIEdit, позволяющая проверять и изменять любые атрибуты объектов. На вкладке улучшена функция декодирования кодированных атрибутов, таких как атрибут userAccountControl. На рис. 8 показано, насколько тесно интегрирован редактор атрибутов.
Рис. 8 Редактор атрибутов в оснастке «Пользователи и компьютеры Active Directory»
Заключение
Кроме самых основных изменений, которых мы коснулись в данной статье, службы ADDS в Windows Server 2008 содержат много других улучшений. Например, в центре KDC используется стандарт шифрования AES-256, если домен расположен на функциональном уровне домена Windows Server 2008. Для любого объекта служб домена можно включить защиту от случайного удаления, установив соответствующий флажок на вкладке «Объект». Был улучшен расширенный обработчик хранилищ, предоставляющий службу управления: в нем используется механиз исправления одноразрядных ошибок памяти, благодаря чему сокращается вероятность сбоя обороудования и программного обеспечения подсистемы диска по причине нарушения дерева каталогов. Служба DNS начинает обработку запросов еще до того, как база данных DNS загрузится полностью. Модуль локатора был усовершенствован: если он не находит контроллер домена в выбранном узле, он пытается найти контроллер в ближайшем узле, а не просто любой контролер, имеющийся в домене. Программа NTDSUTIL поддерживает мгновенные снимки контроллеров RODC и службы теневого копирования томов.
Очевидно, что в Windows Server 2008 появился ряд существенных изменений служб доменов Active Directory. В сумме они серьезно повышают безопасность и управляемость служб ADDS. Но самой лучшей, на мой взгляд, особенностью Windows Server 2008 является то, что при его интеграции в среду Active Directory не приходится устраивать массовые миграции: процесс проходит просто и незаметно.
Автор: Джил Киркпатрик (Gil Kirkpatrick)
Источник: март выпуск Technet Magazine