Active Directory на платформе Windows Server 2003

Вступление

Данная статья посвящена службе каталогов Active Directory, тем новым возможностям и механизмам, что она обрела с появлением Windows Server 2003, а также использованию всех этих улучшений на практике.

Весь представленный материал разбит на шесть тем. Мы поговорим о внедрении Active Directory и интеграции с уже существующими каталогами, администрировании службы, репликации, доверии между лесами, управлении групповыми политиками и ограничении на использование программ.

Внедрение и интеграция

В данной главе мы рассмотрим новые возможности Active Directory с нескольких точек зрения: внедрения этой службы, ее интеграции с другими каталогами, перехода с предыдущей версии (либо обновление с Windows NT 4.0, либо просто установка Active Directory с нуля). Прежде всего, необходимо отметить, что новые возможности Active Directory на базе Windows 2003 по большей части не совместимы с Active Directory на базе Windows 2000. Например, возможности переименовать домен или восстановить ранее деактивированный объект в схеме могут быть использованы только тогда, когда каталог находится на максимально возможном функциональном уровне: уровень домена - Windows Server 2003 и уровень леса - Windows Server 2003. Чтобы получить доступ к этим и другим возможностям, следует перевести лес на максимально функциональный уровень. Рассмотрим, что собой представляют эти самые функциональные уровни.


Замечу, что такая классификация была специально введена для обеспечения совместимости на уровне обратно-несовместимых возможностей. Даже если установить Active Directory с нуля, не выполняя никаких обновлений и не заботясь об интеграции, то есть просто установить новый сервер, а на него - первый контроллер в лесе, то получится система, которая изначально попадает на самый низкий уровень. Другими словами, уровень домена - Windows 2000 Mixed (смешанный) и уровень леса - Windows 2000. Таким образом, в этом режиме установленная система полностью соответствует всем тем возможностям, которые есть в Windows 2000 Active Directory. Чтобы перейти на более высокий уровень, необходимо выполнение определенных условий, например, домен может быть переведен на уровень Windows Server 2003 только после того, как все контроллеры этого домена будут переведены на эту операционную систему. Если говорить о переходе с Windows 2000, то, естественно, процесс перехода заключается в поэтапном обновлении существующих контроллеров. Невозможно все контроллеры разом перевести с Windows 2000 на Windows 2003, это можно делать только по очереди. Пока процесс перевода контроллеров не завершен, функциональный уровень домена остается на уровне Windows 2000 Mixed. Как только будут переведены все контролеры, можно перейти на следующий уровень. Администратор переключает функциональный уровень с помощью специальной консоли Active Directory Domains Trusts. Администратор не в состоянии понизить уровень, он может только перевести его на более высокую ступень, на котором система останется. После того, как администратор перевел домен на новый функциональный уровень, в Active Directory появляются определенные новые возможности.

Рассмотрим эти возможности для простоты изложения в режиме чистый лес - Windows 2003 и все домены - Windows 2003. Другими словами, максимально возможные уровни и, соответственно, максимальный спектр новых возможностей. Первое, на чем стоит остановиться - это функция, которая называется Application Partitions (по-русски - Разделы Приложений).


Дело в том, что Active Directory изначально разрабатывалась, как служба каталога не просто для обеспечения, например, сетевого обслуживания клиентов или для хранения учетных записей этих клиентов, но и как хранилище для сетевых приложений. Поэтому в Active Directory очень много информации, которая поступает от приложений. Таким образом, на Windows 2000, сколько бы приложений мы не установили в режиме фильтрации с Active Directory, вся информация о них попадет в единый каталог и, соответственно, реплицируется между всеми контроллерами равноправно.

Windows 2003 позволяет дифференцировать и отделить информацию, которая принадлежит сетевым приложениям от остального каталога путем создания разделов для приложений. Например, информация, которую хранит сервер DNS, может быть распределена не на все контроллеры, которые есть в домене, а только на те, которые были явно указаны. Фактически, это и означает создание разделов. Сначала можно создать раздел "каталоги", как бы отделяя его от общей структуры, а потом указать, что этот раздел в качестве реплики должен храниться на поименных контроллерах. Это же касается любого другого приложения. За счет такого механизма администратор, управляющий системой, может наиболее оптимально отделить и хранить информацию о каталоге и о приложениях. Например, если заведомо известно, что какое-то приложение будет использовать каталог только на данном конкретном контроллере (не будет обращаться к другим контроллерам), то можно таким способом свести хранилище каталога только к этому контроллеру за счет создания уникального раздела для этого приложения.

