Настройка консоли управления Microsoft

Первый вариант разработки инструмента администрирования состоит в настройке консоли управления Microsoft (ММС - Microsoft Management Console) с помощью одной из заданных по умолчанию оснасток.

Предостережение. Простое создание настроенной ММС-консо-ли не предоставляет и не ограничивает права пользователя на выполнение административных задач. Перед созданием настроенного административного интерфейса нужно делегировать правильный уровень разрешений. Например, если вы даете пользователю право создания учетных записей пользователя на уровне домена, а затем создаете ММС-консоль, которая дает возможность пользователю рассматривать только одну OU, то он сможет создавать учетные записи пользователя в любой OU. Если пользователь загружает обычный инструмент администрирования Active Directory Users And Computers или садится за другой рабочий стол с другой ММС-консолью, он сможет создать учетную запись где угодно.

Для создания настроенной ММС-консоли откройте диалоговое окно Run (Выполнить) и напечатайте ттс. Будет открыта пустая ММС-консоль. Из меню File (Файл) добавьте нужную оснастку инструмента Active Directory. Если вы создаете собственную консоль ММС, используя оснастку Active Directory Users And Computers, разверните домен и найдете

контейнерный объект, которому вы делегировали разрешения. В левой области окна щелкните правой кнопкой мыши на контейнерном объекте  и выберите New Window From Here (Отсюда новое окно).

Откроется новое окно, в котором будут видны только контейнерный объект и все дочерние объекты. Затем вы можете переключиться назад к окну, которое отображает весь домен, и закрыть окно. Далее сохраните инструмент администрирования и предоставьте его пользователям, которые будут управлять только частью домена, видимого в ММС-консо-ли. Консоль ММС может быть предоставлена пользователю несколькими способами. Например, вы можете установить консоль ММС на рабочий стол пользователя или создать ярлык к инструменту администрирования на сетевом ресурсе.

Чтобы быть уверенным, что администраторы контейнера не изменят ММС-консвль, можно изменить опции ММС-консоли, выбирая Options в меню File. Вы можете сконфигурировать ММС-консоль так, чтобы она сохранялась в режиме User Mode (Режим пользователя), и изменить разрешения на ММС, чтобы конечный пользователь не мог сохранять изменения ММС-консоли. На рисунке 9-14 показан соответствующий интерфейс. Для уточнения деталей настройки ММС-консолей смотрите Help And Support Center (Центр справки и поддержки).

Рис. 9-14. Конфигурирование собственной ММС-консоли для предотвращения возможных ее изменений

Назначение владельцев домена

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

Примечание. Если вы развертываете назначенный корневой домен, владельцами этого домена являются владельцы леса. Реальные функции, выполняемые в назначенном корневом домене — это функции леса, так что имеет смысл владельцев леса назначать также владельцами корневого домена.

Роль владельца домена состоит в управлении индивидуальным доменом. Эти задачи включают следующее.

Создание политик безопасности уровня домена. Это включает политику паролей, политику блокировки учетных записей и политику билетов Kerberos.

Проектирование конфигурации Group Policy (Групповая политика) уровня домена. Владелец домена может проектировать групповую политику для всего домена и делегировать право связывать групповую политику с администратором уровня OU.

Создание в домене OU-структуры высокого уровня. После создания OU-структуры высокого уровня задача создания подчиненных OU может быть передана администраторам уровня OU.

Делегирование административных прав в пределах домена. Владелец домена должен установить административную политику уровня домена (включая политики схем именования, проекта групп и т.д.), а затем делегировать права администраторам уровня OU.

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

Неудовлетворенность текущей моделью домена

Если имеющаяся доменная модель Windows NT 4 больше не удовлетворяет организационным потребностям вашей организации: устарела из-за слияния компаний, приобретения, отделения дочерних компаний и пр., по другим причинам больше не является наиболее оптимальной сетевой платформой для служб вашей организации, то наилучшим выбором будет реструктуризация домена. Это даст вам возможность начать с нового проекта Active Directory, который будет удовлетворять вашим деловым и организационным потребностям. Учитывая время и усилия, которые потребуются для развертывания Active Directory в пределах вашего предприятия, начинать с проекта имеет смысл только в том случае, если он упростит вашу жизнь настолько, насколько это возможно.

Низкий уровень риска

Являясь самым легким способом перехода, обновление домена представляет собой и метод с минимальным риском. Когда вы модернизируете контроллер домена с операционной системой Windows NT 4 Server, процесс выполняется автоматически. Без взаимодействия с пользователем возможностей для ошибок возникает немного. Методология восстановления после сбоя при обновлении домена также относительно проста. Если обновление прошло неудачно, выключите основной контроллер домена (PDC), назначьте любой резервный контроллер домена (BDC), имеющий свежие данные, на роль PDC, и начните процедуру снова.

к ключевым функциям Active Directory,

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

Объекты inetOrgPerson

Одним из новых объектов Active Directory Windows Server 2003 является объект inetOrgPerson. Он является основной учетной записью пользователя, которая используется другими каталогами с применением облегченного протокола службы каталогов (Lightweight Directory Access Protocol — LDAP) и Х.500, совместимыми с требованиями документа Request for Comments (RFC) 2798. Вводя объект inetOrgPerson, Microsoft облегчил интеграцию службы Active Directory с другими каталогами и упростил перемещение из каталогов в Active Directory.

Примечание. При обновлении леса Windows 2000 до Windows Server 2003 в схеме создается объект inetOrgPerson, когда вы выполняете команду Adprep.exe с ключом /forestprep. Утилиту Adprep.exe можно найти в папке \I386 на компакт-диске Windows Server 2003.

Объект inetOrgPerson может быть создан с помощью инструмента Active Directory Users And Computers. Для этого найдите контейнер, в котором вы хотите создать объект, щелкните на нем правой кнопкой мыши и выберите New>InetOrgPerson. При создании объекта inetOrgPerson вы должны ввести пользовательское имя входа в систему и полное имя. Объект inetOrgPerson является подклассом объекта user, т.е. он имеет все характеристики пользовательского класса, включая и то, что он действует как участник безопасности. Объекты inetOrgPerson управляются и используются теми же способами, как и объект user.

Объекты связи

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

Объекты связи всегда создаются как односторонние pull («тянущие») соединения между двумя контроллерами домена, потому что нормальный процесс репликации является pull-операцией, в которой контроллер-адресат запрашивает данные у контроллера-отправителя информации. В большинстве случаев КСС строит два односторонних соединения между контроллерами домена так, чтобы информация могла реплицироваться в обоих направлениях.

Примечание. С помощью инструмента Replication Monitor (Монитор репликации) вы можете создать push («толкающую») репликацию для раздела каталога. Нормальный процесс репликации всегда является pull-операцией. (Смотрите детали, касающиеся установки и использования монитора репликации в разделе «Мониторинг и поиск неисправностей при репликации» далее в этой главе.)

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

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

Объекты User

Один из наиболее типичных объектов в любой базе данных Active Directory — объект user. Объект user, подобно любому другому объекту

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

Когда вы создаете объект user , нужно заполнить некоторые из его атрибутов. Как показано на рисунке 10-1, при создании учетной записи пользователя требуется только шесть атрибутов, причем атрибуты сп и sAMAccountName конфигурируются на основе данных, которые вы вводите при создании учетной записи. Остальные атрибуты, включая идентификатор безопасности (SID), автоматически заполняются системой безопасности.

Рис. 10-1. Обязательные атрибуты учетной записи пользователя, отображаемые инструментом Adsiedit.msc

При создании учетной записи пользователя вы можете назначить значения многим атрибутам объекта user. Некоторые из атрибутов нельзя увидеть через интерфейс пользователя (UI), например, атрибут Assistant (Помощник). Его можно заполнять, используя скрипт или инструмент

Adsiedit.msc, который обращается к атрибуту напрямую. Можно заполнять скрытые атрибуты в процессе общего импорта информации каталога с использованием утилит командной строки Csvde или Ldifde. Детальную информацию по использованию этих утилит смотрите в Help And Support Center (Центр справки и поддержки). Заполнять невидимые в UI атрибуты необходимо, так как они используются для поиска и изменения объектов. В некоторых случаях скрытый атрибут доступен через диалоговое окно Find (Поиск). Например, в инструменте Active Directory Users And Computers (Пользователи и компьютеры Active Directory) для поиска всех пользователей, которые имеют один и тот же атрибут Assistant, используйте вкладку Advanced (Дополнительно) в диалоговом окне Find, чтобы создать запрос, основанный на атрибуте Assistant (см. рис. 10-2). В этом окне щелкните на кнопке Field (Поле), выберите User (Пользователь), а затем выберите атрибут, по которому вы хотите сделать поиск. Так можно найти многие скрытые атрибуты.

