Изменение иерархии доменов

Планирование доменов следует закончить перед началом развертывания, потому что доменную конфигурацию трудно изменять после. Windows Server 2003 имеет возможность переименования доменов в лесу, работающем на функциональном уровне Windows Server 2003. Можно перемещать домен из одного дерева в другое в пределах леса, но нет возможности замены корневого домена леса. По существу, возможность переименования домена позволяет вам изменять структуру именования в лесу, но не позволяет делать более фундаментальные изменения. Например, если вы решите изменить деловые подразделения в каждом домене, вы должны переместить большое количество объектов между доменами. Для этого вы должны использовать инструмент для переме-

щения Active Directory (ADMT - Active Directory Migration Tool v.2) или сторонние инструментальные средства. Инструмент ADMT можно найти в папке /I386/ADMT на компакт-диске Windows Server 2003.

Изменение объекта связи, созданного КСС

Вы можете изменять график и контроллер-отправитель для объекта связи в пределах сайта, а также транспортный протокол для межсайто-вых объектов связи. По умолчанию контроллеры домена в пределах сайта каждый час проверяют всех своих партнеров по репликации, чтобы удостовериться, что обновления не были пропущены. Этот график можно изменить так, чтобы никогда не делать проверку, проверять каждые полчаса или каждые 15 минут. (Интерфейс связи показан на рисунке 4-1.)

Когда вы производите изменения объекта связи, его имя <automatically generated> (автоматически сгенерированный) заменяется на глобальный уникальный идентификатор объекта (GUID). После изменения объекта вы можете его переименовать.

Рис. 4-1. Конфигурирование существующего объекта связи

Изменение системного реестра

При создании безопасного канала связи между исходными и целевыми контроллерами домена на исходном контроллере домена Windows NT 4 должен быть модифицирован системный реестр. Если этого не сделать перед установкой ADMT, то инструмент выполнит изменения при первом использовании. После того как ADMT сделает изменения системного реестра, необходимо будет перезагрузить PDC.

Установка этого значения разрешает удаленные вызовы процедуры (RPC) по протоколу TCP, нисколько не уменьшая защиту системы Windows NT 4. На исходном PDC откройте системный реестр и создайте следующий ключ:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentContolSet\Control\Lsa.

Создайте значение TcpijpClientSupport, установив DWORD, равный 1.

Наилучшая практика. Если вы планируете переместить пароли учетных записей пользователя одновременно с самими учетными записями (в противоположность тому, чтобы прекратить срок действия пользовательских паролей в Windows NT 4 и заставить пользователей создавать новые пароли при первом входе в систему домена с сервером Windows Server 2003), то вам сТпять потребуется редактировать системный реестр. Чтобы поддержать перемещение паролей, на исходном PDC отредактируйте (или создайте, если он еще не существует) следующий ключ системного реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\Lsa.

Для значения AllowPasswordExport установите DWORD, равный 1. Для получения дополнительной информации о переносе паролей смотрите справку инструмента ADMT.

Изменение заданного по умолчанию способа применения групповых политик

По умолчанию все групповые политики для учетных записей компьютеров и пользователей применяются в порядке Локальный/Сайт/Домен/ Организационная единица (Local/Site/Domain/Organizational Unit -LSDOU). В пределах контейнера каждый пользователь и компьютер будут затронуты групповой политикой. Однако в некоторых случаях этого происходить не должно, и вы можете сконфигурировать исключения к заданному по умолчанию способу применения групповых политик.

Эмулятор PDC

В большинстве сетей отказ эмулятора PDC обычно вызывает немедленный отклик, чем отказ любого другого хозяина операций. В домене, который работает на функциональных уровнях Windows 2000 mixed (смешанный) или Windows Server 2003 interim (временный), эмулятор PDC является основным (primary) партнером по репликации для всех резервных копий контроллеров домена Windows NT (BDC). Пока не восстановлен эмулятор PDC BDC-контроллеры не будет получать модифицированную информацию. Кроме того, низкоуровневые клиенты типа Windows NT, Windows 95 и Windows 98 (не имеющие клиентов службы каталога) должны соединяться с эмулятором PDC, чтобы пользователь имел возможность изменять свой пароль. Даже в домене, работающем на функциональном уровне Windows 2000 native (естественный) или на более высоком, эмулятор PDC играет роль основного партнера по репликации для замен пароля. Эмулятор PDC является также предпочтительным сервером для создания каких-либо изменений к групповым политикам. Если эмулятор PDC недоступен, когда вы пытаетесь просмотреть групповые политики, вы получите предупреждающее сообщение. Поскольку эмулятор PDC поддерживает все эти службы, то восстановление роли эмулятора PDC в сети должно иметь высокий приоритет.

Хотя эмулятор PDC играет важнейшую роль в домене, захват этой роли другим контроллером домена, в то время как оригинальный эмулятор PDC недоступен, имеет свои ограничения. Фактически, захват этой роли подобен захвату роли PDC в домене Windows NT. Если PDC когда-либо выходил из строя в домене Windows NT, вы могли выбирать другой контроллер домена и конфигурировать его так, чтобы он был PDC-koh-троллером. Те же самые функциональные возможности существуют в Windows Server 2003. Если эмулятор PDC выходит из строя, вы должны передать эту роль на другой контроллер домена. Даже если контроллер домена будет недоступен только в течение пары часов, все равно нужно передать эту роль. Когда оригинальный эмулятор PDC будет восстановлен и снова связан с сетью, он обнаружит присутствие нового эмулятора PDC и уступит ему эту роль.

Эволюция службы каталога от Microsoft

Active Directory является последней версией службы каталога для операционной системы Microsoft Windows. Служба Active Directory впервые появилась в Windows Server 2000, и она является компонентом Windows Server 2003. Потребность в службе каталога в вычислительной среде компьютеров Microsoft выросла в результате быстрого распространения персональных компьютеров на рабочих местах. По мере увеличения количества компьютеров, входящих в рабочую среду корпораций, растет потребность в том, чтобы связать их для совместного использования ресурсов и дать возможность пользователям взаимодействовать в почти реальном времени. Но когда компания совместно использует ре-

сурсы, доступные в сети, требуется также каталог (или справочник) пользователей и системы, предназначенный для назначения ресурсам пользовательских разрешений.

Как клиент определяет, какому сайту он принадлежит

Наличие специфических для сайта записей важно для эффективной работы Active Directory, потому что поле деятельности клиента ограничено определенным сайтом. Например, в процессе входа в систему клиент всегда пробует соединиться с контроллером домена, расположенном в своем сайте, прежде чем соединяться с любыми другими сайтами. Как же клиент узнает, какому сайту он принадлежит?

Информация сайта для леса хранится в разделе конфигурации ката-, лога в Active Directory, она копируется на все контроллеры домена в лесу. Список IP-подсетей, которые связаны с определенным сайтом, включается в конфигурационную информацию. Когда клиент впервые входит в Active Directory, первый ответивший контроллер домена сравнивает IP-адрес клиента с IP-адресом сайта. Часть ответа контроллера домена клиенту составляет информация сайта, которую клиент затем кэширует. Любые последующие попытки входа в систему будут включать информацию сайта клиента.

Если клиент переместился между сайтами (например, портативный компьютер может быть подсоединен к сети в другом городе), он все еще посылает информацию сайта как часть входа в систему. DNS-сервер ответит с записью контроллера домена, который находится в запрашиваемом сайте. Однако если на основе нового IP-адреса клиента контроллер домена решит, что клиент не находится на первоначальном сайте, он пошлет новую информацию сайта клиенту. Затем клиент выполнит кэширование новой информации и попытается найти контроллер домена в правильной подсети.

Если клиент не находится ни в одном из сайтов, которые определены в Active Directory, то он не сможет выполнять запросы на специфическую для сайта информацию о контроллерах домена.

Как осуществлять мониторинг Active Directory

Осуществляя мониторинг Active Directory, вы будете отслеживать ключевые индикаторы производительности и сравнивать их с базовыми показателями, которые представляют работу службы в пределах нормальных параметров. Когда индикатор работоспособности превышает

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

Ниже приводится схема процесса мониторинга службы Active Directory высокого уровня.

Определите, какой из индикаторов функционирования службы вы должны отслеживать. (Начните с просмотра своих SLA-соглашений с клиентами.)

Выполните мониторинг индикаторов функционирования службы, чтобы установить и задокументировать свой базовый уровень.

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

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

уведомления оператора;

автоматические действия, если они возможны;

действия, инициируемые оператором.

Спроектируйте систему создания отчета, фиксирующую историю системного «здоровья» Active Directory.

Реализуйте свое решение, чтобы измерять выбранные ключевые индикаторы в соответствии с расписанием, отражающим изменения данных индикаторов и их воздействие на «здоровье» Active Directory.

Далее в разделе исследуется каждое из этих действий. Идентификация индикаторов функционирования описана в разделе «Что следует отслеживать».

Кэширующие серверы имен

Третий тип сервера имен - это сервер, который только кэширует информацию (caching-only). Он не управляет зонными файлами, а только кэширует любые разрешения имен, которые он выполнял. Кэширующий сервер часто используется в удаленных офисах, подключенных к большому офису с ограниченной пропускной способностью. Поскольку кэширующий сервер не имеет никаких зонных файлов, то и трафик зонной передачи DNS через медленное сетевое подключение отсутствует. Кэширующий сервер должен конфигурироваться так, чтобы он переправлял все DNS-запросы на сервер, расположенный в главном офисе компании. Поскольку кэширующий сервер разрешает DNS-запросы, то он кэширует информацию в течение некоторого времени (по умолчанию -1 час). Это означает, что любой местный DNS-запрос той же самой информации может быть разрешен в местном масштабе.

Примечание. Все DNS-серверы Windows Server 2003, включая основной и дополнительные серверы имен, кэшируют информацию, но они не называются кэширующими (caching-only) серверами. Различие между этими серверами и только кэширующими серверами состоит в том, что последний не имеет никакой зонной информации.

Ключевые функции и преимущества службы Active Directory

Вы можете спросить: «Зачем мне нужна служба Active Directory?». Если вы заинтересованы в выполнении наиболее сильно интегрированной службы каталога для Windows Server 2003, то Active Directory является логичным выбором. Другая очень популярная причина, подталкивающая к реализации службы Active Directory, состоит в поддержке Microsoft Exchange Server 2000. Exchange Server 2000 полагается на Active Directory для своей службы каталога, поэтому многие администраторы реализуют Active Directory, чтобы модернизироваться до Exchange Server 2000. В этом разделе описано несколько ключевых функций и преимуществ службы Active Directory Windows Server 2003.

Компоненты схемы

Схема состоит из объектов классов и атрибутов. Объект класса определяет то, какие новые объекты могут быть созданы в каталоге. Для каждого создаваемого в каталоге объекта сначала должен быть определен класс. Пример объекта класса — класс User (Пользователь). Все новые пользовательские объекты, созданные в Active Directory, являются экземплярами класса User.

Схема определяет и то, какая информация может сохраняться для каждого класса объекта. Эта информация определяется в схеме как атрибут объекта. Объект некоторого класса может содержать значения для всех атрибутов, определенных для этого класса, а также для всех родительских классов этого класса. Например, учетная запись пользователя может иметь определенные значения атрибутов для всех объектов в классе User, так же как и для класса organizationalPerson, являющегося родительским классом класса User. При создании нового пользовательского объекта вы можете включать информацию, касающуюся этого пользователя и определяемую в схеме, в качестве атрибута всех классов, к которым этот новый пользовательский объект будет принадлежать.