Следующей возможностью является поддержка класса объектов InetOrgPerson (RFC 2798). Она появилась только в Windows 2003, а Windows 2000 этот класс объектов не поддерживает. InetOrgPerson нужен для интеграции с другими LDAP-каталогами (Novell, Netscape). Active Directory умеет работать с этим классом, создавать объекты этого класса, возможна также прозрачная и плавная миграция объектов типа InetOrgPerson из других каталогов Active Directory. Соответственно, становится возможным перенос приложений, написанных для других LDAP-каталогов. Если приложения используют данный класс, то их можно безболезненно, прозрачно портировать на Active Directory, сохраняя всю функциональность.

Далее, появилась возможность переименования доменов. В данном случае, следует четко понимать, что под переименованием домена имеется в виду не просто смена названия домена (назывался раньше домен "abcd", а теперь называется "xyz"). На самом деле, структура каталога является деревом, в нем много доменов, а сами домены объединены в иерархию. Переименование домена, это, на самом деле, реструктуризация леса. Можно переименовать домен таким образом, что он окажется в другом дереве.


Рассмотрим домен Contoso, подчиненный домену Sales в дереве WorldWideImporters.com. Его можно переименовать и назвать Contoso.Fabrikam.com. Это не просто переименование, это перенесение домена из одного дерева в другое, то есть достаточно нетривиальная процедура. Логично предположить, что переименование домена может привести к созданию нового дерева. Можно переименовать домен Contoso, который был подчинен домену Sales, и назвать его Contoso.com. Тогда домен станет родоначальником другого дерева в этом же лесе. Именно поэтому процесс переименования домена можно считать весьма сложной и нетривиальной процедурой.

В Windows 2000 такой возможности, как переименовать домен в приведенном выше контексте, не было в принципе. Если домен создан, то на всю жизнь он останется со своим именем. Единственный способ изменить ситуацию - это удалить домен, а потом создать его заново с новым именем.

Вместе с Windows 2003 поставляется утилита, которая называется Rendom, буквально от слов Rename Domain. Утилита Rendom.exe - это утилита командной строки, которая может использоваться для переименования домена. Правда, этот процесс состоит из шести этапов. Подробную информацию о нем можно отыскать в службе справки Windows 2003, специальных технических документах для Microsoft .NET, на сайте MSDN. Там подробно описано, как моделировать, проектировать и проводить процесс переименования домена, с использованием утилиты rendom. В любом случае, это сложный, многоэтапный процесс, требующий тщательной подготовки: слишком много связок и указателей, имен и прочих взаимозависимостей, которые формируются при создании доменов. Просто взять и одним махом все это перенести - невозможно.

В плане внедрения Active Directory появился режим установки контроллера домена со съемного носителя. Что имеется в виду? Очень часто встречается ситуация, когда предприятие внедряет Active Directory в удаленных офисах: связь с удаленным офисом слабая, плохие линии связи между головными офисами и филиалами. Тем не менее нужно в филиале установить новый контроллер доменов. Когда создается новый контроллер в уже существующем домене, утилита DCPromo связывается с существующими, работающими контроллерами и перекачивает себе всю базу данных и реплики, которые можно собрать с контроллера её домена. Если эта база занимает несколько десятков или сотен килобайт, то есть пустая (она по-умолчанию занимает несколько сот килобайт), то проблем нет. Но если говорить о работающей системе, в которой база может занимать десятки или сотни мегабайт, то её перекачка может оказаться просто невыполнимой задачей. Поэтому в этой ситуации можно решить проблему очень простым способом. С помощью Windows NT Back-up сделать архив в режиме "system state", то есть выбрать в консоли Windows NT Back-up опцию Back-up->SystemState. После этого весь созданный Back-up записать на носитель, например, на CD или DVD, взять этот диск и приехать с ним в удаленный офис, там восстановить всю информацию из архива с помощью той же самой Windows NT Back-up. Только нужно сделать восстановление не по умолчанию, а в другой каталог, чтобы сами файлы были просто выложены на диск. Естественно, не нужно заменять ту системную информацию, которая есть на существующем компьютере. Далее следует запустить утилиту DCPromo с ключом "/adv" и указать путь к тому хранилищу, где находится распакованный файл. После этого процесс инсталляции нового контроллера будет создавать свою реплику на основании информации со съемного носителя. При этом все равно потребуется связь с головным офисом, потому что помимо перекачки реплики, требуется еще установление определенных отношений с существующим доменом. Поэтому связь должна быть, но требования к ней существенно снижены: подойдет даже очень слабая линия. В приведенном сценарии 95% информации, которые нужно было перекачивать на новый контроллер, были перенесены на системный носитель, а линию связи между головным офисом и филиалом не пришлось перегружать.