Рис. 10-2. Поиск учетных записей пользователя по атрибутам, которые не видны в пользовательском интерфейсе

Дополнительная информация. Вы можете просматривать и изменять любой атрибут объекта user, используя инструменты Adsiedit.msc или Ldp.exe. Более эффективный способ состоит в использовании скриптов. От этого можно получить значительную выгоду, поскольку Active Directory написана так, чтобы разрешать и поощрять использование скриптов. Информацию об использовании скриптов для автоматизации задач управления службой Active Directory смотрите в центре TechNet Script Center   по   адресу   http://www.microsoft.com/technet/scriptcenter/default.asp. TechNet Script Center содержит ресурсы для создания скриптов и типовые сценарии, используемые для расширения административных задач, которые иначе выполняются через консоли управления службой Active Directory. Смотрите также веб-сайт Microsoft Press Online по адресу http:// www.microsoft.com/mspress/, где находится бонус-глава по созданию сценариев «Introduction to ADSI Scripting Using VBScript» (Введение в ADSI сценарии на языке VBScript), написанная Майком Малкером (Mike Mulcare).

Большинство административных задач, связанных с обычными пользователями, выполняются при помощи инструмента Active Directory Users And Computers. Чтобы создать с его помощью объект user, найдите контейнер, в котором вы хотите создать объект, щелкните правой кнопкой мыши и выберите New>User (Новый>Пользователь). При создании пользователя вы должны ввести Full Name (Полное имя) и User Logon Name (Пользовательское имя для входа в систему). Данные Full Name используются для заполнения атрибута сп пользователя, данные User Logon Name становятся значением sAMAccountName. После создания пользователя можно обращаться к свойствам объекта для заполнения дополнительных атрибутов пользователя, назначение которых вполне понятно. Наиболее важная вкладка, предназначенная для управления учетной записью пользователя — это вкладка Account (Учетная запись) (см. рис. 10-3). Пользовательские параметры настройки, доступные на вкладке Account, описаны в таблице 10-1.





Рис. 10-3. Вкладка Account для объекта user

Табл. 10-1. Свойства учетной записи объекта User Параметры учетной записи      Пояснение

UserLogonName (Пользовательское имя для входа в систему)	Идентифицирует основное имя пользователя (UPN) для данного пользователя.
User Logon Name (Пользовательское имя для входа в систему) (использовалось до Windows 2000)	Идентифицирует имя, применяющееся для входа в более ранние, чем Microsoft Windows 2000, системы, используя формат domain\username.
Logon Hours (Часы входа в систему)	Устанавливает часы, в которые пользователь может входить в домен.
Log On To (Вход на)	Перечисляет компьютеры (используя имена NetBIOS компьютеров), на которые пользователю разрешается вход.
Account Is Locked Out (Учетная запись блокирована)	Указывает на то, что учетная запись была блокирована из-за слишком большого числа неудавшихся попыток входа в систему.
Account Options (Опции учетной записи)	Обеспечивает настройку таких параметров, как политики пароля и опознавательные требования.
Account Expires (Учетная запись недействительна)	Определяет время окончания срока действия учетной записи.

Обеспечение сетевой связи

После установки Windows Server 2003 и до начала установки Active Directory убедитесь, что сервер должным образом сконфигурирован для обеспечения сетевой связи. Попытайтесь соединиться с другим компьютером по сети, указав путь UNC или IP-адрес целевого компьютера в строке адреса программы Windows Explorer или используя утилиту Ping (например, в командной строке напечатайте ping 192.168.1.1). Выполните все необходимые действия для оптимизации сегмента сети, в котором будет находиться новый контроллер домена. Для этого используйте инструмент сетевого управления Network Monitor (Сетевой монитор) для обеспечения достаточной пропускной способности, необходимой для поддержки аутентификации и трафика репликации, который будет генерировать контроллер домена.

Примечание. Инструмент Network Monitor по умолчанию не устанавливается в Windows Server 2003. Его нужно установить с помощью Windows Components Wizard (Мастер компонентов Windows) в приложении Add/Remove Programs (Установка/ Удаление программ) окна Control Panel (Панель управления). Для получения дополнительной информации об установке и использовании сетевого монитора для анализа проблем сетевого трафика сделайте поиск "Network Monitor" (включая двойные кавычки) в Windows Server 2003 Help and Support Center (Центр справки и поддержки Windows Server 2003).

Перед установкой службы Active Directory вы должны сконфигурировать параметры настройки протокола интернета в окне Local Area Connection Properties (Свойства локальных подключений). Чтобы обратиться к этому диалоговому окну, щелкните правой кнопкой мыши на объекте Local Area Connection (Локальные подключения) в папке Network Connections (Сетевые подключения) в окне Control Panel и выберите Properties (Свойства). В окне Local Area Connection Properties выберите Internet Protocol (TCP/IP) (Протокол интернета), затем щелкните на кнопке Properties. В окне Internet Protocol (TCP/IP) Properties (Свойства протокола интернета), сделайте следующее.

На вкладке General (Общее) сконфигурируйте статический IP-адрес компьютера.

Если контроллер домена, который вы устанавливаете, не будет служить сервером DNS, то на вкладке General вы должны сконфигурировать адрес сервера DNS, задав ему IP-адрес сервера DNS, который является официальным (authoritative) для данного домена. Смотрите следующий раздел для получения дополнительной информации о конфигурировании DNS при инсталляции Active Directory.

В окне Advanced TCP/IP Settings (Дополнительные параметры настройки TCP/IP) щелкните на Advanced (Дополнительно) на вкладке General, щелкните на вкладке WINS и сконфигурируйте сервер, задав IP-адрес сервера службы имен интернета для Windows (WINS), который будет использовать данный контроллер домена.

Область действия группы

В Active Directory Windows Server 2003 вы можете создавать группы с тремя различными областями действия: доменной локальной, глобальной и универсальной. В таблице 10-3 перечислены характеристики каждой области действия группы.

Примечание. Универсальные группы доступны только в том случае, если домен работает на функциональном уровне Windows 2000 native. Вложенные группы (nested groups} — это группы, которые являются членами других групп. Опции, предназначенные для вложения групп, зависят от функционального уровня домена. Например, вы можете вложить глобальную группу в доменную локальную группу на любом функн|иональном уровне, но вкладывать глобальную группу внутрь другой глобальной группы можно только в том случае, если домен работает на функциональном уровне Windows 2000 native, или более высоком.

Локальные группы домена являются полнофункциональными только в том случае, когда домен поднят на уровень Windows 2000 native. Если домен выполняется на смешанном (mixed) уровне Windows 2000, локальные группы домена работают точно так же, как локальные группы на контроллерах домена в Windows NT 4. Группа может использоваться для назначения разрешений на ресурсы только контроллеров домена, но не других компьютеров, расположенных в домене. Если домен был переключен на естественный функциональный уровень Windows 2000, то локальные группы домена могут использоваться для предоставления разрешений ресурсам, расположенным на любом сервере с Windows 2000 или с Windows Server 2003.

Табл. 10-3. Область действия групп Active Directory

Область действия группы		Членство группы включает		Область действия группы включает
Domain Local (Локальная сЛоменная)		Учетные записи пользователя из любого домена леса		Используется для назначения доступа к ресурсам только в локальном домене.
		Глобальные группы или универсальные группы из любого домена леса Учетные записи пользователя или глобальные и универсальные группы из любого домена доверенного леса		Используется на всех серверах Windows 2000 или Windows Server 2003.
		Вложенные локальные группы домена из локального домена
Global (Глобальная)		Учетные записи пользователя из домена, в котором данная группа создана		Используется для назначения доступа к ресурсам, расположенным во всех доменах леса, или между доверенными лесами.
		Вложенные глобальные группы из того же домена		Используется на любом сервере-члене домена, на котором выполняется Windows.
Universal (Универсальная)		Учетные записи пользователей из любого домена в лесе		Используется для назначения доступа к ресурсам, расположенным во всех доменах леса, или между доверенными лесами.
		Глобальные группы из любого домена леса или из доверенного леса Вложенные универсальные группы из любого домена в лесе или из доверенного леса		Используется только на серверах Windows 2000 или Windows Server 2003.

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

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