Тип данных, которые могут храниться в Active Directory для каждого атрибута, определен в схеме как синтаксис атрибута. Если пользовательский класс содержит атрибут, названный display Name, синтаксис для этого атрибута определяется как строковое значение, которое может быть любым алфавитно-цифровым символом. Значение каждого атрибута должно удовлетворять требованиям синтаксиса этого атрибута.

Схема Active Directory поддерживает наследование объектов класса. Все объекты схемы организованы в иерархическом порядке в контексте именования. Благодаря этому любой объект класса способен унаследовать все характеристики объекта своего родительского класса. Например, класс Computer (Компьютер) фактически является дочерним классом от класса User (Пользователь), и поэтому класс Computer наследует все атрибуты, связанные с классом User. В этом случае класс Computer ассоциируется с атрибутами, специфическими для этого класса. С помощью оснастки Active Directory Schema вы можете увидеть организацию наследования объектов класса и иерархию объектов класса. На рисунке 2-1 показан класс Computer (Компьютер). Обратите внимание, что он является дочерним по отношению к классу User, который является дочерним классом класса organizationalPerson, и т.д. Эта система наследования значительно облегчает администраторам создание новых классов объектов, потому что они не должны определять каждый атрибут, связанный с новым классом, а могут просто унаследовать все объединения атрибутов подходящего родительского класса.

Рис. 2-1. Объект класса Computer (Компьютер), отображаемый оснасткой Active Directory Schema

Конфигурирование активации расширения файла

Одним из средств, с помощью которых пользователь может начать инсталляцию приложения, является активация расширения файла. В большинстве случаев с каждым определенным расширением файла связано только одно приложение. Однако в некоторых случаях можно иметь более одного приложения. Например, обновить Word 2000 до Word XP и в течение нескольких месяцев держать обе версии программного обеспечения доступными для инсталляции. В этом случае можно сконфигурировать, какая из двух версий приложения будет устанавливаться, когда пользователь начнет его установку через активацию расширения файла. Для этого в редакторе Group Policy Object Editor обратитесь к окну Software Installation Properties (рвойства инсталляционных программ) в разделе Computer Configuration или User Configuration. Выберите вкладку File Extensions (Расширения файла) (см. рис. 12-10). При активизации расширения файла будет установлено приложение, которое указано первым в списке.

Рис. 12-10. Конфигурирование активизации расширения файла

Конфигурирование доверительных отношений между лесами

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

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

Примечание. Создание доверительных отношений между двумя лесами допускает только совместное использование ресурсов между лесами. Все другие различия, существующие на уровне леса, сохранятся после создания доверительных отношений. Например, создание доверительных отношений не подразумевает, что леса будут совместно использовать глобальный каталог (GC) или общую схему.

Когда вы создаете доверительные отношения леса в Active Directory, они автоматически допускают маршрутизацию суффикса имени (name suffix routing) между этими лесами. Используя маршрутизацию суффикса имени, пользователи могут использовать свои основные пользовательские имена (UPN) при входе на любой домен любого леса. Например, если вы создаете доверительные отношения леса между лесом NWTraders.com и лесом Contoso.com, пользователи леса Contoso.com могут входить на рабочие станции в лесе NWTraders.com, используя свои UPN alias@contoso.com. Маршрутизация суффикса имени применяется по умолчанию ко всем именам доменов первого уровня, имеющимся в лесу. Это включает заданный по умолчанию UPN-суффикс и любые альтернативные суффиксы, сконфигурированные в лесу. Маршрутизация суффикса имени не работает между лесами, если один и тот же UPN-суффикс сконфигурирован в обоих лесах. Если UPN-суффикс Contoso.com сконфигурирован в лесе NWTraders.com, пользователи леса Contoso.com не смогут входить в лес NWTraders.com, используя свои UPN.

Когда вы впервые разрешаете доверительные отношения леса, все суффиксы домена первого уровня автоматически направляются на UPN доверительного отношения. Все дочерние суффиксы домена направляются неявно через суффикс родительского домена. Если вы добавляете другой UPN-суффикс к лесу, после того как создано доверительное отношение, вы должны разрешить маршрутизацию суффикса имени для нового суффикса. Вы можете сделать это, проверяя доверительное отношение между доменами или вручную добавляя новый суффикс на вкладку Name Suffix Routing (Маршрутизация суффикса имени) в окне свойств доверительного отношения.

Чтобы создать доверительное отношение леса, лес должен работать на функциональном уровне Windows Server 2003. Только члены группы Enterprise Admins (Администраторы предприятия) имеют разрешение создавать доверительные отношения леса.

Чтобы создать доверительные отношения леса, выполните следующее.

Запустите инструмент Active Directory Domains And Trusts. Щелкните правой кнопкой мыши на имени корневого домена леса и выберите Properties (Свойства). Выберите вкладку Trusts (Доверительные отношения).

Щелкните на кнопке New Trust (Новое доверительное отношение). Запустится New Trust Wizard (Мастер новых доверительных отношений). Напечатайте имя корневого домена леса в другом лесу.

Затем нужно будет выбрать тип доверительных отношений, которые вы хотите установить (см. рис. 7-4). Можно создать внешние доверительные отношения или доверительные отношения леса. Внешние доверительные отношения не являются транзитивными доверительными отношениями, в то время как доверительные отношения леса всегда являются транзитивными. Выберите Forest Trust (Доверительные отношения леса).

Выберите направления доверительных отношений (см. рис. 7-5).



Рис. 7-4. Конфигурирование типа доверительных отношений леса



Рис. 7-5. Конфигурирование направления доверительных отношений леса

Выберите вариант, создавать ли доверительные отношения только для этого домена или также для другого домена. (Эти два домена -корневые домены леса для каждого леса.) Доверительные отношения леса могут быть установлены только между корневыми доменами леса (см. рис. 7-6). Если нужно установить обе стороны доверительных отношений одновременно, впечатайте имя и пароль для учетной записи Enterprise Admins (Администраторы предприятия), которая существует в другом лесу. Если нужно установить доверительные отношения только для этого домена, напечатайте пароль, который будет использоваться для установки начального доверительного отношения. Затем это пароль должен использоваться для конфигурирования доверительных отношений в корневом домене леса другого леса.





Рис. 7-6. Выбор конфигурирования одной или обеих сторон доверительных отношений

Выберите уровень аутентификации, который будет предоставлен для исходящих и входящих доверительных отношений (см. рис. 7-7). Это позволит тщательно контролировать доступ к ресурсам между лесами. Если нужно применить аутентификацию по всему лесу, то пользователи одного леса будут иметь доступ ко всем серверам и ресурсам другого леса. Это такая же конфигурация, как доверительные отношения между доменами в пределах леса. Пользователи из одного домена леса могут обращаться к ресурсам в любом другом домене любого леса при условии, что им дано разрешение на доступ к ресурсу. Можно применять выборочную аутентификацию для доверительных отношений леса. В этом случае вы должны явно дать пользователям или группам из одного леса разрешения на доступ к серверам другого леса. Это можно сделать, предоставляя им права Allowed To Authenticate (Разрешено аутентифицировать) в Active Directory.

После конфигурирования доверительных отношений будет выполнена автоматическая проверка доверительных отношений.



Рис. 7-7. Конфигурирование уровня аутентификации для доверительных отношений леса

Конфигурирование других параметров безопасности

В дополнение к политике безопасности уровня домена групповые политики обеспечивают большое количество связанных с безопасностью параметров настройки. Как и в случае с политиками Account Policies, многие из этих параметров настройки конфигурируются при выборе контейнера Computer Conf iguration\Windows Settings\Security Settings. Некоторые дополнительные параметры настройки конфигурируются при выборе контейнера User Configuration\Windows Settings\Security Settings. На рисунке 13-6 показаны опции, находящиеся в каждой из папок Security Settings (Параметров настройки безопасности), в таблице 13-6 они суммированы для каждого заголовка.

Рис. 13-6. Дополнительные политики, имеющиеся в папке Security Settings

Использование групповых политик для настройки безопасности компьютеров вашей сети значительно облегчает создание и поддержание безопасной сетевой среды. Намного легче конфигурировать безопасность, используя групповые политики, чем иметь дело с каждой рабочей станцией индивидуально. Все, что вы должны сделать, - это создать централизованные политики безопасности, сконфигурировать их в объекте GPO и связать его с контейнерным объектом Active Directory. В следующий раз, когда будет применяться объект GPO, защита будет сконфигурирована на всех компьютерах в контейнере. Использование групповых политик облегчит постоянное управление параметрами настройки защиты для ваших компьютеров. Параметры настройки защиты, которые устанавливаются политиками, непрерывно обновляются. Даже если пользователь изменит конфигурацию защиты на рабочей станции, политика будет повторно применена в следующем цикле обновления. Изменить параметры настройки защиты просто, потому что вы можете изменить групповую политику и применить параметры настройки ко всем компьютерам, на которые воздействует данная политика.

Табл. 13-6. Параметры настройки защиты в групповых политиках

Опция конфигурации		Пояснение
Local Policies\Audit Policy (Локальные политики\Политика аудита)		Используется для конфигурирования параметров настройки аудита. Можно устанавливать политику аудита для таких опций, как действия по управлению учетными записями, события входа в систему, изменения политик, использование привилегий и системных событий.
Local Policies\User Rights Assignment (Локальные полити-ки\Назначение прав пользователей)		Используется для конфигурирования прав пользователей на компьютерах, подверженных воздействию этой политики. Можно устанавливать разнообразные политики, включая конфигурирование локального входа в систему, доступа к компьютеру из сети, резервного копирования файлов и папок, входа в систему для служебных целей и т.п.
Local Policies\Security Options (Локальные политики\Опции безопасности)		Используется для конфигурирования опций безопасности для компьютеров, на которые воздействует эта политика. Можно конфигурировать переименование учетной записи локального администратора, управление установкой принтера, установкой драйверов, не имеющих подписи, возможностью хранения паспорта Microsoft .NET на рабочих станциях и т.п.
Event Log (Журнал регистрации событий)		Используется для конфигурирования параметров журнала регистрации событий для всех компьютеров, на которые воздействует данная политика. Можно конфигурировать максимальный размер журнала, разрешение на просмотр, сохранение всех журналов.
Restricted Groups (Ограниченные группы)		Используется для ограничения членства локальных групп на компьютерах, которые повержены воздействию данной политики. Эта опция обычно используется для конфигурирования членства в группе локальных администраторов на компьютерах с системами Windows 2000 или более поздних. Если эта опция используется для конфигурирования членства локальной группы, то все пользователи или группы, которые являются частью локальной группы, но не входят в список членов, подверженных влиянию этой политики, будут удалены при следующем обновлении политики.
System Services (Системные службы)		Используется для управления службами на компьютерах: для определения автоматически запускаемых службы или для выключения служб.
Registry (Системный реестр)		Используется для конфигурирования защиты на ключах системного реестра. Вы можете добавить любой ключ системного реестра к политике, а затем применит определенную защиту к этому ключу.
File System(Файловая система )		Используется для конфигурирования защиты на файлах и папках. Можно добавить любые файлы или папки к политике, а затем применить управление доступом и аудит для этих объектов файловойсистемы.
Wireless Network (IEEE 802.11) Policies (Политика беспроводных сетей)		Используется для создания беспроводных сетевых политик, которые затем могут использоваться для управления требованиями безопасности для компьютеров, использующих беспроводные сетевые подключения.
Public Key Policies (Политика открытых ключей). Эта установка включена как в раздел Computer Configuration, так и в раздел User Configuration. Раздел User Configuration включает только опцию Enterprise Trust (Доверительные отношения предприятия).		Используется для конфигурирования политик, связанных с цифровыми сертификатами и с управлением сертификатами. Можно также создавать агентов восстановления данных, использующихся для восстановления файлов, которые были зашифрованы на локальных рабочих станциях с помощью системы шифрования файлов (Encrypting File System - EFS).
IP Security Policies On Active Directory (domainname) (Политика IP безопасности в Active Directory)		Используется для конфигурирования политик IP-безопасности (IP Security - IPSec). Можно сконфигурировать политику, точно определяющую, какой сетевой трафик должен быть защищен с помощью IPSec, на каком компьютере она должна использоваться в обязательном порядке.

