Просмотр записей АСЕ с помощью инструмента Ldp.exe

Графический интерфейс пользователя (GUI) является инструментом, который очень удобен для управления огромной совокупностью АСЕ-записей. Чтобы получить возможность по-настоящему оценить значение GUI, потратьте некоторое время на знакомство с инструментом Ldp.exe. Чтобы просмотреть список ACL с помощью Ldp.exe, откройте диалоговое окно Run (Выполнить) и напечатайте ldp. (Если Ldp.exe не был установлен на компьютере, откройте папку \SUPPORT\TOOLS на компакт-диске Windows Server 2003 и дважды щелкнете на файле Suptools.msi, чтобы установить средства поддержки Active Directory.) Выберите раскрывающееся меню Connection (Подключения), затем выберите Connect (Подключиться). Если вы оставите пустым поле сервера, то сервер соединится с локальным компьютером. Вы можете напечатать имя сервера. Как только вы свяжетесь с сервером, выберите раскрывающееся меню Connection (Подключения) и выберите Bind (Связаться). Если вы входите не с учетной записью пользователя, имеющей административные права, введите дополнительные мандаты. Другим способом, оставьте пробелы в полях, предназначенных для информации входа в систему. После подключения к домену щелкните на раскрывающемся меню View (Вид), а затем выберите Tree (Дерево). Чтобы просмотреть весь домен, щелкните на ОК. Структура OU домена будет представлена в левой области окна (см. рис. 9-5).

Чтобы просмотреть список ACL для любого объекТа, найдите объект в дереве в левой области окна. Затем щелкните правой кнопкой мыши на объекте и выберите Advanced (Дополнительно), затем - Security Descriptor (Дескриптор защиты). Список ACL хранится в значении NT Security Descriptor каждого объекта Active Directory. Затем инструмент Ldp.exe запишет каждый АСЕ в правую область окна в зашифрованном формате:

(A;; CCDCLCSWRPWPDTLOCRSDRCWDWO;;; DA)

Каждая пара букв в первом списке АСЕ-записей соответствует определенному разрешению. Например, СС означает, что пользователь имеет право создать все дочерние объекты. Последние две буквы в АСЕ записи относятся к группе или пользователю, который имеет разрешения DA, т.е. относится к группе Domain Admins. Если разрешения назначены пользователю или группе, которая не имеет известного иден-

тификатора SID, то последняя часть каждой записи АСЕ содержит SID пользователя или группы. (Чтобы увидеть полный список всех возможных разрешений, которые могут быть назначены в записях АСЕ, просмотрите справочную информацию для команды DsAcls, сопровождающую инструменты Active Directory. Инструмент командной строки DsAcls может использоваться для назначения или удаления разрешений к любому объекту в Active Directory).



Рис. 9-5. Использование инструмента Ldp.exe для просмотра свойств домена

После строк такого типа информации инструмент Ldp.exe даст более понятное объяснение каждой записи АСЕ. Например, для строки, приведенной выше, это будет выглядеть так:

Асе[О]

Асе Туре: 0x0 - ACCESS_ALLOWED_ACE_TYPE

Асе Size: 36 bytes

Асе Flags: 0x0

Асе Mask: OxOOOfOiff

DELETE

READ CONTROL

WRITE DAC

WRITE_OWNER

ACTRL DS CREATE_CHILD

ACTRL DS DELETE CHILD



ACTRL DS LIST

ACTRL DS SELF

ACTRL DS READ_PROP ACTRL DS WRITE_PROP ACTRL_DS_DELETE_TREE ACTRL_DS_UST_OBJECT ACTRL_DS_CONTROL_ACCESS

Ace Sid: Contoso\Domain Admins S-1 -5-21 -602162358-688789844-1957994488-512

Проведение экспериментальной модернизации

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

Тестирует ваш план перехода в производственной среде.

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

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

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

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

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

Проверка целостности базы данных

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

ных, то работа с большой базой данных требует много времени. Чтобы выполнить проверку целостности, напечатайте integrity в командной строке File Maintenance утилиты Ntdsutil.

Проверка целостности сведений (Knowledge Consistency Checker)

КСС (Knowledge Consistency Checker) — это процесс, который выполняется на каждом контроллере домена, он ответствен за создание топологии репликации в пределах сайта и между сайтами. Как только к лесу Active Directory добавляется второй контроллер домена, служба КСС начинает создавать топологию репликации, которая является и эффективной, и терпимой к ошибкам. По мере добавления к сайту других контроллеров домена или новых сайтов КСС использует информацию о серверах, сайтах, связях сайта и расписаниях для создания оптимальной топологии репликации. Служба КСС динамически анализирует изменения или отказы, возникающие в пределах топологии репликации. Если один из контроллеров домена временно находится в автономном режиме, то КСС пересматривает топологию репликации, чтобы обойти неработающий контроллер домена. По умолчанию КСС каждого контроллера домена повторно вычисляет топологию репликации каждые 15 минут. Имеется возможность в любое время повторно вычислить топологию репликации с помощью инструмента администрирования Active Directory Sites And Services (Сайты и службы Active Directory). Найдя сервер, на котором вы хотите проверить топологию репликации, и щелкнув правой кнопкой мыши на NTDS Settings (Параметры настройки NTDS) в контейнере сервера, выберите опцию All Tasks (Все задачи), затем выберите Check Replication Topology (Проверить топологию репликации).

Проверка или установка DNS-сервера

Active Directory требует, чтобы в сети была установлена служба DNS, тогда компьютеры-клиенты смогут находить контроллеры домена для аутентификации. Для этого реализация DNS должна поддерживать записи SRV. Microsoft рекомендует также поддержку динамических обновлений. Реализация службы DNS в сети может быть выполнена не на платформе Microsoft, это может быть DNS-сервер, работающий под Windows NT 4 (SP4), Windows 2000 Server или Windows Server 2003.

Рис. 6-12. Окно Shared System Volume (Общедоступный системный том)

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

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

вера (в окне свойств TCP/IP) будут модифицированы для указания на локальный DNS-сервер. (Выше рекомендовалось сконфигурировать локальный IP-адрес компьютера перед инсталляцией Active Directory.)

Рис, 6-13. Окно DNS Registration Diagnostics (Диагностика регистрации DNS) мастера инсталляции Active Directory

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

Проверка обновления до Active Directory

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

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

Проверьте доверительные отношения с помощью инструмента Active Directory Domains And Trusts (Домены и доверительные отношения Active Directory).

Проверьте системный журнал Event Viewer (Средство просмотра событий) в поисках каких-либо ошибок, которые могли произойти при запуске службы Active Directory.

Проверьте, можете ли вы создавать новых пользователей на контроллере домена Windows Server 2003. На модернизированном контроллере домена откройте инструмент Active Directory Users And Computers и создайте новую контрольную учетную запись пользователя.

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

Проверьте репликацию на BDC контроллеры. После создания нового контрольного пользователя откройте User Manager For Domains на BDC с системой Windows NT 4 Server и проверьте, что пользователь реплицируется. Вы можете отсоединить контроллер домена Windows Server 2003 от сети и войти в сеть как контрольный пользователь, чтобы BDC с системой Windows NT 4 обработал запрос входа в систему.

Средства диагностики Active Directory расположены в комплекте Support Tools (Средства поддержки) на компакт-диске Windows Server 2003. Вы можете установить эти средства на обновленном контроллере домена с Windows Server 2003, выполняя файл Suptools.msi из папки \SUPPORT\TOOLS, расположенной на компакт-диске Windows Server 2003. Нужно выполнить следующие действия по диагностической проверке.

Чтобы проверить способность к взаимодействию и функциональность Active Directory, запустите инструмент Domain Controller Diagnostic (Диагностика контроллера домена) (в командной строке напечатайте dcdiag). В результате успешного испытания возвращается ряд сообщений «passed» (пройдено).

Дополнительная информация. Компонент Dcdiag инструмента Support Tool Windows Server 2003 анализирует состояние контроллеров домена в лесу и дает детальную информацию о том, как идентифицировать неправильное поведение в системе. Контроллеры домена идентифицируются и проверяются согласно директивам, которые пользователь вводит в командную строку. Для получения дополнительной информации об инструменте Dcdiag напечатайте dcdiag/? в командной строке.

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

Чтобы проверить успешность репликации на контроллеры BDC, напечатайте nltest/bdc_query:domainname, где domainname — имя реп-лицируемого домена. В результате успешного испытания возвращается сообщение «status = success (статус = успех)» для каждого BDC контроллера в домене.

После проверки обновления PDC вы можете модернизировать контроллеры BDC.

Публикация принтеров в Active Directory