Универсальные группы являются наиболее гибкими группами в Active Directory, но эта гибкость дается «не бесплатно». Они могут содержать любого члена домена леса и использоваться для назначения разрешений на ресурсы, расположенные в любом домене леса. Для этого список членства для всех универсальных групп должен храниться в глобальном каталоге (GC) как отдельный атрибут. Если ваш домен работает на функциональном уровне Windows 2000 native, то каждый раз после добавления к универсальной группе нового члена весь список членов должен копироваться на другие контроллеры домена. Для универсальной группы с тысячами пользователей это может привести к значительной репликации. Однако если домен был поднят на функциональный уровень Windows Server 2003, то контроллеры домена, на которых выполняется Windows Server 2003, будут реплицировать только изменения в списке членства.



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

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

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

Active Directory Windows Server 2003 содержит большое количество встроенных учетных записей групп в контейнере Users (Пользователи) и Builtin (Встроенный). Эти группы имеют разнообразные цели и заданные по умолчанию разрешения в пределах домена. Только две группы при установке домена содержат некоторых членов - локальная группа домена Administrators (Администраторы) и глобальная группа Domain Admins (Администраторы домена). Учетная запись Administrator, под которой создавался домен, добавляется к обеим группам, а группа Domain Admins добавляется к группе Administrators. Если домен является первым доменом в лесе, то учетная запись Administrator также добавляется к глобальной группе Enterprise Admins (Администраторы предприятия) и к глобальной группе Schema Admins (Администраторы схемы).

Облегченный протокол службы каталогов (LDAP)

Протокол LDAP является как протоколом доступа, так и моделью службы каталога в Active Directory Windows Server 2003. Как информационная модель иерархия имен LDAP подобна иерархии имен каталогов X.500/OSI. Как программный интерфейс приложения (API) LDAP реализован в Active Directory Windows Server 2003 в Wldap32.dll. Active Directory полностью поддерживает доступ к каталогу, используя собственные запросы LDAP или используя интерфейс ADSI СОМ (Component Object Model — модель компонентных объектов). Как протокол доступа LDAP определен в комплекте TCP/IP для доступа к данным, находящимся в LDAP-совместимых каталогах. Как открытый стандарт LDAP облегчает обмен данными между платформами с различными службами каталога, о чем говорится далее в разделе «Ключевые функции и преимущества службы Active Directory» в этой главе.

Представление иерархии имен LDAP для учетной записи пользователя, приведенной в примере ранее, дается как:

LDAP: // cn=Karen Friske, cn=Users, dc=Contoso, dc=com

Используя это соглашения об именах, администраторы могут более точно ссылаться на объекты и обращаться к объектам в пределах службы LDAP-совместимого каталога. LDAP-протокол и модель каталога (но не синтаксис именования) определен документом RFC 1777, который доступен на сайте http://www.faqs.org/rfcs/rfcl777.html.

Для администрирования службы Active Directory, совместимой с LDAP, используйте LDAP-чувствительный инструмент администрирования типа Ldp.exe, который является частью пакета Suptools.msi, расположенного в папке Support\Tools компакт-диска продукта Windows Server 2003. Используя Ldp.exe, вы можете связаться или подключиться к службе Active Directory по ее номеру UDP (User Datagram Protocol — пользовательский протокол данных) порта и показать отображаемое LDАР-имя каждого атрибута, класса и объекта. Чтобы подключиться к Active Directory, используя Ldp.exe, и отобразить атрибуты пользовательских объектов, свяжитесь с Active Directory, используя UDP порта 389, раскройте контейнер или организационную единицу, а затем дваж-

ды щелкните на определенном названии учетной записи пользователя. На рисунке 1-4 показана учетная запись пользователя с именем Karen Friske, которую можно увидеть через инструмент Ldp.exe.

Рис. 1 -4. Учетная запись пользователя Karen Friske, отображаемая в Ldp.exe

Обновление BDC контроллеров

Возможно, что в модернизации BDC-контроллеров с системой Windows NT 4 нет никакой необходимости. С обновлением PDC вся информация домена обновится до Active Directory Windows Server 2003. После этого

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

Когда выбирается модернизация BDC? Возможно, только в том случае, если имеются приложения, выполняющиеся на BDC, которые неудобно или невозможно повторно установить на новом контроллере домена.

Если вы решите, что необходимо провести обновление BDC, то этот процесс будет таким же, как обновление PDC. Сначала модернизируете NOS, а после перезапуска компьютера воспользуетесь мастером инсталляции Active Directory для установки Active Directory и назначения сервера на роль контроллера домена. Мастер инсталляции Active Directory можно и fie выполнять. В этом случае компьютер останется сервером-членом домена Windows Server 2003, а информация базы данных SAM на этом сервере будет потеряна. Ваш проект Active Directory предписывает потребное количество контроллеров домена, а в плане модернизации указано, какие из оставшихся контроллеров BDC должны быть назначены контроллерами домена после обновления, а какие — остаться серверами-членами домена.

Обновление домена

Обновление домена - это вторая стадия процесса перехода к Windows Server 2003. (Первая стадия - обновление NOS.) При обновлении контроллера домена, на котором выполняются системы Windows NT 4 Server или Windows 2000 Server, после модернизации NOS и перезапуска компьютера мастер инсталляции Active Directory запускается автоматически. По окончании работы мастера служба каталога будет модифицирована до Active Directory Windows Server 2003.

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

В зависимости от версии Windows в процессе обновления выполняются различные действия. Первая часть этого раздела описывает процессы обновления домена с системой Windows NT 4 Server, вторая — домена с системой Windows 2000 Server.

Примечание. Если у вас установлена более ранняя версия системы, чем Windows NT 4, вы не можете обновить ее сразу до Windows Server 2003. Сначала модернизируйте ее до Windows NT 4 и примените комплект обновлений Service Pack 5 (или более поздний) перед обновлением операционной системы.

Обновление контроллеров домена

В отличие от контроллеров домена с системой Windows NT 4 все контроллеры домена в сети, на которых выполняется Windows 2000, являются в некотором смысле PDC контроллерами. Они одинаково способны писать в базу данных Active Directory, подтверждать подлинность пользователей и отвечать на запросы. За исключением держателей ро-

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

Процесс обновления Windows 2000 такой же, как для обновления Windows NT 4 до Windows Server 2003. Он состоит из двух шагов: модернизация NOS до Windows Server 2003 и выполнение мастера инсталляции Active Directory.

Обновление с последующей реструктуризацией

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

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

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

Модернизация в пределах леса и модернизация между лесами имеют следующие отличия.

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

При модернизации в пределах леса для поддержки правил группового членства нужно переместить учетные записи пользователей и групп, которым они принадлежат, одновременно. Это называется замкнутым набором (closed set). Этот процесс отличается от модернизации исходного домена Windows NT 4 до целевого домена Windows, в котором учетные записи пользователя и учетные записи группы можно переносить или вместе, или по отдельности. Однако инструмент ADMT не вычисляет полный замкнутый набор, так что нужно очень осторожно перемещать пользователей, которые являются членами глобальных групп. Если вы переносите группу, которая включает учетную запись пользователя, являющуюся членом другой глобальной группы, и если та глобальная группа не является рекурсивно членом какой-либо группы, перемещаемой в это же время, то будет нарушено членство данной учетной записи пользователя в глобальной группе, которая не включена в модернизацию. Другие типы групп (типа универсальных групп) допускают наличие членов, не принадлежащих их собственным доменам.

Обновление существующего пакета программ

Еще одна полезная функция, доступная при использовании групповых политик для установки программного обеспечения, предназначена для обновления существующего пакета программ. Имеется два способа обновления: внесение исправлений (заплаток) или установка сервисного пакета (service pack) на существующее приложение и обновление приложения до новой версии. Если у вас работает Microsoft Office 2000, то установка пакета Service Release I for Office 2000 является примером первого типа модификации, а инсталляция программы Office XP дает пример второго типа.