Примечание. Политики Software Restriction (Ограничения программного обеспечения) включены в раздел Security Settings как для параметров настройки User Configuration, так и для Computer Configuration. Они будут подробно рассмотрены в следующем разделе.

Как говорилось выше, протокол Kerberos

Как говорилось выше, протокол Kerberos по умолчанию задан в качестве опознавательного протокола для клиентов с системами Windows 2000, или более поздними, которые входят в Active Directory. Вы можете сконфигурировать несколько свойств Kerberos через политику безопасности домена. Чтобы обратиться к параметрам настройки политики Kerberos, откройте пункт Domain Security Policy (Политика безопасности домена) из инструментов администрирования и разверните папку Account Policies (Политики учетных записей) (см. рис. 8-7). Вам станут доступны следующие политики.



Рис. 8-7. Конфигурирование параметров настройки протокола Kerberos через Domain Security Policy (Политика безопасности домена)

Enforce User Logon Restrictions (Усиление ограничений пользовательского входа в систему). Эта политика устанавливает опцию службы KDC, по которой при каждом запросе на билет сеанса проверяются установки прав пользователя на целевом компьютере. Если эта политика включена, то пользователь, запрашивающий билет сеанса, должен иметь права Allow Log On Locally (Разрешить локальный вход), если он вошел в систему в интерактивном режиме, или права Access This Computer From The Network (Доступ к этому компьютеру из сети) на целевом компьютере. Эти права назначаются в меню Local Policies\User Rights Assignment (Локальные политики\ Назначение прав пользователей) в пункте Domain Security Policy (Политика безопасности домена). По умолчанию эта политика включена.

Maximum Lifetime For Service Ticket (Максимальный срок годности служебного билета). Эта политика устанавливает максимальное время (в минутах), в течение которого билет сеанса может использоваться для доступа к определенной службе. Если установлен нуль минут, то срок годности билета никогда не окончится. Если установлено ненулевое количество минут, то оно должно быть больше, чем 10 минут, и меньше или равно значению, установленному для параметра Maximum Lifetime For User Ticket (Максимальный срок годности для пользовательского билета). По умолчанию эта установка составляет 600 минут (10 часов).



Maximum Lifetime For User Ticket (Максимальный срок годности для пользовательского билета). Эта политика устанавливает максимальное время (в часах), в течение которого может использоваться TGT-билет пользователя. После того как истечет срок годности TGT-биле-та, существующий билет должен быть возобновлен, иначе нужно затребовать новый билет в центре KDC. По умолчанию эта установка составляет 10 часов.

Maximum Lifetime For User Ticket Renewal (Максимальный срок, в течение которого возможно обновление пользовательского билета). Эта политика устанавливает время (в днях), в течение которого TGT-билет может быть возобновлен (вместо получения нового TGT-биле-та). По умолчанию эта установка составляет 7 дней.

Maximum Tolerance For Computer Clock Synchronization (Максимально допустимое расхождение в показаниях компьютерных часов). Эта политика устанавливает максимальную разницу во времени (в минутах) между временем на компьютере клиента и временем на контроллере домена, обеспечивающем аутентификацию по протоколу Kerberos, которую протокол Kerberos считает допустимой. Если разница во времени между показаниями этих двух компьютеров больше, чем допустимый уровень, все билеты Kerberos будут отвергнуты. По умолчанию эта установка составляет 5 минут. Имейте в виду, что в случае изменения этой установки при перезапуске компьютера она возвратится к заданному по умолчанию значению.

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

Конфигурирование параметров настройки защиты с помощью групповых политик

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

Конфигурирование политики безопасности на уровне домена

Account Policies (Политики учетных записей), расположенные в контейнере Computer Conf iguration\ Windows Settings\Security Settings, содержат параметры настройки защиты, которые могут быть сконфигурированы только на уровне домена. Account Policies включает три группы политик: Password Policy (Политика паролей), Account Lockout Policy (Политика блокировки учетных записей) и Kerberos Policy (Политика Kerberos) (см. рис. 13-5). Эти политики, за исключением Kerberos Policy, применяются ко всем пользователям в домене, независимо от того, с какой рабочей станции пользователи вошли в сеть. Политика Kerberos Policy применяется только на тех компьютерах домена, на которых вы-

полняются системы Windows 2000, Windows XP Professional или Windows Server 2003.

Рис. 13-5. Отображение политик безопасности уровня домена Политика паролей

Опции конфигурации политики паролей содержат параметры настройки для истории пароля, его длины и сложности. В таблице 13-3 описывается каждая установка.

Табл. 13-3. Политики паролей