По умолчанию любой принтер, установленный на сервере с Windows 2000 или Windows Server 2003, к которому разрешен общий доступ, автоматически публикуется в Active Directory. Если этого не требуется, можно очистить опцию List In The Directory (Зарегистрировать в каталоге) в окне Properties (Свойства) принтера. Однако если принтер расположен на сервере с системой Windows NT или другой операционной системой, вы должны вручную опубликовать принтер в Active Directory. Чтобы выполнить это, найдите объект container, в котором вы хотите опубликовать объект printer, щелкните на нем правой кнопкой мыши и выберите New (Новый)>Printer (Принтер). Затем напечатайте UNC-путь на общедоступный компьютер.

Совет. Если вы используете серверы печати Windows NT и не хотите модернизировать их до Windows 2000 или Windows Server 2003, нужно вручную опубликовать все принтеры на серверах печати Windows NT в Active Directory. Компания Microsoft создала сценарий с именем Pubprn.vbs, предназначенный для автоматизации процесса публикации. Этот сценарий расположен в папке %systemroot %\system32.

Публикация принтера в Active Directory нужна для поиска пользователями объектов printer в Active Directory. После публикации принтера информация о нем автоматически регистрируется в окне Properties (Свойства) принтера, доступного из инструмента Active Directory Users And Computers. Эта информация нужна пользователю, который ищет определенный принтер, например, цветной принтер, который печатает, по крайней мере, шесть страниц в минуту. Если эта информация хранится в Active Directory, клиент может использовать опцию A Printer On The Network (Сетевой принтер) операции Search (Поиск), выбранной из меню Start (Пуск), чтобы найти все принтеры, удовлетворяющие этим требованиям. На рисунке 10-7 показано окно на рабочей станции с системой Windows ХР Professional. Как только сетевой принтер найден, пользователь может щелкнуть правой кнопкой мыши на принтере и выбрать Connect (Подключить), чтобы установить принтер на машине клиента.

Если объекты printer опубликованы в Active Directory, для управления ими используется редактор Group Policy Object Editor (см. рис. 10-8).

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

дым сервером печати каждые 8 часов, чтобы подтвердить правильность информации о принтере. Если сервер печати не отвечает, объект printer удаляется из Active Directory. При каждом запуске сервера печати Windows 2000, или более поздней версии, он автоматически повторно регистрирует общие принтеры на сервере в Active Directory. Вы можете сконфигурировать параметры удаления принтера, используя редактор Group Policy Object Editor.



Рис. 10-7. Поиск принтеров в Active Directory



Рис. 10-8. Конфигурирование параметров настройки принтера с помощью редактора Group Policy Object Editor

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

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



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

Откройте инструмент Active Directory Sites And Services и найдите объект subnet (подсеть), в котором включите мониторинг местоположения принтеров. Щелкните правой кнопкой мыши на объекте subnet и выберите Properties (Свойства). Щелкните на вкладке Location (Местоположение) и введите значение location (место расположения) для этой подсети. Запись места расположения должна иметь формат: location/sublocation (Общее расположение/детализированное расположение) (например, Главный офис/Третий этаж).

Используйте редактор Group Policy Object Editor для включения политики Pre-Popula-te Printer Search Location Text (Предварительно заполнить текст, указывающий место расположения принтера при поиске) для выбранного контейнера. В большинстве случаев это делается на уровне домена.

На вашем сервере печати обратитесь к окну Properties для каждого принтера. На вкладке General (Общее) вы можете заполнить место расположения принтера. Если первые два шага этой процедуры завершены, можете щелкнуть на Browse (Просмотр), чтобы найти место расположения принтера. Можно добавить больше деталей к описанию места расположения принтера, чтобы оно было лучше определено (например, Главный офис/Третий этаж/Внешняя комната для собраний 5).

После того как вы включили мониторинг места расположения принтеров, пользователи могут легко находить ближайший к ним принтер. Когда пользователь запускает Add Printer Wizard (Мастер добавления принтера) и ищет принтер в каталоге, атрибут Location (Место расположения) заполняется в соответствии с текущим сайтом пользователя. На рисунке 10-9 показано окно клиента Windows ХР Professional. Пользователь может щелкнуть Browse для нахождения более точного места расположения принтера.



Рис. 10-9. Поиск объекта printer в Active Directory с помощью атрибута Location

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

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

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

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

Ваша цель может состоять в объединении несколько доменов в вашей организации. Большие организации могут иметь сотни доменов, отвечающих потребностям службы каталога их пользователей. Почему количество доменов растет, выходя из-под контроля? Одна из причин - довольно низкий размер базы данных SAM (предел в 80 Мб, выше которого происходит ухудшение производительности, для существующих аппаратных стандартов, 40 Мб - на более старых системах). По мере роста организации должны добавлять большее число доменов Windows NT 4, чтобы удовлетворить возрастающие требования к объему. Другая причина «раздувания домена» - это модель с одним хозяином домена. Она использует

домены учетных записей для учетных записей пользователей и групп, домены ресурсов для общедоступных ресурсов (компьютеров, принтеров и т.д.) и локальные группы, которые управляют доступом к ресурсам. По мере увеличения количества общедоступных ресурсов в сети растет и число доменов ресурсов. В результате возникает слишком много доменов, и административные заботы увеличиваются. Такая организация является хорошим кандидатом на реструктуризацию домена, причем сокращение количества доменов должно быть целью при проектировании Active Directory. Домены Active Directory Windows Server 2003 могут поддерживать миллионы объектов, возможно объединение такое количество доменов учетных записей, которое необходимо для удовлетворения потребностей вашего бизнеса. Через введение OU вы можете достичь того же уровня административной власти, какой вы имели в доменной модели системы Windows NT 4, без необходимости делать всех администраторов ресурсов членами группы Domain Admins (Администраторы домена). Организация с сотнями доменов Windows NT 4 может перейти к Active Directory с единственным доменом.

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

Пути перехода

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

Существует три пути перехода:

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

реструктуризация домена;

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

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

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

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

Работа подсистемы защиты

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

Табл. 14-3. Ключевые объемы, связанные с защитой

Объект		Счетчик		Рекомендуемый интервал		Почему этот счетчик важен
NTDS		NTLM Authentications (NTLM аутентификации)		Каждые 15 минут		Указывает количество клиентов в секунду, которые аутенти-фицируются на контроллере домена, используя NTLM вместо Kerberos (клиенты, имеющие более ранние, чем Windows 2000, системы или аутентификация между лесами).
NTDS		KDC AS Requests (Запросы KDC AS)		Каждые 15 минут		Указывает количество билетов сеанса, выпускаемых в секунду центром распределения ключей (KDC). Позволяет наблюдать воздействие изменения срока службы билета.
NTDS		Kerberos Authentications (Аутентификации Kerberos)		Каждые 15 минут		Указывает количество нагрузки, связанной с аутентификацией, получаемой центром KDC. Позволяет наблюдать тенденции роста.
NTDS		KDC TGS Requests (Запросы KDC TGS)		Каждые 15 минут		Указывает количество TGT билетов, выпускаемых службой KDC. Используется для наблюдения за изменением срока службы билета.

Распределение программного обеспечения и пропускная способность сети

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

Другой способ управлять использованием сети для нескольких сайтов состоит в том, чтобы применить распределенную файловую систему (Distributed File System - DFS). С помощью DFS можно создать структуру логического каталога, не зависящую от того, в каком месте сети фактически хранятся файлы. Например, можно создать корень DFS с именем \\serverl\softinst, а затем для всех приложений создать подкаталоги ниже этой общей точки. С помощью системы D*FS можно найти подкаталоги на нескольких серверах и сконфигурировать физические связи к одним и тем же логическим каталогам. Если вы используете интегрированную систему DFS, можно сконфигурировать автоматическую репликацию содержания папки между копиями одного и того же каталога. Система DFS является приложением, учитывающим наличие сайтов, т.е. если у вас имеется несколько сайтов, то компьютеры клиентов будут всегда подключаться к копии DFS папки, расположенной в их собственном сайте, вместо того чтобы пересекать глобальную сеть WAN для обращения к папке, расположенной в другом сайте.

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

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

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

Распределенная база данных

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

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

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

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

Раздел домена каталога

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

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

Раздел глобального каталога

Раздел глобального каталога GC не является разделом в полном смысле. Он хранится в базе данных подобно другому разделу, но администраторы не могут вводить информацию в него напрямую. Раздел GC предназначен только для чтения на всех GC-серверах, он построен из содержимого баз данных домена. Каждый атрибут в схеме имеет булевое значение с именем isMemberOf Partial Attributes et. Если оно установлено на true (истина), атрибут копируется в каталог GC.

Раздел конфигурации каталога