Важно отметить, что у заказчиков по-прежнему очень часто используется Windows NT 4.0. Windows 2003 позволяет перейти с существующих каталогов (с NT 4 или с Windows 2000) быстрее, более безболезненно и эффективно. Этой цели служит утилита Active Directory Migration Tool (ADMT) . ADMT поможет с миграцией с Windows NT на Windows 2003, а также с Windows 2000 на Windows 2003 в том случае, если потребуется какая-то реструктуризация доменов, перенесение учетных записей и т.д.


Active Directory Migration Tool представляет собой набор программ-мастеров. Каждый мастер выполняет определенную задачу (см. картинку выше). Важно, что большинство программ-мастеров имеет режим, который называется "Test migration settings and migrate later" - моделирование процесса без реального выполнения операций. Другими словами, процесс миграции эмулируется, и администратор может посмотреть, каков будет результат и как все будет происходить. Реальные действия в этом режиме не выполняются. В случае, когда результаты работы тестового режима удовлетворительны, можно попросить Active Directory Migration Tool выполнить полноценную миграцию.

Администрирование

Данная глава посвящена инструментальному администрированию. В принципе, нельзя сказать, что здесь появилось много новых очень полезных возможностей. Однако кое-что все-таки есть. Например, поддержка Drag&Drop: до выхода Windows 2003 поддержки Drag&Drop не было. Теперь можно кликнуть на объект "пользователь" и перетащить его мышкой в новый контейнер. Это очень удобно. Жаль, что такого механизма в предыдущих версиях не было.

Появилась дополнительная консоль для хранения запросов к каталогу. Известно, что Active Directory - это LDAP-каталог. Значит, к LDAP-каталогам можно делать запросы на стандартном языке запросов. Если эти запросы делать и не запоминать, то это является дополнительной нагрузкой на администратора: каждый раз ему нужно запрос писать заново или копировать его из какого-то документа. Для упрощения данного процесса предлагается раздел, который называется Saved Queries. В нем собственно и сохраняются те запросы, которые администратор или пользователь ввели в консоли.


Теперь, когда этот запрос потребуется вновь, достаточно просто выбрать его из списка. Более того, в правой части консоли отображаются результаты запроса: слева можно выбрать интересующий запрос и щелкнуть на нем, а справа уже появится результат отработки.

Windows Server 2003 содержит очень много программ командной строки. Это кажется странным и даже, может быть, противоречащим. Казалось бы, Microsoft все эти годы продвигает графический интерфейс, удобство управления с помощью графического интерфейса, но в то же время, оказывается, выпускает новые утилиты командной строки. Вот только для Active Directory их целых шесть штук.


В этом нет, на самом деле, никакого противоречия. Дело в том, что очень много операций, которые приходится выполнять администратору, удобнее делать в виде командных файлов. Например, когда речь идет о модификации у одинаковых или похожих объектов какого-то атрибута, это часто удобнее сделать в командной строке, написав соответствующий скрипт. Если необходимо изменить какой-то параметр, например, телефоны пользователей, которые прописаны в учетной записи (у всех в подразделении может поменяться телефон), можно зайти в каждую учетную запись и изменить телефон. Если это делать через графический интерфейс, то придется произвести как минимум сто операций по изменению объекта "Учетная запись". Можно же взять одну простую команду, которая называется DSMod (модификация объекта), сформировать строчку для записи новой информации, после чего написать скрипт с условиями поиска и выполнить всё в виде одной команды. Для таких операций (а в повседневной работе администратора их множество) следует использовать утилиты командной строки и скрипты.

Репликация

Вопросы репликации очень актуальны при внедрении Active Directory, проектировании и планировании инфраструктуры.