Эти методы обновления программного обеспечения требуют применения различных процедур. Если вы применяете заплатки (patch file) или сервисный пакет к существующему приложению, сначала нужно получить файл .msi или patch-файл (.msp) для обновленного приложения. (В идеальном случае этот файл поставляется изготовителем программы, но вы можете создать свой собственный.) Скопируйте новый файл .msi и другие инсталляционные файлы в ту же самую папку, в которой находится оригинальный файл .msi, записывая любые дублированные файлы поверх старых. Затем повторно разверните приложение. Чтобы это сделать, щелкните правой кнопкой мыши на пакете программ в редакторе объектов групповой политики, выделите All Tasks (Все задачи), а затем выберите Redeploy Application (Повторно развернуть приложение). Пакет программ будет повторно развернут для всех пользователей и компьютеров, находящихся под управлением этой групповой политики. При обновлении существующего приложения до новой версии программного обеспечения вам потребуется другой подход. Нужно будет создать новый пакет программ для развертывания приложения. Затем можно обратиться к свойствам пакета программ нового приложения и выбрать вкладку Upgrades (Обновления). Используя параметры настройки, представленные на этой вкладке, создайте ссылку на существующий пакет в новом пакете распределения программного обеспечения. Щелкнув на кнопке Add (Добавить) во вкладке Upgrades, выберите пакет программ, который будет модернизирован с помощью нового пакета. Вы сможете также сконфигурировать, должно ли старое приложение деинсталлироваться, прежде чем будет установлено новое приложение. На рисунке 12-6 показан пример обновления приложения Office 2000.

Рис. 12-6. Обновление существующего пакета программ

Когда связь с обновлением создана, вкладка Upgrades показывает новую информацию (см. рис. 12-7). С помощью вкладки Upgrades можно сделать это обновление обязательным. В этом случае все программное обеспечение, распределенное предыдущим объектом GPO, будет обновлено во время следующей перезагрузки компьютера или при следующем входе пользователя в систему. Если обновление не сделать обязательным, пользователь сможет выбирать время установки нового приложения, активизируя приложение в меню Start (Пуск) или через панель управления Add Or Remove Programs (Установка и удаление программ). Если для пакета обновления программного обеспечения и для начального приложения вы используете один и тот же объект GPO, то первоначальный пакет программ покажет, что новый пакет его модернизирует.

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



Рис. 12-7. Вкладка Upgrades в окне Properties (Свойства) пакета программ

Обновление Windows 2000 Server

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

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

Наилучшая практика Перед подготовкой домена (и леса, в котором он расположен) вы должны применить комплект обновления Windows 2000 Server Service Pack 2 (SP2), или более поздний, ко всем контроллерам домена, на которых выполняется Windows 2000 Server. Вы можете загрузить комплекты обновлений для Windows 2000 Server с веб-сайта Microsoft по адресу http://www.microsoft.com/ windows2000/downloads /servicepacks/default, asp.

это переход от службы каталога

Наиболее часто встречающийся сценарий — это переход от службы каталога Windows NT 4 к Active Directory Windows Server 2003. Несмотря на свой возраст, система Windows NT 4 Server является оплотом рынка сетевых операционных систем (NOS) для предприятий. На момент выхода книги компания Microsoft объявила о планах «отставки» системы Windows NT 4 Server и постепенного «свертывания» поддержки этого продукта в течение следующих нескольких месяцев. С выпуском Windows Server 2003 многие организации, которые не хотели переходить к Windows 2000, будут обновляться до Active Directory Windows Server 2003.

Обновление Windows NT 4 Server

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

Дополнительная информация. В этом разделе обсуждаются только вопросы обновления до Active Directory Windows Server 2003. Поскольку вначале выполняется обновление операционной системы Windows NT 4 Server до Windows Server 2003, необходимо предварительно ознакомиться с техническими требованиями для модернизации NOS. Для получения дополнительной информации для небольших инсталляций (от одного до пяти серверов) смотрите страницу «Installing and Upgrading the Operating System (Установка и обновление операционной системы)» на веб-сайте Microsoft по адресу http:// www.microsoft.com/technet/prodtechnol/windowsserver2003/ proddocs/entserver/ins. Информацию для больших инсталляций смотрите в статье Microsoft Windows Server 2003 Deployment Kit (Комплект развертывания Windows Server 2003) по адресу http:// www.microsoft.co7n/windowsserver2003/techinfo/reskit/ deploykit.mspx.

Более простой путь доступен для

Более простой путь доступен для владельцев Windows Server 2000, которые планируют провести модернизацию до Windows Server 2003. Многие архитектурные изменения службы каталога осуществлялись тогда, когда клиенты создавали свою среду сети Windows 2000, или когда они модернизировали систему Windows NT Server 4. Клиенты, переходящие к Active Directory Windows Server 2003 с системы Windows 2000, наиболее вероятно планируют извлечь выгоду из новых функций, доступных в версии Active Directory Windows Server 2003.

Дополнительная информация. Для получения дополнительной информации о новых функциях, доступных в Active Directory Windows Server 2003, см. гл. 1.

Для Windows NT 4 переход к Active Directory выполняется путем модернизации операционных систем на контроллерах домена. Как только обновление закончено, можно пользоваться преимуществами новых функций Active Directory Windows Server 2003. Может клиент Windows 2000 Server выбрать реструктуризацию домена вместо обновления домена? Да, по тем же самым причинам, по которым клиенты Windows NT 4 Server выбирают реструктуризацию домена, - инфраструктура службы каталога больше соответствует потребностям бизнеса в организации. Клиент Windows 2000 Server, вероятнее всего, модернизирует NOS, a затем реструктуризирует ее, чем выполнит чистую реструктуризацию домена.

Перед модернизацией Windows 2000 Server до Windows Server 2003 нужно выполнить два действия: подготовить лес и домен Active Directory для Windows Server 2003. В папке \I386 на компакт-диске Windows Server 2003 находятся два инструмента для решения этих задач: ForestPrep и DomainPrep. Процедуры подготовки леса и домена описываются далее в этой главе.

Практический опыт. Переименование домена

При обновлении Windows NT 4 или Windows 2000 до Windows Server 2003 Active Directory не изменяет имя домена. Новой функцией в Active Directory является инструмент Domain Rename (Переименование домена). После того как домены модернизированы, и уровень леса поднят до Windows Server 2003, можно изменить имя модернизированного домена в соответствии с текущими потребностями вашей организации. Инструменты переименования домена обеспечивают следующее:

переименование домена без необходимости изменять положение какого-нибудь домена леса;



создание структуры нового дерева доменов путем изменения положения доменов в пределах дерева;

создание новых деревьев доменов.

Инструменты переименования доменов могут использоваться для изменения имени корневого домена леса, но с их помощью нельзя назначить корневым доменом леса другой домен, добавлять или удалять домены из леса. Для переименования доменов Windows Server 2003 нужно установить инструмент Domain Rename (Переименование доменов). Файлы Rendom.exe и Gpfixup.exe находятся на компакт-диске Windows Server 2003 в папке \VALUEADD\MSFT\MGMT\DOMREN. Инструмент Domain Rename доступен также на веб-сайте Microsoft по адресу http:// www.microsoft.com/windowsserver2003/downloads/ domainrename.mspx. Domain Rename работает только в Windows Server 2003 и не поддерживает Windows 2000.

Для получения дополнительной информации об использовании Domain Rename смотрите статью «Understanding How Domain Rename Works (Как работают инструменты переименования доменов)» по адресу http: / /www. microsoft.com/windowsserver2003 /docs /Domain-Rename- Intro.doc. Подробно процедура развертывания Domain Rename описана в статье «Step-by-Step Guide to Implementing Domain Rename (Пошаговое руководство по применению средства Domain Rename)» no адресу http://www.microsoft.com/windowsserver2003/docs/Domain-Rename- Procedure, doc.

Обработка групповой политики

Теперь, когда вы знаете, как создавать объекты GPO и связывать их с контейнерами в пределах Active Directory Windows Server 2003, следующий шаг состоит в понимании того, как на самом деле групповые политики применяются к компьютерам. Когда компьютер запускается и пользователь входит в систему, происходит применение групповых политик следующим образом.

Во время запуска компьютера клиента считывается системный реестр и определяется сайт, в котором расположен компьютер. Компьютер посылает запрос DNS-серверу, запрашивая IP-адреса контроллеров домена, расположенных в этом сайте.

Получив ответ DNS-сервера, компьютер клиента соединяется с контроллером домена в своем сайте. В процессе опознания, проводимом контроллером домена, компьютер клиента запрашивает список всех GPO-объектов, которые применяются к компьютеру.

Контроллер домена присылает клиенту список всех GPO-объектов в том порядке, в котором политики должны применяться. Затем компьютер извлекает объект GPO с контроллера домена и применяет политику. Порядок, в котором применяются групповые политики, основан на LSDOU-конфигурации.

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

Совет. Групповые политики применяются к клиентам с операционной системой Windows XP асинхронно, а с системой Windows 2000 - синхронно, т.е. все компьютерные политики полностью применяются до того, как появится пользовательский экран входа в систему, а все пользовательские политики - до того, как по-

явится рабочий стол пользователя. Асинхронное применение политик означает, что загрузка системы Windows XP и вход пользователей в систему происходит более быстро.