Раздел конфигурации содержит информацию о конфигурации леса, например, информацию о сайтах, связях сайта и подключениях репликации. В нем хранят информацию многие прикладные программы. Приложения Exchange Server 2000, Microsoft Internet Security And Acceleration (ISA) Server помещают свою конфигурационную информацию в раздел конфигурации каталога Active Directory, а не в свою собственную службу каталога. Когда вы устанавливаете первый ISA-сервер в свою организацию, вы можете сконфигурировать массив, который будет хранить всю конфигурационную информацию ISA в Active Directory. Затем легко устанавливаются дополнительные ISA-серверы, использующие эту же конфигурацию, которая читается из службы Active Directory.

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

Раздел приложений каталога

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

DNS в Active Directory Windows Server 2003 использует раздел приложений каталога для облегчения репликации информации DNS в лесу. При установке DNS, когда вы назначаете первый сервер в лесу на роль контроллера домена, в Active Directory создаются два новых раздела каталога. Это разделы DomainDnsZones и ForestDnsZones. (Их не видно ни в одном из обычных инструментальных средств управления Active Directory, они отображаются при использовании ADSI Edit или Ldp.exe; использование ADSI Edit показано на рисунке 3-11.) Каждый из этих разделов хранит разную конфигурацию репликации. Раздел DomainDnsZones реплицируется на все серверы DNS, выполняющиеся на контроллерах домена. Раздел ForestDnsZones реплицируется на все серверы DNS, выполняющиеся на контроллерах домена в лесу. Вы можете хранить информацию DNS в разделе каталога домена, т.е. она будет копироваться на все контроллеры домена в домене.

Необходимо выбрать место хранения информации DNS при создании новой зоны (см. рис. 3-12) в окне Zone Properties (Свойства зоны) в инструменте администрирования DNS. Имеются четыре варианта хранения информации DNS.

То All DNS Servers In The Active Directory Forest domainname (Ha все серверы DNS леса Active Directory). Информация хранится в разделе ForestDnsZones, откуда копируется на все серверы DNS контроллеров домена леса. Эта конфигурация задана по умолчанию для зоны _msdcs в интегрированной зоне Active Directory.

Рис. 3-11. Раздел приложений каталога DNS в инструменте ADSI Edit

То All DNS Servers In The Active Directory Domain domainname (Ha все серверы DNS в домене Active Directory). Информация хранится в разделе DomamDnsZones, откуда копируется на все серверы DNS, выполняющиеся на контроллерах домена. Это конфигурация, принятая по умолчанию для интегрированной зоны Active Directory, созданной в процессе обновления контроллера домена.

То All Domain Controllers In The Active Directory Domain domainname (На все контроллеры домена в домене Active Directory). Информация хранится в разделе домена каталога, откуда копируется на все контроллеры домена. Различие между этой опцией и предыдущей состоит в том, что в этом случае все контроллеры домена получат информацию, в то время как раздел DomamDnsZones реплицируется только на контроллеры домена, являющиеся серверами DNS.

То All Domain Controllers Specified In The Scope Of The Following Application Directory Partition (На все контроллеры домена в пределах следующего раздела приложений каталога). Эта опция доступна только в том случае, если вы создаете дополнительный раздел приложений каталога с его собственной конфигурацией репликации. Информация DNS будет копироваться на все контроллеры домена, которые имеют реплику этого раздела.

Примечание. Раздел приложений каталога для DNS создается только в том случае, если выбрана установка DNS при назначении первого контроллера домена или леса. Если вы хотите воспользоваться преимуществами раздела приложений каталога для DNS после того, как обновили контроллер домена, необходимо вручную создать раздел перед его использованием. Для создания раздела применяется инструмент администрирования DNS или инструмент командной строки DNSCMD. При использовании инструмента администрирования DNS щелкните правой кнопкой мыши на имени сервера DNS и выберите Create Default Application Directory Partitions (Создание заданных по умолчанию разделов приложений каталога). При использовании инструмента DNSCMD откройте командную строку и напечатайте dnscmd DN S servername/CreateBuiltin-DirectoryPartitions /forest. В результате будет создан раздел ForestDnsZones. Чтобы создать раздел DomainDnsZones, используйте «/domain» в качестве последнего параметра в команде. Поскольку эта команда изменяет раздел конфигурации каталога в Active Directory, вы должны входить в систему как член группы Enterprise Admins (Администраторы предприятия).



Рис. 3-12. Конфигурирование области репликации для зон DNS

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

Раздел схемы каталога

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

Разделы Active Directory

Как вы уже знаете, база данных Active Directory хранится в файле на жестком диске каждого контроллера домена. Она разделена на несколько логических разделов, каждый из которых хранит различные типы информации. Разделы Active Directory называются контекстами именования (NC - naming contexts). Просмотреть их можно с помощью инструмента Ldp.exe или ADSI Edit (рис. 2-4).

Рис. 2-4. Просмотр разделов Active Directory с помощью инструмента ADSI Edit

Разделы приложений каталога

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

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

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

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

Совет. Обычно разделы приложений каталога создаются в процессе инсталляции приложения, для которого требуется использование раздела каталога. Инсталляционная процедура приложения должна разрешать создание дополнительных реплик на других контроллерах домена. Вы можете создать каталог приложений с помощью утилиты Ntdsutil, но в среде предприятия это обычно не используется. Процедуры управления разделами приложений каталога описаны в справке Windows Server 2003 Help And Support Center (Центр справки и поддержки Windows Server 2003). Для получения детальной информации о разделах приложений каталога, о том, как обращаться к ним программно, сделайте поиск фразы «Using application directory partitions» на сайте msdn.microsoft.com.

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

Размещение DNS-серверов

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

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

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

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

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

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

Несмотря на это, планирование и развертывание сайтов Active Directory в компании с сотнями сайтов все еще является сложным случаем. Если вы имеете дело с таким типом среды, то лучшим ресурсом для вас является Active Directory Branch Office Planning Guide (Руководство планирования Active Directory для филиалов), имеющееся на сайте Microsoft по адресу http://www.microsoft.com/windows2000/ techinfо/planning/activedirectory/branchofficе/default.asp. Хотя это руководство подготовлено для Windows 2000, многие из концепций применимы к Windows Server 2003.

Размещение контроллеров домена

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

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

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

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

Размещение серверов глобального каталога

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

бы размещать GC-сервер в каждом сайте и несколько GC-серверов в больших сайтах.

Одно из улучшений Active Directory Windows Server 2003 состоит в том, что эта система поддерживает входы в систему домена без доступа к GC-серверу за счет кэширования универсального группового членства. Когда эта функция включена, контроллеры домена могут кэшировать универсальное групповое членство пользователей в домене. Когда пользователь входит на сайт в первый раз, универсальное членство группы пользователя должно быть найдено в GC-сервере. После первого входа в систему контроллер домена будет кэшировать универсальное групповое членство пользователя неопределенно долго. Кэш на контроллере домена модифицируется каждые 8 часов в результате контакта с назначенным GC сервером. Чтобы включить функцию универсального группового членства, откройте инструмент администрирования Active Directory Sites And Services (Сайты и службы Active Directory) и разверните объект того сайта, на котором вы хотите включить эту установку. Щелкните правой кнопкой мыши на объекте NTDS Site Settings (NTDS параметры сайта) и выберите Properties (Свойства) (см. рис. 5-13). На вкладке Site Settings (Параметры установки сайта) выберите опцию Enable Universal Group Membership Caching (Разрешить кэширование универсального группового членства) и в раскрывающемся списке Refresh Cache From (Обновить кэш из) выберите сайт, в котором расположен самый близкий GC-сервер.

Рис. 5-13. Конфигурирование кэширования универсального группового членства

Совет. Развертывание Exchange Server 2000 создает большую нагрузку на GC-серверах. Exchange Server 2000 не имеет своей собственной службы каталога, так что он зависит от GC. Когда клиент просматривает GAL, он видит всех получателей почты, перечисленных в GC. Когда Exchange Server 2000 надо найти адрес пользователя, чтобы доставить электронную почту, он делает запрос каталогу GC. Если вы развертываете Exchange Server 2000, вы должны расположить GC в каждом месте, где выполняется Exchange Server 2000, и увеличить общее количество GC серверов.

Размещение серверов хозяев операций

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

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

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

Хозяин RID должен быть доступен для всех контроллеров домена через подключение по удаленному запросу процедуры (RPC). Когда контроллеру домена потребуется больше идентификаторов RID, он будет использовать RPC подключение, чтобы запросить их у хозяина RID.

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

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

Разрешение

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

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

Разрешения объектов службы Active Directory

Как описано в главе 8, когда пользователь входит в сеть Windows Server 2003, ему предоставляется лексема доступа. Лексема доступа включает идентификаторы защиты (SID) для учетной записи пользователя, а также SID для всех групп, к которым принадлежит пользователь. Как только пользователь вошел, он пытается обратиться к сетевому ресурсу, ко-