В Windows 2000 есть определенные ограничения по количеству сайтов, в которых можно было бы автоматически сгенерировать топологию. Существует служба, которая называется Inter-Site Topology Generator (ISTG) . Когда создаются два или три, а лучше пять или даже десять сайтов, служба ISTG автоматически генерирует топологию репликаций между сайтами, сама выбирает узловые серверы, сама определяет, как будет выполняться сценарий этой репликации. Всё хорошо, но если сайтов порядка двухсот, то служба ISTG не справляется с объемом информации и зацикливается. Поэтому для Windows 2000 есть совершенно четкая рекомендация - количество сайтов не должно быть более двухсот, если необходимо, чтобы топология репликации между сайтами генерировалась автоматически. Если же сайтов больше - автоматическую генерацию надо отключить и настраивать все это вручную.

Проблема, казалось бы, не очевидна, но с ней люди реально сталкиваются, когда доходит до внедрения Active Directory на многосайтные системы. Windows Server 2003 снимает этот вопрос. В этой системе реализован абсолютно новый Inter-Site Topology Generator, который работает принципиально по-другому и генерирует топологию, используя новый алгоритм. Количество сайтов, которое может теперь автоматически генерироваться (топология которых может генерироваться автоматически с помощью службы ISTG), только на тестах было несколько тысяч. Неизвестно, кому может потребоваться столько сайтов, но, тем не менее, можно забыть о каком-либо ограничении только за счет модификации механизма ISTG.

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

Есть еще одно ограничение в том, как Active Directory в Windows 2000 реплицирует группы. Речь идет о группе безопасности. Когда дело касается назначения прав для доступа к каким-то объектам, обычно правильная практика администрирования подразумевает, что права назначаются группам. Пользователи либо включаются в группу, либо исключаются. Группа - это точно такой же объект в Active Directory, как и все остальные объекты. Объект же имеет атрибуты. Особенность группы заключается в том, что список членов группы - это не несколько атрибутов, это один атрибут с большим количеством значений, так называемый "Multi Value Attribute" (на самом деле, это один атрибут, у которого много значений). Механизм репликации Active Directory детализирован до уровня атрибута. Если объект модифицируется, то система будет реплицировать эти изменения ровно для тех атрибутов, которые изменились, а не для всего объекта целиком. Теперь вернемся к группе, у которой есть атрибут, состоящий, например, из ста значений. Если в группу входит сто человек, значит у этого атрибута сто значений. А если 5 тысяч? Ограничение заключается в следующем: если членство в группе составляет 5 тысяч объектов, то репликация такого объекта становилась невозможна. Как только появится 5001 член группы, сразу же разрушается процесс репликации этой группы на Windows 2000. Есть даже документированный способ атаки, когда администратор, обиженный на кого-то, может разрушить процесс репликации в системе, просто написав скрипт, который циклическим образом поместит в какую-то группу 5 тыс. членов. После чего возникают проблемы с репликацией каталога. Windows Server 2003 Active Directory вводит дополнительный механизм, который называется "Репликация присоединенных значений" ("Linked Value Replication").

В этом случае механизм предназначен исключительно для репликации атрибутов, у которых есть много значений. То есть теперь, при использовании этого механизма членство в группе реплицируется на уровне отдельных членов. Если включить нового человека в группу, то репликация будет вестись не всего списка, как атрибут, а только значения за счет механизма Linked Value Replication.

Еще одна проблема, связанная с репликацией, имела отношение к глобальному каталогу. Трудность заключалась в том, как ведет себя глобальный каталог, когда администратор модифицирует, так называемый, Partial Attribute Set (PAS) - список атрибутов, которые должны быть помещены в глобальный каталог.

Возможно, имеет смысл пояснить. У каждого атрибута есть статусное значение: помещать в глобальный каталог или нет. Глобальный каталог - это дополнительный каталог, который содержит информацию обо всех объектах, которые есть в каталоге, но не полностью, а ровно списки тех атрибутов, которые помечены, как экспортируемые в глобальный каталог. Таким образом, например, о каждом пользователе в глобальный каталог помещается его имя, его электронный адрес, возможно, еще какой-нибудь дополнительный параметр. Буквально несколько параметров, для того, чтобы можно было быстро найти этого пользователя в каталоге.

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

Windows Server 2003 снимает эту проблему. Репликация и синхронизация глобального каталога будет проводиться исключительно в объеме добавленного атрибута. То есть когда проводится операция добавления атрибута к PAS, происходит просто сбор информации у тех объектов, у которых этот атрибут есть. А затем он [атрибут] добавляется к глобальному каталогу. Полной синхронизации не происходит.