Вы можете использовать групповые политики для модификации применения других групповых политик. Опции конфигурации устанавливаются в папках UserConfiguration\Administrative Templates\System\ Group Policy или Computer Configuration\Administrative Templates\ System\Group Policy. На рисунке 11-12 показаны опции, имеющиеся в ветви Computer Configuration дерева папок.

Рис. 11-12. Опции конфигурации групповой политики

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

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

Чтобы определить, используется ли медленное сетевое подключение, компьютер посылает пакет утилиты ping с нулевым байтом контроллеру домена. Если время ответа составляет меньше десяти миллисекунд, то сеть считается быстрой, и применяются все групповые политики. Если время ответа составляет больше десяти миллисекунд, компьютер про-званивает контроллер домена три раза с помощью утилиты ping с двух-килобайтными пакетами. Компьютер усредняет времена ответов и использует это усредненное значение для определения сетевой скорости связи. Ecjfti пропускная способность сетевого подключения составляет большее 500 Кб/с, то по умолчанию применяются все групповые политики. Если компьютер обнаруживает сетевое подключение, скорость которого меньше 500 Кб/с, то применяются только политики с параметрами настройки защиты и административными шаблонами.

Можно изменить заданное по умолчанию определение медленной связи. Оно может быть сконфигурировано для компьютеров в папке Computer Conf iguration\Administrative Templates\System\Group Policy. Щелкните правой кнопкой мыши на Group Policy Slow Link Detection (Обнаружение медленной связи для групповых политик) и выберите Properties (Свойства) (см. рис. 11-13). Для изменения значения скорости передачи для медленной связи выберите Enabled (Включено), а затем введите значение, которое вы хотите использовать.





Рис. 11-13. Конфигурирование параметров медленной связи

Если компьютер обнаруживает медленное сетевое подключение, то по умолчанию обрабатываются только компоненты защиты и административных шаблонов, и нет никакого способа выключить эти параметры настройки. Однако вы можете сконфигурировать другие параметры так, чтобы они обрабатывались даже по медленному сетевому подключению. Папка Computer Conf iguration\Administrative Templates\System\Group Policy содержит и другие опции. Например, вы решите применить обработку политики обслуживания программы Internet Explorer по медленному сетевому подключению. Щелкните правой кнопкой мыши на этой установке в папке Group Policy (Групповая политика) и выберите Properties. Затем щелкните Enabled (Включено) и выберите, как вы хотите применять эту политику (см. рис. 11-14).



Рис. 11-14. Конфигурирование обработки политики обслуживания программы Internet Explorer по медленным сетевым подключениям

Чтобы применять эту политику независимо от сетевой пропускной способности, выберите Allow Processing Across A Slow Network Connection (Разрешить обработку по медленному сетевому подключению). Другие параметры настройки задают, будут ли параметры настройки обрабатываться каждый раз, когда обновляется групповая политика, и будет ли политика применяться в случае, если она не была изменена.

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

компьютерная политика применялась последней и переписывала все политики, примененные к пользователю. Групповая политика loopback устанавливается с помощью опции User group Policy Loopback Processing Mode (Режим Loopback для пользовательских групповых политик) в контейнере Computer Configuration\Administrative Templates\System\ Group Policy (см. рис. 11-15).





Рис. 11-15. Конфигурирование обработки loopback для групповых политик

Когда вы разрешаете обработку loopback, вам предоставляются две дополнительные опции конфигурации. Первая опция Merge (Соединить) означает, что сначала применяется компьютерная групповая политика, затем — пользовательская групповая политика, а затем компьютерная групповая политика применяется снова. Некоторые из пользовательских параметров настройки могут не изменяться компьютерной политикой. Переписываются только противоречивые параметры настройки. Вторая опция Replace (Заменить) означает, что будет обработана только компьютерная политика.

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

стол, поскольку групповая политика loopback защищает общественный компьютер.

Обслуживание базы данных Active Directory

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

Один или несколько лесов

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

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

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

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

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

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

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

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

Практический опыт. Вовлечение пользователей в проектирование леса

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

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

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

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

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



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

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

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

Практический опыт. Административная автономия и административная изоляция - за и против

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

Административная автономия означает, что вы имеете полный административный контроль над некоторыми компонентами леса на уровне леса, домена или OU. Однако это не подразумевает эксклюзивного управления. Например, вы имеете возможность полностью управлять своим доменом, но группа Enterprise Admins (Администраторы предприятия) также имеет административные разрешения на управление вашим доменом.

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

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



Однако если вам требуется административная изоляция, единственный способ достичь этого состоит в создании отдельных лесов. Причина этого частично связана с тем, как разработана Active Directory. Группа Enterprise Admins автоматически добавляется к местной группе Administrators каждого домена. Группа Domain Admins (Администраторы домена) имеет полный административный контроль над каждым объектом в домене и автоматически добавляется к группе Administrators на каждом компьютере в домене. В то время как заданная по умолчанию конфигурация может быть модифицирована, а группы могут быть удалены из административных групп низшего уровня, администраторы более высокого уровня всегда могут восстанавливать управление объектами низшего уровня. Это означает, что никакая часть леса не является административно изолированной.

Другая причина того, что отдельный лес может быть необходим для административной изоляции, состоит в возможности злонамеренных действий со стороны администраторов в домене. Любой человек с административным доступом к контроллеру домена может нарушить административную изоляцию любого другого раздела в лесу. Администратор может устанавливать программное обеспечение на контроллере домена, которое изменяет информацию каталога для всех доменов в лесу. Администратор может изменять сёой собственный идентификатор защиты (SID) так, чтобы казалось, что он является членом группы Enterprise Admins, а затем использовать этот доступ, чтобы сделать изменения, касающиеся всего леса.

Аналогично, если пользователь может выключить и перезапустить контроллер домена в режиме Directory Services Restore (Восстановление службы каталога), то он сможет изменить информацию в Active Directory так, что это затронет весь лес.

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



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

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

Помещение только администраторов с высоким уровнем доверия в группы, которые имеют административный контроль над контроллерами домена. Эти группы включают группу Domain Admins (Администраторы домена), а также локальные группы Administrators (Администраторы), Server Operators (Операторы сервера) и Backup Operators (Операторы резервного копирования). Административные задачи, которые не требуют доступа к контроллерам домена, должны быть делегированы другим группам.

Физическая защита контроллеров домена путем разрешения доступа к серверам только администраторам, имеющим высокий уровень доверия.

Аудит всех действий, выполняемых администраторами высокого уровня.

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

Односторонние доверительные отношения

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

зуются для оптимизации производительности работы между доменами, которые связаны транзитивными доверительными отношениями. Эти односторонние доверительные отношения называются укороченными доверительными отношениями (shortcut trusts). Укороченные доверительные отношения нужны в том случае, когда требуется частый доступ к ресурсам между доменами, которые удаленно связаны через дерево домена или лес. Примером этому является лес Contoso, изображенный на рисунке 2-9.

Рис. 2-9. Доверительные отношения в лесу Contoso

Если группа безопасности в домене Sales.Europe.Contoso.com часто обращается к общему ресурсу в домене Research.NAmerica.Contoso.com, то при наличии только транзитивных доверительных отношения между доменами пользователи в домене Sales.Europe.Contoso.com должны подтверждать подлинность в каждом домене дерева, расположенном между ними и доменом, который содержит ресурс. Такая организация работы неэффективна, если часто возникает потребность доступа к этим ресурсам. Укороченные доверительные отношения являются прямыми односторонними доверительными отношениями, которые дадут возможность пользователям в домене Sales.Europe.Contoso.com эффективно подтверждать подлинность в домене Research.NAmerica.Contoso.com без необходимости пересекать все дерево каталога, чтобы туда добраться. На рисунке 2-10 показаны эти прямые доверительные отношения. Если возникает потребность установить такие же доверительные отношения в другом направлении, можно создать прямые доверительные отношения между этими двумя доменами, взаимно изменив их роли. (Такие двойные прямые доверительные отношения кажутся транзитивными

отношениями, но эти исключительные доверительные отношения не простираются за пределы этих двух доменов).

Ограничение времени выполнения перехода

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

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

Хотя групповые политики обеспечивают мощные механизмы управления программным обеспечением на компьютерах клиентов, у этой технологии имеются некоторые ограничения. Эти ограничения очевидны при сравнении групповых политик с инструментами управления программным обеспечением Microsoft Systems Management Server (SMS) или LANDesk от Intel.