Параметры установки конфигурации		Описание		Значение по умолчанию
Enforce Password History (Предписанная история пароля)		Определяет количество новых уникальных паролей, которые должны быть введены, прежде чем пользователь сможет повторно использовать старый пароль. Возможные значения: от 0 до 24		24 пароля запоминается для контроллеров домена и компьютеров-членов домена; 0 для автономных серверов.
Maximum Password Age (Максимальное время использования пароля)		Определяет количество дней, в течение которых может использоваться пароль, прежде чем пользователь должен будет его изменить. Чтобы сконфигурировать пароль для бесконечно долгого использования, установите число дней на 0. Возможные значения: от 0 до 999		42 дня.
Minimum Password Age (Минимальное время использования пароля)		Определяет количество дней, в течение которых пароль должен использоваться,      прежде      чем пользователь сможет его изменить. Чтобы позволить немедленное изменение пароля, установите это значение на 0. Возможные значения: от 0 до 998		1 день для контроллеров домена и компьютеров-членов домена; 0 -для автономных серверов.
Minimum Password Length (Минимальная длина пароля)		Определяет наименьшее количество символов, требуемых для пароля. Если никакого пароля не требуется, установите значение на 0. Возможные значения: от 0 до 14		7   символов  для контроллеров домена и компьютеров-членов домена; 0 - для автономных серверов.
Passwords Must Meet Complexity Requirements (Пароли должны удовлетворять требованиям определенной сложности)		Увеличение сложности пароля за счет предписания :    условия, что пароль не должен содержать какую-либо часть имени пользователя -    этой учетной записи, должен содержать по крайней мере 6 символов, содержать символы, принадлежащие трем из четырех перечисленных ниже категорий: английские прописные буквы, английские буквы нижнего регистра, цифры от 0 до 10, специальные символы (типа !, $,#)		Включено      для контроллеров домена и компьютеров-членов домена.    Выключено для автономных серверов.
Store Password Using Reversible Encryption (Хранить пароль, используя обратимое кодирование)		Использование этой установки означает то же самое, что и сохранение паролей в открытом тексте. Эта политика обеспечивает поддержку для приложений, которые требуют доступа   к   паролю   для аутентификации.		Заблокировано.

Конфигурирование репликации между сайтами

Причина создания нескольких сайтов в Active Directory заключается в необходимости управлять трафиком репликации между несколькими офисами компании, особенно между теми, которые соединены низкоскоростными WAN-соединениями. Конфигурация сайта для вашей компании будет оказывать существенное воздействие на трафик репликации, идущий по сети.

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

Как сказано в главе 2, сайт в Active Directory — это место, в котором все контроллеры домена связаны друг с другом высокоскоростными соединениями. Одна из задач установки сети Active Directory состоит в определении того, где следует провести границы сайта, а затем соединить сайты вместе.

Конфигурирование серверов-плацдармов

Как уже говорилось выше, репликация между сайтами выполняется через серверы-плацдармы. По умолчанию генератор межсайтовой топологии (ISTG - Inter-Site Topology Generator) автоматически идентифицирует сервер-плацдарм при вычислении топологии репликации между сайтами. Чтобы узнать, какие контроллеры домена используются в качестве серверов-плацдармов, можно использовать Replication Monitor

(Монитор репликации). Щелкните правой кнопкой мыши на имени сервера, который контролируется монитором репликации, и выберите Show Bridgehead Servers (Показать серверы-плацдармы). Вы можете выбрать серверы-плацдармы: только для сайта, которому принадлежит данный сервер, или для всего предприятия. Вы можете также просмотреть серверы-плацдармы через инструмент Repadmin. Откройте окно с командной строкой и напечатайте repadmin /bridgeheads.

В некоторых случаях необходимо управлять тем, какие контроллеры домена будут использоваться в качестве серверов-плацдармов. Работа сервера-плацдарма может добавлять существенную нагрузку на контроллер домена, если имеется много изменений информации каталога и установлено частое проведение репликации. Для конфигурирования серверов-плацдармов нужно получить доступ к объектам в инструменте администрирования Active Directory Sites And Services, щелкнуть правой кнопкой мыши на имени сервера, а затем выбрать Properties (Свойства) (см. рис. 4-12). Вы получите доступ к опции конфигурирования сервера как привилегированного (preferred) сервера-плацдарма для передачи данных по SMTP или по IP.

Рис. 4-12. Конфигурирование привилегированного сервера-плацдарма

Преимущество конфигурирования привилегированных серверов-плацдармов состоит в гарантии того, что серверами-плацдармами будут выбраны контроллеры домена, указанные вами. Если вы захотите контролировать то, какие серверы используются в качестве серверов-плацдармов, вы должны сконфигурировать привилегированный сервер-плацдарм для каждого раздела, который нужно реплицировать в сайт. Например, если сайт содержит реплики раздела каталога домена Contoso.com, раздела каталога домена Fabrikam.com, раздела GC и раздела приложений, вы должны сконфигурировать, по крайней мере, один контроллер домена с репликой каждого из этих разделов. Если вы этого не сделаете, то ISTG зарегистрирует

событие в журнале событий, а затем выберет привилегированный сервер- плацдарм для раздела. Вы можете также сконфигурировать несколько привилегированных серверов-плацдармов, в этом случае ISTG выберет в качестве сервера-плацдарма один из указанных серверов.

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

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

Конфигурирование свойств пакета программ

После создания пакета программ можно изменись его свойства. Для этого щелкните правой кнопкой мыши на пакете и выберите Properties. На рисунке 12-2 показана вкладка Deployment (Развертывание). В таблице 12-1 описаны опции окна Properties.

Табл. 12-1. Опции развертывания для пакета программ

Параметры настройки		Объяснение
Deployment Type (Тип развертывания) Auto-Install This Application By File Extension Activation (Автоматически установить это приложение путем активации расширения файла)		Используется для указания того, как приложение будет публиковаться для клиентов. Используется для включения или блокировки функции, устанавливающей программное обеспечение, когда пользователь открывает файл с определенным расширением. Эта опция недоступна, если вы назначаете приложение.
Uninstall This Application When It Falls Out Of The Scope Of Manage ment (Деинсталлировать приложение, когда оно выходит из контекста управления )		Используется для управления ситуацией, когда групповая политика более не применяется к пользователю или компьютеру. Например, если групповая политика связана с учетными записями пользователя в какой-либо OU, выбор этой опции означает, что приложение будет деинсталлироваться, если учетная запись пользователя переместится из этой организационной единицы.
Do Not Display This Package In The Add/ Remove Programs Control Panel (He отображать этот пакет в панели управления Add/Remove Programs )		Используется для управления отображением приложения в панели управления Add/ Remove Programs (Добавление/Удаление программ).
Install This Application At Logon (Установить это приложение при входе в систему)		Используется для полной установки приложения при входе пользователя в систему вместо того, чтобы ожидать инициацию инсталляции пользователем. Эта опция недоступна, когда приложение опубликовано.
Installation User Interface Options (Опции пользовательского интерфейса во время инсталляции)		Используется для управления тем, какая информация будет отображаться при установке программного обеспечения. Выбор опции Basic (Основной) означает, что будут отображены только сообщения об ошибках и о завершении инсталляции. Выбор опции Maximum (Максимум) означает отображение всех экранов установки программы.
Advanced (Дополнительные опции)		Используется для конфигурирования дополнительных параметров настройки пакета программного обеспечения. Опции включают инсталлирование 32-битных приложений в 64-битных операционных системах, установку приложения, даже если оно использует язык, отличающийся от языка операционной системы адресата, и включение в пакет СОМ-компонент, чтобы клиент мог устанавливать компоненты из Active Directory (см. рис. 12-3).

<


Рис. 12-2. Изменение свойств развертывания для пакета программ



Рис. 12-3. Использование окна Advanced Deployment Options (Дополнительные опции развертывания) для конфигурации групповой политики, предназначенной для инсталляции программного обеспечения

Установка заданных по умолчанию свойств процесса инсталляции программ

Когда вы готовитесь установить программное обеспечение, используя групповые политики, можно сконфигурировать параметры, заданные по умолчанию для всех пакетов программ, развертываемых с помощью оп-

ределенного объекта GPO. Откройте соответствующее окно, щелкнув правой кнопкой мыши на контейнере Software Installation (Инсталляция программ) и выбрав Properties (Свойства) (см. рис. 12-4).



Рис. 12-4. Конфигурирование заданных по умолчанию параметров настройки, используемых при инсталляции программ

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

Консоль управления групповой политикой

Использование встроенных инструментов для управления групповой политикой подходит для маленькой организации, где имеется только несколько групповых политик и простая иерархия OU, в которых групповые политики применяются только на одном или двух уровнях. Однако в больших предприятиях, где существует множество групповых политик и мест, в которых политика связана с контейнерами, управление групповыми политиками значительно усложняется. Поэтому компания Microsoft разработала новый инструмент — консоль управления групповой политикой (GPMC - Group Policy Management Console) (см. рис. 11-18).

Рис. 11-18. GPMC является инструментом, предназначенным для управления всеми групповыми политиками

Примечание. Во время написания этой книги компания Microsoft объявила, что инструмент GPMC будет доступен бесплатно вскоре после отправки покупателям Windows Server 2003. Этот раздел основан на бета-версии 2 инструмента GPMC. Часть функциональных возможностей в заключительном выпуске может отличаться от тех, которые показаны здесь.

GPMC является отдельным инструментом, который используется для управления всеми конфигурациями групповых политик всей организации. В таблице 11-4 показаны все функциональные возможности инструмента GPMC.

Табл. 11 -4. Опции конфигурирования инструмента GPMC

Функциональные возможности		Опции конфигурирования
GPO Settings (Параметры настройки GPO)		Используются для конфигурирования всех параметров настройки GPO.
GPO Links (Связи GPO)		Используются для просмотра и изменения всех мест, где объект GPO связан с контейнерными объектами.
GPO Delegation (Делегирование GPO)		Используется для просмотра и изменения делегирования создания, удаления и модификации связей GPO объектов и разрешений на генерацию данных RSoP.
Security Filtering (Фильтрация защиты)		Используется для просмотра и модификации всей фильтрации, основанной на группах безопасности.
RSoP Planning (RSoP планирование)		Назван как «Group Policy Modeling (Моделирование групповой политики)», но использует мастер режима планирования в инструменте RSoP.
RSoP Logging (RSoP регистрация)		Назван как «Group Policy Results (Результаты групповой политики) », но использует мастер режиме регистрации в инструменте RSoP.
Modify Inheritance (Изменить наследование)		Используется для установки параметров настройки No Override (He подменять) и Block Inheritance (Блокировка наследования).
Search (Поиск)		Используется для поиска любых типов объектов, связанных с групповой политикой. Например, можное найти все объекты GPO, в которых включена опция Folder Redirection (Переназначение папки).
Backup And Restore GPOs (Резервное копирование и восстановление объектов GPO)		Используется для резервного копирования и восстановления индивидуальных объектов GPO или всех объектов GPO в домене. Без этого инструмента единственным способом резервного копирования и восстановления объектов GPO является копирование данных состояния системы на контроллере домена.
Scripting Interface (Интерфейс создания сценариев)		Инструмент GPMC представляет несколько СОМ-объектов, которые могут использоваться для написания сценариев управления групповыми политиками. Для получения дополнительной информации обратитесь в веб-сайту Microsoft по адресу http:// www.microsoft.com/windowsserver2003/gpmc/ default.mspx.

Как видите, GPMC представляет собой мощный инструмент управления групповыми политиками в среде предприятия.

Контроллеры домена

По определению любой компьютер, на котором выполняется Windows Server 2003, и который поддерживает копию базы данных службы Active Directory, является контроллером домена. Все контроллеры домена создаются равными за несколькими исключениями, которые будут рассмотрены далее в этой главе. При использовании процесса репликации с несколькими хозяевами домена (multimaster), описанного в гл. 4, каждый контроллер домена в домене поддерживает новейшую копию базы данных домена и способен создавать изменения в ней.

В дополнение к контроллерам домена, которые содержат службу Active Directory, имеется несколько контроллеров домена специального назначения, которые требуются службе Active Directory для выполнения определенных функций. Они являются серверами глобального каталога (GC) и хозяевами операций (operations masters).

Краткий обзор DNS

DNS является службой разрешения имен. Если вы пытаетесь найти сервер в интернете, более вероятно, что вы помните его имя, например, www.microsoft.com, чем IP-адрес, который может выглядеть как 207.46.230.219. Однако вашему компьютеру для соединения с Web-сайтом Microsoft требуется знать его IP-адрес. Служба DNS выполняет этот перевод. Вы сообщаете своему браузеру имя компьютера, с которым вы хотели бы соединиться, a DNS превращает это имя в правильный IP-адрес.

Примечание. Поскольку доменная система имен важна для работы Active Directory, вы должны ознакомиться с концепциями службы DNS и знать, как она реализована. Если вы не знакомы с DNS, вам следует просмотреть некоторые ресурсы, имеющиеся на веб-сайте Microsoft по адресу http://msdn.microsoft.com/ library/en-us /dns/dns_concepts. asp.

Краткий обзор групповых политик

Групповые политики Active Directory Windows Server 2003 обеспечивают мощные инструментальные средства, предназначенные для управления пользовательскими рабочими столами. В таблице 11-1 показано многое из того, что можно делать с помощью групповых политик.

Табл. 11-1. Опции групповых политик Опция конфигурации    Объяснение

Инсталляция программ и управление		Используется для установки программного обеспечения на компьютерах и его обслуживания с помощью установки заплат или обновлений. Используется также для деинсталляции пакетов программ. Программное обеспечение может быть назначено и на пользователей, и на компьютеры.
Сценарии		Используется для выполнения сценариев при запуске и выключении компьютера, а также при входе и выходе из системы. Сценарии могут быть файлами MS-DOS .bat или файлами Windows Script Host.
Перенаправление папки		Используется для перенаправления некоторых частей рабочей среды пользователя, таких как My Documents (Мои документы), меню Start (Пуск) или Desktop (Рабочий стол), к сетевому ресурсу, на котором может быть сделана резервная копия. Это перенаправление прозрачно для пользователя.
Конфигурация защиты		Используется для конфигурирования параметров настройки защиты. Некоторые из этих параметров, такие как политики паролей и учетных записей, должны быть сконфигурированы на уровне домена, остальные - на уровне любого контейнера.
Административные шаблоны		Используется для создания административных шаблонов установки значений системного реестра, которые ограничивают модификации, выполняемые пользователями на своих компьютерах.

Существует два типа групповых политик. Первый тип — это локальная групповая политика на компьютере с системами Windows 2000, Windows XP и Windows Server 2003. Локальная групповая политика может быть только одна, и это единственная групповая политика, доступная на компьютере, не являющемся членом домена. Она применяется также на всех компьютерах, которые являются частью домена. Многие из локальных политик те же самые, что и групповые политики домена, но из-за того, что локальная групповая политика применяется первой, групповые политики Active Directory часто отменяют многие параметры ее настройки.

Примечание. Локальный объект групповой политики (GPO - Group Policy Object) хранится на локальном компьютере в папке %systemroot%\System32\GroupPolicy.

Второй тип групповой политики - э|го групповая политика Active Directory. Ее объекты хранятся в Active Directory, и каждая политика разными способами управляет компьютерами домена. Когда формируется домен Active Directory Windows Server 2003, создаются две групповые политики Active Directory: Default Domain Policy (Заданная по умолчанию политика домена) и Default Domain Controllers Policy (Заданная по умолчанию политика контроллеров домена). Default Domain Policy устанавливает политики учетных записей и паролей и используется для конфигурирования общих для домена параметров настройки. Политика Default Domain Controllers Policy применяется в организационных единицах (OU) контроллеров домена и используется для усиления некоторых параметров настройки защиты для контроллеров домена. В дополнение к этой политике можно создавать столько групповых политик, сколько потребуется, и связывать их с различными местами в структуре Active Directory. Групповые политики могут быть связаны с контейнером сайта, контейнером домена или любым контейнером OU вашей организации.

Все политики Active Directory имеют две группы параметров настройки. Первая группа параметров обращается к компьютерам, вторая - к учетным записям пользователя. Групповые политики могут применяться только к компьютерам и пользователям. Группы Active Directory используются для определения того, будет ли данная групповая политика применяться к определенному пользователю.

Объекты GPO, основанные на Active Directory, фактически состоят из двух различных объектов. Один из них — это объект контейнера групповой политики (GPC), к которому можно обратиться с помощью инструмента Active Directory Users And Computers через контейнер System (Система)\Policies (Политики). Если вы не видите системный контейнер, выберите Advanced Features (Дополнительные свойства) из меню View (Вид) (см. рис. 11-1). Объект GPC содержит следующую информацию.



Информация о версии. Поддерживается как объектом GPC, так и шаблоном групповой политики (GPT - Group Policy Template) и используется для проверки синхронизации этих объектов.

Список компонентов. Используется для указания того, параметры настройки какой групповой политики (компьютера, пользователя или обеих) сконфигурированы в этом объекте GPO.

Информация о состояния. Используется для указания того, является ли объект GPO действующим, или он заблокирован.

Подробности, касающиеся объекта GPC, отражаются в свойствах объекта в инструменте ADSI Edit, но модифицировать их можно только через редактор групповой политики Group Policy Editor.



Рис. 11-1. Поиск объектов GPC в Active Directory

Совет. На рисунке 11-1 показано, что глобально уникальные идентификаторы (GUID), которые используются для идентификации объектов GPC в Active Directory, не всегда удобны. Для определения отображаемого имени каждого из GPC-объектов используйте утилиту ADSIedit.msc. Найдите GPC в Active Directory, используя ADSI Edit, а затем рассмотрите атрибут display Name.

Второй объект, который входит в групповую политику, — это объект GPT, содержащий большинство фактических параметров настройки для групповой политики и хранящийся в папке Sysvol на каждом контрол-

лере домена. Этот объект включает папки и информацию о содержимом (см. табл. 11-2).

Табл. 11-2. Содержание шаблона групповой политики

Место расположения	Содержание папки
Adm	Содержит файлы .adm, использующиеся для конфигурирования административных шаблонов.
Scripts	Содержит сценарии, назначенные с помощью групповых политик.
User	Содержит параметры настройки системного реестра, применяемые политиками к данному пользователю. Параметры настройки хранятся в файле Registry.pol.
User\Applications	Содержит сценарии рекламы приложений для всех приложений, развернутых для пользователей.
Machine	Содержит все параметры настройки системного реестра, применяемые политикой к компьютеру. Параметры настройки хранятся в файле Registry.pol.
Machine\ Applications	Содержит сценарии рекламы приложений для всех приложений, развернутых для компьютеров.
{GUID}	Содержит файл Gpt.ini, в котором находится номер версии GPO.

<


Оба GPO- компонента реплицируются на все контроллеры домена в домене. Объект каталога (GPC) реплицируется как часть обычной репликации Active Directory. Объект Sysvol (GPT) реплицируется службой репликации файлов (File Replication service - FRS).

Примечание. Если вы создали новый объект GPO или изменили существующий, политики должны реплицироваться на все контроллеры домена в домене. Используйте монитор репликации Replication Monitor для проверки статуса репликации. (Replication Monitor является инструментом Active Directory, который устанавливается, когда вы дважды щелкаете на файле Suptools.msi, расположенном в папке \Support\Tools на компакт-диске Windows Server 2003.) Откройте Replication Monitor и добавьте контроллеры домена к списку Monitored Servers (Кон-троллируемые серверы). Затем щелкните правой кнопкой мыши на имени контроллера домена и выберите Show Group Policy Object Status (Показать состояние объекта групповой политики). На рисунке 11-2 показано, как выглядит реплицируемая информация.



Рис. 11 -2. Просмотр статуса объекта групповой политики с помощью монитора репликации Replication Monitor

Критерии выбора пути перехода

Следующие вопросы уместно задать при определении наиболее подходящего пути перехода для вашей организации.

Удовлетворены ли вы моделью вашего домена? Отвечает ли существующая модель домена Windows NT 4 вашим организационным и деловым потребностям?

Какую степень риска вы можете допустить при переходе к новой модели домена?

Сколько времени вы готовы потратить на выполнение перехода?

Какое количество рабочего времени системы потребуется на проект перехода?

Какие ресурсы доступны для выполнения перехода?

Каков бюджет проекта перехода?

Какое количество серверных приложений, которые не смогут выполняться на Windows Server 2003, должны быть поддержаны после перехода?

Представьте себе возможные ответы в виде спектра от низкого к высокому уровню, причем, путь обновления домена находится на самом низком уровне, а путь реструктуризации домена - на самом высоком. Для пути перехода, связанного с обновлением и последующей реструктуризацией вы, вероятно, увидите комбинацию деловых требований на каждой стороне спектра или посередине (см. рис. 7-1).

Рис. 7-1. Спектр критериев выбора пути перехода для домена

Лексемы доступа

Связующей точкой между SID участника безопасности и ACL является лексема доступа. Когда пользователь аутентифицируется через Active Directory, в процессе входа в систему ему назначается лексема доступа. Эта лексема включает основной SID пользователя, идентификаторы SID всех групп, которым принадлежит пользователь, а также права и привилегии пользователя.

Лексема доступа используется подсистемой защиты всякий раз, когда пользователь пытается обратиться к ресурсу. В этом случае лексема предъявляется компьютером клиента любому процессу или приложению, которые запрашивают информацию, касающуюся безопасности, перед получением доступа к ресурсу. Например, когда пользователь пытается обратиться к почтовому ящику сервера, на котором выполняется Exchange 2000 Server, лексема доступа предъявляется серверу. Подсистема защиты Exchange 2000 Server сравнивает идентификаторы SID в лексеме доступа с разрешениями, которые были предоставлены в списке ACL. Пользователь сможет открыть почтовый ящик, если это позволяют разрешения, предоставленные данному идентификатору SID.

Леса

Лес представляет самую дальнюю репликацию и является границей безопасности для предприятия. Все домены и доменные деревья существуют в пределах одного или несколько лесов Active Directory. Лес является общим для всех контроллеров домена в лесу. Общими компонентами могут быть:

Общая схема. У всех контроллеров домена в лесу имеется одна и та же схема. Единственный способ развертывания двух различных схем в одной организации состоит в том, чтобы развертывать два отдельных леса.

Общий раздел конфигурации каталога. Все контроллеры домена в лесу имеют один и тот же конфигурационный контейнер, который используется для репликации в пределах леса. Раздел конфигурации каталога интенсивно используется приложениями, поддерживающими службу Active Directory (Echange Server 2000 и ISA).

Общий глобальный каталог GC. Он содержит информацию обо всех объектах в лесу. Это делает поиск любого объекта более эффективным и дает возможность пользователям входить на любой домен леса, используя свои имена UPN.

Общий набор администраторов в пределах леса. В корневом домене для леса создаются две группы безопасности (security groups). Им предоставляются такие разрешения, которыми не обладают никакие другие пользователи. Группа Schema Admins является единственной группой, которая имеет право изменять схему, а группа Enterprise Admins (Администраторы предприятия) является единственной группой, которая имеет право выполнять действия на уровне леса, такие как добавление или удаление доменов из леса. Группа Enterprise Admins автоматически добавляется к каждой местной группе Administrators (Администраторы) на контроллерах домена в каждом домене леса.

Общая конфигурация доверительных отношений. Все домены в лесу автоматически сконфигурированы так, чтобы доверять всем другим доменам леса. Более подробно о доверительных отношениях рассказано в следующем разделе.

На рисунке 2-8 показан лес Contoso.

Леса и проект Active Directory

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

Глобальный каталог. Лес имеет один глобальный каталог (GC). Каталог GC облегчает поиск объектов в любом домене леса и вход на любой домен леса независимо от того, на каком домене зарегистрирована учетная запись пользователя.

Раздел конфигурации каталога. Все контроллеры домена совместно используют один и тот же раздел конфигурации каталога. Эта информация используется для оптимизации репликации информации в пределах леса, для хранения приложений и информации Active Directory, поддерживающей приложения, и для совместного использования информации с помощью раздела приложений каталога.

Доверительные отношения. Все домены в лесу связаны двухсторонними транзитивными доверительными отношениями. Не существует никакой опции, позволяющей изменить это.

Примечание. Использования одного леса для облегчения сотрудничества можно рассмотреть на примере Microsoft Exchange Server 2000. Граница леса является также границей организации в Exchange Server 2000. Exchange Server 2000 хранит большую часть своей конфигурационной информации в разделе конфигурации каталога, облегчая управление маршрутизацией сообщений в пределах большой организации. Глобальный список адресов (GAL - Global Address List) состоит из всех почтовых получателей в каталоге GC. Наличие единой организации Exchange Server 2000 желательно для большинства компаний. В пределах одной организации календарная информация и общие папки доступны каждому, многие типы сотрудничества допускаются по умолчанию. Как только вы развернете несколько лесов, многие из этих преимуществ будут потеряны или их будет труднее конфигурировать.

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

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

Централизованное управление. Развертывание единственного леса означает, что некоторые компоненты сетевого управления должны быть централизованы. Например, единственная группа, обладающая правом изменять схему, — это группа Schema Admins (Администраторы схемы). Единственная группа, обладающая правом добавлять и удалять домены из леса, - это группа Enterprise Admins (Администраторы предприятия). Группа Enterprise Admins автоматически добавляется к домену локальной группы Administrators (Администраторы) на каждом контроллере домена в лесу. Для некоторых компаний этот тип централизованной администрации неприемлем. Это относится к компаниям, осуществляющим переход от Windows NT 4, которая не предписывают централизованное управление между несколькими доменами.

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

Доверенные администраторы. Развертывание одного леса требует определенной степени доверия администраторам всех доменов. Любой администратор, обладающий правами управления контроллером домена, может сделать такие изменения, которые затронут весь лес. Это означает, что все администраторы доменов должны быть высоко доверенными людьми.

Обдумывая вопрос, касающийся количества развертываемых лесов, вы должны оценить каждый из этих факторов для определения своих собственных потребностей.

Логическая структура Active Directory

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

разделы;

домены;

деревья доменов;

леса;

сайты;

организационные единицы.

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

Малый бюджет проекта перехода

Обновление домена стоит дешевле, чем реструктуризация, потому что вы можете использовать существующие серверные аппаратные средства. Это вовсе не означает, что вы должны к этому стремиться; в действительности, обновление NOS — весьма подходящее время для модернизации аппаратных средств контроллеров домена и других серверов, выполняющих критические миссии (электронная почта, веб-серверы и т.д.). Однако если ваши имеющиеся серверные аппаратные средства функционально пригодны для работы с Windows Server 2003, вы можете потратить меньшее количество денег на обновление домена. Вы можете избежать необходимости покупать дополнительные серверы для создания среды «чистого» леса, которая требуется для реструктуризации домена. Среди других факторов, способствующих уменьшению необходимых бюджетных средств, будет более низкая стоимость ресурсов (включая минимальные контрактные расходы и стоимость «нереализованных возможностей» для постоянных служащих), а также уменьшение расходов на тестирование (поскольку нужно будет тестировать меньшее количество задач модернизации).

Масштабируемость

Поскольку организация постепенно растет в процессе бизнеса, либо это происходит быстро, через ряд слияний с другими компаниями и в результате приобретений, служба Active Directory спроектирована масштабируемой, для того чтобы справляться с этим ростом. Вы можете расширить размер доменной модели или просто добавить больше серверов, чтобы приспособиться к потребностям увеличения объема.

Любые изменения в инфраструктуре Active Directory должны быть тщательно реализованы в соответствии с проектом Active Directory, который предусматривает такой рост. Отдельный домен, представляющий самый маленький раздел инфраструктуры Active Directory, который может реплицироваться на единственный контроллер домена, может поддерживать более одного миллиона объектов, так что модель отдельного домена подходит даже для больших организаций.

Мастер инсталляции Active Directory

Active Directory Installation Wizard (Мастер инсталляции Active Directory) можно запустить, напечатав dcpromo.exe в диалоговом окне Run или в командной строке. Команда Dcpromo.exe имеет два параметра командной строки:

параметр /answer[:answerfilе] используется для выполнения автоматической инсталляции Active Directory. Включите в этот параметр имя файла автоматического ответа, который содержит всю информацию, необходимую для выполнения инсталляции;

параметр /adv используется для запуска мастера инсталляции Active Directory в том случае, когда контроллер домена будет создан из восстановленных резервных файлов. Когда вы добавляете параметр /adv, то в процессе инсталляции нужно указать путь к восстановленным резервным файлам.

Детальная информация о ключевых пунктах ответов дана в разделе этой главы «Использование мастера инсталляции Active Directory».

Мастер конфигурирования сервера

Окно Manage Your Server (Управление сервером) появляется автоматически после того, как закончится инсталляция или обновление Windows Server 2003. Оно отображает список всех сетевых услуг, которые установлены на сервере, и позволяет установить дополнительные услуги (см. рис. 6-2).

Рис. 6-2. Окно Manage Your Server (Управление сервером)

Из окна Manage Your Server вы можете добавить серверу роль контроллера домена. Это можно сделать, выбрав опцию Typical Settings for a First Server (Типичные параметры настройки первого сервера) с предварительно разработанными настройками или роль контроллера домена. Если выбраны типичные установки первого сервера, то автоматизированный процесс добавит службы сервера DNS и DHCP. Программа инсталляции автоматически установит Active Directory с заданными по умолчанию вариантами для многих опций, используя Active Directory Installation Wizard (Мастер инсталляции Active Directory). Если вы планируете установить Active Directory со всеми заданными по умолчанию опциями, то программа Configure Your Server Wizard (Мастер конфигурирования сервера) обеспечит защищенную от ошибок установку этой службы.

Механизм удаления неактивных объектов

Удаление неактивных объектов представляет собой процесс, в результате которого объекты-памятники (tombstone) удаляются из тех контроллеров домена, которые были недоступны для репликации после процесса сборки мусора. Объект-памятник представляет собой маркер, который указывает на то, что объект был удален. «Сборка мусора» — это процесс, с помощью которого объекты, отмеченные как объекты-памятники, удаляются изо всех реплик базы данных Active Directory по всему домену. Процесс удаления этих неактивных объектов используется в таких ситуациях, в которых удаление маркеров-памятников в разделе каталога домена выполняется после того, как контроллер домена находился в автономном режиме или был недоступен по другим причинам. Прежде не существовало никакого процесса, предназначенного для очищения системы от таких «потерянных» маркеров-памятников, в резуль-

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

Менеджер LAN для операционных систем OS/2 и MS-DOS

В1987 году первая служба каталога, разработанная для поддержки вычислительной среды компьютеров Microsoft (операционные системы OS/2 и MS-DOS), основывалась на сетевой операционной системе Microsoft LAN Manager. Служба каталога системы LAN Manager обеспечивала основные функциональные возможности для совместного использования файлов и ресурсов печати, а также для пользовательской защиты, но она не годилась для сред большого предприятия. Эта служба плохо масштабировалась и не поддерживала доверительные отношения. Чтобы обратиться к общедоступным ресурсам, сетевые пользователи должны были входить на каждый домен отдельно.

Место расположения файла

Мастер инсталляции Active Directory попросит вас выбрать место для хранения файла базы данных Active Directory (Ntds.dit), файлов регистрационных журналов Active Directory и общей папки Sysvol. Вы можете выбрать заданные по умолчанию места или задать другие (см. рис. 6-11).

Рис. 6-11. Окно Database And Log Folders (Папки базы данных и регистрационных журналов)

Заданное по умолчанию место для базы данных каталога и журналов — папка %systemroot %\system32. Однако для обеспечения лучшей производительности нужно сконфигурировать Active Directory так, чтобы хранить файл базы данных и журналы на отдельных жестких дисках. Заданное по умолчанию место общей папки Sysvol - %systemdrive %\Windows. Единственное ограничение на выбор места для общей папки Sysvol состоит в том, что она должна храниться в разделе с файловой системой NTFS v5. В папке Sysvol хранятся все файлы, которые должны быть доступны клиентам домена Active Directory, например, сценарии входа в систему (см. рис. 6-12).

Модель репликации Active Directory

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

В отличие от модели репликации с единственным хозяином, которая используется в системе Microsoft Windows NT, Active Directory использует модель репликации с несколькими хозяевами. В Windows NT основной контроллер домена (PDC — Primary Domain Controller) является единственным контроллером домена, который может принимать изменения информации домена. После того как изменение сделано, оно реплицируется на все резервные контроллеры домена (BDC — Backup Domain Controllers). Недостатком модели репликации с единственным хозяином является то, что она не масштабируется для большой распределенной среды. Поскольку изменения (например, пароля пользователя) могут выполняться только на контроллере PDC, это может стать узким местом, если делаются сразу тысячи изменений. Контроллер PDC находится только в одном месте компании, и любые изменения информации домена, расположенного в удаленном месте, должны быть сделаны на этом контроллере PDC. Другая проблема заключается в том, что контроллер PDC является единственной точкой отказа. Если он недоступен, никаких изменений информации каталога сделать нельзя до тех пор, пока он не вернется в интерактивный режим или пока другой BDC-контроллер не будет назначен на роль контроллера PDC.

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

Примечание. В главе 2 говорилось о том, что в Active Directory имеются определенные роли хозяев операций, которые могут выполняться только одним контроллером домена. Эти роли представляют собой критическую точку отказа системы, но их можно легко передавать на другой контроллер домена.

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

контроллеры домена достигнут единообразного состояния и будут иметь идентичную информацию.

При репликации используется также процесс хранения и ретрансляции (store and forward). Это означает, что контроллер домена может получать изменение к каталогу, а затем отправлять его на другие контроллеры домена. Это выгодно в тех случаях, когда несколько контроллеров домена, находящихся в разных офисах компании, соединены медленными WAN-соединениями. Изменение к каталогу может реплицироваться с контроллера домена одного из сайтов на единственный контроллер домена второго сайта. Контроллер домена, который получает обновление, может затем переправить изменения на другие контроллеры домена во втором сайте. Контроллер домена, на котором были сделаны изменения каталога, не должен копировать изменения непосредственно на все контроллеры домена, как это имеет место в модели репликации с единственным хозяином.

Модификация схемы

Схема Active Directory содержит большинство постоянно используемых классов и атрибутов, необходимых для реализации службы каталога предприятия. Эти атрибуты и классы определяются как объекты Category 1 (Категория 1), или основные объекты схемы. Для поддержки классов и атрибутов, определяемых клиентом, при разработке схемы Active Directory закладывались возможности ее расширения. Другими словами, она может быть изменена для включения новых объектов классов и атрибутов, в которых, возможно, нуждается организация. Объекты схемы, которые создаются позднее, определяются как объекты Category 2 (Категория 2). Схему обычно расширяют для того, чтобы она удовлетворяла потребностям приложений, пользующихся поддержкой Active Directory. Хорошим примером такого приложения является Microsoft Exchange Server 2000, для поддержки которого при конфигурировании Active Directory было сделано более тысячи дополнений к схеме.

Кроме использования приложений, пользующихся поддержкой Active Directory, администраторы могут расширять схему другими методами. Это можно сделать в пакетном режиме с помощью средств администрирования с командной строкой, включая инструменты LDAP Data Interchange Format Directory Exchange (LDIFDE) и Comma Separated Value Directory Exchange (CSVDE). Схема может быть расширена программно, используя Active Directory Service Interfaces (ADSI) и сценарии Microsoft Visual Basic.

Дополнительная информация. Для получения дополнительной информации об инструментах LDIFDE или CSVDE напечатайте название команды в командной строке для вызова онлайновой подсказки. Для получения дополнительной информации об ADSI и ADSI Edit обратитесь к комплекту разработки программного обеспечения Microsoft Windows Platform (SDK), который можно загрузить или заказать на компакт-диске на сайте http:// www.microsoft.com/msdownload/platformsdk/sdkupdate.Чacть ADSI Platform SDK можно просмотреть интерактивно на сайте http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/netdir/adsi/directory_services.asp.

Схема может быть изменена через интерфейс пользователя Windows Server 2003 с помощью оснастки Active Directory Schema. Сначала нужно зарегистрировать оснастку, выполнив команду Regsvr32 Schmmgmt.dll из командной строки. Для изменения схемы вы должны быть членом глобальной группы Schema Admins (Администраторы схемы). Чтобы понять, как работает изменение схемы, представьте себе, что организации необходимо сохранять записи о датах, когда служащие приступили к работе, т.е. сохранять дату начала работы служащего как ат-

рибут пользовательского объекта в Active Directory. Чтобы этот атрибут был доступен при создании каждого нового пользовательского объекта, он сначала должен быть определен в схеме.

С помощью оснастки Active Directory Schema вы можете добавить новый атрибут к схеме и связать его с объектом класса User. Для этого выполните следующие шаги.

Откройте оснастку Active Directory Schema (Схема Active Directory).

Выберите папку Attributes (Атрибуты) на панели дерева.

В меню Action (Действие) щелкните на Create Attribute (Создать атрибут).

В окне предупреждения Schema Object Creation (Создание объекта схемы) щелкните на Continue (Продолжить).

В диалоговом окне Create New Attribute (Создание нового атрибута) введите информацию в раздел Identification (Идентификация):

Common Name (обычное имя);

LDAP Display Name (отображаемое LDAP-имя);

Unique X500 Object ID (уникальный идентификатор объекта Х500);

Description (описание).

В разделе Syntax And Range (Синтаксис и диапазон) внесите информацию в поля:

Syntax (синтаксис);

Minimum (минимум);

Maximum (максимум).



Выберите, будет ли новый атрибут многозначным (Multi-Valued) атрибутом.

Подробная информация, касающаяся содержания каждого поля, становится доступной при выборе соответствующего текстового поля и нажатии клавиши F1.

Получение идентификатора Х500 Object ID

Иногда два приложения могут попытаться сделать несовместимые модификации в схеме. Чтобы решить эту проблему, каждый класс и атрибут в Active Directory могут быть идентифицированы уникальным идентификатором объекта (OID — Object Identifier) для гарантии того, что другой объект схемы не использует тот же самый OID. Организация, планирующая создание новых OID, должна зарегистрироваться в Международной организации по стандартизации (ISO — International Standards Organization) или в Американском национальном институте стандартов (ANSI - American National Standards Institute). При регистрации организация стандартов выделит вам часть пространства OID, которое затем можно расширять для удовлетворения своих потребностей. Например, компании может быть предоставлено число типа 1.2.840.ХХХХ. Оно организовано в иерархическом порядке и содержит следующие части:



1 - ISO;

2-ANSI;

840 - Соединенные Штаты Америки;

ХХХХ — уникальное число, идентифицирующее вашу компанию.

Как только вы получили это число, можно управлять своей собственной частью иерархии. Например, если вы создаете новый атрибут с именем Employee Start Date (Дата начала работы служащего), ему можно назначить число типа 1.2.840.ХХХХ.12.

Пусть OID для контакта в Active Directory задан в виде 1.2.840.113556.1.5.15. Первые три части числа выделены для ISO, ANSI и США соответственно. Число 113556 ANSI предоставил компании Microsoft, которая назначила 1 - на Active Directory, 5 — на классы Active Directory, 15 - на класс Contact (Контакт).

Комплект ресурсов Microsoft Windows Server 2000 Resource Kit содержит инструмент по имени OIDGen, который можно использовать для создания уникальных идентификаторов OID для классов или атрибутов объекта без необходимости регистрировать OID. Этот инструмент не должен использоваться, если схема будет развертываться вне вашей организации. Для внешнего развертывания Microsoft предлагает сгенерировать и зарегистрировать ваш новый OID. Подробности см. на сайте http://msdn.microsoft.com/certification/ad-registration.asp.

На рисунке 2-2 показано создание нового атрибута с помощью оснастки Active Directory Schema (Схема Active Directory).



Рис. 2-2. Создание нового атрибута схемы

Примечание. Добавление нового атрибута к схеме не подразумевает, что атрибут будет автоматически доступен из любого средства администрирования. Инструментальные средства администрирования, подобные Active Directory Users And Computers (Пользователи и компьютеры Active Directory), показывают только некоторые атрибуты для каждого класса и не показывают атрибуты, которые добавляете вы. Если вы хотите, чтобы новый атрибут появился в инструменте администрирования, нужно изменить существующий инструмент или создать ваш собственный. О том, как изменять и создавать инструментальные средства администрирования, см. в разделе Directory Services (Службы каталога) документа Platform SDK на сайте http:// msdn.microsoft.com/library/default.asp?url=/library/en-us/ netdir/ad/extending_the_user_interface_for_directory_objects.asp.

Модификация способа наследования групповых политик

Есть два способа изменить заданное по умолчанию наследование групповой политики. Первый вариант состоит в блокировании наследования политики на контейнерном уровне. Для этого щелкните правой кнопкой мыши на контейнере, в котором вы хотите изменить наследование, и выберите Properties (Свойства). Щелкните на вкладке Group Policy (Групповая политика) и отметьте флажок Block Policy Inheritance (Блокировать наследование политики) (см. рис. 11-8). Это означает, что параметры настройки групповой политики, унаследованные от контейнеров

более высокого уровня, будут блокированы. Опция блокировки наследования политики полезна, когда ваша политика должна применяться к большой группе пользователей и компьютеров в нескольких OU, но при этом вы не хотите применять ее к определенной группе пользователей. Типичным примером является сценарий, в котором всем пользователям в организации нужно, чтобы часть их рабочего стола (команда Run или редактор системного реестра) были заблокированы, а сетевым администраторам требуется полный доступ ко всем инструментальным средствам. В этом сценарии вы можете сконфигурировать такую групповую политику на уровне домена, которая блокирует часть инструментов рабочего стола на всех компьютерах, затем создать отдельную OU для учетных записей сетевых администраторов и блокировать наследование групповой политики на этом уровне.

Рис. 11 -8. Блокирование наследования групповой политики на уровне 0U

Предостережение. Одно из ограничений блокировки наследования групповых политик состоит в том, что после выбора блокировки все наследование групповой политики будет блокировано. Нет никакого способа выборочно блокировать наследование только определенных групповых политик.

Второй способ изменять заданное по умолчанию наследование групповых политик состоит в использовании опции No Override (He подменять). Эта опция используется для предписания применения групповой политики даже в тех контейнерах, в которых установлена опция блоки-

ровки наследования групповой политики. Чтобы сконфигурировать групповую политику, не подлежащую отмене, найдите контейнерный объект, с которым связана данная групповая политика, а затем откройте окно Properties (Свойства) этого контейнера. Выберите вкладку Group Policy, выберите политику группы, щелкните на кнопке Options и выберите опцию No Override (см. рис. 11-9).

Рис. 11-9. Конфигурирование опции No Override для групповой политики

Опция No Override может быть полезна, когда ваша групповая политика применяется ко всем пользователям независимо от того, где они расположены. Например, вы можете использовать групповые политики для управления антивирусным программным обеспечением на всех компьютерах-клиентах вашей организации. В этом случае нужно выбрать контейнер высокого уровня, содержащий все компьютеры вашего домена, и применить политику на этом уровне. Затем сконфигурируйте групповую политику опцией No Override, чтобы параметры настройки применялись ко всем компьютерам клиентам.

Опция No Override устанавливается в том месте, где объект GPO связывается с контейнером, а не в самом объекте GPO. Если вы связываете объект GPO с несколькими местами вашего домена и конфигурируете одну из связей с применением опции No Override, другие связи не будут сконфигурированы с этой опцией автоматически. Опция No Override устанавливается применительно к одному объекту GPO, т.е. ее установка на одном объекте GPO, связанном с OU, не затрагивает опцию No Override для других объектов GPO, связанных с этой же OU.

Примечание. Опция No Override заставляет применять параметры настройки групповой политики, даже если наследование блокировано. Параметры настройки уровня домена типа политики учетной записи и политики пароля применяются ко всем компьютерам и пользователям в домене. Блокировка наследования политики никак не влияет на эту политику.

Мониторинг Active Directory

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

Отдельного инструмента или пакета программ, предназначенного для мониторинга Active Directory, не существует. Скорее мониторинг здорового состояния Active Directory является комбинацией задач, имеющих общую цель - измерение текущей характеристики некоторого ключевого индикатора (занимаемый объем диска, степень использования процессора, период работоспособного состояния службы и т.д.) по сравнению с известным состоянием (отправная точка). Поэтому ваш мониторинг службы каталога будет состоять из различных задач и инструме-нов. (Существуют наборы инструментов, которые могут соединить мониторинг этих ключевых индикаторов вместе в легко управляемый

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

Чтобы разбираться в мониторинге Active Directory, вы должны знать, почему его следует проводить, как это делать и что конкретно нужно отслеживать. Чтобы сохранить максимальную производительность службы каталога, необходимо также знать, что предпринимать в ответ на проведенный мониторинг. Цель этой главы состоит в том, чтобы вы могли делать все необходимое, что требуется для поддержания функционального состояния службы в пределах нормальных рабочих параметров, которые вы установили. Например, если мониторинг функционирования службы показывает, что диск, на котором расположена база данных Active Directory, фрагментирован, вы должны его дефрагментировать.

Мониторинг Active Directory с помощью инструмента Event Viewer

В дополнение к использованию инструмента Performance для мониторинга Active Directory вы должны периодически рассматривать содержимое журналов регистрации событий, используя инструмент администрирования Event Viewer (Средство просмотра событий). По умолчанию средство просмотра событий отображает следующие три регистрационных журнала.

Application log (Журнал приложений). Содержит события, зарегистрированные приложениями или программами.

System log (Системный журнал). Содержит правомерные и неправомерные попытки входа в систему, а также события, связанные с использованием ресурсов, такие как создание, открытие и удаление файлов или других объектов.

Security log (Журнал безопасности). Содержит события, зарегистрированные компонентами системы Windows.

Для серверов, сконфигурированных как контроллеры домена, на которых выполняется система Windows Server 2003, будут отображаться следующие журналы регистрации событий.

Directory Service log (Журнал регистрации службы каталога). Содержит события, зарегистрированные службой Active Directory.

File Replication Service log (Журнал регистрации службы репликации файлов) Содержит события, зарегистрированные службой репликации файлов.

Если контроллер домена с системой Windows Server 2003 является также сервером DNS, то будет отображаться следующий журнал регистрации.

DNS Server log (Журнал сервера DNS). Содержит события, зарегистрированные службой сервера DNS.

Для просмотра журнала регистрации событий выберите инструмент Event Viewer из папки Administrative Tools. Выберите журнал регист-

рации событий, предназначенный для той службы, работу которой вы хотите отслеживать. Левая область окна на рисунке 14-5 показывает все журналы событий для контроллеров домена с системой Windows Server 2003, которые являются также серверами DNS.

Рис. 14-5. Инструмент администрирования Event Viewer с журналами регистрации событий

В журнале регистрации событий рассмотрите типы событий Errors (Ошибки) и Warnings (Предупреждения). Чтобы отобразить детали событий в журнале регистрации, дважды щелкните на этом событии. На рисунке 14-6 показаны детали события Warnings (ID-событие 13562) из журнала File Replication Service (Служба репликации файлов).

Мониторинг и поиск неисправностей репликации

Одно из наиболее полезных инструментальных средств, предназначенных для мониторинга и поиска неисправностей репликации, — это Replication Monitor (Монитор репликации). Он устанавливается как часть файла Suptools.msi из каталога Support\Tools с компакт-диска Windows Server 2003. Чтобы запустить Replication Monitor, в командной строке напечатайте replmon. Монитор репликации открывается с пустым инструментом управления. Перед началом работы щелкните на Edit в строке меню, чтобы добавить один или более серверов к списку контролируемых серверов. Как только серверы добавлены в список, вы можете управлять почти всеми аспектами репликации Active Directory. Например, отслеживать текущее состояние репликации, последнюю успешную репликацию или любые отказы при репликации; вынуждать репликацию; вынуждать КСС к повторному вычислению топологии маршрутизации. Используя инструмент мониторинга, вы можете контролировать репликации на всех контроллерах домена вашей сети. Второй полезный инструмент мониторинга репликаций - Repadmin. Он также устанавливается с помощью файла Suptools.msi. Чтобы запустить этот инструмент, в командной строке напечатайте repadmin. Инструмент Repadmin обеспечивает такие же функциональные возможное-

ти, как и Replication Monitor, но через интерфейс командной строки. Инструмент Repadmin дополнительно позволяет изменять топологию репликации, добавляя объекты связи.

Примечание. Чтобы получить подробную информацию об использовании инструментов Replication Monitor и Repadmin, откройте Help And Support Center (Центр информации и поддержки). Далее в пункте Support Tasks (Задачи поддержки) щелкните на Tools (Сервис), а затем щелкните на Windows Support Tools (Поддержка Windows). Вам будет представлен алфавитный список всех инструментальных средств поддержки с информацией о том, когда следует использовать каждый инструмент, а также инструкции о том, как им пользоваться. Вы можете запускать инструментальные средства непосредственно из окна Help And Support Center.

Существуют два стандартных средства администрирования серверов для мониторинга и поиска неисправностей репликации. Первый инструмент -Event Viewer (Средство просмотра событий). Журнал событий Directory Service (Служба каталога) — это один из журналов регистрации событий, который добавляется ко всем контроллерам домена. Большая часть событий, связанных с репликацией каталога, записывается в него, и это первое место, которое вы должны просмотреть при возникновении сбоя при репликации. Инструмент администрирования Performance (Производительность) полезен для контроля деятельности, связанной с репликацией, которая происходит на сервере. Когда сервер назначается контроллером домена, то к списку счетчиков производительности добавляется объект NTDS Performance. Счетчики производительности можно использовать для контроля объема трафика репликации, а также другой деятельности, связанной с Active Directory.

Совет. Если вы заметите отказы в репликации Active Directory между контроллерами домена, то первое, что нужно проверить -это DNS. Без правильного функционирования инфраструктуры DNS репликация не будет работать.

Мониторинг репликации

Один из критических компонентов Active Directory, за работой которого вы должны наблюдать, - это репликация. В отличие от мониторинга контроллера домена, который использует инструмент Performance Monitor, репликация между контроллерами домена чаще всего отслеживается с помощью инструмента из набора Windows Server 2003 Support Tools (Средства обслуживания Windows Server 2003): Repadmin.exe, Dcdiag.exe и журнала регистрации событий службы каталога (см. выше). Repadmin представляет собой инструмент командной строки, который сообщает об отказах репликационных связей между двумя партнерами по репликации. Следующая команда вызывает отображение партнеров по репликации и все отказы репликационных связей для контроллера домена DC1, расположенного в домене Contoso.com:

repadmin/showreps dd .contoso.com

Dcdiag - это инструмент командной строки, который может проверять DNS-регистрацию контроллера домена. Он отслеживает наличие идентификаторов защиты (SID) в заголовках контекста именования (naming context) соответствующие разрешения для репликации, анализирует состояние контроллеров домена в лесе или предприятии и многое другое. Для получения полного списка опций Dcdiag напечатайте dcdiag/?. С помощью следующей команды можно проверить наличие ошибок репликации между контроллерами домена:

dcdiag/test: replications

И, наконец, журнал службы каталога сообщает об ошибках репликации, которые происходят после установления репликационной связи. Нужно просматривать журнал регистрации событий службы каталога в поисках событий репликации, имеющих тип Error (Ошибка) или Warning (Предупреждение). Далее приводится два примера типичных ошибок репликации в том виде, как они отображены в журнале регистрации событий службы каталога.

Событие ID 1311. Информация о конфигурации репликации, имеющаяся в инструменте Active Directory Sites And Services (Сайты и службы Active Directory), не отражает точно физическую топологию сети. Эта ошибка указывает на то, что один или более контроллеров домена или сервер-плацдарм (bridgehead) находятся в автономном режиме, или что серверы-пладармы не содержат нужных контекстов именования (NC).

Событие ID 1265 (Access denied — Доступ запрещен). Эта ошибка может возникать в том случае, если локальный контроллер домена не сумел подтвердить подлинность своего партнера по репликации при создании репликационной связи или при попытке реплицировать по существующей связи, она возникает тогда, когда контроллер домена был отсоединен от остальной части сети в течение долгого времени, и его пароль учетной записи компьютера не синхронизирован с паролем учетной записи компьютера, хранящимся в каталоге его партнера по репликации.

Мосты связей сайта

В некоторых случаях вы можете отменить транзитивный характер связей сайта и вручную сконфигурировать мосты связей сайта (site link bridges). При конфигурировании мостов связей сайта вы определяете, какие из связей сайта должны рассматриваться как транзитивные, а какие - нет. Отмена транзитивного характера связей сайта может быть полезной, когда у вас нет полностью трассированной сети, т.е. не все сегменты сети доступны (на-

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

Дополнительная информация. В главе 5 приводится подробная информация о том, когда и как следует использовать мосты связей сайта.

При создании моста связей вы должны определить, какая связь сайта является частью моста. Любые связи сайта, которые вы добавляете к мосту связей сайта, рассматриваются по отношению друг к другу как транзитивные; связи сайта, не включенные в мост связей сайта, транзитивными не являются. В примере, рассмотренном выше, мост связей сайта можно создать для связей, соединяющих Site1, Site2, Site4 и Site5. Тогда все эти связи сайтов считались бы транзитивными, что означает, что сервер-плацдарм сайта Sitel мог бы напрямую обмениваться репликами с сервером-плацдармом сайта Site5. Но так как связь от сайта Site2 к сайту Site3 не включена в мост связей, она не является транзитивной. Трафик репликации от сайта Site3 направляется к сайту Site2, а оттуда к другим сайтам.

Чтобы выключить транзитивные связи сайта, очистите опцию Bridge All Site Links (Все сетевые связи объединены в мост) на вкладке General (Общие) окна IP-Properties (Свойства IP). Объект IP расположен в контейнере Inter-Site Transports (Средства передачи между сайтами) в инструменте администрирования Active Directory Sites And Services. Будьте осторожны, выполняя это действие, поскольку теперь вы должны будете сконфигурировать мосты связей сайта для всех сайтов, если захотите установить транзитивные связи сайта.

Наличие адекватных ресурсов

Реструктуризация домена влечет за собой большее количество задач, чем обновление домена, и поэтому требуется большее количество ресурсов. Выбирая этот путь перехода, убедитесь, что ваш штат сотрудников адекватно укомплектован для выполнения дополнительной рабочей нагрузки, связанной с реструктуризацией домена. Не забудьте учесть, что ваш штат не будет выполнять обычные ежедневные обязанности из-за времени, потраченного на реструктуризацию. Велика вероятность того, что вы не сможете приостановить процедуры сетевого резервирования на несколько недель из-за того, что ваши техники будут налаживать испытательную лабораторию, поэтому не забудьте предусмотреть заполнение этих ролей, если вы осуществляете переход с внутренним штатом. В качестве альтернативы можно переложить часть задач или весь проект на внешних сотрудников, поскольку существует множество консультативных групп, которые специализируются на таких проектах. Это сэкономит время и деньги, необходимые для обучения ваших внутренних сотрудников.

Наличие ограниченных ресурсов

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

Наличие времени, достаточного для выполнения перехода

Реструктуризация домена всегда занимает больше времени. Однако если график вашего проекта перехода разрешает включить необходимое пла-

нирование, тестирование и выполнение задач, то не избегайте реструктуризации домена.

Наследование групповой политики и ее применение

Объекты GPO могут быть связаны с объектами сайтов, доменов и объектами OU в Active Directory. Групповые политики связываются только с этими контейнерами и не могут связываться с контейнерами Users или Computers.

По умолчанию параметры настройки групповой политики наследуются от контейнеров высокого уровня к контейнерам низкого уровня. Следовательно, групповые политики, назначенные пользователю или компьютеру, применяются при каждом запуске компьютера или при каждом входе пользователя в систему. Групповые политики применяются в следующем порядке.

1.       Local group policy (Локальная групповая политика). Первой всегда применяется локальная групповая политика.

2.       Site-level group policies (Групповые политики уровня сайта). Эти групповые политики связаны с объектом сайта в Active Directory.

3.       Domain-level group policies (Групповые политики уровня домена). Эти групповые политики связаны с объектом домена в Active Directory.

4.       OU-level group policies (Групповые политики уровня OU). Если домен содержит несколько уровней OU, вначале применяются групповые политики более высоких уровней OU, а затем — OU низшего уровня.

Иногда на любом из уровней Active Directory может применяться свыше одной групповой политики. В этом случае порядок их применения определяется порядком, в котором объекты GPO перечислены в административном окне снизу вверх. На рисунке 11-7 показаны три групповые политики, применяемые к OU. Сначала будет применяться Scripts Policy (Политика сценариев), затем - Desktop Policy (Политика рабочих столов), а далее - Office Installation Policy (Политика инсталляции офиса).

Рис. 11-7. Несколько групповых политик, связанных с одним и тем же контейнером, применяются в порядке расположения в списке, снизу вверх

Порядок применения групповых политик важен, если они изменяют одни и те же параметры настройки. Например, если объект GPO уровня домена удаляет команду Run со всех компьютеров, а объект GPO организационной единицы более низкого уровня добавляет команду Run, то команда Run будет доступна на всех компьютерах OU. Такой конфликт возникает, если две политики изменяют одну и ту же установку. Иуш объект GPO более высокого уровня может быть сконфигурирован для удаления команды Run, а объект GPO более низкого уровня — для удаления значка конфигурации с панели управления. Поскольку нет никакого конфликта между этими параметрами настройки, применятся обе настройки.

Большинство параметров настройки объекта GPO включает три опции конфигурации: Enabled (Включен), Disabled (Заблокирован) и Not Configured (He сконфигурировано). Если установлена опция Enabled, то независимо от того, какая групповая политика сконфигурирована, она будет применена. Если установлена опция Disabled, то независимо от того, какая групповая политика сконфигурирована, она будет заблокирована. Если установка была включена в объекте GPO, который применялся ранее, она все равно будет изменена на Disabled. Например, вы можете включить установку по удалению команды Run в объект GPO, связанный с OU высокого уровня. Затем вы блокируете установку по удалению команды Run в OU более низкого уровня, после чего команда Run будет доступна для всех пользователей в OU низшего уровня. Если установлено Not Configured, параметры настройки политики не изменятся, и будут поддерживаться установки, унаследованные от более высокого уровня.

Наследование разрешений

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

По умолчанию все разрешения в Active Directory наследуются. Большинство разрешений, установленных на контейнерном уровне, наследуется всеми объектами в пределах этого контейнера, включая другие контейнерные объекты. Например, если пользователь имеет разрешение создавать учетные записи пользователей в OU, он также может создавать учетные записи в любой дочерней OU в пределах этой OU. В большинстве случаев вы, вероятно, примете заданное по умолчанию наследование разрешений. Если вы разработали свою структуру OU с целью делегирования администрирования, то нужно создать OU-структу-ру, в которой на высшем иерархическом уровне предоставляются разрешения администраторам высшего уровня, нуждающимся в разрешениях ко всем объектам Active Directory. По мере продвижения вниз по иерархии вы можете назначать разрешения для других администраторов, которые должны иметь контроль над меньшей частью домена.

В некоторых случаях можно блокировать любые административные разрешения администраторов высокого уровня для определенной дочерней OU. Например, вы создали дочернюю OU для филиала вашей компании и дали локальной административной группе полное управление над этой OU. Возможно, вы не хотите, чтобы эти локальные администраторы имели доступ к учетным записям пользователей, представляющих исполнительную власть в этой OU. Вы можете создать OU Executives (Руководство) в пределах OU-филиала, а затем блокировать наследование разрешений на уровне Executives OU.

Чтобы блокировать наследование разрешений на объекте Active Directory, обратитесь к окну Advanced Security Settings для данного

объекта (см. рис. 9-2). Затем очистите опцию Allow Inheritable Permissions From The Parent To Propagate To This Object And All Child Objects (Разрешить наследованным разрешениям распространяться от родителя к этому объекту и всем дочерним объектам). После очистки этой опции вам будет представлена опция, позволяющая копировать существующие разрешения или удалять разрешения перед явным назначением новых разрешений (см. рис. 9-6).



Рис. 9-6. Выбор опции, позволяющей копировать или удалять разрешения при блокировании наследования разрешений

После блокировки наследования вы можете сконфигурировать разрешения на объектах. Блокировка наследования имеет несколько следствий.

Разрешения блокируются для объекта и любых дочерних объектов. Вы не можете блокировать наследование разрешений на контейнерном уровне, а затем повторно применять наследование от более высокого контейнера на более низкий уровень.

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

У вас нет большого выбора того, какие разрешения будут блокированы. Когда вы блокируете разрешения, то все наследованные разрешения также блокируются. Разрешения, которые были назначены на объект или дочерние объекты явно, не блокируются.

Примечание. Одна из возможных проблем с блокированием унаследованных разрешений состоит в том, что можно создать «осиротевший» объект, к которому никто не имеет разрешений. Например, в организационной единице OU можно блокировать все наследование разрешений к ней и назначить разрешения только для административной группы. Вы можете даже удалить группу Domain Admins из списка ACL этой OU, чтобы группа Domain Admins не имела никаких разрешений при нормальных обстоя-

тельствах, и в OU не будет групп с административным управлением. В этом случае группа Domain Admins всегда может взять объект в собственность и повторно назначить разрешения.

Настройка инструментов для делегирования администрирования

Служба Active Directory Windows Server 2003 обеспечивает мощные способы делегирования административных задач и назначения очень точных разрешений, которые пользователи должны иметь при необходимости выполнить специфические задачи. В дополнение к этим способам Active Directory облегчает развитие административных средств, которые соответствуют конкретной задаче пользователя. Например, если вы делегируете право устанавливать пароли для отдельной OU, вы можете воспользоваться простым инструментом администрирования, который может использоваться только для этой задачи. Windows Server 2003 имеет два способа создания специально настроенных инструментов. Вы можете настроить внешний вид средств обычных консолей ММС или создать панель задач (taskpad), которая является полностью настроенным инструментом администрирования.

---

---