торый включает объект Active Directory. Каждый сетевой ресурс или объект Active Directory имеет список ACL, хранящийся в его атрибуте NT Security Descriptor, который состоит из одной или более записей управления доступом (АСЕ), определяющей, какие права на данный объект имеет каждый идентификатор SID. Дескриптор защиты содержит владельца объекта, а также список управления разграничительным доступом (DACL) и список управления системным доступом (SACL). Список DACL определяет разрешения на объект, которые имеют все участники безопасности. Список SACL определяет параметры настройки аудита объекта.

Примечание. Каждый объект в Active Directory имеет список ACL, т.е. разрешения на этом объекте можно изменять. Это справедливо для объектов, отражаемых как через инструменты Active Directory Users And Computers (Пользователи и компьютеры Active Directory), Active Directory Sites And Services (Сайты и службы Active Directory), ADSI Edit или Ldp.exe. Основное внимание в этой главе будет уделено объектам, отображаемым через Active Directory Users And Computers, потому что почти все администрирование защиты выполняется с помощью этого инструмента. Однако многие из концепций и процедур, обсуждаемых здесь, могут применяться и к другим инструментальным средствам администрирования Active Directory. Например, вы можете использовать тот факт, что каждый объект имеет список ACL, чтобы изменить разрешения для объектов сайтов в инструменте Active Directory Sites And Services. Можно использовать также Delegation Of Control Wizard, который будет обсуждаться позже в этой главе.

Есть множество различных инструментов, которые могут использоваться для просмотра дескриптора защиты любого объектов Active Directory. Обычно используется инструмент Active Directory Users And Computers. Он может давать несколько различных представлений списков ACL. Это связано с тем, что разрешения на доступ к объектам Active Directory разбиты на две категории: стандартные (standard) и специальные (special). Просмотр информации о защите через Active Directory Users And Computers осложняется, если вы можете предоставлять разрешения объектам внутри контейнерного объекта или атрибутам объекта.

Развертывание приложений

После создания сетевого ресурса и копирования на него инсталляционных файлов вы готовы к реализации объектов групповой политики GPO, которые будут публиковать приложение для клиентов. Вы можете создать новый объект GPO или изменить существующий. При конфигурировании GPO вы должны сначала определить, необходимо ли публиковать приложение для компьютеров или пользователей. Используйте контейнер Computer Configuration\Software Settings в Group Policy Object Editor (Редактор объектов групповой политики), и приложение будет установлено на рабочей станции, когда она перезагрузится в следующий раз. Если вы решите публиковать приложение для пользователей, используйте контейнер User Conf iguration\Sof tware Settings в редакторе объектов групповой политики, и приложение будет доступно пользователю при его следующем входе в систему.

Примечание. В главе 11 была представлена консоль управления групповыми политиками Microsoft Group Policy Management Console (GPMC), являющаяся мощным инструментом для управления всеми конфигурациями групповых политик целой организации. Поскольку консоль разработана как отдельный инструмент, предназначенный для управления групповой политикой, то ее пользовательский интерфейс сильно отличается от интерфейса, используемого в других инструментах администрирования Active Directory. Однако поскольку GPMC-консоль не является обязательным дополнением, то информация, данная в главах 11, 12 и 13, базируется на использовании только тех инструментов администрирования и оснасток, которые поставляются как часть инсталляционного компакт-диска Windows Server 2003.

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

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

Когда вы назначаете приложение пользователю, оно будет опубликовано, когда пользователь в следующий раз войдет в сеть. Можно сконфигурировать то, каким образом это будет происходить, но обычно приложение добавляется к меню Start (Пуск). Приложение будет также добавлено к списку опубликованных приложений в панели управления Add Or Remove Programs (Добавление или удаление программ). По умолчанию приложение устанавливается не при входе пользователя в систему, а при активации из меню Start или через панель Add Or Remove Programs. Можно сконфигурировать такую логику установки, что приложение установится, когда пользователь попытается открыть файл с расширением, которое ассоциировано с данным приложением. Например, приложение Microsoft Word отсутствует на компьютере пользователя. Если он щелкнет два раза на файле с расширением .doc, то Word будет автоматически установлен. Этот процесс часто называют активацией расширений (extension activation).

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

приложения не будут установлены полностью, пока они не инсталлируются через панель Add Or Remove Programs или через активацию расширения. Эта опция не используется, если приложение назначено компьютеру, потому что приложение полностью устанавливается только при перезагрузке компьютера.

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



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

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

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

Найдите контейнер: сайт, домен или организационную единицу (OU), в котором вы хотите опубликовать приложение, и обратитесь к свойствам контейнера. Щелкните на вкладке Group Policy (Групповая политика). Создайте новый объект GPO или щелкните на кнопке Edit (Правка) для изменения свойств существующего объекта GPO.

Если вы публикуете приложение для учетных записей пользователей, раскройте контейнер User Conf iguration\Sof tware Settings (Конфигурирование пользователей\Параметры настройки программ) в редакторе объектов групповых политик, щелкните правой кнопкой мыши на кнопке Software Installation (Инсталляция программ), выберите New (Новый), а затем выберите Package (Пакет). Если вы публикуете приложение для компьютерных учетных записей, то раскройте контейнер Computer Configuration\Software Settings (Конфигурирование компьютеров\Параметры настройки программ) в редакторе GPO, щелкните правой кнопкой мыши на кнопке Software Installation (Инсталляция программ), выберите New (Новый), а затем выберите Package (Пакет).

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



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

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



Рис. 12-1. Опции для публикации пакета программ

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

Как только объект GPO сконфигурирован, приложение будет опубликовано для всех клиентов контейнерного объекта. По умолчанию программный инсталляционный компонент групповой политики применяется только при входе пользователя в систему (если политика применяется к учетным записям пользователей) или при перезагрузке компьютера (если политика применяется к компьютерным учетным записям). Инструмент командной строки GPUpdate, который имеется на всех компьютерах с системами Windows XP Professional и Windows Server 2003, может вызвать принудительный выход из системы или перезагрузку на рабочей станции как часть обновления, связанного с групповой политикой. Чтобы вызвать выход из системы или перезагрузку, используйте команду gpupdate /logoff или gpupdate /reboot.

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

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

Прежде чем вы сможете опубликовать приложение для пользователей сети, нужно скопировать инсталляционные файлы программ, включая .msi-файл, на доступный сетевой ресурс. Необходима гарантия того, что все пользователи или компьютеры имеют соответствующий доступ к ресурсу. Если вы назначаете приложение для компьютеров, компьютерные учетные записи должны иметь доступ Read (Чтение). Если вы назначаете или публикуете приложение для пользователей, то пользователи должны иметь доступ Read. (Смотрите следующий раздел для сравнения деталей назначения приложений и публикации приложений.)

Реализация групповых политик

Когда вы создаете новый объект GPO или модифицируете существующий, изменения по умолчанию делаются на эмуляторе основного контроллера домена (PDC). В большинстве случаев нужно принять это для уменьшения вероятности того, что несколько администраторов сделают несовместимые изменения параметров настройки групповой политики. Однако если эмулятор PDC недоступен в то время, когда нужно сделать изменения, вам необходимо выбрать контроллера домена, с которым можно будет соединиться (см. рис. 11-3). (Вы можете модифицировать то, какой контроллер домена будет изменен, обращаясь к тому же самому окну через меню View (Вид)>БС Options (Выбор DC) в редакторе объектов групповой политики.) Если вы выберете соединение с контроллером домена, имеющим лексему Operations Master (Хозяин операций) для эмулятора PDC, то соединитесь с эмулятором PDC. Вы можете также делать изменения на контроллере домена, с которым связаны в текущий момент, или на любом другом контроллере домена.

Рис. 11 -3. Выбор контроллера домена, на котором будут сделаны изменения объекта GPO

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

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

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

ность соединяться с контроллером домена, расположенном в исходном домене GPO, для загрузки групповой политики. Если один из контроллеров домена находится в том же сайте, где и компьютеры-клиенты, это не очень сильно отразится на пропускной способности сети. Однако если все контроллеры домена, имеющие копию GPO объекта, находятся в другом сайте, соединенным медленным WAN-подключением, то применение групповой политики будет происходить очень медленно и может серьезно воздействовать на пропускную способность. Кроме того, если пользователи, принадлежащие одному домену, должны применять групповую политику, созданную в другом домене, то пользователи и компьютеры, принадлежащие домену-адресату, должны иметь разрешение Read к объектам GPC в Active Directory и к объектам GPT в папке Sysvol. В большинстве случаев наилучшей практикой является создание объектов GPO в каждом домене вместо совместного использования одного объекта GPO в нескольких доменах.

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

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