Еще одна дополнительная функция, касающаяся глобального каталога - это механизм кэширования универсальных групп. Напомню, группы в Active Directory бывают трех типов: локальные, глобальные и универсальные. Локальные и глобальные хранятся вместе с репликой на контроллере, универсальные группы хранятся в глобальном каталоге. Когда сотрудник удаленного офиса хочет войти в сеть, система провести регистрацию пользователя в сети и создать его контекст безопасности. Для этого ей необходимо узнать, в какие группы входит пользователь. Узнать о локальных и глобальных группах Windows 2000 может на своем ближайшем контроллере, но по устройству сети, глобальный каталог находится в головном офисе. Проверить членство пользователя в универсальных группах можно только, сделав запрос к глобальному каталогу. Поэтому на момент регистрации необходимо послать запрос в головной офис. Если связь оборвана и глобальный каталог не доступен, то пользователю будет отказано в регистрации (по умолчанию в этой ситуации). Если в реестре поставить значение "игнорировать ошибки, связанные с членством в универсальных группах", в системе безопасности образуется дыра.

Windows Server 2003 предлагает механизм кэширования универсальных групп. Теперь требуется подключение к глобальному каталогу только при самой первой регистрации пользователя. Эти группы попадают на контроллер и там сохраняются. Каждая последующая регистрация пользователя не потребует обращения, потому что членство в универсальных группах уже известно. При этом кэширование информации определенным образом обновляется: через условленные промежутки времени информация глобального каталога запрашивается для обновления информации о членстве пользователей в универсальных группах.

Доверие между лесами

Доверие между лесами позволяет интегрировать совершенно независимые организации. Active Directory представляет собой структуру, в которой может быть дерево доменов с корневым доменом, а может быть лес, состоящий из нескольких деревьев. Характеристикой леса является то, что для всех доменов, входящих в него, для всех тех деревьев, есть три одинаковые сущности - это единая схема, единые контейнеры конфигурации и общий глобальный каталог для леса. Естественно, пространство имен у них разное, хотя можно дать имя лесу целиком. Если это не сделано, то у каждого дерева будет своя иерархия имен. Можно сделать так, что все деревья в лесе будут выстроены в одну систему имен.


Когда речь идет об интеграции и взаимодействии между двумя разными лесами, обычно имеются две разные системы, построенные независимо друг от друга. Тем не менее, необходимо, чтобы пользователи одного леса (определенные только в одном лесе) могли обращаться к объектам, определенным в другом лесе. Для этого нужно установить доверительные отношения.

Windows 2000 позволяет сделать прямые и транзитивные отношения между конкретными доменами из разных лесов, но работать это будет только для данных доменов. Windows Server 2003 предлагает новый тип доверия, который называется "Отношение доменов между лесами". Эти отношения являются транзитивными для доменов, которые входят в каждый из лесов. То есть, когда два леса соединяются доверительными отношениями, пользователи из любого домена одного леса абсолютно прозрачно могут видеть объекты другого леса и обращаться к ним из любых доменов.

Можно сделать цепочку, например, из трех лесов A, B, C. A доверяет В, а В доверяет С. Из этого не следует, что между лесом А и С тоже установились доверительные отношения. Это как в Windows NT 4: не транзитивные отношения в том смысле, что они не транзитивны между лесами. Но между доменами, которые связывают два леса, отношения являются транзитивными.

Управление групповыми политиками

Групповые политики - это основной инструмент, который используется для управления практически всеми подсистемами и компонентами в рамках Windows. Будь то рабочая станция и ее настройки, будь то сервер и его сетевые службы, Active Directory, параметры безопасности - все это настраивается через групповые политики.

Механизм групповых политик позволяет назначать политики контейнерам, то есть организационным подразделениям, сайтам и доменам. Групповую политику нельзя назначить конкретному пользователю. При этом, поскольку структура контейнеров в Active Directory иерархична, можно на разных уровнях назначать разные групповые политики. Следовательно, работают механизмы наследования. У администратора есть определенные функции по блокировке наследования или, наоборот, по принудительному применению политики наследования. Администратор имеет возможность фильтровать применение групповых политик через права доступа. В любом случае, большое количество задач решается с помощью не меньшего количества инструментов. Для каждой задачи есть определенный инструмент. Таким образом, чтобы управлять групповыми политиками в Windows 2000, требуется знать порядка шести инструментов и использовать их для различных задач.

Windows Server 2003 позволяет существенно упростить жизнь администратору за счет появления специального инструмента, который называется Group Policy Management Console. Это интегрированная или консолидированная консоль, которая включает в себя интерфейс для выполнения абсолютно всех задач, связанных с групповыми политиками. Больше не нужно ломать голову, где делается данная операция - все в Group Policy Management Console, при этом консоль группирует информацию очень логично, интуитивно понятно.

