Управление пользовательскими профилями

Пользовательский профиль содержит всю конфигурационную информацию для рабочего стола пользователя. Эта информация включает содержание поддерева HKEY_CURRENT_USER в системном реестре (хранящееся как файл Ntuser.dat), который включает параметры настройки конфигурации для приложений и рабочего стола. Кроме того, профиль содержит папки My Documents (Мои документы), Start Menu (Меню Пуск), Desktop (Рабочий стол) и Application Data (Данные приложений). На рисунке 13-2 показано содержимое пользовательского профиля на компьютере с системой Windows Server 2003.

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

Пользовательский профиль создается на каждом компьютере, когда пользователь первый раз входит в систему. Начальный профиль основан на заданном по умолчанию пользовательском профиле, который хранится в папке %systemdrive%\Documents And Settings. Когда пользователь выходит из системы, профиль пользователя, включая любые сделанные им изменения к заданному по умолчанию, сохраняется в папке с именем, под которым пользователь входил в систему, в папке Documents And Settings (Документы и параметры настройки). Когда пользователь снова войдет на тот же самый компьютер, его профиль будет найден, и пользователю будет представлен тот же самый рабочий стол, который был перед выходом из системы. Некоторые компании реализовали роу-минговые профили пользователя. Роуминговые пользовательские профили хранятся на сетевом ресурсе, чтобы быть доступными пользователю, когда он перемещается между компьютерами. Когда пользователь, для которого сконфигурирован роуминговый профиль, впервые входит на компьютер, этот профиль загружается с сетевого ресурса и применяется к компьютеру. Когда пользователь выходит из системы, сделанные им изменения к пользовательскому профилю копируются назад на сетевой ресурс. Копия профиля также кэшируется на местной рабочей станции. Если пользователь уже входил на рабочую станцию прежде, то временная метка профиля, хранящегося на местной рабочей станции, сравнится с временной меткой профиля, хранящегося на сетевом ресурсе. В системах Windows 2000 и Windows XP Professional временная метка на индивидуальных файлах используется для определения того, какой из файлов профиля является более новым. Если профиль, хранящийся на сервере, новее, чем местный профиль, то весь профиль будет скопирован с сервера на местную рабочую станцию. Включить роуминговый профиль пользователя можно, конфигурируя путь профиля на вкладке Profile (Профиль) окна Properties (Свойства) учетной записи пользователя в инструменте Active Directory Users And Computers (Пользователи и компьютеры Active Directory).

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

Ntuser.dat в Ntuser.man. Далее сконфигурируйте всех необходимых пользователей, чтобы этот профиль был их роуминговым профилем. Когда пользователи войдут в сеть, им будет представлен стандартный профиль, и поскольку этот профиль является принудительным, они не смогут сохранить никакие изменения, сделанные к нему.

Роуминговые пользовательские профили существуют и в Windows Server 2003. Если в вашей компании реализованы роуминговые или принудительные пользовательские профили, можно продолжать их использование. Для управления пользовательскими профилями используются групповые политики. Большинство пользовательских параметров настройки профиля расположено в папке Computer Configuration\ Administrative Templates\ System\User Profiles. Дополнительные параметры настройки расположены в подпапке того же названия в разделе параметров User Configuration. В таблице 13-2 объясняются опции конфигурации.

Табл. 13-2. Конфигурирование пользовательских профилей с помощью редактора объектов групповой политики