Сценарии входа в систему могут располагаться на контроллере домена другого леса и читаться оттуда.

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

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

Репликация глобального каталога

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

GC представляет собой список всех атрибутов, переданных в него, атрибут isMemberOfPartialAttributesSet которых установлен на true (истину).

Тот факт, что GC создан из баз данных доменов, затрагивает также кольцо репликации для GC. Каждый GC-сервер должен получить GC-информацию от контроллеров домена всех доменов. На рисунке 4-7 приведен пример компании, имеющей два домена с одним контроллером домена в каждом; оба домена расположены в одном и том же сайте. Домен DCl.Contoso.com сконфигурирован как сервер глобального каталога. GC-сервер является также единственным контроллером домена для домена Contoso.com, поэтому он извлекает GC-информацию для Contoso.com из своей собственной базы данных домена. Контроллер домена в домене Fabrikam.com имеет единственную копию раздела каталога этого домена, поэтому DCl.Contoso.com собирает GC-информацию для домена Fabrikam.com из DC2.Fabrikam.com. Для извлечения информации из домена Fabrikam.com создан объект связи, направленный от DC2.Fabrikam.com к DCl.Contoso.com. В дальнейшем эта связь может использоваться для репликации GC-информации в DCl.Contoso.com.

Рис. 4-7. Пример простой репликации глобального каталога

На рисунке 4-8 показан более сложный пример создания GC и его репликации. В этом случае сконфигурирован объект связи, направленный от контроллера домена каждого домена на каждый GC-сервер. DCl.Contoso.com имеет входящий объект связи от контроллеров DC2.Contoso.com, DC4.Fabrikam.com и DC6.NWTraders.com. Этот объект связи используется для создания глобального каталога на DCl.Contoso.com. Все другие GC-серверы имеют подобный набор объектов связи. Кроме того, создано также отдельное кольцо для репликации раздела GC между всеми GC серверами.

Репликация изменений

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

Для репликации изменений информации каталога контроллерам домена требуется механизм для управления потоком репликации. Для оптимизации репликации Active Directory следует пересылать только те изменения, которые должны реплицироваться между двумя контроллерами домена. Контроллеры домена должны уметь определять эти изменения, если таковые вообще имеются, а затем копировать только ту часть изменений, которая требуется. Для управления репликацией каталога в Active Directory используются порядковые номера обновлений (USN - update sequence number), значения уровня (high-watermark value), векторы новизны (up-to-dateness vectors) и отметки об изменениях (change stamps). Эти компоненты обсуждаются далее.

Репликация между сайтами

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

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

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

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

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

Трафик репликации посылается не партнерам по репликации, а через серверы-плацдармы. Изменения каталога сайта реплицируются на единственный сервер-плацдарм (один на каждый раздел каталога) этого сайта, а затем — на сервер-плацдарм другого сайта. Далее изменения реплицируются с сервера-плацдарма второго сайта на все контроллеры домена этого сайта.

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

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

Репликация удалений объектов

Репликация удалений объектов обрабатывается в Active Directory иначе, чем другие модификации каталога. Когда удаляется учетная записи пользователя, она не уничтожается немедленно. Вместо этого создается объект-памятник (tombstone). Объект-памятник является исходным объектом, у которого атрибут isDeleted установлен на true (истина), а большинство атрибутов объекта удалено. Сохранены только несколько атрибутов, типа GUID, SID, USN и отличительного имени, которые требуются для идентификации этого объекта.

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

данных. Процесс удаления объектов-памятников из базы данных называется сборкой мусора (garbage collection). По умолчанию интервал времени, через который производится сборка мусора, для леса установлен на 12 часов. Каждые 12 часов выполняется процесс сборки мусора, и удаляются все объекты-памятники, время жизни которых истекло.

В главе 1 говорилось о том, что служба Active Directory Windows Server 2003 обеспечивает поддержку неактивных объектов в Active Directory. Неактивный объект (lingering object) — это объект, который не был удален из контроллера домена, потому что контроллер находился в автономном режиме или был не способен к репликации в течение всего времени жизни объекта-памятника. Для удаления неактивных объектов используется инструмент Repadmin.

Совет. Время жизни объекта-памятника и интервал сборки мусора может быть изменен с помощью ADSI Edit или Ldp.exe. Эти свойства сконфигурированы в объекте CN=Directory Service,CN=Windows NT,CN=Services,CN = Configuration, DC=ForestRootDomain. Атрибуты garbageCollPeriod и tombstoneLifetime определяют эти параметры настройки. В большинстве случаев эти значения менять не требуется.

Репликация внутри сайта

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

Репликация происходит сразу после того, как произошло изменение информации Active Directory. По умолчанию контроллер домена ожидает 15 с после того, как изменение было сделано, а затем начинает копировать это изменение на другие контроллеры домена в сайте. После завершения репликации с одним партнером контроллер домена ожидает 3 с, а затем начинает репликацию с другим партнером. Ожидание в 15 с необходимо для увеличения эффективности репликации в случае, если к информации раздела будут сделаны дополнительные изменения. Продолжительность периода ожидания может быть изменена через системный реестр Windows 2000 или Windows Server 2003 (обратитесь к соответствующим разделам в комплекте ресурсов Resource Kits за подробностями). На функциональном уровне Windows Server 2003 это значение можно изменить для каждого раздела каталога, используя инструмент ADSI Edit.

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

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

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

Изменить трафик репликации в пределах сайта нетрудно. Можно сконфигурировать объекты-связи вручную через инструмент администрирования Active Directory Sites And Services (Сайты и службы Active Directory), изменить некоторые значения (например, начальное уведомление партнера по репликации) через системный реестр (обратитесь к соответствующим разделам документа Resource Kits за подробностями) или через объект Partition (Раздел), если ваш лес работает на функциональном уровне Windows Server 2003. Но в большинстве случаев этого делать не придется.

Реструктурирование домена

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

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

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

Active Directory Migration Tool (Инструмент модернизации Active Directory) (ADMT). Он находится на компакт-диске Windows Server 2003   папке   в   \I386\ADMT.   Дважды   щелкните   на   файле Admigration.msi для его установки.