Одно из ограничений для многих компаний состоит в том, что групповые политики могут использоваться только для распределения программного обеспечения на клиентские компьютеры с системами Windows 2000 или Windows XP Professional. Хотя большинство компаний перешло на самые последние операционные системы, многие все еще используют системы Windows NT Workstation, Windows 95 или Windows 98 на клиентских компьютерах. Если такие компании захотят использовать

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

Более существенное ограничение состоит в недостатке гибкости групповых политик при назначении графика инсталляции программного обеспечения. Приложения не публикуются на рабочей станции до тех пор, пока пользователь не сделает новый вход в систему или пока не произойдет перезагрузка компьютера. Инструментальные средства распределения программ, обладающие полным набором функций, такие как SMS, имеют и другие опции. Например, вы можете сконфигурировать SMS или LANDesk для запуска компьютера в течение ночи, используя технологию wake-on-LAN, устанавливающую программное обеспечение с последующим выключением компьютера. Распределение программного обеспечений может быть намечено на любое время в течение дня, пользователю не обязательно даже выходить из системы, он может и не знать, что идет распределение программного обеспечения.

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

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

При использовании групповой политики для распределения программного обеспечения нельзя указать, какие именно клиенты должны получить пакет программ иным способом, кроме как через назначение объекта GPO на контейнерном уровне или через фильтрацию, основанную на группах. Более полнофункциональные инструменты распределения программного обеспечения (например, SMS и LANDesk) создают опись всех клиентских компьютеров. Она включает также такие компьютерные атрибуты, как объем пространства жесткого диска, характеристики процессора и оперативной памяти, а также список программно-

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

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

Таким образом, использование групповых политик для управления программным обеспечением не поддерживает желаемый набор функций. Однако для маленьких компаний и компаний среднего размера, у которых на большинстве компьютеров установлены системы Windows 2000 или Windows XP Professional, групповые политики могут решить многие проблемы, связанных с распределением программного обеспечения. И цена использования групповых политик безусловно оправдана, если сравнить ее с довольно дорогими затратами по лицензированию клиентов при использовании других инструментальных средств.

Онлайновая дефрагментация

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

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

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

Рис. 14-8. Сообщение журнала службы каталога, указывающее на успешную онлайновую дефрагмента-цию

Определение количества доменов

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

Определение подходящего пути перехода

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

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

Определение владельцев леса

Независимо от того, сколько развертывается лесов, для каждого леса вы должны идентифицировать его владельцев. В технических терминах просто определить, кто является владельцем леса. Группы Schema Admins (Администраторы схемы), Enterprise Admins (Администраторы предприятия) и Domain Admins (Администраторы домена) в корневом домене могут быть определены как владельцы леса, потому что они управляют теми изменениями, которые могут быть сделаны в лесу. Это роли чисто технические, и люди в этих группах почти не имеют окончательных полномочий на то, будут ли на самом деле сделаны модификации к лесу. Например, группа Schema Admins может изменять схему, но член группы Schema Admins обычно не имеет полномочий для принятия заключительного решения относительно того, будет ли запрос на изменение схемы одобрен.

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

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

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

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

Организационные единицы (OU - Organizational Unit) предназначены для того, чтобы облегчить управление службой Active Directory. OU используются для того, чтобы сделать более эффективным управление единственным доменом, вместо того чтобы иметь дело с управлением несколькими доменами службы Active Directory. OU служат для создания иерархической структуры в пределах домена. Домен может содержать сотни тысяч объектов. Управление таким количеством объектов без использования определенных средств организации объектов в логические группы затруднено. Организационные единицы выполняют именно эти функции. На рисунке 2-13 показан пример структуры OU в корпорации Contoso.

Рис. 2-13. Пример структуры организационных единиц

OU являются контейнерами объектов, содержащими несколько типов объектов службы каталога:

компьютеры;

контакты;

группы;

inetOrgPerson;

принтеры;

пользователи;

общедоступные папки;

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

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

Организационные единицы и проектирование Active Directory

Домены Windows NT используют неразветвленное пространство имен, т.е. все объекты в домене находятся на одном уровне. Нет никакого способа назначить административное управление одним объектом в домене без того, чтобы установить тот же самый уровень управления надо всеми другими объектами в каталоге. OU в Active Directory позволяют со-

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

Когда вы проектируете структуру OU, вы группируете объекты вместе с целью единообразного управления этой группой. Например, можно установить общий набор приложений для всех пользователей в определенном отделе. Группируя всех пользователей в OU, вы можете назначить групповую политику (Group Policy), которая автоматически установит требуемое программное обеспечение. Возможно, вы захотите сгруппировать объекты для назначения одного администратора этой группе. Например, если имеется отдаленный офис с местным администратором, можно создать OU, поместить всех пользователей и компьютеры отдаленного офиса в это подразделение, а затем делегировать администрирование этой OU местному администратору.

Организационные единицы характеризуются следующим.

Проектировани OU не оказывает влияния на проектирование пространства имен DNS. OU получают имена каталога в пределах пространства имен DNS. Например, организационная единица может иметь отличительное имя OU=ManagersOU,OU=AdministrationOU, DC=Contoso, DC=Com. В этом случае Contoso.com является DNS-име-нем, а LDAP-имена внутри пространства имен DNS являются именами OU.

Организационные единицы могут быть созданы внутри других единиц. По умолчанию административные права и параметры настройки Group Policy (Групповая политика), установленные на верхнем уровне единиц OU, наследуются дочерними OU. Это поведение может быть изменено.

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

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

Основные серверы имен

Основным сервером имен (Primary Name Server) является единственный сервер, имеющий перезаписываемую копию зонных файлов (зона на основном сервере имен называется основной зоной - primary zone). Это означает, что DNS-администратор должен иметь доступ к основному серверу имен всякий раз, когда нужно внести какие-либо изменения в зонную информацию. После того как внесены изменения, эти данные автоматически копируются на дополнительные серверы имен с помощью процесса, который называется зонной передачей.

Основы защиты Active Directory

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

Отключение групповых политик

Еще одна опция, которую можно использовать для изменения области приложения групповых политик, состоит в отключении групповой политики. Чтобы сделать это, обратитесь к окну Properties (Свойства) объекта GPO и выберите Options (Опции) (см. рис. 11-9). Путем отключения групповой политики можно предотвращать ее применение без необходимости изменять другие параметры настройки. Например, у вас есть групповая политика, которую требуется применять лишь время от времени, или групповая политика, которая находится в экспериментальной стадии. Вы можете создать групповую политику, связать ее с соответствующим контейнером, а затем отключить ее. При необходимости можно снова ее включить.

Отключение сжатия трафика репликации между различными сайтами

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

Открытые стандарты службы Active Directory

Чтобы удовлетворить растущие запросы службы каталога в неизменно плюралистической вычислительной среде современного предприятия, Microsoft должен был включить открытые вычислительные стандарты в свои NOS и в свою реализацию службы каталога. Представляется все более вероятным, что, в конечном счете, серверное пространство средних и больших организаций будет содержать разнообразные системы NOS, выполняющиеся на различных типах серверных аппаратных средств. Серверное пространство может включать серверы Windows и Novell Netware, выполняющиеся на платформах Intel, UNIX-платформы, выполняющиеся на базе аппаратных средств RISC (компьютеры с сокращенным набором команд), и серверы рабочих групп семейства Linux, выполняющиеся на любых платформах, к которым могут приложить руки администраторы. Для реализации этих систем NOS должны взаимодействовать с помощью общего языка или языков. Потребность в общих языках является основой для вычислительной техники открытых стандартов. Вместо напряженных усилий, прилагаемых в рамках старой парадигмы однородной серверной среды, использующей закрытые (лицензированные) реализации службы каталога, вычислительная среда современных предприятий стремится быть объединенной сетевой службой.

В следующих двух разделах рассматривается пара открытых стандартов, на которых основана Active Directory: иерархия пространства имен Х.500 и протокол LDAP.

Отметки об изменениях и разрешение конфликтов

И последнее, что используется для управления репликацией между контроллерами домена, — это отметка об изменении (change stamp). Всякий раз, когда атрибут модифицируется, эта модификация помечается отметкой об изменении. Затем отметка об изменении посылается вместе с модификацией, когда модификация копируется на другие контроллеры домена. Отметка об изменениях используется для того, чтобы определить, какое изменение будет принято в случае конфликта репликации. Отметка об изменениях состоит из трех компонентов.

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

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

Исходный сервер (Originating server). Этот компонент представляет собой GUID сервера, на котором была применена последняя исходная модификация атрибута.

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