Помимо того, что Group Policy Management Console является консолидированным графическим инструментарием, она еще и добавляет ряд новых функций к управлению групповыми политиками. Например, функции архивирования и восстановления групповых политик, функции копирования групповых политик между доменами одного леса и импорт/экспорт групповых политик.

Group Policy Management Console, как составная часть Windows Server 2003, отсутствует. Ее нужно скачивать с web-сервера Microsoft (http://www.microsoft.com/downloads). Установить консоль можно либо на Windows Server 2003, либо на Windows XP при наличии Service Pack 1 и .NET Framework. Таким образом, с помощью Group Policy Management Console можно управлять групповыми политиками, даже не находясь непосредственно на контроллере домена. Можно установить консоль прямо на рабочую станцию Windows XP и с этой рабочей станции централизованно управлять всеми групповыми политиками леса. Кроме того, в составе Group Policy Management Console есть два мастера, которые позволяют анализировать и моделировать процесс применения групповых политик. Первый называется "Мастер результатов применения групповых политик" и он показывает, какие политики применялись к данному конкретному компьютеру, какие значения изменились и с каких политик эти значения были получены. Если что-то не применилось, мастер показывает, почему это не применилось.

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

Процесс такого моделирования выполняется с помощью консоли, которая расположена в Group Policy Management Console и называется Process Modeling. Моделирование не требует подключения к исследуемому компьютеру. Оно работает только с информацией, которая хранится в Active Directory. Достаточно просто иметь доступ к контроллеру Windows Server 2003 Active Directory. Можно, например, представить, что случится, если пользователь войдет в какую-то группу безопасности, можно условно поместить пользователя в какой-то контейнер и посмотреть, что произойдет.

Есть еще некоторые новые возможности Group Policy Management Console - это архивирование и восстановление групповых политик. Сами объекты можно сохранить в виде файла в определенном каталоге. Потом их можно восстановить обратно в случае какой-то проблемы или при экспериментах с доменом, Active Directory или групповыми политиками. Важно, что восстановить групповую политику можно только в том же домене, в котором она была заархивирована. Восстанавливается только объект групповой политики сам по себе: то, что было к нему дополнительно привязано, нельзя поместить в архив, соответственно, восстановить тоже.

Перейдем теперь к Windows Management Instrumentations (WMI). Это технология, которая сейчас является основной в управлении системами. WMI используется практически везде: любая служба так или иначе задействует WMI.

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

Политика ограничения на использование программ

Это централизованная политика, которая может реализовываться на уровне всего предприятия. С её помощью администратор имеет возможность ограничить список программ, которые могут запускать пользователи на своих рабочих станциях. Администратор может, наоборот, указать список программ, которые пользователи на своих машинах ни при каких условиях запускать не могут.

Для реализации этого механизма используется принцип: базовый уровень, плюс исключение. Соответственно, базовые уровни могут быть двух типов для разных сценариев. Первый базовый уровень называется "Disallowed": все программы по-умолчанию запрещены, кроме тех, которые разрешены в исключениях, в дополнительных правилах. Второй называется Unrestricted: разрешены все программы, но в списке дополнительных правил указаны исключения, то есть черный список программ, которые нельзя запускать.

Правила могут быть четырех типов (ранжированы по приоритету): Certificate (максимальный приоритет), Hash, Path и Zone. Приоритет актуален, когда есть несколько политик, определяющих одно и то же приложение разными правилами. Например, одна политика разрешает запускать все программы, которые расположены в каталоге "ABCD", а другая политика запрещает запускать программы, имеющие такой-то хэш. Если окажется, что эта программа, которую запрещено запускать, находится в разрешенном каталоге ABCD, то сильнее окажется правило запрета, потому что правило по хэшу "побеждает" правило по пути. Именно для этого используется приоритет.

Заключение

Можно резюмировать, что с появлением Windows Server 2003 добавилось не так уж и много полезных возможностей для работы с Active Directory. Тем не менее, некоторые из них очень полезны и могут сэкономить время и нервы системному администратору. Это, прежде всего, Group Policy Management Console и утилиты командной строки. Остальные изменения зачастую устраняют недоработки предыдущих версий системы (обновленные механизмы и алгоритмы), однако все равно необходимо знать, где именно возможности Active Directory расширены и как ими пользоваться...