Оценочная версия инструмента bv-Admin для модернизации Windows 2000 и Windows Server 2003 от корпорации BindView (http://www.bindview.com/products/Admin/winmig.cfm) можно взять на веб-сайте продуктов компании.

Испытательная версия программы Domain Migration Administrator (Администратор модернизации домена) (DMA) от компании NetlQ (http://www.netiq.com/products/dma/) доступна для загрузки на веб-сайте продуктов компании.

Испытательная версия программы Domain Migration Wizard (Мастер модернизации домена) (DMW) от компании Aelita Software (http:// www.aelita.com/products/DMW.htm) доступна для загрузки на вебсайте продуктов компании.

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

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

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

Ретрансляторы и корневые ссылки

Второй способ соединения различных уровней иерархии системы DNS состоит в использовании корневых ссылок и ретрансляторов. В большинстве случаев ретрансляторы и корневые ссылки используются низкоуровневыми серверами пространства имен DNS для поиска информации, находящейся на высокоуровневых серверах DNS-иерархии. Ретрансляторы и корневые ссылки используются DNS-сервером для поиска информации, которая отсутствует в их собственных зонных файлах. Например, DNS-сервер может быть полномочным только для домена Contoso.com. Когда он получит запрос от клиента, запрашивающего разрешение имени в домене Fabrikam.com (см. рис. 3-1), DNS-сервер Contoso.com должен иметь какой-то способ поиска этой информации.

Рис. 3-4. Делегированные зоны

Одним из способов конфигурирования сервера для этих целей является использование ретрансляторов. Ретранслятор (forwarder) - это просто другой DNS-сервер, который используется определенным DNS-сервером, когда он не может разрешить запрос. Например, полномочный сервер имен для Contoso.com может получить рекурсивный запрос для домена Fabrikam.com. Если DNS-сервер Contoso был сконфигурирован с ретранслятором, то он отправит рекурсивный запрос ретранслятору, запрашивая эту информацию. Ретрансляторы часто используются во внутренней сети организации. Организация может иметь несколько DNS-серверов, главной задачей которых является внутреннее разрешение имен. Пользователям внутри организации может потребоваться разрешение IP-адресов интернета. Это можно выполнить, сконфигурировав все внутренние DNS-серверы так, чтобы они могли разрешать адреса интернета. Более распространенным вариантом является конфигурирование внутренних DNS-серверов с ретранслятором, указывающим на DNS-сервер, являющийся ответственным за разрешение имен интернета. Этот вариант показан на рисунке 3-5. Все внутренние DNS-серверы отправляют любой запрос для неполномочной зоны на один DNS-сервер, который разрешает интернет-адреса. Если DNS-сервер сконфигурирован с несколькими ретрансляторами, то он будет отправлять запросы всем ретрансляторам по порядку, прежде чем попытается использовать любой другой способ разрешения IP-адресов.

Рис. 3-5. Использование ретрансляторов для разрешения имен в интернете

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

Примечание. Корневые серверы, которые автоматически указываются на DNS-сервере при его конфигурировании, копируются из файла Cache.dns, который поставляется с файлами установки DNS-сервера.

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

По умолчанию DNS-серверы Windows Server 2003 используют ретрансляторы и корневые ссылки, когда они пытаются разрешать имена. Если сервер конфигурирован с ретрансляторами, он сначала отправит рекурсивные запросы всем ретрансляторам. Если ни один из ретрансляторов не может обеспечить необходимую информацию, то DNS-cep-вер начнет посылать повторяющиеся запросы серверам, сконфигурированным как корневые ссылки. В некоторых случаях необходим DNS-сервер, использующий только ретрансляторы и не использующий корневые ссылки. Чтобы сконфигурировать такой сервер, выберите опцию Do Not Use Recursion For This Domain (He использовать рекурсию для этого домена) на вкладке Forwarders (Передатчики) в окне Properties (Свойства) DNS-сервера. После этого DNS-сервер сначала будет пытаться разрешить любые запросы с помощью своей местной зонной или кэ-шированной информации, посылая рекурсивные запросы каждому из своих ретрансляторов. Если ретрансляторы не смогут обеспечить необходимую информацию, DNS-сервер не будет использовать другие средства, чтобы найти эту информацию. Он сообщит клиенту, что хост не может быть найден.

Примечание. В системе DNS Windows Server 2003 возможности традиционных ретрансляторов расширены за счет реализации условных ретрансляторов. Эта тема подробно рассматривается в разделе «Условная ретрансляция» далее в этой главе.

В этой главе вы узнали,

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


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


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


Ключевым аспектом управления службой Active Directory Windows Server 2003 является понимание того, как работает репликация. Устойчивая среда репликации необходима для поддержания новейших копий всей информации каталога на всех контроллерах домена в лесу, что необходимо для гарантии согласованного входа пользователей в систему и функционирования поиска в каталоге. В этой главе было дано описание работы репликации каталога: создание топологии репликации между контроллерами домена Active Directory в одном сайте и между контроллерами домена, расположенными в разных сайтах, описание самого процесса репликации, принципов ее оптимизации для уменьшения объема сетевого трафика.
Часть II. Реализация службы Active Directory Windows Server 2003
Задача авторов при написании части I данной книги состояла в том, чтобы помочь вам понять работу службы каталога Active Directory Microsoft Windows Server 2003. Часть II поможет вам реализовать Active Directory. Первый шаг в этом направлении состоит в создании архитектуры Active Directory для вашей организации. Структуры леса, домена, сайта и организационной единицы (OU) уникальны для каждой компании, поэтому разработка правильного проекта для вашей среды потребует знаний и усилий. В главе 5 приводится краткий обзор процесса проектирования. Как только вы создадите свою модель Active Directory, можно начать ее установку. Глава 6 содержит описание процедур, необходимых для развертывания Active Directory. Многие компании, реализующие Active Directory Windows Server 2003, переходят к ней от Microsoft Windows NT 4. Поскольку Active Directory Windows Server 2003 сильно отличается от службы каталога Windows NT, этот переход достаточно сложен и является главной темой главы 7.


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


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


В этой главе были рассмотрены различные пути перехода от службы каталога Windows NT 4 или Active Directory системы Windows 2000 к Active Directory Windows Server 2003. Были описаны три главных пути перехода: обновление, реструктуризация и обновление с последующей реструктуризацией. Существует несколько критериев, которые можно использовать для определения подходящего пути перехода для вашей организации. Для организаций, которые удовлетворены своей текущей доменной структурой, обновление домена является наименее сложным и опасным средством модернизации службы каталога. Если ваша доменная структура не соответствует организационной модели, вы должны реструктуризировать ваш домен. Независимо от выбранного пути, осторожное планирование, тестирование и пробная реализация вашего плана перехода являются важными условиями для успеха вашего проекта модернизации.
В главе описаны также основные этапы, необходимые при реализации обновления систем Windows NT Server 4 и Windows 2000 Server. Затем показан процесс реструктуризации домена учетных записей и домена ресурсов с системой Windows NT 4 с помощью инструмента ADMT. Обсуждены отличия пути обновления с последующей реструктуризацией, известного как перемещение в пределах леса, от реструктуризации домена. Заканчивает эту главу обсуждение функции доверительных отношений между лесами, имеющейся в Windows Server 2003.
Часть III. Администрирование службы каталога Active Directory Windows Server 2003
В частях I и II этой книги были объяснены концепции и компоненты Active Directory — службы каталога Microsoft Windows Server 2003, а также дана информация о том, как проектировать, реализовывать, и развертывать Active Directory. После развертывания Active Directory вы должны управлять ею для обеспечения максимальной выгоды вашей компании. В части III показаны административные процессы, которые вы будете использовать для выполнения этой задачи. Одна иэ основных причин развертывания службы каталога состоит в том, чтобы обеспечить защиту, поэтому глава 8 рассказывает про концепции, лежащие в основе безопасности Active Directory Windows Server 2003. В главе 9 дается описание способов, которыми вы можете делегировать административные разрешения в пределах вашего домена. Глава 10 знакомит вас с управлением объектами службы каталога Active Directory. Одна из наиболее мощных функций в Active Directory - это Group Policy (Групповая политика), которая может применяться для управления тысячами компьютеров, использующих Active Directory. Главы 11, 12 и 13 посвящены групповым политикам, в них объясняется, как использовать эти инструментальные средства, чтобы осуществить распределение программ и управление клиентскими компьютерами.


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


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


В этой главе приведен краткий обзор стандартных объектов Active Directory Windows Server 2003 и процедур, позволяющих ими управлять. Наибольшие административные усилия вы потратите на управление этими объектами. В частности, вы будете управлять учетными записями пользователей и групп по мере притока и оттока служащих из вашей компании или по мере создания новых групп для защиты сетевых ресурсов. Одно из осложнений, с которыми вы столкнетесь, - у вас может быть три различных объекта, представляющих индивидуальных пользователей: объекты user, inetOrgPerson и contact. Кроме того, имеется два типа групп и три области действия, с которыми вам придется работать. Ваше время будет также занято управлением такими объектами как computer, printer или shared folder.


Эта глава объясняет опции конфигурации групповых политик в Active Directory Windows Server 2003, создавая предпосылки для понимания последующих глав. В ней обсуждаются вопросы создания и управления групповыми политиками с помощью инструментов, поставляемых вместе с Windows Server 2003, вопросы наследования групповых политик и применения их к компьютерам клиентов. Вы можете использовать заданную по умолчанию модель наследования групповой политики, установленной высоко в иерархии OU, и получить параметры настройки GPO для многих объектов домена. Вы можете также изменить заданное по умолчанию наследование параметров настройки групповой политики, блокируя или фильтруя наследование. Главы 12 и 13 посвящены тому, что вы фактически можете делать с групповой политикой. Глава 12 показывает, как использовать групповые политики при распространении программного обеспечения на компьютеры-клиенты, глава 13 — как использовать групповые политики для управления разнообразными опциями конфигурации рабочего стола.


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


В Active Directory Windows Server 2003 имеется множество инструментальных средств и опций, предназначенных для управления рабочими столами пользователей. Групповые политики могут использоваться для управления данными и профилями пользователей, чтобы обеспечить им знакомую рабочую среду, оставляя централизованным управление некоторыми данными. Они применяются также для конфигурирования параметров настройки защиты, чтобы все компьютеры, на которые воздействует данная групповая политика, имели стандартную и постоянную конфигурацию защиты. Групповые политики используются для определения административных шаблонов, которые могут конфигурировать параметры настройки системного реестра для управления рабочими столами пользователей. В этой главе дан краткий обзор того, как можно реализовать эти варианты управления рабочими столами пользователей.
Часть IV. Обслуживание Active Directory Windows Server 2003
Части I, II и III этой книги дали вам понятие об основных концепциях и компонентах, проектировании и реализации службы каталога Active Directory в системе Microsoft Windows Server 2003, а также ознакомили с управлением пользователями и компьютерами вашей сети. Эта заключительная часть книги подготовит вас к обслуживанию инфраструктуры Active Directory после ее развертывания. В главе 14 детально рассказывается, как следить за состоянием Active Directory, включая информацию о мониторинге эксплуатационных качеств Active Directory и ее репликации. Обсуждается также управление базой данных Active Directory. В главе 15 обсуждается создание резервной копии и восстановление Active Directory. Active Directory — это критическая служба в вашей сети, и вы должны уметь восстанавливать ее после любых видов сбоя, которые могут произойти во время работы.


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


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

Сайты

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

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

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

Репликация. Одним из важнейших способов, которым сайты пользуются для оптимизации сетевого трафика, является управление трафиком репликации между контроллерами доменов и GC-серверами. В пределах сайта любое изменение, сделанное в каталоге, будет копироваться в течение приблизительно пяти минут. Графиком репликации между сайтами можно управлять так, чтобы репликация происходила во время нерабочих часов. По умолчанию трафик репликации между сайтами сжат для сохранения пропускной способности сети, в пределах сайта трафик репликации не сжимается. (В главе 4 представлена более детальная информации относительно различий между внутрисайтовой и межсайтовой репликациями.)

Идентификация. Когда пользователь входит в домен Windows Server 2003 с клиента, на котором работает система Windows 2000 или Microsoft Windows XP Professional, компьютер клиента пробует подключить контроллер домена, находящийся в том же самом сайте, где находится клиент. В главе 3 будет обсуждаться, как каждый контроллер домена регистрирует записи указателя служб (SRV), специфические для сайта. Когда компьютер клиента пытается найти контроллер домена, он всегда запрашивает записи сайтов у DNS-серверов. Это означает, что трафик входа клиента в систему останется в пределах сайта. Если домен работает на функциональном уровне Windows 2000 native (основной) или Windows Server 2003, то клиент будет пытаться найти каталог GC во время входа в систему. Если на сайте имеется GC-сервер, клиент соединится с этим сервером. (Роль сайтов в поиске контроллеров домена подробно обсуждается в гл. 3.)

Примечание. Клиентские компьютеры, на которых работает система Windows NT 4 SP6a, могут регистрироваться на контроллерах домена Active Directory, если они установили службу Directory Services Client (Клиент служб каталога), которая доступна для загрузки на сайте http://www.microsoft.com/ windows2000/server/evaluation/news/bulletins/ adextension.asp. Для тех клиентов, которые не были модернизированы с Windows 95 или Windows 98, программное обеспечение Directory Services Client доступно на компакт-диске Windows Server 2000.

Сетевые службы, учитывающие наличие сайтов. Третий способ, который позволяет сайтам сохранять высокую пропускную способность, состоит в ограничении клиентских подключений к сайту только теми приложениями и службами, которые учитывают наличие сайтов. Например, используя распределенную файловую систему (DFS -Distributed File System), вы можете создавать несколько реплик папки на различных сайтах в сети. Поскольку система DFS спроектирована так, что она учитывает конфигурацию сайта, компьютеры клиента всегда пробуют обратиться к DFS-реплике на своем собственном сайте, прежде чем использовать связи WAN-сети, чтобы получить доступ к информации на другом сайте.

Каждый компьютер в сети Windows Server 2003 будет назначен сайту. Когда служба Active Directory устанавливается в среде Windows Server 2003, создается заданный по умолчанию сайт, называемый Default First Site Name (заданное по умолчанию имя первого сайта), и все компьютеры леса будут назначены этому сайту, если не создается дополнительных сайтов. Когда создаются дополнительные сайты, они связываются с подсетями IP. Когда сервер, на котором выполняется система Windows Server 2003, становится контроллером домена, то он автоматически назначается тому сайту, который назначен IP-адресу компьютера. При необходимости контроллеры домена можно перемещать между сайтами с помощью инструмента администрирования Active Directory Sites And Services (Active Directory: Сайты и службы).

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



Примечание. Если контроллер домена или компьютер клиента имеют IP-адрес, который не связан с определенным сайтом, то этот компьютер будет приписан в сайт Default First Site Name. Каждый компьютер, который является частью домена Windows Server 2003, должен принадлежать сайту.

Как уже было сказано выше, нет прямой связи между сайтами и другими логическими концепциями Active Directory. Один сайт может содержать более одного домена, и один домен может принадлежать нескольким сайтам. На рисунке 2-12 показано, что сайт Seattle содержит два домена: Contoso.com и NAmerica.Contoso.com. Домен NWTraders.com распределен между несколькими сайтами.



Примечания. Сайты подробно обсуждаются в других главах. В главе 3 детализируется роль DNS и сайтов для клиентских входов в систему. Глава 4 посвящена роли сайтов в репликации и тому, как создавать и конфигурировать сайты. В главе 5 дается детальная информация по проектированию оптимальной конфигурации сайта для леса Active Directory.

Сайты и проектирование Active Directory

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

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

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

Приложения, учитывающие наличие службы Active Directory, подобные распределенной файловой системе (DFS - Distributed File System), можно добавить к сети для ограничения трафика, связанного с доступом клиентов к местному сайту.

Сборка мусора

Один из автоматических процессов, который обычно используется для обслуживания базы данных Active Directory, — это сборка мусора. Сборка мусора - это процесс, который выполняется на каждом контроллере домена каждые 12 часов. В процессе сборки мусора восстанавливается свободное пространство в пределах базы данных Active Directory.

Процесс сборки мусора начинается с удаления объектов-памятников (tombstone) из базы данных. Объекты-памятники являются остатками объектов, которые были удалены из Active Directory. При удалении учетной записи пользователя она не удаляется немедленно. Вместо этого атрибут isDeleted этой записи устанавливается на true, она помечается как объект-памятник, и большинство атрибутов этого объекта удаляются. Остается несколько атрибутов, необходимых для идентификации объекта: как глобально-уникальный идентификатор (GUID), идентификатор SID, порядковый номер обновлений (USN) и отличительное имя. Этот объект-памятник затем реплицируется на другие контроллеры домена в домене. Каждый контроллер домена поддерживает копию объекта-памятника до тех пор, пока не истечет срок его службы. По умолчанию срок службы объекта-памятника установлен на 60 дней. В следующий раз, когда процесс сборки мусора будет запущен после истечения срока службы объекта-памятника, этот объект будет удален из базы данных.

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

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

Процесс сборки мусора выполняется на каждом контроллере домена с двенадцатичасовым интервалом. Можно изменять этот интервал, модифицируя атрибут garbageCollPeriod в глобальном для предприятия объекте DS конфигурации (NTDS). Чтобы изменить эти параметры настройки, можно использовать инструмент Adsiedit.msc. Откройте ADSI Edit (Редактирование ADSI) из диалогового окна Run (Выполнить) и выберите объект CN=Directory Service,CN=Windows NT, CN=Services, CN=Configuration, DC=f orestname. Затем найдите атрибут garbageCollPeriod и установите его значение так, чтобы оно удовлетворяло вашим требованиям. В большинстве случгмвв вам не придется1

изменять эту установку. На рисунке 14-7 показан этот атрибут в инструменте ADSI Edit.

Рис. 14-7. Атрибут garbageCollPeriod в инструменте ADSI Edit

Счетчики, характеризующие функционирование репликации

Счетчики (см. табл. 14-2) отслеживают количество реплицируемых данных. Пороги определяются по базовым значениям, установленным ранее, если не указано ничего другого.

Табл. 14-2. Счетчики, характеризующие репликацию

Объект		Счетчик		Рекомендуемый интервал		Почему этот счетчик важен
NTDS		DRA Inbound Bytes Compressed (DRA входящие сжатые байты) (Между сайтами после сжатия/ секунды)		Каждые 15 минут		Указывает количество репли-цируемых данных, входящих в этот сайт. Изменение значения этого счетчика указывает на изменение топологии репликации или на то, что существенные данные были добавлены или изменены в Active Directory.
NTDS		DRA Outbound Bytes Compressed (DRA исходящие сжатые байты) (Между сайтами после сжатия/ секунды)		Каждые 15 минут		Указывает количество реплици-руемых данных, выходящих из этого сайта. Изменение значения этого счетчика указывает на изменение топологии ответа или на то, что существенные данные были добавлены или изменены в Active Directory.
NTDS		DRA Outbound Bytes Not Compressed (Исходящие несжатые DRA байты )		Каждые 15 минут		Указывает количество репли-цируемых данных, выходящих из этого контроллера домена, но адресованных в пределах сайта.
NTDS		DRA Outbound Bytes Total/sec (Общее количество исходящих DRA байтов/ секунда)		Каждые 15 минут		Указывает количество реплици-руемых данных, выходящих из этого контроллера домена. Изменение значения этого счетчика указывает на изменение топологии репликации или на то, что существенные данные были добавлены или изменены в Active Directory. Это важный счетчик, который следует отслеживать.

Счетчики производительности и пороги

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

Семантический анализ базы данных

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

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

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

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

В командной строке Semantic Checker (Проверка семантики) напечатайте verbose on. Эта установка конфигурирует утилиту Ntdsutil для выведения на экран дополнительной информации при выполнении семантической проверки.

В командной строке Semantic Checker напечатайте go.

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

это хороший выбор, если на

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

система Windows NT Server 4, пока не появится новая версия вашего приложения. Имейте в виду, что сервер, на котором выполняется Windows NT 4, может существовать неопределенно долго в качестве сервера-члена домена в сети, основанной на Windows Server 2003.

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

Серверные приложения, требующие Windows NT 4 Server

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

Серверы глобального каталога

На сервере глобального каталога находится глобальный каталог (GC). Он является частичной, предназначенной только для чтения копией всех контекстов именования домена (NC - Naming Context) в лесу. Каталог GC содержит основной, но неполный набор атрибутов для каждого объекта леса в каждом домене NC. Данные каталога GC получают из всех разделов каталога доменов в лесу, они копируются с использованием стандартного процесса репликации службы Active Directory.

Совет. Будет ли атрибут скопирован в каталог GC, определяется схемой. Администраторы могут конфигурировать дополнительные атрибуты, которые будут реплицироваться в каталог GC, используя меню Active Directory Schema (Схема Active Directory), встроенное в консоль управления ММС. Чтобы добавить атрибут к каталогу GC, выберите опцию Replicate This Attribute To The Global Catalog (Копировать этот атрибут в глобальный каталог) на самом атрибуте. В результате значение параметра атрибута isMemberOfPartialAttributeSet будет установлено на true (истина). Вы можете добавлять атрибут к глобальному каталогу, если ожидаете, что пользователям потребуется искать этот объект в лесу. Редко упоминаемые атрибуты обычно не добавляются к каталогу GC.

Первый контроллер домена, установленный в домене, автоматически является контроллером глобального каталога. Дополнительные контроллеры домена можно назначить как GC, выбирая опцию Global Catalog Server (Сервер глобального каталога) в инструменте администрирования Active Directory Sites And Services (Сайты и службы Active Directory). Это делается с целью оптимизации входа в систему. Как используется каталог GC в процессе входа в систему, описано далее в этом разделе. В главе 5 дается более подробная информация о количестве GC-серверов, которое потребуется при развертывании, и о том, где их следует располагать.

Вы можете задаться вопросом, зачем вообще нужны GC-серверы. Во-первых, они используются для поиска в Active Directory. Без каталога GC поиск по запросам, полученным контроллером домена, который не обладает запрошенным объектом, приведет к тому, что он переправит запрос на контроллер домена другого домена. Поскольку GC-каталог содержит полный список всех объектов леса (и не содержит атрибуты объекта), GC-сервер может ответить на любой запрос, используя атрибут, который копировался в GC-каталог, без необходимости передавать его другому контроллеру домена. Запрос, который послан GC-серверу, является LDAP-запросом (Lightweght Directory Access Protocol — облегченный протокол службы каталогов), использующим порт 3268 (заданный по умолчанию порт GC-каталога).

Во-вторых, GC- серверы необходимы для обработки пользовательских входов в систему. Обычно каждый раз, когда пользователь входит в домен, выполняется обращение к GC-каталогу. Это происходит потому, что контроллеры домена, не являющиеся глобальными, не содержат никакой информации об универсальном членстве группы. (Универсальные группы имеются только в доменах, обладающих функциональным уровнем Microsoft Windows 2000 или Windows Server 2003. Функциональные уровни используются в Windows Server 2003, чтобы разрешить функ-

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

Примечание. Windows Server 2003 поддерживает новую функцию кэширования универсального группового членства, которая дает возможность входить в сеть Windows Server 2003 без контакта с GC-каталогом. Универсальное групповое членство кэши-руется на контроллерах домена, не являющихся контроллерами GC, если эта опция разрешена, а пользователь впервые пытается войти в систему. Как только эта информация попадает в GC-каталог, она кэшируется на неограниченное время на контроллере домена сайта и периодически обновляется (по умолчанию каждые 8 часов). Включение этой функции приводит к ускорению входа в систему пользователей с удаленных сайтов, так как для аутентификации контроллеру домена не требуется обращения к GC-каталогу. Чтобы включить опцию универсального группового членства на сайте, откройте оснастку Active Directory: Sites And Services (Сайты и службы Active Directory) и выберите нужный сайт в дереве консоли. Щелкните правой кнопкой мыши на панели деталей NTDS Site Settings (Параметры настройки сайта NTDS), затем выберите Properties (Свойства). На вкладке Properties выберите опцию Enable Universal Group Membership Caching (Разрешить кэширование универсального группового членства), а затем укажите сайт, с которого будет обновляться кэш. По умолчанию сайт обновит информацию с самого близкого сайта, который имеет глобальный каталог GC.

Шаблоны защиты

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

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

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

Почти все параметры настройки защиты, сконфигурированные с помощью групповых политик, могут быть сконфигурированы с использованием шаблон защиты. (Исключения составляют политики IPSec и политики открытых ключей.) Вы можете создать ваш собственный шаблон защиты или использовать один из предопределенных шаблонов. Если вы изменяете шаблон, сохраните его так, чтобы он был доступен другим объектам GPO. При сохранении шаблона он записывается в виде текстового .inf файла.

Схема

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

Служба DNS Locator

Служба DNS Locator (Указатель DNS) очень важна для Active Directory, потому что DNS обеспечивает информацию, которая необходима клиентам для поиска контроллеров домена в сети. Далее детально рассматривается процесс, которым пользуется клиент для поиска контроллеров домена.

Примечание. В Windows NT вход в систему домена был основан на именах NetBIOS. Каждый контроллер домена регистрировал имя NetBIOS Domainname с <1С> в качестве шестнадцатого символа имени в сети и в службе WINS. Когда клиент пробовал войти в сеть, он пытался найти серверы, которые имели зарегистрированное имя контроллера домена. Если клиент не находил ни один из этих серверов, то он не мог войти в систему. Записи SRV на Windows Server 2003 используются для поиска контроллеров домена клиентами, на которых выполняются системы Windows 2000 и Windows XP Professional. Без записей SRV эти клиенты не смогут войти на домен Windows Server 2003.

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

Одной из критических задач, выполняемых сетевым администратором, является обслуживание заплат на уровне операционной системы для всех компьютеров в сети. Из-за масштаба необходимых для этого усилий некоторые компании вообще не обновляют настольные компьютеры или применяют только наиболее критические модификации. Они обычно обновляют все серверы, но для защиты рабочих станций полагаются на брандмауэр интернета и антивирусное программное обеспечение. Некоторые компании применяют другой подход и конфигурируют все компьютеры своих клиентов на использование сайта Windows Update (Обновление Windows) для загрузки заплат. Эти компании, возможно, даже позволяют обычным деловым пользователям самим управлять применением заплат. Использование групповых политик может облегчить управление заплатами, но оно не решит проблему. Компания Microsoft создает .msi файлы только для существенных модификаций типа сервисных пакетов, так что управление заплатами по-прежнему связано с большим количеством работы. Поэтому компания Microsoft создала службу обновления программного обеспечения (Software Update Service — SUS) как альтернативное средство, предназначенное для развертывания обновлений на рабочих станциях.

Служба SUS состоит из серверного компонента и компонента клиента. Чтобы включить службу SUS, вы должны установить серверный компонент на компьютере с системой Windows 2000 или Windows Server 2003. Затем сконфигурируйте серверный компонент службы для загрузки всех критических модификаций с сайта Windows Update. Эта загрузка может быть автоматической или ручной. Как только модификации будут загружены и проверены, можно сконфигурировать службу для распределения модификаций всем клиентам. Клиентский компонент службы SUS можно устанавливать на компьютерах с системами Windows 2000 Professional и Server (с Service Pack 2 или более поздним), Windows XP Professional или Windows Server 2003. Системы Windows 2000 Service Pack 3 и Windows XP Professional Service Pack 1 включают клиентский SUS-компонент. Компьютер клиента использует клиентский компонент службы SUS для соединения с серверным компонентом службы SUS, чтобы загрузить и установить заплаты.

Служба SUS может управляться с помощью групповых политик. В редакторе объектов групповой политики используйте параметры настройки, расположенные в разделе Computer Configuration, выберите Administrative Templates, далее выберите Windows Components, а затем — Windows Update для конфигурирования управления автоматическими модификациями на рабочих станциях (см. рис. 12-13). Вы можете использовать групповые политики для определения того, с каким SUS-сервером будут соединяться рабочие станции.

Рис. 12-13. Конфигурирование клиентского компонента для автоматических модификаций

Чтобы узнать больше об использовании службы SUS и ее интеграции с групповой политикой, загрузите с веб-сайта Microsoft статью, расположенную по адресу http://www.microsoft.com/windows2000/ windowsupdate/sus/susoverview.asp.

---

---