Номер версии. Всегда принимается изменение с самым высоким номером версии. Если изменение на одном контроллере домена имеет номер версии 3, а изменение на другом контроллере домена - номер версии 4, будет всегда приниматься изменение с номером версии 4.

Время последней записи. Если номера версий идентичны, то будет принято изменение с самым недавним временем последней записи.

GXJID сервера. Если номера версий и времена последней записи идентичны, то используется GUID базы данных сервера для определения того, какое изменение должно быть принято. Будет принято изменение, прибывающее с сервера, имеющего более высокий GUID. Идентификаторы GUID назначаются при добавлении контроллера домена к домену, a GUID назначается произвольно.

Практический опыт. Конфликты репликации

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

Служба Active Directory способна разрешать конфликты, которые создаются, когда один и тот же атрибут объекта изменяется одновременно на двух контроллерах домена. Имеются два других типа конфликтов, которые могут возникать.

Добавление или изменение объекта на одном контроллере домена в то же самое время, когда контейнерный объект этого объекта удаляется на другом контроллере домена. Рассмотрим пример, в котором на одном контроллере домена был добавлен новый пользователь к организационной единице (OU) Accounting (Бухгалтерия). В это же время на другом контроллере домена другой администратор удаляет OU Accounting. В этом случае объект, который был добавлен к удаленному контейнеру, будет перемещен в контейнер Active Directory с именем LostAndFound.



Добавление объектов с одним и тем же относительным отличительным именем (relative distinguished name) в один и тот же контейнер. Такой конфликт возникает, когда администратор на одном контроллере домена создает пользовательский объект с относительным отличительным именем BDiaz в OU Accounting, в то же самое время на другом контроллере домена пользователь, имеющий такое же относительное отличительное имя, перемещается в ту же самую OU или создается в той же самой OU. В этом случае для определения того, какой объект будет сохранен, а какой переименован, в модели разрешения конфликтов будет использоваться GUID, назначенный модифицируемому каталогу. Объект, имеющий более высокий GUID, будет сохранен, а объект с более низким GUID переименован на BDiaz#CNF:userGUID, где значок номера (#) является символом дублирования. Если второй пользовательский объект потребуется, то его можно будет переименовать.

Отслеживание «здоровой» функциональности сервера с помощью системного монитора

Инструмент System Monitor (Системный монитор) включен в средства администрирования Performance. Используя этот инструмент, можно собирать и рассматривать в реальном масштабе времени данные функционирования местного компьютера или нескольких удаленных компьютеров. Системный монитор дает графическое представление тех же самых данных, которые отслеживаются с помощью инструмента Performance Logs And Alerts. Этот инструмент значительно облегчает определение тенденций в работе службы.

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

Memory\Pages/sec (Память\Страницы/с).

PhysicalDisk (_Total)\Avg. Disk Queue Length (Физический диск (__Тotа1)\средняя длина очереди к диску).

Processor (_Total)\%Processor Time (Процессор (_Totа1)\Время процессора).

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

Каждый из этих счетчиков показан в системе координат «время/работа» линией своего цвета. Они очень полезны для мониторинга системного «здоровья» сервера (в данном случае контроллера домена). На рисунке 14-4 показано заданное по умолчанию представление системного монитора.

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

Чтобы оптимизировать представление определенного счетчика, выберите описание счетчика, расположенное в нижней части окна, и щелкните на кнопке Highlight (Выделить) на инструментальной панели. Так вы измените график, соответствующий выбранному счетчику, представив его полужирной белой линией, чтобы его было легче рассматривать.

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

Можно сохранить параметры настройки графика системного монитора в виде HTML-страницы. Для этого сконфигурируйте график необходимыми счетчиками, щелкните правой кнопкой мыши на графике и выберите Save As (Сохранить как). График будет сохранен в виде файла HTML, который вы сможете открыть в браузере. Когда вы открываете

HTML- версию графика, дисплей замораживается. Чтобы перезапустить мониторинг, щелкните на кнопке Freeze Display, расположенной на инструментальной панели Performance в браузере.



Рис. 14-4. Счетчики функционирования, заданные по умолчанию в системном мониторе

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

В системе Windows Server 2003 имеются две новые группы безопасности, которые гарантируют, что только надежные пользователи могут получить доступ и управлять данными функционирования службы: группы Performance Log Users (Пользователи, регистрирующие работу) и Performance Monitor Users (Пользователи, выполняющие мониторинг).

Чтобы добавить дополнительные счетчики к системному монитору, выполните следующие действия.

Щелкните правой кнопкой мыши на панели деталей системного монитора, затем щелкните на Add Counters (Добавить компьютеры).

В диалоговом окне Add Counters щелкните на Use Local Computer Counters (Счетчики локального компьютера пользователя), чтобы отслеживать работу компьютера, на котором выполняется консоль мониторинга. Чтобы отслеживать работу определенного компьютера независимо от того, где выполняется консоль мониторинга, щелкните на Select Counters From Computer (Выбрать счетчик на компьютере) и укажите имя компьютера или его IP-адрес.

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

Щелкните на кнопке Add (Добавить), а затем щелкните на Close (Закрыть).

Передача ролей хозяина операций

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

хозяин схемы - оснастка Active Directory Schema;

хозяин именования доменов — инструмент администрирования Active Directory Domains And Trusts (Домены и доверительные отношения Active Directory);

хозяин RID, эмулятора PDC и инфраструктуры — инструмент администрирования Active Directory Users And Computers (Пользователи и компьютеры Active Directory).

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

Переход через обновление домена

Обновление домена, или «обновление на месте» (in-place), является самым простым путем перехода. Но определить это для вашей организации может оказаться весьма затруднительно. При обновлении домена существующая платформа службы каталога преобразуется в Active Directory одновременно с модернизацией контроллера домена до Windows Server 2003. Простота состоит в том, что вы не имеете возможности изменить структуру домена в процессе обновления. Если вы - администратор домена NAmerica в Contoso.com, представляющего среду Windows NT 4, то после обновления вы будете администратором домена NAmerica Windows Server 2003. При обновлении домена вы не сможете изменить структуру домена или доменное имя.

Примечание. В терминах процесса обновления исходным доменом (source domain) называется домен, который вы модернизируете, т.е. «пункт А». Доменная структура, к которой вы переходите, называется целевым доменом (target domain) - это «пункт Б». В сценарии обновления домена первоначальный домен считается исходным до момента окончания инсталляция Active Directory, с этого момента он становится целевым доменом.

Переход через обновление с последующей реструктуризацией

Переход через обновление с последующей реструктуризацией представляет собой комбинацию двух главных путей перехода. Сначала домен Windows NT 4 обновляется до Windows Server 2003 и службы Active Directory. Затем учетные записи реструктуризируются в новые или существующие домены Windows Server 2003. Этот метод сочетает сиюминутные выгоды от обновления домена (скорость, малый риск, высокий уровень автоматизации) с долгосрочными преимуществами от реструктуризации домена (создает новую модель домена, реализован в виде стадий, убирает старые и ненужные объекты учетных записей).

Обновление доменов от Windows NT 4 до Windows Server 2003 является наиболее целесообразным способом перехода. Процесс реструктуризации объектов учетных записей может быть выполнен через какое-то время, согласно вашему расписанию, ресурсам и бюджету. Он дает возможность сетевым администраторам познакомиться с новой службой каталога, прежде чем погрузиться в процесс перепроектирования домена или начать какой-либо опасный проект перехода. Этот путь выгоден конечным пользователям, поскольку их мир сетевых услуг не изменится внезапно: сначала они перейдут к новой NOS, а затем, через какое-то время, будет реструктуризирована модель домена.

Переход путем реструктуризации домена

При реструктуризации домена создается новая инфраструктура службы каталога Windows Server 2003, а затем объекты перемещаются в эту среду. Преимущество этого пути перехода состоит в том, что оригинал среды Windows NT 4 остается нетронутым во время создания целевой среды, известной также как «чистый» лес (pristine forest). Образ «чистого» леса, безусловно, привлекателен, его можно быстро заполнить объек-

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

Переименование домена

Active Directory теперь поддерживает переименование существующих доменов в пределах леса при сохранении глобально уникального идентификатора (GUID — Globally Unique Identifier) и идентификатора защиты (SID - Security Identifier) домена. Есть несколько сценариев, в которых это свойство полезно, включая слияние двух организаций, имеющих отдельные инфраструктуры Active Directory, которые хотят объединиться под одним именем домена, отражающим их внешнее зарегистрированное пространство имен. Переименование доменов не является тривиальной IT-процедурой. Это действие разрушительно с точки

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

Перемещение базы данных и места расположения журналов транзакций