Опция конфигурации	Пояснение
Do Not Check For User Ownership Of Roaming Profile Folders (He проверять право собственности пользователя на папки роу-минговых профилей)	Используется для конфигурирования действий в случае, если папка роуминговых профилей пользователя уже существует и рабочие станции модернизированы до Microsoft Windows 2000 Service Pack 4 или Microsoft Windows XP Professional Service Pack. Эти новые сервисные пакеты увеличивают заданную по умолчанию защиту пользовательских профилей. Включение этой опции означает, что поддерживается более ранняя защита.
Delete Cached Copies Of Roaming Profiles (Удалить кэширован-ные копии роуминго-вых профилей)	Используется для удаления в местном масштабе кэшированной копии роумингового профиля пользователя, когда пользователь выйдет из системы. Не включайте эту опцию, если вы используете функцию обнаружения медленных связей в системах Windows 2000 или Windows XP Professional, потому что этой функции требуется локально кэшированная копия пользовательского профиля.
Do Not Detect Slow Network Connections (He обнаруживать медленные сетевые подключения)	Используется для предотвращения использования функции обнаружения медленных связей при конфигурировании способов управления роуминговыми профилями пользователя. Если опция включена, то роуминговые профили пользователей будут загружаться всегда, независимо от скорости передачи в сети.
Slow Network Connection Timeout For User Profiles (Лимит времени в медленном сетевом подключении для пользовательских профилей)	Используется для определения медленного сетевого подключения. Если опция включена, то заданное по умолчанию определение медленного сетевого подключения - менее 500 Кб/с, или (для компьютеров, не использующих IP-адрес) если серверу на ответ требуется более 120 мс.
Wait For Remote User Profile (Ждать удаленный пользовательский профиль)	Используется для того, чтобы всегда загружать роуминговый профиль пользователя с сервера. Если опция включена, рабочая станция загрузит пользовательский профиль, даже если будет обнаружено медленное сетевое подключение.
Prompt User When Slow Link Is Detected (Предупредить пользователя, если обнаружены медленные связи)	Используется для предупреждения об обнаруженном медленном сетевом подключении, чтобы дать пользователю возможность выбора между загрузкой местного профиля или профиля, расположенного на сервере. Если опция не включена, местный профиль будет загружен без уведомления пользователя.
Timeout For Dialog Boxes (Лимит времени для диалоговых окон)	Используется для конфигурирования времени ожидания система после того, как пользователь будет предупрежден об обнаружении медленного сетевого подключения. Если лимит времени истекает, то применяется заданное по умолчанию значение или действие, связанное с диалоговым окном.
Log Users Off When Roaming Profile Fails (Предотвратить вход пользователей, если роуминговый профиль не доступен)	Используется для запрета входа пользователей в систему, если роуминговый профиль недоступен. Если опция не включена, будет загружен профиль, котируемый в местном масштабе, если он доступен. (Иначе загружается местный заданный по умолчанию пользовательский профиль.)
Maximum Retries To Unload And Update User Profile (Максимальное количество повторных попыток для выгрузки и обнов-	Используется для конфигурирования количества попыток системы обновить файл Ntuser.dat, когда пользователь выходит из системы и обновление терпит неудачу. По умолчанию система будет пробовать обновить файл один раз в секунду в течение 60 с.
Add The Administrators Security Group To Roaming User Profiles (Добавьте группу безопасности администраторов к роуминговым профилям пользователей)	Используется для конфигурирования административного доступа к пользовательским профилям. По умолчанию в системах Windows 2000 и Windows XP Professional учетной записи пользователя дается полное управление профилем, а администраторы не имеют никакого доступа
Prevent Roaming Profile Changes From Propagating To The Server (Предотвратить перемещение изменений роумингового профиля на сервер)	Используется для конфигурирования действий при выходе пользователя из системы. Если эта опция включена, то роуминговый профиль на сервере не модифицируется, когда пользователь выходит из системы.
Only Allow Local User Profiles (Разрешить только местные пользовательские профили)	Используется для конфигурирования того, будут ли роуминговые профили пользователя скопированы с сервера. Если опция включена, роуминговый профиль пользователя не будет применяться
Connect Home Directory To Root Of The Share (Подключить домашний каталог к корню ресурса) (в разделе User Configuration)	Используется для конфигурирования отображения домашнего диска так, как он был сконфигурирован в Windows NT. Если опция включена, то домашним диском' для всех пользователей будет сетевой ресурс, на котором расположены домашние папки пользователей. Если опция отключена (задано по умолчанию), домашние диски б^удут отображать специфичные для пользователя папки, а не ресурс более высокого уровня.
Limit Profile Size (Ограничить размер профиля) (в разделе User Configuration)	Используется для ограничения размера роумингового профиля пользователя, а также для конфигурирования того, какое предупреждение получит пользователь, если размер его профиля будет превышен.
Exclude Directories In Roaming Profile (Исключить каталоги из роуминговых профилей) (в разделе User Configuration)	Используется для предотвращения включения определенных пользовательских каталогов в роуминговый профиль пользователя.

<


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

Роуминговые пользовательские профили полезны для компаний, в которых пользователи не пользуются все время одним и тем же компьютером. Когда функция роуминговых профилей включена, рабочая среда пользователя остается одной и той же, независимо от того, в каком месте пользователь входит в систему. Однако роуминговые профили пользователя имеют некоторые ограничения. Самая большая проблема состоит в том, что пользовательский профиль может стать очень большим. Например, пользователь хранит большинство своих документов в папке My Documents (Мои документы) или на рабочем столе. Временные интернет-файлы могут вырастать до размеров, составляющих десятки мегабайт. Все эти файлы сохраняются в пользовательском профиле. Проблема заключается в том, что весь профиль должен быть скопирован на локальную рабочую станцию всякий раз, когда пользователь входит в систему, и компьютер обнаруживает, что профиль, находящийся на сервере, новее, чем профиль, находящийся на локальной рабочей станции. Если пользователь делает изменения профиля, то при выходе профиль копируется назад на сервер. Этот процесс создает существенный объем сетевого трафика.

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

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

Рис. 13-1. Контейнеры высшего уровня в Default Domain Policy (Заданная по умолчанию политика домена)

Табл. 13-1. Контейнеры высшего уровня в заданной по умолчанию политике домена

Контейнер высшего уровня		Дочерние контейнеры		Содержимое
Computer Configuration and User Configuration (Компьютерная и пользовательская конфигурация)		Software Settings (Параметры настройки программного обеспечения)		Содержит параметры настройки для пакетов программного обеспечения, используемых для распределения программ.
Computer Configuration and User Configuration (Компьютерная и пользовательская конфигурация)		Windows Settings\ Scripts (Параметры настройки Windows\Сценарии)		Содержит сценарии запуска и выключения для компьютеров и сценарии входа в систему и выхода из нее для пользователей.
Computer Configuration and User Configuration (Компьютерная и пользовательская конфигурация)		Windows Settings\ Security Settings (Параметры настройки Windows\ Параметры настройки защиты)		Содержит параметры настройки, используемые для конфигурирования защиты компьютера. Некоторые параметры настройки специфичны для доменного уровня, а некоторые можно установить на контейнерном уровне. Большинство параметров настройки защиты конфигурируются в разделе компьютерной конфигурации
User Configuration (Пользовательская конфигурация)		Windows Settings\ Folder Redirection (Параметры настройки Windows \Пере-назначение папки)		Содержит параметры настройки, которые переадресовывают пользовательские папки, такие как папки My Documents (Мои документы), на сетевой ресурс.
User Configuration (Пользовательская конфигурация)		Windows Settings\ Remote Installation Services (Параметры настройки Windows \Служба удаленной инсталляции)		Содержит отдельную опцию конфигурации для службы удаленной инсталляции (RIS).
User Configuration (Пользовательская конфигурация)		Windows Settings\ Internet Explorer Maintenance (Параметры настройки Windows\Обслуживание Internet Explorer)		Содержит параметры настройки для управления конфигурацией приложения Microsoft Internet Explorer на пользовательских рабочих столах.
Computer Configuration and User Configuration (Компьютерная конфигурация и пользовательская конфигурация)		Administrative Templates (Административные шаблоны)		Содержит большое количество конфигурационных параметров настройки, которые могут использоваться для конфигурирования системного реестра компьютера.

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

Условная переадресация

Условная переадресация (conditional forwarding) значительно увеличивает возможности процесса переадресации. До выхода Windows Server 2003 в процессе переадресации нельзя было делать различий, основанных на именах домена. Когда клиент-преобразователь делал запрос, на который сервер не мог ответить с помощью своего кэша или зонных файлов, сервер посылал рекурсивный запрос по своему списку конфигурированных ретрансляторов. Не было возможности сконфигурировать ретранслятор так, чтобы он был чувствителен к специфике домена. Условная переадресация обеспечивает как раз такой тип осмысления: DNS-cep-вер может теперь передавать запросы домена на различные серверы DNS, учитывая имя домена.

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

С помощью Windows Server 2003 серверы DNS в каждом домене могут быть сконфигурированы с условным ретранслятором, переадресующим запросы на один или более серверов DNS в других доменах. Когда один из серверов DNS разрешает имя из другого домена, он может использовать только тот ретранслятор, который сконфигурирован для этого домена. Например, когда клиент в домене Contoso.com должен найти ресурс в домене Fabrikam.com, он делает запрос DNS-серверу домена Contoso.com. DNS-сервер проверяет свои зонные файлы, чтобы определить, является ли он полномочным сервером для этого домена, а затем проверяет свой кэш. Если он не сможет разрешить имя с помощью этих источников, он проверит список ретрансляторов. Один из ретрансляторов определен для домена Fabrikam.com, так что DNS-сервер Contoso.com пошлет рекурсивный запрос только этому серверу DNS. Если нет никаких условных ретрансляторов для домена Fabrikam.com, сконфигурированных на сервере DNS Contoso.com, то он отправит запрос любому ретранслятору, который сконфигурирован без каких-либо определенных параметров настройки домена, а затем попробует использовать корневые ссылки.

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

Условная переадресация конфигурируется в окне Properties (Свойства) сервера в административном инструменте DNS (см. рис. 3-8). С его помощью вы можете сконфигурировать один или более контроллеров домена в качестве ретрансляторов для каждого имени домена. Если вы конфигурируете несколько серверов DNS для имени домена, то DNS-сервер будет пытаться использовать первый DNS-сервер в списке. Если этот сервер не отвечает в течение заданного значения интервала тайма -ута, которое устанавливается на вкладке Forwarders (Ретрансляторы), то сервер будет пробовать использовать следующий DNS-сервер из списка, пока не будут запрошены все имеющиеся в списке DNS-серверы. Если никаких условных ретрансляторов, сконфигурированных для имени домена, в списке нет, то сервер будет запрашивать серверы DNS, определенные в опции All Other DNS Domains (Другие домены DNS).



Рис. 3-8. Конфигурирование условных ретрансляторов

При использовании условной переадресации DNS-сервер всегда будет пробовать найти соответствие наиболее точному имени домена. На-

пример, если имеются условные ретрансляторы, сконфигурированные для Fabrikam.com и для Europe.Fabrikam.com, а клиент делает запрос о сервере Webl.Europe.Fabrikam.com, то DNS-сервер отправит запрос на DNS-сервер для Europe.Fabrikam.com.

Усовершенствование репликации группового членства

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

Усовершенствование UI-селектора объектов

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

Усовершенствования в оснастке Active Directory Users And Computers

Имеется два приятных изменения в оснастке Active Directory Users And Computers (Active Directory: пользователи и компьютеры). В Windows Server 2003 эта оснастка позволяет администратору сохранять запросы. Администраторы могут делать поиск в каталоге по определенному атрибуту, сохранять запрос, а затем выполнять его снова в будущем для анализа или поиска неисправностей. Например, администратор может сохранять результаты поиска любого пользовательского объекта, который имеет пароль с неограниченным временем действия (Account Options: Password Never Expires - опции учетной записи: пароль с неограниченным временем действия), а затем периодически пользоваться этим поиском, чтобы следить за наличием такого пароля, представляющего потенциальный риск для безопасности.

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

Установка Active Directory из восстановленных резервных файлов

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

Процесс установки из резервной копии не предназначен для восстановления существующих контроллеров домена в случае их отказов. Для выполнения этой задачи используется метод восстановления состояния системы. После того как контроллер домена будет синхронизирован с помощью восстановленных резервных данных, произойдет репликация, обновляющая новый контроллер домена всеми изменениями, которые произошли с момента создания резервного набора данных. Чтобы уменьшить время репликации, всегда используйте недавнюю копию резервных данных Active Directory. Резервный набор не может быть старше, чем время жизни объектов-памятников домена, который имеет заданное по умолчанию значение 60 дней. Резервная копия состояния системы должна быть взята с контроллера домена Windows Server 2003 в пределах того же самого домена, в котором создается новый контроллер домена; резервные копии с контроллера домена Windows 2000 несовместимы. Последнее ограничение состоит в том, что резервный файл должен быть восстановлен на локальный диск, и обращаться к нему нужно как к диску, обозначенному буквой логического имени (пути UNC и отображаемые диски (mapped drives) недопустимы в качестве части параметра /adv). Для получения дополнительной информации о создании резервной копии разделов Active Directory см. гл. 15.

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

Создайте и проверьте резервную копию System State (Состояние системы) на контроллере домена в домене. Восстановите эту резервную копию на локальный диск или в другое место в сети, где к ней можно обращаться (через букву — имя диска) с сервера, на котором выполняется Windows Server 2003 и который должен быть назначен контроллером домена.

На сервере запустите мастер инсталляции Active Directory из командной строки или диалогового окна Run, используя параметр /adv — напечатайте dcpromo / adv.

В окне Domain Controller Type (Тип контроллера домена) выберите Additional Domain Controller For An Existing Domain (Дополнительный контроллер домена для существующего домена).

В окне Copying Domain Files (Копирование файлов домена) выберите место расположения восстановленных резервных файлов.

В окне Copy Domain Information (Копирование информации домена) выберите место расположения восстановленных резервных файлов для этого домена.

Заполните остальные пункты мастера инсталляции Active Directory так, как описано в предыдущих разделах.

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

Дополнительная информация. Для организаций со множеством маленьких отдаленных сайтов, связанных медленными связями с центральным сайтом или центром данных, развертывающих Active Directory, смотрите документ «Active Directory Branch Office Guide» (Руководство по созданию Active Directory для филиалов) по адресу http://www.microsoft.com/windows2000/ techinfо/planning/activedirectory/branchoffice/default.asp. Этот документ включает руководства по планированию и развертыванию, предназначенные помочь вам в проектировании стратегии развертывания Active Directory в сценарии с несколькими филиалами. В руководствах содержатся также пошаговые инструкции реализации этой стратегии.

Установка Active Directory Migration Tool

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

Инструмент ADMT версии 2.0, имеющийся на компакт-диске Windows Server 2003, поддерживает следующие задачи, необходимые для модернизации домена:

перемещение учетных записей пользователей;

перемещение учетных записей групп;

перемещение учетных записей компьютеров;

перемещение учетных записей служб;

перемещение доверительных отношений;

перемещение каталога Exchange;

перевод защиты на мигрированные учетные записи компьютеров;

сообщения о просмотре результатов модернизации;

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

Одно из» преимуществ ADMT по сравнению с другими инструментами состоит в том, что это средство включено в продукт Windows Server 2003. Инсталляционная папка расположена на компакт-диске Windows Server 2003 в папке \I386\ADMT.

Дополнительная информация. Вместе с инсталляционными файлами ADMT папка ADMT на компакт-диске Windows Server 2003 содержит документ Readme.doc, в котором хранится важная информация, касающаяся ADMT. Обязательно прочтите этот документ перед установкой инструмента ADMT или его использованием. Наиболее свежую версию этого документа смотрите на веб-сайте Windows 2000 Active Directory Migration Tool по адресу: http://www.microsoft.com/windows2000/downloads/ tools/admt/default.asp. С этого сайта можно также загрузить сам инструмент ADMT. Убедитесь, что он совпадает или является более новым, чем версия, имеющаяся на компакт-диске Windows Server 2003.

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

Откройте папку \I386\ADMT на компакт-диске Windows Server 2003.

Дважды щелкните на файле Admigration.msi, чтобы установить ADMT на вашем компьютере.

Примите лицензионное соглашение и заданные по умолчанию параметры на страницах мастера.

После того как инструмент ADMT будет установлен, его можно запустить из папки Administrative Tools (Средства администрирования) в

меню Start (Пуск). Инструмент ADMT запускается как оснастка ММС вместе со всеми мастерами, доступными из меню Action (Действие) (см. рис. 7-3).



Рис. 7-3. Мастера, доступные в инструменте ADMT Разрешение аудита в исходных и целевых доменах

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

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

Откройте инструмент администрирования Active Directory Users And Computers (Пользователи и компьютеры Active Directory), щелкните правой кнопкой мыши на контейнере Domain Controllers (Контроллеры домена) и выберите Properties (Свойства).

В окне Domain Controllers Properties (Свойства контроллера домена) выберите вкладку Group Policy (Групповая политика).

Выберите Default Domain Controllers Policy (Заданная по умолчанию политика контроллеров домена) и щелкните на кнопке Edit (Правка).

Раскройте пункт Default DomainControllers Policy\Computer Conf iguration\ Windows Settings\Security Settings\Local Policies\ Audit Policy (Заданная по умолчанию политика контроллеров домена\Кон-фигурация компьютера\Параметры настройки Windows\ Параметры настройки защиты\Локальные политики\Политика аудита), дважды щелкните на Audit Account Management (Управление аудитом учетных записей), а затем выберите обе опции: Success (Успех) и Failure (Отказ).

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

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

Откройте инструмент администрирования User Manager For Domains (Менеджер пользователей для доменов), выберите Policies (Политики), а затем выберите Audit (Аудит).

Проверьте, что опция Audit These Events (Проводить аудит этих событий) выбрана и что для User And Group Management (Управление пользователями и группами) выбраны опции Success (Успех) и Failure (Отказ). Кроме того, нужно создать новую локальную группу на исходном контроллере домена для целей внутреннего аудита ADMT. Имя этой новой группы — sourcedomainname$$$ (например, Contoso$$$). ADMT создаст группу автоматически при первом запуске, если вы не создадите ее заранее.

Установка настраиваемых пакетов программ

Иногда компании может понадобиться настройка инсталляции пакета программ, даже если он поставляется с «родным» пакетом инсталлятора Windows. Например, требуется создать настроенную инсталляцию своего приложения, предназначенного для обработки текстов, чтобы включить в него собственные словари или шаблоны. Или настроить инсталляцию приложения Microsoft Office, чтобы на каждом рабочем столе устанавливались только Microsoft Word и Microsoft Excel, а полный пакет развертывался лишь для определенных пользователей. Если вы работаете в международной компании, вам потребуется развернуть одно и то же приложение на нескольких языках.

Вы можете настроить инсталляцию пакета программ, создавая файл преобразования (.mst). В дополнение к файлу .msi файл преобразования содержит команды настройки инсталляции. Самый легкий способ созда-

ния файла .mst состоит в использовании специально предназначенных для этого инструментов, если они предоставлены изготовителем программы. Например, Microsoft включает Custom Installation Wizard (Мастер выборочной инсталляции) в комплекты ресурсов Microsoft Office 2000 Resource Kit и Microsoft Office XP Resource Kit. После запуска мастера нужно выбрать файл .msi, имя и место расположения файла .mst. Тогда мастер представляет все опции, предназначенные для настройки заданной по умолчанию инсталляции программного обеспечения. Вы можете настроить практически каждый аспект инсталляции, включая удаление предыдущих версий Microsoft Office, выбор устанавливаемых компонент и место установки компонентов. Можно переносить пользовательские параметры настройки, если инсталляция представляет собой обновление существующего программного обеспечения, или выборочно сконфигурировать персональные параметры настройки и параметры настройки защиты. Можно добавлять дополнительные файлы к инсталляции (например, собственные шаблоны), Создавать или удалять ключи системного реестра, добавлять или удалять ярлыки к приложениям Microsoft Office и конфигурировать параметры настройки электронной почты клиента.

После создания файла преобразования нужно создать новый пакет программ для развертывания выборочной инсталляции. Для этого при выборе метода развертывания выберите опцию Advanced (Дополнительно) для добавления файла преобразования, прежде чем создание пакета будет закончено. В окне Properties (Свойства) пакета программ выберите вкладку Modifications (Модификации), а затем добавьте файлы преобразования. На рисунке 12-5 показана вкладка Modifications.



Рис. 12-5. Добавление файлов преобразования к пакету программ

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

Установление базовых уровней и порогов

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

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

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

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

Установление доверительных отношений

Чтобы сохранить доступ к ресурсам для пользователей, нужно создать односторонние доверительные отношения от каждого домена Windows NT 4, содержащего ресурсы, к которым должны обращаться перемещенные пользователи, к целевому домену Windows Server 2003. Создание доверительных отношений состоит из двух шагов.

Первый шаг выполняется на контроллере целевого домена с Windows Server 2003. Добавьте каждый домен ресурсов с системой Windows NT 4 к списку Domains That Trust This Domain (Домены, которые доверяют этому домену) в окне Properties (Свойства) целевого домена, используя инструмент Active Directory Domains And Trusts. Чтобы защитить эти доверительные отношения, создайте пароль, который потребуется при формировании второй половины доверительных отношений.

Второй шаг выполняется на PDC домена ресурсов с системой Windows NT 4. С помощью User Manager For Domains (Менеджер пользователей для доменов) добавьте целевой домен Windows Server 2003 к разделу Trusted Domains (Доверенные домены). Чтобы выполнить эту задачу, вам потребуется пароль, созданный на первом шаге. Будет получено сообщение о статусе, если доверительные отношения успешно создадутся.

Увеличение бюджета проекта модернизации

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

Варианты инсталляции Active Directory

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

Существует несколько способов запуска процесса инсталляции Active Directory:

Configure Your Server Wizard (Мастер конфигурирования сервера);

Active Directory Installation Wizard (Мастер инсталляции Active Directory);

инсталляция без сопровождения.

Варианты проекта пространства имен

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

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

Рис. 5-7. Проект пространства имен DNS в отсутствие инфраструктуры DNS

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

Вопрос использования внутреннего пространства имен, отличного от внешнего, может вызвать дискуссии в компании. В некоторых случаях лучше использовать различные пространства имен, но владельцы компании могут оказывать сильное сопротивление использованию чего-либо, отличного от пространства имен интернета. Часто причина для этого — торговая марка; некоторые компании потратили годы и миллионы долларов, создавая торговую марку, которую клиенты хорошо знают, вебсайты компании и адреса SMTP для всех пользователей отражают это пространство имен. Некоторые компании имеют признанные обществом идентификаторы при наличии несколько деловых подразделений в пределах компании, каждое из которых обладает собственной торговой маркой. В большинстве случаев деловые пользователи не хотят показывать внешнему миру имя, отличное от их распознаваемого имени компании. Хорошая новость состоит в том, что вы можете использовать различные внутреннее и внешнее пространства имен, а внешне поддерживать только одно пространство имен. Например, Contoso мог бы использовать Contoso.net как внутреннее пространство имен и Contoso.com как публичное пространство имен. Внутреннее пространство имен может быть полностью скрыто от всех, кроме сетевых администраторов. Адреса SMTP для пользователей могут быть alias@contoso.com, а веб-серверы могут использовать веб-индекс Contoso.com. Если нужно, то UPN для пользователей может быть сконфигурирован как alias@contoso.com, несмотря на использование другого внутреннего пространства имен.

На рисунке 5- 7 показано, как серверы DNS сконфигурированы по этому сценарию. DNS-сервер Contoso.com является официальным (authoritative) для своего домена и содержит записи делегирования на NAmerica.Contoso.com и Europe.Contoso.com, а также условные ретрансляторы и сокращенные зоны для домена Fabrikam.com. DNS-сервер Fabrikam.com является официальным для своей зоны и содержит условные ретрансляторы и сокращенные зоны для Contoso.com. Чтобы разрешать адреса интернета, серверы корня дерева должны быть сконфигурированы с ретранслятором, указывающим на сервер в интернете, или с корневыми ссылками интернета.

Проектирование DNS усложнится, если у вас есть внутренняя инфраструктура DNS. В этом случае существуют три варианта для объединения с текущей инфраструктурой. Первый вариант состоит в использовании только текущей инфраструктуры DNS для Active Directory, включая имя домена. Например, Contoso может использовать Contoso.net как свое внутреннее пространство имен, а DNS-серверы BIND — для обеспечения службы DNS. Компания может взять Contoso.net как имя домена Active Directory и продолжать использовать текущие серверы DNS (при условии, что они поддерживают SRV-записи указателей служб). В качестве альтернативы компания может использовать то же имя домена, но переместить службу DNS на DNS-сервера, на которых выполняется Windows Server 2003. В любом случае требуется очень небольшая реконфигурация DNS-серверов. Серверы DNS могут продолжать использовать те же самые ретрансляторы или корневые ссылки для разрешения имен в интернете.

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



Второй вариант при наличии инфраструктуры DNS состоит в выборе различных DNS-имен для доменов Active Directory. Например, Contoso может использовать Contoso.net как текущее внутреннее пространство имен DNS и развернуть домены Active Directory, использующие AD.Contoso.net как имя домена (см. рис. 5-8).

В этом случае DNS-сервер разворачивается как основной сервер имен для AD.Contoso.net с записями делегирования для NAmerica.AD. Contoso.net и Europe.AD.Contoso.net. Этот DNS-сервер может быть тем же самым DNS-сервером, который является официальным сервером для Contoso.net, или можно развернуть дополнительный DNS-сервер. Если вы развертываете дополнительный DNS-сервер для домена Active Directory, необходимо сконфигурировать ретрансляторы и корневые ссылки для него.

В третьем варианте при наличии инфраструктуры DNS домен Active Directory является дочерним доменом от внутреннего пространства имен. Например, Contoso мог бы создавать поддомен AD.Contoso.net как домен Active Directory (см. рис. 5-9). В этом случае DNS-сервер для Contoso.net может быть сконфигурирован с записью делегирования для домена AD.Contoso.net. DNS-сервер AD.Contoso.net может быть сконфигурирован с записью ретранслятора, указывающего на DNS-сервер Contoso.net.

Наиболее сложный проект DNS, с которым вы когда-либо столкнетесь, возникнет в случае, если компания решит скомбинировать все способы объединения DNS с внутренним пространством имен. Например, на рисунке 5-10 показано, что компания, возможно, уже использует Contoso.net и Fabrikam.net как внутренние пространства имен. Решив развернуть Active Directory, компания может добавить дочерние домены под существующие, а также создать новое дерево доменов NWTraders.net. С помощью сконфигурированных ретрансляторов и корневых ссылок DNS-серверы могут разрешать любые имена DNS в организации.



Рис. 5-8. Конфигурирование DNS для использования отличающегося внутреннего пространства имен



Рис. 5-9. Конфигурирование DNS путем добавления поддомена к существующему внутреннему пространству имен

Однако это пространство имен DNS не определяет иерархию Active Directory. В примере на рисунке 5-10 домен AD.Contoso.net может быть корневым доменом Active Directory с дочерними доменами NAmerica.AD.Contoso.net и Europe.AD.Contoso.net и доменами AD.Fabrikam.net и NWTraders.net, использующимися в качестве корневых доменов для дополнительных деревьев в лесу Active Directory.



Рис. 5-10. Конфигурирование DNS путем добавления дочерних доменов к существующим доменам

Векторы новизны и демпфирование распространения

Векторы новизны (up-to-dateness vectors) также используются для управления тем, какая информация должна копироваться между контроллерами домена. Векторы новизны используются для отслеживания всех исходных модификаций, которые данный контроллер домена получил от какого-либо контроллера домена. Например, изменен номер телефона пользователя на контроллере домена DC1, и атрибуту назначен исходный USN, равный 5556. Когда этот атрибут реплицируется на контроллер DC2, исходный USN копируется с обновленным атрибутом. Кроме того, GUID контроллера DC1 реплицируется вместе с атрибутом. Когда DC2 получает это обновление, он модифицирует свой вектор новизны, показывая, что самое последнее исходное обновление, полученное от DC1, теперь равно 5556. Вектор новизны используется для ограничения трафика репликации между контроллерами домена. Когда контроллер-адресат запрашивает обновление у контроллера-отправителя, он включает в запрос свои векторы новизны. Затем компьютер-отправитель использует эту информацию для фильтрации списка всех возможных модификаций, которые он может послать контроллеру-адресату. Такой выбор важен, когда имеется более двух контроллеров домена для данного раздела каталога. Например, если к сценарию, описанному в предшествующем параграфе, добавить контроллер DC3, то изменение номера телефона, сделанное на DC1, будет копироваться и на DC2, и на DC3. Теперь DC3 и DC2 будут иметь обновленный номер телефона, они изменят свои векторы новизны, показывая, что самая последняя модификация, которую они оба получили от DC1, имела исходный USN 5556. Приблизительно через 15 с после получения этой модификации DC2 уведомит DC3, что у него есть обновленная информация. Когда DC3 будет запрашивать обновления каталога у DC2, он включит свой вектор новизны в запрос. В этом случае DC2 определит, что вектор новизны контроллера DC3 для DC1 уже имеет новейший исходный номер USN. Если модификация номера телефона была единственным изменением, сделанным к каталогу в этот временной период, то информация между контроллерами домена DC2 и DC3 реплицироваться не будет. Процесс ограничения модификаций, посылаемых во время репликации, с помощью вектора новизны называется демпфированием распространения. Как уже говорилось, служба КСС создает избыточные репли-кационные связи между контроллерами домена. Одна из проблем, связанных с этим, состоит в том, что одни и те же модификации могут посылаться контроллеру домена от нескольких партнеров по репликации. Это ведет к увеличению трафика репликации, а также потенциально приводит к ситуации, когда одна и та же модификация посылается неоднократно всем контроллерам домена. Демпфирование распространения, использующее вектор новизны, устраняет такую возможность.

Внутреннее и внешнее пространства имен DNS

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

Внутренняя и внешняя репликация между сайтами

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

Совет. Если вы работали с Microsoft Exchange Server 5.5 или более ранней версией, различия процессов репликации внутри и между сайтами вам знакомы. Служба Active Directory использует многие принципы управления репликацией в Exchange Server 5.5.

Восстановление Active Directory

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

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

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

Восстановление Active Directory путем создания нового контроллера домена

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

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

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

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

Планирование. Варианты восстановления, перечисленные выше, не потребуются, если вы сможете отремонтировать отказавший контроллер домена без необходимости создавать его заново и восстанавливать. Система Windows Server 2003 обеспечивает несколько усовершенствованных опций поиска неисправностей, таких как Last Known Good Configuration (Последняя известная хорошая конфигурация) и Safe Mode (Безопасный режим). Используйте эти инструментальные средства, чтобы попробовать вернуть контроллер домена в рабочее состояние, прежде чем начнете выполнять полное восстановление.

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

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

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



Чтобы очистить каталог, выполните следующие действия на любой рабочей станции или сервере с системой Windows 2000, на рабочей станции Windows XP Professional или на сервере Windows Server 2003 /который является членом домена.

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

В командной строке утилиты Ntdsutil напечатайте metadata cleanup.

В окне Metadata Cleanup (Очистка мета-данных) напечатайте connections. Эта команда используется для соединения с текущим контроллером домена с целью удаления отказавшего контроллера домена.

В окне Server Connections (Подключение к серверу) напечатайте connect to server servername (соединиться с сервером servername), где servername - имя доступного контроллера домена. Если вы войдет в систему под учетной записью с административными правами в Active Directory, вы подключитесь к этому контроллеру домена. Если вы не имеете административных прав, используйте команду set creds domain username password, чтобы ввести «верительные грамоты» пользователя, имеющего разрешения уровня домена. Если вы напечатаете help в окне Server Connections, то увидите, что одна из опций ваших команд — это connect to server %s (соединиться с сервером %s). Переменная %s должна всегда заменяться значением, имеющим тип символьной строки. В этом случае строка является или DNS-именем контроллера домена, или IP-адресом сервера.

В окне Server Connections напечатайте quit, чтобы возвратиться в окно Metadata Cleanup.

Напечатайте select operation target (выбрать адресата операции). Эта команда используется для выбора домена, сайта и контроллера домена, чтобы вы могли удалить контроллер домена.

В окне Select Operation Target напечатайте list domains (перечислить домены). Все домены вашего леса перечисляются с назначенными каждому их них номерами.

Напечатайте select domain number (выбрать номер домена), где number указывает домен, содержащий отказавший контроллер домена. Если вы напечатаете help перед тем, как напечатать select domain number, то увидите, что одна из опций команды -select domain %d (выбрать домен %d). Переменная %d должна всегда заменяться числом.



Напечатайте list sites (перечислить сайты). Будут перечислены все сайты леса.

Напечатайте select site number (выбрать номер сайта), чтобы выбрать сайт, содержащий контроллер домена, который вы должны удалить.

Напечатайте list servers in site (перечислить серверы в сайте). Все контроллеры домена, имеющиеся в выбранном сайте, будут перечислены. Используйте команду select server number, чтобы выбрать контроллер домена, который вы должны удалить. Утилита Ntdsutil покажет*выбранный домен, сайт и контроллер домена (см. рис. 15-1.)



Рис. 15-1. Отображение домена, сайта и контроллера домена в утилите Ntdsutil

Напечатайте quit. Вы вфнетесь в окно Metadata Cleanup.

Напечатайте remove selected server (удалите выбранный сервер). Вас попросят подтвердить, что вы хотите удалить сервер из каталога. Щелкните на Yes (Да).

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

Восстановление хозяев операций и серверов глобального каталога

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

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

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

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

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

Чтобы захватить роли хозяина операций, вы можете использовать утилиту Ntdsutil или инструмент Active Directory Users And Computers (чтобы захватить роли эмулятора PDC и хозяина инфраструктуры). Роли хозяина RID, хозяина схемы и хозяина именования доменов можно захватить только с помощью утилиты Ntdsutil.

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

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

В окне команд Ntdsui^l напечатайте roles (роли).

В окне койанд Fsmo Maintenance (Обслуживание Fsmo) напечатайте connections (подключения).

В окне команд Server Connections (Подключения сервера) напечатайте connect to server servername.domainname (соединиться с сервером servername.domainname), где servername - контроллер домена, на котором вы хотите захватить роль хозяина операций. Напечатайте quit (выход).



В окне команд Fsmo Maintenance напечатайте seize operations_master_role (захватить роль хозяина операций). Где operations_master_role — это роли, которые вы хотите захватить: schema master (хозяин схемы), domain naming master (хозяин именования доменов), infrastructure master (хозяин инфраструктуры), RID-master (хозяин RID) или PDC.

Примите предупреждение. Сервер сначала будет пробовать выполнить нормальную передачу роли хозяина операций. Если это не получится, потому что с вышедшим из строя контроллером домена нельзя войти в контакт, то роль будет захвачена. На рисунке 15-4 смотрите пример захвата роли хозяина RID.



Рис. 15-4. Вывод утилиты Ntdsutil при захвате роли хозяина RID

Напечатайте quit (выход) в каждой командной строке, пока не выйдете из утилиты Ntdsutil.

Эмулятор PDC и роль хозяина инфраструктуры могут быть захвачены также через инструмент администрирования Active Directory Users And Computers. Откройте инструмент Active Directory Users And Computers и используйте опцию Connect To Domain Controller (Подключиться к контроллеру домена), чтобы удостовериться, что он связан с контроллером домена, на котором вы хотите захватить роль. Затем щелкните правой кнопкой мыши на имени домена и выберите Operations Masters (Хозяева операций). Если вы попробуете захватить роль, получите предупреждающее сообщение (см. рис. 15-5). Если вы выберите вынужденную передачу, то роль хозяина операций будет захвачена. Только эмулятор PDC и роль хозяина инфраструктуры могут быть захвачены таким образом, т.е. попытки передать любую другую роль хозяина операций с помощью другого инструмента, кроме утилиты Ntdsutil, потерпят неудачу.



Рис. 15-5. Предупреждающее сообщение, полученное при захвате роли хозяина операций через инструмент Active Directory Users And Computers

Восстановление информации Sysvol

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

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

домена. Кроме того, если вы не хотите восстанавливать контроллер домена, а только восстановить его функциональные возможности, создавая другой контроллер домена в домене, то информация Sysvol будет реплицироваться с любых существующих контроллеров домена. Это происходит при помощи службы репликации файлов (File Replication Service - FRS), а не в процессе репликации Active Directory.

Потенциально может возникнуть одно осложнение, если вам надо выполнить восстановление с полномочиями для контейнера Sysvol. Например, если кто-то удалил все сценарии входа в систему, находившиеся в папке Sysvol, вы захотите восстановить сценарии, вместо того чтобы заново создавать их. Проблема состоит в том, что, если удаление было реплицировано на все другие контроллеры домена, то оно будет иметь более довременное репликационное значение, чем на восстановленном контроллере домена. Поэтому если вы выполните просто обычное восстановление контроллера домена, то он реплицирует удаление с другого контроллера домена. Решение проблемы состоит в том, чтобы выполнить основное (primary) восстановление информации Sysvol. Если вы используете системную резервную копию сервера Windows Server 2003 и программу восстановления, то будет выполняться обычное восстановление без полномочий, но при выполнении программы восстановления не следует принимать заданные по умолчанию параметры настройки восстановления. Вместо этого в окне Advanced Restore Options (Дополнительные опции восстановления) мастера восстановления выберите опцию When Restoring Replicated Data Sets, Mark The Restored Data As The Primary Data For All Replicas (При восстановлении наборов реплициру-емых данных отмечать восстановленные данные как основные для всех реплик) (см. рис. 15-3). В результате папка Sysvol на этом контроллере домена будет отмечена, как основной контейнер для репликации Sysvol.

Рис. 15-3. Выполнение основного восстановления для Sysvol информации

Восстановление системы после неудавшегося обновления домена

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

Добавьте BDC ко всем доменам Windows NT 4 с одним контроллером домена. Это будет гарантировать путь восстановления в случае сбоя при обновлении единственного контроллера домена в домене.

Синхронизируйте все контроллеры BDC с PDC. Это будет гарантией того, что база данных SAM содержит самые свежие данные.

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

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

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

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

Выключите обновленный контроллер домена. Он считается PDC контроллером в домене Windows NT 4 и будет мешать успешному выполнению следующего шага.

Подключите автономный BDC назад в сеть и назначьте его на роль PDC контроллера. Это действие запустит репликацию сохраненной базы данных SAM на все оставшиеся в сети BDC контроллеры с системой Windows NT 4.

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

Восстановление системы после неудавшейся реструктуризации домена

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

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

Добавьте BDC ко всем доменам Windows NT 4, которые имеют только один контроллер домена. Это будет гарантировать путь восстановления в том случае, если произойдет сбой при обновлении единственного контроллера домена в домене.

Синхронизируйте все контроллеры BDC с PDC. Это будет гарантировать актуальность базы данных SAM.

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

Если реструктуризация домена окончится неудачей, план восстановления состоит в том, чтобы продолжить работу в среде Windows NT 4, расследовать причины неудачи, проверить план развертывания и пробовать снова. Если база данных SAM системы Windows NT 4 разрушена в процессе перемещения учетных записей, используйте резервную копию для восстановления базы данных учетных записей. Разрушение данных проявит себя тем, что не все объекты появятся в User Manager (Менеджер пользователей), или пользователи не смогут войти в систему.

Восстановление журналов транзакций

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

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

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

Перезагрузите сервер и выберите загрузку в режиме восстановления службы каталога. Это требуется для работы инструмента Ntdsutil.

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

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

В командной строке File Maintenance напечатайте recover.

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

Время ожидания репликации

Репликация в Active Directory Windows Server 2003 реализована таким образом, что копирование на другие контроллеры домена изменений, сделанных на одном из контроллеров, может занимать некоторое время. Эта временная задержка называется временем ожидания репликации (replication latency). В большинстве случаев время ожидания репликации легко вычислить, особенно в пределах сайта. Как уже говорилось, любое изменение, сделанное в базе данных каталога на одном из контроллеров домена, будет копироваться партнерам по репликации приблизительно через 15 с. Контроллер домена адресата задержит это изменение на 15 с, а затем передаст его своим партнерам по репликации. Время ожидания репликации в пределах сайта приблизительно равно 15-ти секундам, умноженным на количество ретрансляций, которые потребуются, прежде чем информация достигнет всех контроллеров домена. Топология репликации в пределах сайта никогда не требует более трех ретрансляций, так что максимальное время ожидания репликации в пределах сайта составляет примерно 45 с.

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

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

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

в технический справочник по Active

Добро пожаловать в технический справочник по Active Directory для Microsoft Windows Server 2003, являющийся источником информации, которая потребуется вам для проектирования и реализации службы каталога Active Directory в системе Windows Server 2003. Служба каталога Active Directory первоначально была выпущена с системой Microsoft Windows 2000. Большинство концепций Active Directory, реализованных в системе Windows 2000, сохранились и в системе Windows Server 2003, кроме того, появилось много усовершенствований. Эта книга содержит все, что вы должны знать об Active Directory, включая детальную техническую информацию и руководство, предназначенное для планирования, реализации и управления службой Active Directory в вашей организации. Другими словами, эта книга является универсальным справочником, содержащим все, чтобы заставить Active Directory работать на вас.
Структура книги
Технический справочник по Active Directory для Microsoft Windows Server 2003 составлен так, чтобы наиболее понятно описать и объяснить технологии Active Directory. Многие компании не реализовали Active Directory в системе Windows 2000, поэтому книга не предполагает наличие глубоких знаний Active Directory у читателей. Книга начинается с описания основ службы каталога и объяснения того, как служба каталога реализована в Active Directory. Затем рассказывается, как работает Active Directory, как ее использовать и как управлять ею в вашей среде.
Книга разделена на четыре части, усложняющиеся по мере накопления вами знаний. В части I дается краткий обзор терминов Active Directory и концепций. В части II объясняется планирование и проектирование, необходимые для развертывания Active Directory в вашей среде. После развертывания службы Active Directory ей нужно управлять, поэтому в части III уточняются детали, касающиеся управления службой Active Directory, и делается сильный акцент на безопасность Active Directory и групповых политик. Часть IV, заключительный раздел книги, посвящена обслуживанию Active Directory.


Часть I, « Краткий обзор службы каталога Active Directory Windows 2003», содержит введение в концепции и компоненты Active Directory системы Windows Server 2003. Эта версия Active Directory является последним вариантом службы каталога, поставляемой компанией Microsoft. Active Directory обеспечивает мощную службу каталога, предназначенную для управления пользователями, группами и компьютерами, и пред-
лагает безопасный доступ к сетевым ресурсам. Чтобы использовать ее наиболее эффективно, вы должны понять концепцию Active Directory и принципы ее работы. Эти основы изложены в части I, которая включает следующие главы.
В главе 1, «Концепции Active Directory», предлагается краткая история служб каталога, которые компания Microsoft поставляла как часть операционных систем Windows 2000 и Windows NT. Далее подробно обсуждаются преимущества Active Directory по сравнению с предыдущими службами каталога. В этой главе вы найдете также краткий обзор нововведений, появившихся в системе Windows Server 2003 в дополнение к тем, которая имелись в Windows 2000.
В главе 2, «Компоненты Active Directory», дается детальное описание концепций и компонентов, составляющих Active Directory. В этой главе вы найдете описание физических компонентов Active Directory, таких как контроллеры домена и схема Active Directory, и логических компонентов Active Directory, таких как домены, деревья и леса.
В главе 3, «Active Directory и система доменных имен», приводится описание принципов функционирования Active Directory. Служба Active Directory глубоко интегрирована с доменной системой имен (DNS - Domain Name System), и если вы неправильно реализуете свою инфраструктуру службы DNS, вы никогда не сможете создать устойчиво функционирующую службу Active Directory. Глава начинается с краткого обзора концепций DNS, затем описывается интеграция между Active Directory и DNS, далее объясняется, как лучше всего реализовать DNS, чтобы обеспечить функционирование службы разрешения имен, необходимой для работы Active Directory.


В главе 4, «Репликация Active Directory и сайты», продолжается описание принципов работы Active Directory. Чтобы понять, как работает Active Directory, нужно знать, как контроллеры домена Active Directory реплицируют информацию друг у друга. По умолчанию Active Directory создает устойчивую и избыточную топологию репликации, также имеются опции, предназначенные для создания оптимальной конфигурации репликации для вашей компании.
Как только вы изучите основные концепции и компоненты Active Directory, ваш следующий шаг будет состоять в реализации службы Active Directory в вашей организации. Часть II, «Реализация Active Directory Windows Server 2003», обеспечит вас необходимой информацией. Первый шаг в реализации Active Directory состоит в создании проекта структуры для вашей организации. Такие структурные элементы, как лес, домен, сайт и организационная единица (OU - Organizational Unit), уникальны для каждой компании, поэтому создание правильного проекта службы для вашей среды требует существенных знаний и усилий. Как только проект Active Directory для Windows Server 2003 будет создан, вы можете приступать к установке Active Directory. Многие компании, реализующие Active Directory для Windows Server 2003, переносят ее с предыдущей версии службы каталога, особенно часто с версии Microsoft Windows NT 4. Поскольку Active Directory для Windows Server 2003 отличается от службы каталога Windows NT, то это перемещение может вызвать сложности. В части II эти темы представлены в следующих главах.
В главе 5, «Проектирование структуры Active Directory», дается краткий обзор процесса проектирования, подготавливающего вашу реализацию Active Directory. Эта глава ведет вас через весь процесс создания собственного проекта: от нисходящего проектирования к разработке структуры службы Active Directory. В этой главе обсуждаются все компоненты вашего проекта, начиная с того, сколько лесов вам следует развертывать, заканчивая тем, как создавать свою структуру OU.
В главе 6, «Установка Active Directory», описаны процедуры, необходимые для инсталляции Active Directory. Она посвящена установке контроллеров домена Active Directory и включает обсуждение некоторых новых опций, предназначенных для осуществления этой инсталляции.


В главе 7, «Переход к Active Directory», приводится информация, необходимая для модернизации предыдущей службы каталога от Microsoft к Active Directory для Windows Server 2003. Обновление происходит сложнее, если модернизируется служба каталога Windows NT, нежели Active Directory системы Windows 2000. Поэтому в данной главе содержатся, главным образом, вопросы обновления службы каталога от Windows NT к Active Directory Windows Server 2003, а также модернизации Active Directory Windows 2000.

После развертывания Active Directory вы должны управлять ею так, чтобы обеспечить максимальную выгоду своей компании. В части III, «Администрирование службы каталога Active Directory Windows Server 2003», описываются многие административные процессы, которые вы будете использовать. В части III имеются две основных темы: безопасность и управление доменом с помощью групповых политик. Вы узнаете, как работает защита в Active Directory, как можно воспользоваться инфраструктурой безопасности для делегирования административного управления в пределах вашей структуры Active Directory. Далее следует обсуждение групповых политик. Одно из основных преимуществ Active Directory по сравнению с предыдущими службами каталога состоит в том, что она содержит мощные инструментальные средства для управления рабочими станциями вашей компании. Централизованное администрирование рабочих станций может сильно упростить управление сетью и привести к существенному уменьшению затрат на обслуживание сети. Групповые политики - это основные инструментальные средства, которые вы будете использовать для управления рабочими станциями вашей сети. Часть III включает следующие главы.
Глава 8, «Защита Active Directory», начинается с описания концепций, лежащих в основе безопасности Active Directory Windows Server 2003. Основное внимание в этой главе уделено протоколу Kerberos, который является заданным по умолчанию опознавательным протоколом в Active Directory.
В главе 9, «Делегирование администрирования Active Directory», более широко обсуждается система безопасности Active Directory, подробно описываются способы делегирования административных разрешений в пределах своего домена. Active Directory обеспечивает администраторов многими уровнями административных разрешений, а также позволяет предоставлять административные разрешения только в определенной части домена. В главе описывается, как реализовать эту функциональность в Active Directory.


В главе 10, «Управление объектами Active Directory», вы познакомитесь с управлением объектами Active Directory: учетными записями пользователей и групп, которые всегда были частью службы каталога. Active Directory Windows Server 2003 содержит и другие объекты, такие как inetOrgPerson, универсальные группы, принтеры и общие папки.
В главе 11, «Введение в групповые политики», дается краткий обзор групповых политик. Рассказывается о создании и конфигурировании групповых политик, об их применении в рамках Active Directory, дается основная информация, которая требуется для понимания следующих двух глав, содержащих конкретные примеры того, что можно делать с помощью групповых политик.
В главе 12, «Использование групповых политик для управления программным обеспечением», уточняется один из способов использования групповых политик. С помощью групповых политик вы можете инсталлировать программное обеспечение на компьютерах клиентов и управлять им. Во многих компаниях управление программным обеспечением представляет собой сложную, отнимающую много времени задачу. Групповые политики могут использоваться для автоматизации этой задачи, и в данной главе показано, как это сделать.
Глава 13, «Использование групповых политик для управления компьютерами», посвящается вопросам использования групповых политик для управления компьютерами клиентов. Групповые политики имеют много опций, предназначенных для управления рабочими столами, включая блокирование некоторых компонентов рабочих столов, конфигурирование защиты рабочих станций и ограничение типов приложений, которые может выполнять пользователь. В главе показывается, как реализовать все эти возможности.
Последняя часть книги содержит информацию, необходимую для обслуживания инфраструктуры Active Directory после ее развертывания. Для этого нужно профилактически отслеживать состояние компонентов Active Directory. Часто в процессе мониторинга вы можете увидеть первые предупреждения о том, что что-то идет не так, как надо. Поскольку это происходит независимо от того, как тщательно вы управляете средой, необходимо иметь план восстановления Active Directory на случай ее отказа. Часть IV, «Обслуживание службы каталога Active Directory Windows Server 2003», включает следующие главы.


В главе 14, «Мониторинг и обслуживание Active Directory», содержится подробная информация о том, как осуществлять мониторинг Active Directory, включая вопросы контроля функционирования службы каталога Active Directory и ее репликации. В этой главе также имеется информация, касающаяся вопросов обслуживания базы данных Active Directory.
В главе 15, «Восстановление системы в случае сбоя», содержится информация, необходимая для создания резервной копии и восстановления Active Directory. Active Directory является критической службой вашей сети, и вы должны уметь восстановить ее после любой поломки, которая может влиять на вашу реализацию службы каталога.
Все разделы этой книги посвящены процессу проектирования, развертывания, управления и обслуживания Active Directory. Однако технический справочник по Active Directory Microsoft Windows Server 2003 - это, прежде всего, справочник. Если вам надо познакомиться с определенной темой, вы можете сразу читать соответствующую главу без необходимости читать предыдущие главы. В некоторых случаях для понимания темы может потребоваться базовая информация. Например, обсуждение в главе 5 лесов, доменов, организационных единиц и сайтов предполагает, что вы понимаете эти концепции так, как они представлены в главе 2. Чтобы понять, как используются групповые политики для развертывания программного обеспечения (см. главу 12), вы должны понимать компоненты групповой политики, которые обсуждаются в главе 11.

Введение в протокол Kerberos

В системе, основанной на протоколе Kerberos, имеется три компонента. Во-первых, клиент, который должен получить доступ к сетевом ресурсам. Во-вторых, сервер, который управляет сетевыми ресурсами и гарантирует, что только должным образом заверенные и уполномоченные пользователи могут получать доступ к ресурсу. Третий компонент — центр распределения ключей (KDC - Key Distribution Center), который служит центральным местом хранения пользовательской информации и главной службой, подтверждающей подлинность пользователей.

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

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

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

Одной из проблем общего секрета является то, что пользователь и сервер, управляющий сетевым ресурсом, должны иметь какой-либо способ владения общим секретом. Если пользователь пробует получить доступ к ресурсу на определенном сервере, то учетная запись пользователя может быть создана на сервере с паролем, который знает только пользователь. Когда пользователь попытается обратиться к ресурсам на этом сервере, он может представить общий секрет (пароль) и получить доступ к ресурсу. Однако в корпоративной среде могут быть тысячи пользователей и сотни серверов. Управление различными общими секретами всех этих пользователей было бы непрактичным. Протокол Kerberos справляется с этой проблемой, используя центр распределения ключей (KDC - Key Distribution Center). Служба KDC выполняется как служба сервера в сети и управляет общими секретами всех пользователей в сети. KDC имеет одну центральную базу данных для всех учетных записей пользователей сети и хранит общий секрет каждого пользователя (в форме одностороннего кэша пароля пользователя). Когда пользователю требуется получить доступ к сети и сетевым ресурсам, служба KDC подтверждает, что пользователь знает общий секрет, а затем подтверждает подлинность пользователя.

Примечание. В терминологии Kerberos центральным сервером, управляющим учетными записями пользователя, является служба KDC. В реализации Kerberos сервера Windows Server 2003 этот сервер называется контроллером домена. Каждый контроллер домена Active Directory является KDC. В Kerberos граница, определенная пользовательской базой данных, расположенной на одном KDC, называется областью (realm). В терминологии Windows Server 2003 эта граница называется доменом.
Каждая служба KDC состоит из двух отдельных служб: службы аутентификации (AS - Authentication Service) и службы предоставления билетов (TGS — Ticket-Granting Service). Служба AS отвечает за начальный вход клиента в систему и выдает билет TGT (TGT - Ticket-Granting Ticket) клиенту. Служба TGS отвечает за все билеты сеанса, которые используются для доступа к ресурсам в сети Windows Server 2003.
Служба KDC хранит базу данных учетных записей, которая используется для аутентификации протоколом Kerberos. В реализации Kerberos Windows Server 2003 база данных управляется агентом системы каталога (DSA - Directory System Agent), который выполняется в пределах процесса LSA на каждом контроллере домена. Клиенты и приложения никогда не получают прямой доступ к базе данных учетных записей - все запросы идут через агента DSA, используя один из интерфейсов Active Directory. Каждый объект в пределах базы данных учетных записей (фактически, каждый атрибут каждого объекта) защищен с помощью списка ACL. Агент DSA гарантирует, что любые попытки обращения к базе данных учетных записей должным образом санкционированы.
Совет. Когда Active Directory устанавливается на первом контроллере домена в домене, создается специальная учетная запись, которая называется krbtgt. Эта учетная запись не может быть удалена или переименована, ее никогда нельзя разрешать (enable). При создании этой записи назначается пароль, который регулярным образом автоматически изменяется. Этот пароль используется для создания секретного ключа, предназначенного для шифрования и расшифровки билетов TGT, выдаваемых всеми контроллерами домена в домене.

Выбор единственного домена

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

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

Практический опыт. Конфигурация текущего каталога и проектирование Active Directory

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

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

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

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

сильно затрагивает решение о количестве лесов и доменов, а также проектирование доменного пространства имен. Эти решения трудно изменить после того, как развертывание началось. Другие решения типа финального проекта OU и проекта сайтов легко изменить после развертывания.

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

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

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

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

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

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

Выбор нескольких доменов

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

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

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

Любые офисы компании, связь между которыми обеспечивается только простым протоколом передачи почты (SMTP), должны конфигурироваться как отдельные домены. Информация домена не может реплицироваться через связи сайта, использующие протокол SMTP.

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

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

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

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

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

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

Выбор реструктуризации домена в качестве пути перехода

Ниже приводятся характеристики организации, которой хорошо подходит реструктуризация домена в качестве пути перехода.

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

Обе системы, Windows Server 2003 и Windows 2000, реализуют более строгую защиту для атрибутов пользовательских и групповых объектов, чем та, которая была в Windows NT 4. Доступ к пользовательским объектам и групповое членство по умолчанию недоступны для анонимных пользовательских входов в систему. Чтобы сохранить обратную совместимость с приложениями и службами, созданными до Windows 2000 (Microsoft SQL-сервер и служба удаленного доступа Remote Access Service, RAS), Active Directory конфигурируется так, чтобы ослабить заданную по умолчанию защиту и позволить анонимный доступ к этим объектам службы каталога. Это выполняется путем добавления специальных групп Everyone (Все) и Anonymous Logon (Анонимный вход в систему) к локальной группе Pre-Windows 2000 Compatible Access (Доступ, совместимый с системами, разработанными до Windows 2000).

В процессе инсталляции Active Directory вы должны установить заданные по умолчанию разрешения для групповых и пользовательских объектов. В окне Permissions (Разрешения) выберите одну из двух опций (см. рис. 6-14):

Permissions Compatible With Pre-Windows 2000 Server Operating Systems (Разрешения, совместимые с операционными системами, созданными до Windows 2000);

Permissions Compatible Only With Windows 2000 Or Windows Server 2003 Operating Systems (Разрешения, совместимые только с операционными системами Windows 2000 или Windows Server 2003).

Рис. 6-14. Окно Permissions (Разрешения)

Какую опцию выбрать? Если ваша сетевая среда будет включать серверы Windows NT, а также службы или приложения, которые требуют защиты Windows NT для пользователей и групп, вы должны принять заданную по умолчанию: Permissions Compatible With Pre-Windows 2000 Server Operating Systems. Если ваша сетевая среда включает только Windows 2000 или Windows Server 2003, если в ней не будут выполняться программы, разработанные для более ранних, чем Windows 2000, систем, выберите Permissions Compatible Only With Windows 2000 Or Windows Server 2003 Operating Systems. Имейте в виду, что с заданной по умолчанию опцией анонимные пользователи будут способны обращаться к данным Active Directory, нарушая защиту.

После того как вы модернизируете все серверы в домене до Windows 2000 или Windows Server 2003, нужно заново установить разрешения Windows Server 2003 для групповых и пользовательских объектов. Для этого просто удалите всех членов локальной группы Pre-Windows 2000 Compatible Access (Доступ, совместимый с системами, разработанными до Windows 2000). В домене Windows Server 2003 членами будут идентификаторы SID групп Everyone (Все) и Anonymous Logon (Анонимный вход в систему).

Чтобы удалить членов этой группы с помощью инструмента администрирования Active Directory Users And Computers (Пользователи и компьютеры Active Directory), откройте контейнер Builtin (Встроенные объекты), а затем дважды щелкните на группе Pre-Windows 2000 Compatible Access (раскройте столбец Name (Имя) в случае необходимости). На вкладке Members (Члены) окна групповых свойств выберите оба идентификатора SID и щелкните на кнопке Remove (Удалить). Для удаления членов этой группы из командной строки напечатайте следующую команду:

net localgroup "Pre-Windows 2000 Compatible Access" Everyone "Anonymous Logon" /delete

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

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



Рис. 6-15. Окно Directory Services Restore Mode Administrator Password (Пароль администратора режима восстановления службы каталога)

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

Наилучшая практика. После установки службы Active Directory вы должны открыть инструмент администрирования Active Directory Users And Computers и проверить, что созданы все встроенные участники безопасности, такие как учетная запись пользователя Administrator и группы безопасности Domain Admins, Enterprise Admins. Вы должны также проверить создание «специализированных тождеств» Authenticated Users (Удостоверенные пользователи) и Interactive (Интерактивный). «Специализированные тождества» обычно известны как группы, но вы не можете видеть их членство. Пользователи автоматически включаются в эти группы, когда они обращаются к специфическим ресурсам. «Специализированные тождества» по умолчанию не отображаются в инструменте администрирования Active Directory Users And Computers. Чтобы рассмотреть эти объек-

ты, выберите View (Вид), а затем выберите Advanced Features (Дополнительные функции).

В результате отобразятся дополнительные компоненты инструмента. Откройте контейнер Foreign Security Principals (Внешние участники безопасности). Там вы найдете объекты S-1-5-11 и S-1-5-4, которые являются идентификаторами Authenticated Users SID и Interactive SID, соответственно. Дважды щелкните на этих объектах, чтобы просмотреть их свойства и заданные по умолчанию разрешения.

Выгоды от мониторинга Active Directory

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

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

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

Снижение административных затрат с помощью профилактических мер в обслуживании системы.

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

Увеличение доброжелательности в отношении IT-отдела в результате удовлетворения клиентов.

Выполнение инсталляции «без сопровождения»

Чтобы установить Active Directory без пользовательского участия, можно использовать параметр /answer [:filename] с командой Dcpromo. В этот параметр нужно включить имя файла ответов. Файл ответов содержит все данные, который обычно требуются в процессе инсталляции. Можно также устанавливать Active Directory при установке Windows Server 2003 в автоматическом режиме. В этом случае используется команда E:\I386\winnt32/unattend[:unattend.txt], где unattend.txt - имя файла ответов, используемого для полной инсталляции Windows Server 2003. (Предполагается, что дисководом CD-ROM является диск Е, и вы вставили в дисковод диск.) Файл Unattend.txt должен содержать раздел [Deinstall], чтобы можно было установить Active Directory.

Чтобы выполнить автоматическую установку Active Directory после установки операционной системы Windows Server 2003, создайте файл ответов, который содержит раздел [Deinstall]. Для этого напечатайте в командной строке или в диалоговом окне Run dcpromo/ answer:answerfile (где answerfile - имя файла ответов). Файл ответов представляет собой текстовый ASCII-файл, который содержит всю информацию, необходимую для заполнения страниц мастера инсталляции Active Directory. Для создания нового домена в новом дереве нового леса так, чтобы служба DNS сервера была сконфигурирована автоматически, содержание файла ответов выглядит следующим образом:

[Deinstall]

UserName=admin_ username

Password=admin_password

UserDomain=acmin_domain

DatabasePath=

LogPath=

SYSVOLPath=

SafeModeAdminPassword=password

ReplicaOrNewDomain=Domain

NewDomain=Forest

NewDomainDNSName=DNSdomainname

DNSOnNetwork

DomainNetbiosName=NetBIOSdomainname

AutoConfigDNS=yes

AllowAnonymousAccess=yes

CriticalReplicationOnly=yes

SiteName=

RebootOnSuccess=yes

Для ключей, не имеющих значений, или для отсутствующих ключей будут использоваться значения, заданные по умолчанию. Ключи, необходимые для файла ответов, изменяются в зависимости от типа домена, который будет создан (новый или уже существующий лес, новое или уже существующее дерево). Для получения дополнительной информации относительно ключей и соответствующих значений смотрите< документ http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b223757.

Выполнение неофициального восстановления

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

•    Сервер является единственным контроллером домена в домене. Если дело обстоит так, у вас нет выбора, как восстанавливать службу Active Directory. Вы должны восстановить базу данных на новом или исправленном сервере.

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

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

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

В некоторых случаях вы будете восстанавливать контроллер домена на сервере, который использует другой набор аппаратных средств, чем тот, который был доступен на первоначальном сервере. Хотя вполне возможно восстановить Windows Server 2003 на аппаратных средствах, отличающихся от аппаратных средств сервера, с которого было сделана резервная копия, этот процесс чреват проблемами. Если вы попробуете восстановить Windows Server 2003 на сервере с отличающимися аппаратными средствами, выберите аппаратные средства, которые будут максимально совместимы. Гарантируйте, что уровень аппаратного абстрагирования (hardware abstraction layer - HAL), видеокарты и сетевые платы идентичны. Кроме того, конфигурация жесткого диска на новом сервере должна быть такой же, как на отказавшем. Даже если вы будете соблюдать эти предосторожности, восстановление системы Windows Server 2003 на сервер с другими аппаратными средствами труден, и успех не гарантирован. Возможная альтернатива состоит в создании контроллера домена из резервной копии. В этом случае вы сможете воспользоваться преимуществом чистой инсталляции системы Windows Server 2003, и в то же время сможете создать начальную копию базы данных из резервной копии, а не через репликацию.

Выполнение восстановления с полномочиями

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

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

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

Высокие требования к сохранению работоспособности системы

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

Высокий уровень риска

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

Windows 2000 и Active Directory

Так как база данных SAM не была легко доступной с внешней стороны самой NOS, она не подходила для поддержки сетевых приложений типа Exchange Server. Когда была выпущена четвертая версия Exchange Server, она имела свою собственную службу каталога - Exchange Directory. Служба Exchange Directory была предназначена для поддержки вычислительной среды больших предприятий, в более поздних версиях она основывалась на открытых стандартах интернета. Поддержка открытых стандартов подразумевала, что Exchange Directory удовлетворяла спецификации облегченного протокола службы каталогов (LDAP) семейства протоколов TCP/IP (Протокол для взаимодействия сетей в интернете) и была легко доступна программно.

Разрабатывая следующую версию NOS-систем Windows, компания Microsoft рассматривала службу каталога Exchange Server в качестве модели для будущей реализации службы каталога. Дополнительная выгода от развития сетевой службы каталога на базе существующей служ-

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

Устойчивая служба каталога Active Directory, которая скромно начиналась как служба каталога Exchange Server версии 4, была в итоге выпущена с Windows 2000. Служба Active Directory заменила базу данных SAM в качестве службы каталога для сетевых сред от Microsoft. Эта новая реализация службы каталога была направлена на преодоление ограничений службы Windows NT 4 SAM и обеспечивала дополнительные выгоды сетевым администраторам. Главная выгода Active Directory в реализации Windows 2000 состоит в том, что она масштабируема. Новый файл базы данных учетных записей может достигать 70 Тб, что является весомым усовершенствованием по сравнению с лимитом SAM в 40 Мб. Число объектов, которые могут быть сохранены в Active Directory, превышает один миллион.

Фактически Active Directory была реализована в испытательной среде в модели отдельного домена, содержащей более ста миллионов объектов. В качестве демонстрации масштабируемости корпорация Compaq Computer Corporation, теперь входящая в состав корпорации Hewlett-Packard, успешно объединила в модели отдельного домена сводные каталоги домашних телефонных номеров для всех пятидесяти штатов Соединенных Штатов Америки. Списки, представляющие два самых больших штата, были загружены дважды, чтобы увеличить объем до размера, превышающего сто миллионов объектов. Если Active Directory может хранить, управлять и быстро отвечать на запросы для каждого домашнего номера телефона в Соединенных Штатах, то она может также масштабироваться до размеров организаций больших предприятий.

Такой огромный прогресс в допустимом объеме означает, что сетевые администраторы больше не должны делить свои среды на несколько доменов, чтобы обойти ограничения размеров службы каталога. Результат состоит в уменьшении количества доменов, серверных аппаратных средств и уменьшении объема сетевого администрирования, то есть появляются три неотразимых причины для реализации службы Active Directory. Сложные доменные модели, которые преобладали в Windows NT 4, теперь могут быть объединены в меньшее количество доменов с помощью организационных единиц (OU - organizational unit), предназначенных для группировки содержимого ресурсного или регионального домена Windows NT 4. На рисунке 1-2 показана типичная модель отдельного домена системы Windows 2000.

Другое важное преимущество службы Active Directory состоит в ее доступности.

Архитектура Active Directory разработана на открытых стандартах интернета, таких как LDAP и пространство имен Х.500. Active Directory

также доступна этим открытым стандартам программно. Администраторы могут управлять своими реализациями службы Active Directory, используя LDAP-совместимые инструментальные средства, такие как Active Directory Service Interface (ADSI) Edit и Ldp.exe (LDAP-совмес-тимый инструмент администрирования службы Active Directory). Так как служба Active Directory открыта для LDAP, она может управляться программно. В результате сетевые администраторы могут писать сценарии задач управления типа пакетного импорта пользовательских объектов, которые требуют много времени, если выполняются через графический интерфейс пользователя (GUI).

Рис. 1 -2. Модель отдельного домена системы Windows 2000

Windows NT и SAM

Войдите в Microsoft Windows NT 3.1 Advanced Server. Платформа Windows NT Server предлагает устойчивую 32-битную вычислительную среду с привычным внешним видом и «ощущением» популярной операционной системы Microsoft Windows for Workgroups, предназначенной для настольных компьютеров. Сердцем Windows NT NOS (Network Operating System — сетевая операционная система) является база данных SAM (Security Accounts Management - управление безопасными учетными записями). Она представляет центральную базу данных учетных записей, включающую все учетные записи пользователей и групп в домене. Эти учетные записи используются для управления доступом к совместным ресурсам, принадлежащим любому серверу в домене Windows NT.

База данных SAM оставалась главной службой каталога для нескольких вариантов систем Microsoft Windows NT NOS, включая систему Windows NT 3.5 и систему Windows NT Server 4. База данных SAM масштабировалась намного лучше, чем предыдущая архитектура службы каталога из-за введения междоменных доверительных отношений. Доверительные отношения в Windows NT были важны для преодоления других ограничений службы каталога Windows NT.

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

ограничения, сетевые администраторы должны были добавить больше доменов к своим средам. Организации также разбивались на несколько доменов, чтобы достигнуть административной автономии, чтобы каждый администратор мог иметь полный контроль над своим собственным доменом. Поскольку все администраторы домена Windows NT 4 имеют, по существу, неограниченные административные привилегии, создание отдельных доменов было единственным методом установления границ администрирования. Однако в пределах домена все администраторы имели полный контроль над серверами и службами, которые на них выполнялись. Создание дополнительных доменов не было привлекательным методом, поскольку каждый новый домен требовал дополнительных серверных аппаратных средств, что приводило к увеличению административных накладных расходов. По мере роста количества доменов в организации обеспечение уверенности относительно доверительных отношений, которые делали возможным пользовательскую идентификацию для доступа к ресурсам внешних доменов, также приводило к росту накладных расходов. Чтобы справиться с этой растущей сложностью доменов и доверительных отношений, сетевые администраторы реализовывали одну из четырех доменных моделей: отдельный домен (single domain), домен с одним хозяином (master domain), домен с несколькими хозяевами (multiple master domain, или multimaster) и отношения полного доверия (complete trust). Эти доменные модели показаны на рисунке 1-1.

Рис. 1 -1. Четыре доменные модели, используемые в Windows NT 4

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

Второе ограничение на базу данных SAM состояло в возможностях доступа. Единственным методом доступа, применявшимся при взаимодействии с базой данных SAM, была сама NOS. Этот метод ограничивал программируемый доступ и не обеспечивал конечным пользователям легкого доступа для поиска объектов. Все запросы на чтение, создание или изменение объектов SAM должны были инициироваться с использованием одного из нескольких инструментальных средств, включенных в интерфейс пользователя (UI - User Interface) Windows NT 4, таких как User Manager For Domains (Администрирование доменов) или Server Manager (Администрирование серверов). Это ограничило полезность базы данных SAM в качестве службы каталога и внесло вклад в потребность найти замену службе каталога Windows NT в будущих версиях систем Windows-NOS. Такая служба каталога начала обретать форму на рабочих столах команды разработчиков Microsoft Exchange Server.

Записи ресурсов

Текущие записи, хранящиеся в зонных файлах DNS, называются записями ресурсов (RR — Resource Records). Записи ресурсов содержат текущую информацию о домене. Вы можете создать двадцать два различных типа записей ресурсов на DNS-сервере системы Windows Server 2003. Наиболее распространенные записи ресурсов перечислены в таблице 3-1.

Табл. 3-1. Наиболее распространенные записи ресурсов в доменной системе имен Windows Server 2003

Название		Пояснение
Start of Authority (SOA) - начало полномочий		Идентифицирует основной сервер имен для зоны, устанавливает параметры, заданные по умолчанию для зонной передачи, параметры длительности хранения зонной информации и время жизни (TTL — Time to Live) (см. рис. 3-2).
Host (A) - хост		Идентифицирует IP-адрес для определенного имени хоста. Это та запись, которую DNS-cep-вер возвращает в процессе разрешения имен.
Mail Exchanger (MX) - коммутатор электронной почты		Идентифицирует серверы передачи интернет-сообщений. Используется другими серверами передачи интернет-сообщений для поиска аналогичных серверов в домене.
Name Server (NX) -сервер имен		Идентифицирует все серверы имен для домена.
Pointer (PTR) -указатель		Идентифицирует имена хостов, отображаемых на определенных IP-адресах. Хранится в зоне обратного просмотра.
Canonical Name (CNAME) - каноническое имя Service Locator (SRV) - указатель служб		Идентифицирует псевдоним другого хоста в домене. Применяется в том случае, когда несколько имен хоста используют один и тот же IP-адрес. Идентифицирует службу, которая имеется в домене. Active Directory широко использует записи SRV для поиска контроллеров домена.

Рис. 3-2. Запись SOA для домена Contoso.com

Совет. На рисунке 3-2 показана запись SOA в инструменте администрирования DNS. Записи DNS могут быть сохранены в стандартном текстовом формате. Например, стандартная запись хоста для сервера по имени Webl.Contoso.com может быть записана как Webl.Contoso.com IN A 192.168.1.100.

Записи ресурсов DNS, зарегистрированные контроллером домена Active Directory

Чтобы облегчить нахождение контроллеров домена, Active Directory использует указатель служб (service locator) или записи SRV. Записи SRV - это новый тип DNS-записи, описанный в документе RFC 2782, он используется для идентификации услуг в TCP/IP-сети. На примере одной из записей, используемых службой Active Directory, показано, как каждая запись SRV использует стандартный формат (см. табл. 3-2).

_ldap._tcp.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com

Табл. 3-2. Компоненты записи SRV

Компонент		Пример		Объяснение
Служба		_ldap		Служба, которую идентифицирует запись. Дополнительные службы включают _kerberos, _kpassword и _gc.
Протокол		_tcp		Протокол, используемый для этой службы. Может быть протоколом TCP или протоколом пользовательских датаграмм (UDP).
Имя		contoso.com		Имя домена, на который ссылается запись.
Время жизни (TTL - Time to Live)		600		Заданное по умолчанию «время жизни» записи (в секундах).
Класс		IN		Стандартный DNS-класс интернета.
Запись ресурса		SRV		Идентифицирует запись как запись SRV.
Приоритет		0		Идентифицирует приоритет записи для клиента. Если существует несколько SRV-записей для одной и той же службы, клиенты будут сначала пытаться соединиться с сервером, имеющим самый низкий приоритет.
Вес		100		Механизм балансировки нагрузки. Если существует несколько SRV-записей для одной и той же службы, и приоритет всех записей одинаков, клиенты чаще выбирают записи с более высокими весами.
Порт		389		Порт, используемый этой службой.
Адресат		dc2.contoso.com		Хост, который обеспечивает службу, идентифицированную записью.

По сути, информация в этой записи говорит, что если клиент ищет сервер облегченного протокола службы каталогов (LDAP) в домене Contoso.com, он должен соединиться с dc2.contoso.com.

Контроллеры домена в домене Windows Server 2003 регистрируют много SRV-записей в системе DNS. Следующий список включает все записи, зарегистрированные первым сервером леса.

contoso.com. 600 IN A 192.168.1.201

_ldap._tcp.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.

_ldap._tcp.Default-First-Site-Name._sites.contoso.com. 600 IN SRV 0 100 389

dc2.contoso.com.

_ldap._tcp.pdc._msdcs.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.

_ldap._tcp.gc._msdcs.contoso.com. 600 IN SRVO 100 3268 dc2.contoso.com.

_ldap._tcp. Default-First-Site-Name._sites._gc._msdcs.contoso.com. 600 IN SRV 0

100 3268 dc2.contoso.com.

_ldap._tcp.64c228cd-5f07-4606-b843-d4fd114264b7.domains._msdcs.contoso.com.

600 IN SRV 0 100 389 dc2.contoso.com.

gc._msdcs.contoso.com. 600 IN A 192.168.1.201

175170ad-0263-439f-bb4c-89eacc410ab1._msdcs.contoso.com. 600 IN CNAME

dc2.contoso.com.

_kerberos._tcp.dc._msdcs.contoso.com. 600 IN SRVO 100 88 dc2.contoso.com.

_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.contoso.com. 600 IN

SRV 0 100 88 dc2.contoso.com.

_ldap._tcp.dc._msdcs.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.

_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.contoso.com. 600 IN SRV 0

100 389 dc2.contoso.com.

_kerberos._tcp.contoso.com. 600 IN SRV 0 100 88 dc2.contoso.com.

_kerberos._tcp.Default-First-Site-Name._sites.contoso.com. 600 IN SRV 0 100 88

dc2.contoso.com.

_gc._tcp.contoso.com. 600 IN SRV 0 100 3268 dc2.contoso.com.

_gc._tcp.Default-First-Site-Name._sites.contoso.com. 600 IN SRVO 100 3268

dl2.contoso.com.

_kerberos._udp.contoso.com. 600 IN SRV 0 100 88 dc2.contoso.com.

_kpasswd._tcp.contoso.com. 600 IN SRV 0 100 464 dc2.contoso.com.

_kpasswd._udp.contoso.com. 600 IN SRV 0 100 464 dc2.contoso.com.

DomainDnsZones.contoso.com. 600 IN A 192.168.1.201

_ldap._tcp.DomainDnsZones.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.

_ldap._lcp.Default-First-Site-Name._sites.DomainDnsZones.contoso.com. 600 IN

SRV 0 100 389 dc2.contoso.com.

ForestDnsZones.contoso.com. 600 IN A 192.168.1.201

_ldap._tcp.ForestDnsZones.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.

_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.contoso.com. 600 IN



SRV 0 100 389 dc2.contoso.com.

Примечание. Если на котроллере домена установлена система Windows Server 2003, все эти записи записываются в файл по имени Netlogon.dns, расположенный в папке %systemroot%\ system32\config. Если вы не хотите допускать динамические обновления на DNS-серверах, вы можете импортировать эти записи в зонные файлы DNS.

Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV. Существуют следующие службы:

_ldap Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2003 или другими LDAP-серверами;

_kerberos - основной опознавательный протокол для всех клиентов Windows 2000 и Windows XP Professional. SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC - Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;

_kpassword — идентифицирует серверы изменения паролей kerberos в сети (это или контроллеры домена с Windows Server 2003 или с другими системами изменения пароля kerberos);

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

Многие из SRV-записей содержат идентификатор сайта в дополнение к компонентам, перечисленным в таблице 3-2. Сайт используется в Active Directory для идентификации одной или более IP-подсетей, которые связаны через высокоскоростные сетевые подключения. Одно из преимуществ использования сайтов состоит в том, что сетевые клиенты всегда будут пробовать войти на контроллер домена, который находится на том же самом сайте, что и клиент. Записи сайта нужны компьютерам для поиска контроллеров домена, расположенных в том же самом сайте, где находится клиент. Подробности механизма, который используется клиентом для поиска информации, касающейся сайта, обсуждаются в следующем разделе.



Другим необходимым компонентом SRV- записей является значение _msdcs, которое имеется во многих записях. Некоторые службы, предусмотренные записями SRV, не относятся к службам, разработанным компанией Microsoft. Например, могут встретиться LDAP или kerberos-cep-веры в реализациях, не принадлежащих Microsoft. Эти серверы также могут регистрировать записи SRV на сервере DNS. Контроллеры домена с Windows Server 2003 регистрируют как основные (generic) записи (например, _ldap._tcp.contoso.com), так и записи, содержащие ссылку на _msdcs. Они ссылаются только на роли, определенные продуктами Microsoft, т.е. на Windows Server 2003 или на контроллеры домена Windows 2000. Записи идентифицируют основную функцию каждого сервера: gc (глобальный каталог), dc (контроллер домена) или pdc (основной эмулятор контроллера домена).

Другая зарегистрированная запись содержит глобальный уникальный идентификатор (GUID - globally unique identifier) домена. Запись GUID домена используется для поиска контроллеров домена в случае его переименования.

Примечание. Имеются записи, расположенные ниже поддоме-нов ForestDnsZones и DomainDnsZones. О них более подробно вы узнаете в разделе «Раздел приложений каталога» этой главы.

Защита с использованием протокола Kerberos

До сих пор в этой главе описывались основы защиты Active Directory без обсуждения фактического механизма, который осуществляет защиту. Основной механизм аутентификации в Active Directory — это протокол Kerberos. Протокол Kerberos был впервые разработан инженерами Массачусетского Технологического института (MIT) в конце 80-х годов. Текущая версия Kerberos - это версия 5 (Kerberos v5), которая описана в документе RFC 1510. Реализация Kerberos в Windows Server 2003 полностью совместима с документом RFC-1510 с некоторыми расширениями для аутентификации открытых (public) ключей.

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

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

Более эффективный доступ к ресурсам. Когда пользователь обращается к сетевому ресурсу в сети, использующему протокол NTLM (например, Microsoft Windows NT 4), то сервер, на котором расположен ресурс, должен контактировать с контроллером домена для проверки разрешения на доступ данного пользователя. В сети, использующей Kerberos, клиент соединяется с контроллером домена и получает билет на сетевое соединение, чтобы получить доступ к серверу ресурса. Это означает, что сервер ресурса не должен соединяться с контроллером домена.

Затраты на мониторинг Active Directory

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

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

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

Часть пропускной способности вашей сети будет использоваться для мониторинга «здоровья» Active Directory на всех контроллерах домена предприятия.

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

Стоит отметить, что стоимость мониторинга быстро повышается, когда вы перемещаетесь на платформу глобального мониторинга предприятия типа Microsoft Operations Manager (MOM). Инструментальные средства MOM дороги, требуют обучения оператора и расходуют большее количество системных ресурсов в отличии от мониторинговых решений Windows Server 2003, но они являются проверенными, интегрированными и поддерживаемыми продуктами.

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

Дополнительная информация. MOM включает управление событиями, мониторинг служб и предупреждений, генерацию отчетов и анализ тенденций. Это делается через центральный пульт, в котором агенты, выполняющиеся на управляемых узлах (серверах, являющихся объектами мониторинга), посылают данные, которые будут проанализированы, отслежены и отображены на едином пульте управления. Эта централизация дает возможность сетевому администратору управлять большой совокупностью серверов из одного места с помощью мощных инструментов, предназначенных для удаленного управления серверами. Системы MOM используют пакеты управления для расширения базовой информации, касающейся определенных сетевых услуг, а также серверных приложений. Пакет управления Base Management Pack содержит характеристики всех служб сервера Windows Server 12003, включая Active Directory, службу доменных имен (DNS) и интернет-службу Microsoft Internet Information Services (IIS). Пакет управления Application Management Pack включает характеристики серверов Microsoft .NET Enterprise Servers, таких как Microsoft Exchange 2000 Server и Microsoft SQL Server 2000. Дополнительную информацию о MOM смотрите на сайте http://www.microsoft.com/mom.

Жесткий диск

Размер пространства на жестком диске, необходимого для хранения службы Active Directory, будет зависеть от количества объектов в домене и от того, является ли данный контроллер домена сервером глобального каталога (GC). Чтобы установить Active Directory на сервер, на котором выполняется система Windows Server 2003, жесткий диск должен удовлетворять следующим минимальным требованиям:

15 Мб свободного пространства - на раздел установки системы;

250 Мб свободного пространства - для базы данных Active Directory Ntds.dit;

50 Мб свободного пространства - для файлов регистрационного журнала транзакций процессора наращивания памяти (ESENT). ESENT представляет собой систему взаимодействия базы данных, которая использует файлы регистрационных журналов для поддержки семантики откатов (rollback), чтобы гарантировать передачу транзакций базе данных.

В дополнение к перечисленным требованиям для поддержки установки папки Sysvol по крайней мере один логический диск должен быть отформатирован под файловую систему NTFS v.5 (версия NTFS, которая используется в системах Microsoft Windows 2000 и Windows Server 2003).

Дополнительная информация. Размер необходимого свободного пространства на жестком диске для установки службы Active Directory будет зависеть от количества объектов в вашем домене и лесу. Чтобы больше узнать о планировании дискового пространства для Active Directory, смотрите статью «Planning Domain Controller Capacity (Планирование вместимости контроллера домена)» на сайте www.microsoft.com/technet/ prodtechnol/windowsserver2003/evaluate/cpp/reskit/adsec/ parti /rkpdscap. asp.

Значения уровней

Значения уровней (high-watermark values) используются для управления тем, какая информация реплицируется между контроллерами домена. Каждый контроллер домена поддерживает свой собственный набор уровней для каждого из своих прямых партнеров по репликации. Уровень -это последнее значение uSNChanged, которое контроллер домена получил от определенного партнера по репликации. Когда контроллер домена посылает модификацию партнеру по репликации, значение uSNChanged посылается вместе с модификацией. Контроллер домена адресата сохраняет его как значение уровня для партнера по репликации.

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

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

Зоны полномочий

Чтобы полностью понимать DNS, вы должны познакомиться с зонами полномочий (zones of authority) и полномочными (authoritative) серверами имен. Каждый основной и дополнительный серверы имен являются полномочными для своего домена. Например, если DNS-сервер содержит зонные файлы для домена Contoso.com, то этот сервер является

полномочным сервером имен для этого домена. Как полномочный сервер имен он не будет отправлять никаких запросов о хостах этой зоны другим DNS-серверам. Многие компании устанавливают конфигурацию DNS-сервера так, как показано на рисунке 3-3. В этом сценарии имеются два основных DNS-сервера, сконфигурированные для домена Contoso.com. DNS1 содержит запись хоста для сервера по имени Webl.Contoso.com, a DNS2-cepBep этой записи не имеет. Когда клиент соединяется с DNS1, он сможет разрешить IP-адрес для Webl. Когда клиент соединяется с DNS2 и запрашивает IP-адрес для Webl, сервер ответит, что хост не может быть найден. Поскольку DNS2 сервер является полномочным для домена Contoso.com, он не будет отправлять запросы серверу DNS1. Его поведение заложено в проекте и, как показывает обсуждение примера в разделе «Практический опыт», это дает определенное преимущество в безопасности.

Рис. 3-3. Множество полномочных DNS-серверов

Практический опыт. Использование нескольких полномочных серверов для одной зоны

Иногда возникает ситуация, когда компания имеет два DNS-сервера, являющимися полномочными для одного домена, и интернет-имя DNS компании и ее внутреннее имя DNS идентичны (как показано на рис. 3-3). Сервер DNS1 находится с внутренней стороны брандмауэра, а сервер DNS2 - с его внешней стороны. Сервер DNS2 используется для разрешения DNS-запросов клиентов интернета, в то время как DNS1 используется для внутренних клиентов и для SRV-записей Active Directory. Поскольку оба сервера полномочны для одной и той же зоны (Contoso.com), они не будут отправлять запросы об этом домене друг другу.

В этом случае необходимо поддерживать уникальную зонную информацию на каждом DNS-сервере. Внешний DNS-сервер, вероятно, будет иметь относительно маленький зонный файл, состоящий из веб-серверов и МХ-записей, которые должны быть доступны из интернета. Внутренний DNS-сервер будет иметь намного больший зонный файл, содержащий все записи контроллера домена, все внутренние записи сервера и, возможно, записи хоста для всех клиентских компьютеров в сети. Единственное дублирование между двумя зонными файлами может состоять из некоторых внешних записей DNS. Например, когда внутренние клиенты соединяются с www.Contoso.com, вы можете потребовать, чтобы они соединялись с тем же внешним веб-сервером, к которому обращаются интернет-клиенты. Для этого нужно включить запись хоста для вебсервера в зонный файл на DNS1. Если вы не сделаете этого, то внутренние клиенты не смогут соединяться с веб-сервером.

---

---