Инструмент Ntdsutil может также использоваться для перемещения базы данных Active Directory и журналов транзакций. Например, если журналы транзакций и база данных находятся на одном и том же жестком диске, вы можете переместить один из компонентов на другой жесткий диск. Если жесткий диск, содержащий файл базы данных, заполнится, нужно будет переместить базу данных.

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

Откройте командную строку и напечатайте ntdsutil.

В командной строке Ntdsutil напечатайте files.

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

Чтобы переместить файл базы данных, в командной строке File Maintenance напечатайте move db to director, где dirеctorу задает новое место для файлов. Эта команда перемещает базу данных в указанное место и реконфигурирует системный реестр так, чтобы обращаться к файлу по его правильному месту расположения.

Чтобы переместить журнал транзакций, в командной строке File Maintenance напечатайте move logs to directory.

Перемещение доменов ресурсов

Чтобы переместить домены ресурсов, необходимо выполнить следующее.

Удовлетворить дополнительные требования защиты.

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

Переместить учетные записи компьютеров (серверы-члены домена и рабочие станции).

Переместить совместно используемые локальные группы.

Переместить учетные записи служб.

Прекратить эксплуатацию всех исходных доменов.

Перемещение доменов учетных записей

Домен учетных записей Windows NT 4 содержит учетные записи пользователей и групп, которые обращаются к сетевым ресурсам. Согласно сценарию перехода путем реструктуризацией домена вы будете перемещать объекты службы каталога в доменах учетных записей перед перемещением доменов ресурсов. Этот порядок операций предпочтителен, потому что при этом сохраняется доступ к ресурсам в процессе перехода.

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

Установите доверительные отношения между целевым доменом Windows Server 2003 и доменом ресурсов Windows NT 4.

Переместите учетные записи глобальной группы.

Переместите учетные записи пользователей (с паролями или без).

Это лучшая практика для перемещения домена учетных записей.

Перемещение общих локальных групп

Общие локальные группы (shared local groups) — это просто локальные группы на контроллере домена с Windows NT 4. Они используются для организации прав доступа. Если на вашем предприятии существуют такие группы, то вы должны перенести их на целевой домен для сохранения доступа к ресурсам для перемещенных пользователей. Процесс модернизации общих локальных групп не сильно отличается от процесса модернизации глобальных групп, который был описан выше.

Примечание. Модернизация локальных групп, расположенных на серверах-членах домена или рабочих станциях, не является необходимой. Эти локальные группы используются для предоставления доступа к ресурсам, находящимся на компьютере, и находятся в базе данных SAM на сервере-члене домена или на рабочей станции. Поскольку база данных SAM всегда перемещается с компьютером, то нет необходимости перемещать эти учетные записи. Вы должны перевести защиту для этих локальных групп, чтобы обновить ссылки SID для новых учетных записей домена. Посмотрите описание Computer Migration Wizard, приведенное выше в этой главе, для получения дополнительной информации о переводе защиты в процессе модернизации компьютера.

Чтобы переместить общие локальные группы, используя ADMT, выполните следующие действия.

Откройте Group Account Migration Wizard (Мастер модернизации учетных записей групп).

Выберите исходные и целевые домены.

Выберите общую локальную группу, которую нужно переместить.

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

Обязательно выберите опцию Migrate Group SIDs To Target Domain (Переместить SID группы в целевой домен).

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

Перемещение против клонирования

Учетные записи пользователей, групп, служб и компьютеров, называемые также участниками безопасности (security principals), обновляются от службы каталога SAM Windows NT 4 Server к Active Directory. Это обновление выполняется двумя способами: учетные записи могут быть или перемещены, или клонированы. При перемещении объекта первоначальный участник безопасности в исходном домене удаляется. Перемещение объекта - это деструктивный процесс, исходные объекты домена, необходимые для восстановления в случае сбоя, не сохраняются. Клонирование — это процесс создания нового, идентичного участника безопасности в целевом домене, основанном на объекте исходного домена. Предпочтительным методом передачи участников безопасности в чистый лес Windows Server 2003 является клонирование. Перемещение участников безопасности, как правило, производится при переходе между двумя лесами Windows Server 2003 или между лесом Windows 2000 и лесом Windows Server 2003.

Сценарий перехода, связанный с обновлением и последующей реструктуризацией, приведен в разделе «Обновление и реструктуризация» в этой главе.

Практический опыт. Понимание атрибута SID-History

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

Рассмотрим пример. Во время реструктуризации домена вы переносите пакет учетных записей пользователей из домена Windows NT 4 в домен Windows Server 2003. После завершения переноса вы инструктируете пользователей, как входить в новый домен и сбрасывать свои пароли. Допустим, пользователь X успешно входит на целевой домен, а затем пытается обратиться к существующей ранее общей папке файлового сервера, на котором выполняется система Windows NT 4 Server, с которой он работал в течение нескольких месяцев. Сможет ли пользователь X обратиться к этой папке?

Да, и это возможно благодаря атрибуту SID-History.

SID-History является атрибутом участников безопасности Active Directory, который используется для хранения старых идентификаторов защиты (SID) объекта. Если пользователь X имел в домене Windows NT 4 идентификатор SID, равный S-1-5-21-2127521184-1604012920-18879275 27-324294, то такое же значение появится в поле атрибута SID-History для созданного объекта учетной записи Windows Server 2003. При перемещении группы из домена Windows NT 4 в домен Active Directory SID домена Windows NT 4 сохраняется в атрибуте SID-History данной группы. При перемещении пользователей и групп учетные записи пользователя автоматически назначаются членами групп, перенесенных в домен Windows Server 2003. Это значит, что права доступа, назначенные для группы в домене Windows NT 4, сохраняются в процессе перехода. Новый SID, сгенерированный целевым контроллером домена, помещается в атрибут SID перемещенной учетной записи.

Каким образом сохраняется доступ к ресурсам? Когда пользователь X пытается обратиться к общей папке, расположенной на файловом сервере Windows NT 4, подсистема защиты проверяет его лексему доступа, чтобы удостовериться в наличии необходимых разрешений на доступ к папке. Лексема доступа содержит не только SID пользователя X и SID всех групп, к которым он принадлежит, но и все входы SID-History самого пользователя и учетных записей его групп. Если найдено соответствие между дискреционным списком управления доступом (DACL -discretionary access control list) на дескрипторе защиты папки и предыдущим SID (теперь включенным в лексему доступа с помощью атрибута SID-History), то выдается разрешение на доступ к папке.

Как много из всего этого должен знать конечный пользователь? Ничего. Как много должны знать вы, как системный администратор? Вам следует знать все. Доступ к ресурсам — это наиболее проблемная область переноса учетных записей пользователя. Понимая то, как поддерживаются разрешения после перехода, вы как администратор можете эффективно решать проблемы, возникающие при доступе к ресурсам. В процессе перехода вам, возможно, придется дополнительно поработать для гарантии того, что поле SID-History заполнено. Вы узнаете больше при исследовании утилиты Active Directory Migration Tool (Инструмент перехода к Active Directory, ADMT).

Как работает атрибут SID-History в сценарии обновления домена? Ответ: он не работает. При обновлении домена поддерживаются SID учетных записей групп и пользователей. Пользователь X сможет нормально обращаться к ресурсам. Как SID-History работает в сценарии обновления с последующей реструктуризацией? Ответ: так же, как в сценарии с простым обновлением домена, т.е. доступ к ресурсам сохраняется за счет поддержки первоначального SID объекта в атрибуте SID-History. Единственное различие состоит в том, что Active Directory требует, чтобы идентификаторы SID появлялись в лесу только один раз, включая оба поля: SID и SID-History. В результате в сценарии обновления с последующей реструктуризацией участники безопасности должны быть перенесены, а не клонированы.

Перемещение учетных записей глобальных групп

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

та новой группы. Сохраняя SID исходного домена в поле SID-History, пользователи могут продолжать обращаться к ресурсам, расположенным в домене ресурсов с Windows NT, которые еще не перемещены.

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

Процесс перемещения глобальных групп с Windows NT 4 на Windows Server 2003 при помощи Group Account Migration Wizard (Мастер модернизации учетных записей групп) инструмента ADMT несложен.

Чтобы перенести глобальные группы с Windows NT 4 на Windows Server 2003 с помощью Group Account Migration Wizard, выполните следующие действия.

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

Выберите глобальные группы Windows NT 4, которые вы хотите переместить на Windows Server 2003.

Выберите OU, к которой вы хотите добавить глобальные группы в целевом домене.

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

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

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

---

---