Сначала обновляем PDC

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

Наилучшая практика. Вместо обновления существующего PDC вашего домена наилучшая практика состоит в том, чтобы построить чистый BDC с Windows NT 4, назначить его на роль PDC, a затем обновить тот контроллер домена до Windows Server 2003. Этот дополнительный шаг гарантирует, что вы начнете обновление с контроллера домена, который по аппаратным средствам совместим с Windows Server 2003, и что сервер не будет иметь истории модификаций, которые могут предотвратить чистое обновление.

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

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

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

Вставьте компакт-диск с Windows Server 2003 в CD-ROM. Если ваш CD-ROM разрешает Autorun (Автоматическое выполнение), автоматически запустится программа Setup (Установка). Вы можете также запустить файл Setup.exe из корневой папки компакт-диска вручную.

При запуске программы Setup выберите опцию Install Windows Server 2003 (Установка Windows Server 2003).

После того как программа Setup соберет информацию о вашей текущей операционной системе, выберите опцию Upgrading To Windows Server 2003 (Обновление до Windows Server 2003).

Введите информацию, необходимую для завершения программы Setup.

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

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

Соглашения, используемые в этой книге

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

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

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

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

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

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

Совет. В этих разделах вам даются советы, касающиеся эконо мии времени или стратегических действий.

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

Часть I. Краткий обзор службы каталога Active Directory Windows Server 2003

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

Сокращенные зоны

Сокращенные зоны (stub zones) - это второе улучшение к службе DNS в Windows Server 2003. Они предназначены для упрощения конфигурирования разрешения имен между несколькими пространствами имен. Сокращенная зона подобна дополнительной зоне. При установлении сокращенной зоны вы должны определить IP-адрес основного сервера имен для зоны. Тогда сервер, владеющий сокращенной зоной, запрашивает зонную передачу у основного сервера имен. Однако сокращенная зона отличается от дополнительной тем, что она содержит только записи SOA, NS и записи хоста (А) для сервера имен домена, а не все записи зоны.

Это улучшает процесс разрешения имен без необходимости использовать дополнительные серверы. Когда DNS-сервер сконфигурирован с сокращенной зоной, он не является полномочным для домена. Он эффективен при поиске полномочного сервера имен для указанной зоны. С помощью дополнительных зон DNS-сервер может найти полномочный сервер имен для зоны без необходимости контактировать с серверами корневых ссылок. Обратите внимание, как дополнительная зона может работать в лесу с одним деревом, т.е. с непрерывным пространством имен (см. рис. 3-9). Без дополнительных зон в случае запроса клиента из NAmerica.Contoso.com IP-адреса хоста в домене SAmerica.Contoso.com DNS сервер в NAmerica. Contoso.com проверяет свои зонные файлы, кэш и ретрансляторы. Если ни один из этих источников не обеспечивает нужную информацию, он посылает итерационный запрос серверу корневых ссылок. В этом случае DNS сервер в корневом домене Contoso.com должен быть сконфигурирован как корневой сервер, чтобы DNS-сервер домена NAmerica. Contoso.com послал запрос ему. Корневой сервер проверяет свои записи делегирования и передает IP-адрес полномочного сервера имен домена SAmerica.Contoso.com серверу имен NAmerica. Contoso.com. Затем сервер имен NAmerica. Contoso.com запрашивает у одного из серверов DNS домена SAmerica. Contoso.com IP-адрес сервера, который требуется клиенту.

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

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

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



Рис. 3-9. Конфигурация DNS с одним лесом без использования сокращенной зоны

Сокращенная зона поддерживает список серверов имен для делегированных зон. Когда вы устанавливаете делегированный поддомен, вы должны ввести IP-адреса всех серверов имен в делегированный домен. Если этот список серверов имен изменяется, например, один из серверов имен удален из сети, вам придется вручную обновить запись делегирования. Вы можете использовать сокращенную зону, чтобы автоматизировать процесс обновления списка серверов имен. Чтобы сделать это в домене Contoso.com, вы можете сконфигурировать сокращенную зону для домена NAmerica.Contoso.com на серверах DNS домена Contoso.com. Вы также можете сконфигурировать запись делегирования в зоне Contoso.com, указывающую на сокращенную зону. Когда записи сервера имен изменятся в дочернем домене, они будут автоматически обновлены в сокращенной зоне. Когда серверы DNS Contoso.com будут использовать запись делегирования, они получат ссылку на сокращенную зону, так что у них всегда будет доступ к обновленной информации сервера имен.

Чтобы сконфигурировать сокращенную зону, используйте New Zone Wizard (Мастер новой зоны) в инструменте администрирования DNS. Щелкните правой кнопкой мыши на Forward Lookup Zones (Прямая зона просмотра) или на Reverse Lookup Zones (Обратная зона просмотра)) и выберите New Zone (Новая зона). Появится опция создания сокращенной зоны (см. рис. 3-10).



Рис. 3-10. Создание новой сокращенной зоны

Совершенствование DNS

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

Совместимость операционных систем

Контроллеры домена, на которых выполняются Windows Server 2003, лучше защищены, чем те, на которых выполняются предыдущие версии сетевых операционных систем Windows, и мастер инсталляции Active Directory дает информацию о том, как эта защита затрагивает вход клиента в систему. Заданная по умолчанию политика безопасности для контроллеров домена, на которых выполняются Windows Server 2003, требует двух новых уровней защиты взаимодействия контроллеров домена: подписи блока серверных сообщений (Server Message Block — SMB), а также шифрования и подписи сетевого трафика безопасного канала.

Эти функции защиты вызывают проблемы при входе в систему клиентов низкого уровня. Нижеприведенные клиентские операционные системы Windows в основном режиме не поддерживают подписи SMB, шифрование и подписи безопасного канала:

Microsoft Windows for Workgroups;

Microsoft Windows 95 и Windows 98;

Microsoft Windows NT 4 (Service Pack 3 и более ранние).

Если ваша сеть поддерживает эти системы, то вы должны выполнить определенные действия, чтобы дать им возможность входить в систему контроллера домена, на котором выполняется Windows Server 2003 (см. табл. 6-1).

Табл. 6-1. Предоставление клиентским операционным системам возможности входа в Active Directory

Клиент ОС		Действие
Windows for Workgroups Windows 95/Windows 98		Модернизируйте операционную систему. Модернизируйте операционную систему (рекомендуется) или установите Directory Services Client (Клиент служб каталога).
Windows NT 4		Модернизируйте операционную систему (рекомендуется) или установите Service Pack 4 (или более поздний).

Directory Services Client (Клиент служб каталога) — это компонент клиентской стороны, который дает возможность низкоуровневым клиентским операционным системам (Microsoft Windows 95, Windows 98 и Windows NT 4) воспользоваться преимуществами Active Directory. (Это использование распределенной файловой системы (DFS) и поиска). Посмотрите страницу дополнений клиента Active Directory на сайте http:/ /www.microsoft.corn/windows2000/server/evaluation/news/bulletins/ adextension.asp для получения информации относительно загрузки и использования службы Directory Services Client в системе Windows NT 4 SP6a. Обратите внимание, что предыдущее название службы Directory Services Client было Active Directory Client Extension, с этим именем вы будете сталкиваться во многих статьях веб-сайта Microsoft.

На рисунке 6-6 показано окно Operating System Compatibility (Совместимость операционных систем).

Создание чистого леса

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

Рис. 7-2. Организационная модель домена учетных записей и домена ресурсов в системе Windows NT 4

Совет. При установке Active Directory в чистый лес в окне Permissions (Разрешения) мастера инсталляции Active Directory выберите опцию Permissions Compatible With Pre-Windows 2000 Server Operating Systems (Разрешения, совместимые с операционными системами, предшествующими Windows 2000). Эта установка позволяет анонимным учетным записям пользователя обращаться к информации домена и требуется для клонирования участников безопасности. Чтобы получить доступ к этой опции, вы должны выбрать опцию Custom configuration (Выборочная конфигурация) в окне Custom Options (Выборочные опции) мастера конфигурирования сервера.

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

Создание дополнительных сайтов

Когда устанавливается Active Directory, создается единственный сайт с именем Default-First-Site-Name (в дальнейшем сайт можно переименовать). Если не создается дополнительных сайтов, то все последующие контроллеры домена будут добавляться к этому сайту по мере их установки. Однако если ваша компания расположена в нескольких местах с ограниченной пропускной способностью между ними, то вы наверняка захотите создать дополнительные сайты. Дополнительные сайты создаются с помощью инструмента администрирования Active Directory Sites And Services (Сайты и службы Active Directory). Чтобы создать новый сайт, щелкните правой кнопкой мыши на контейнере Sites (Сайты), затем выберите New Site (Новый сайт). В списке Link Name (Имя связи) вы должны выбрать ту связь сайта, которая будет использоваться для соединения этого сайта с другими сайтами. Каждый сайт связан с одной или более подсетями IP в Active Directory. Создайте дополнительные подсети в контейнере Subnets (Подсети) в инструменте Active Directory Sites And Services и свяжите подсети с новым сайтом. Каждый сайт должен иметь, по крайней мере, один контроллер домена и GC-сервер. Чтобы переместить существующий контроллер домена в сайт, вы можете щелкнуть правой кнопкой мыши на объекте контроллера домена в его текущем контейнере Servers (Серверы) и выбрать Move (Переместить). Затем вам будет предложен выбор сайта, в который вы хотите переместить контроллер домена. Если вы устанавливаете новый контроллер домена, то он будет автоматически расположен в том сайте, в котором подсеть IP соответствует IP-адресу контроллера домена. Возможно создание сайта без контроллеров домена, но этого делать не следует.

Создание доверительных отношений

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

После этого проверьте их, используя инструмент администрирования Active Directory Domains And Trusts (Домены и доверительные отношения Active Directory) в Windows Server 2003 и инструмент администрирования Server Manager (Менеджер серверов) в системе Windows NT 4 Server.

Создание файла .msi

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

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

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

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

Установите приложение на рабочей станции. Обычно используется «родной» процесс инсталляции программ.

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

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

Как только вы создали .msi файл, используйте процесс Group Policy Software Installation (Инсталляция программного обеспечения с помощью групповых политик) для распределения программного обеспечения на рабочие станции.

Создание модели сайта

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

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

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

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

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

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

Табл. 5-1. Сопоставление сетевой пропускной способности со стоимостью связи сайта

Доступная пропускная способность	Стоимость связи сайта
Больше или равно 10 Мб/с	10
От 10 Мб/с до 1,544 Мб/с	100
От 1,544 Мб/с до 512 Кб/с	200
От 512 Кб/с до128 Кб/с	400
От 128 Кб/с до 56 Кб/с	800
Меньше 56 Кб/с	2000

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

Управлять репликациями Active Directory можно также при помощи отключения мостов (site link bridging) между связями сайта. В большинстве случаев мосты связей сайта выключать не нужно, потому что при наличии мостов все связи сайта становятся транзитивными, т.е. если сайт А имеет связь с сайтом В, а сайт В имеет связь с сайтом С, то сайт А может реплицироваться напрямую с сайтом С. В большинстве случаев такое поведение желательно. Однако существуют исключения, когда необходимо отключить возможность наведения мостов между связями сайта. Например, компания имеет несколько центральных сайтов (hub sites) во всем мире и несколько небольших офисов, соединяющихся с центральными сайтами через медленные или средние сетевые подключения (см. рис. 5-12). Если центральные сайты связаны высокоскоростными соединениями, то автоматическое наведение мостов между связями сайта приемлемо. Однако, если сетевые подключения между центральными сайтами недостаточно быстры или большая часть полосы пропускания используется для других приложений, вы, возможно, не захотите иметь транзитивные подключения.



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

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



Рис. 5-12. Конфигурирование наведения мостов между связями сайта

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

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

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

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

Создание объектов GPO

Существует два способа создания новых объектов GPO. Первый способ заключается в использовании инструмента Active Directory для поиска контейнера, в котором нужно создать новый объект GPO. Затем нужно щелкнуть правой кнопкой мыши на контейнерном объекте и выбрать Properties (Свойства). Выберите вкладку Group Policy (Групповая политика) (см. рис. 11-4). Чтобы создать новый объект GPO, который будет связан с этим контейнером, щелкните на New (Новый).

 Рис. 11 -4. Создание нового объекта GPO, связанного с OU

Второй способ — это создание собственной консоли ММС (Microsoft Management Console) и добавление к ней оснастки Group Policy Object Editor (Редактор объектов групповой политики). При выборе этой оснастки необходимо указать объект GPO, который вы планируете изменить. По умолчанию оснастка загрузит Local Computer Policy (Локальная компьютерная политика). Щелкните на кнопке Browse (Просмотр), чтобы загрузить любой объект GPO из вашего домена или сайта. Используйте этот инструмент для изменения локального объекта GPO для любого компьютера, на котором у вас есть административные права (см. рис. 11-5).

Рис. 11 -5. Выбор GPO-объекта при изменении политики путем добавления оснастки Group Policy Object Editor к ММС-консоли

Чтобы создать новый объект GPO с помощью Welcome To The Group Policy Wizard (Мастер групповой политики), перейдите в нужное место вашего домена и щелкните на кнопке Create New Group Policy Object (Создать новый объект групповой политики).

Независимо от того, какой инструмент используется при создании нового объекта GPO, создается новая групповая политика и связывается с объектом, в котором вы создаете GPO. На рисунке 11-6 показан недавно созданный объект GPO. Позже объект GPO можно изменить в соответствии с вашими требованиями.

Создание панели задач для администрирования

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

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

Создание панели задач состоит из двух шагов. Сначала создается вид панели задач, а затем назначаются задачи, которые пользователь может выполнять на объектах. Чтобы создать панель задач, создайте настроенную ММС-консоль, содержащую административную оснастку, которую вы хотите использовать. Найдите контейнер, в который вы делегировали административные разрешения, затем щелкните правой кнопкой мыши и выберите New Taskpad View (Новый вид панели задач). Запустится мастер New Taskpad View Wizard. Мастер предоставит вам опции для выбора типа объектов, отображаемых на панели задач, и информации, отображаемой на экране. После создания вида панели вы можете добавлять задачи с помощью мастера новых задач. Мастер определит, какие типы задач могут быть выполнены пользователями панели задач. Список доступных задач зависит от типов объектов, которые видны на панели задач. Например, если вы выберите просмотр OU, которая содержит учетные записи пользователей, вы получите опцию назначения задач, которые могут быть выполнены с учетными записями пользователя. Закончив создание панели задач, можно также сконфигурировать ее параметры настройки, чтобы она содержала очень простой интерфейс.

На рисунке 9-15 показана панель задач, которая может использоваться администратором для установки паролей в определенной OU. Чтобы использовать этот инструмент, администратор просто выбирает учетную запись пользователя, а затем щелкает Reset Password (Заново установить пароль).

Рис. 9-15. Панель задач для сброса пользовательских паролей

Создание проекта группы безопасности

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

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

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

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

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

Добавьте глобальные или универсальные группы к локальным группам домена.

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

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

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

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

Часто пользователям требуется различный уровень доступа к совместно используемым папкам. Например, компания имеет общую папку Human Resource (Кадры), где хранится вся информация о полисах служащих. Все пользователи должны иметь возможность читать информацию, хранящуюся в папке, но только члены отдела кадров могут изменять эту информацию. В этом случае создаются две доменные локальные группы для общей папки. Одной группе назначается разрешение Read Only (Только для чтения), другой - Full Control (Полное управление) или Modify (Изменение). Затем глобальная группа Human Resources может быть добавлена к доменной локальной группе, которой было назначено разрешение Full Control, а все другие глобальные группы, которые нуждаются только в доступе Read Only, - к доменной локальной группе Read Only.

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



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

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

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



Рис. 10-6. Конфигурирование доступа к ресурсу с помощью глобальных и доменных локальных групп с несколькими доменами

Одним из основных вопросов при создании проекта группы безопасности является вопрос о том, когда использовать глобальные группы, а когда - универсальные. В некоторых случаях у вас нет выбора. Например, в Exchange 2000 Server группы, поддерживающие электронную почту, заменяют списки рассылки, используемые в Exchange Server 5.5 для группировки получателей электронной почты и назначения доступа к общим папкам. Если вы используете группы, поддерживающие электронную почту для Exchange 2000 Server, вы должны использовать уни-



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

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

Создание проекта OU

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

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

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

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

На рисунке 5- 11 показан проект OU для крупной компании. OU высшего уровня включает Domain Controllers OU (OU контроллеров домена) (все контроллеры домена расположены в этой OU) и OU администраторов уровня домена. OU высшего уровня могут включать OU службы

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



Рис. 5-11. Типовая структура OU

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

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

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

OU компьютеров - содержит все пользовательские компьютеры и включает отдельные OU компьютеров с системой Windows NT, Windows 2000, Microsoft Windows XP Professional и OU портативных компьютеров.

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

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

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

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

Создание резервной копии Active Directory

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

базу данных Active Directory и журналы транзакций;

системные файлы и файлы запуска, находящиеся под защитой Windows;

системный реестр контроллера домена;

всю зонную информацию DNS, интегрированную с Active Directory;

папку Sysvol;

базу данных регистрации классов СОМ+;

базу данных службы сертификатов (если контроллер домена является также сервером службы сертификатов);

информацию кластерной службы;

метакаталоги информационной интернет-службы Microsoft (IIS) (если служба IIS установлена на компьютере).

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

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

Примечание. По умолчанию только члены группы Administrators (Администраторы) и группы Backup Operators (Операторы резервного копирования) имеют разрешение делать резервное копирование контроллеров домена.

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

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

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

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

Создание сценария развертывания

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

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

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

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

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

1.      Установите самый последний пакет обновлений к системе Windows NT 4 Server на всех контроллерах домена Contoso.

2.      Синхронизируйте все контроллеры домена в домене Contoso.

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

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

5.      С помощью Server Manager (Менеджер сервера) пошлите сетевое сообщение пользователям, связанным с PDC по имени DC1 за один час до начала обновления NOS.

6.      Запустите обновление NOS контроллера DC1, после того как все пользователи отключатся. (Этот процесс включает установку Active Directory и может занимать несколько часов.)

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

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

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

Войдите в систему как тестирующий обновление пользователь с именем Upgradel, пароль = P@sswOrd. Задокументируйте результаты входа в систему в тестовом документе в папке проекта. Доложите менеджеру проекта, если вход не был успешным.

Обратитесь к общей папке \\ ITStaff\Policies\ и откройте файл PersonalSoftware.doc. Сделайте изменения и сохраните этот файл. Открылась ли эта папка? Открылся ли этот файл? Возникли какие-либо ошибки?

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

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

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

Создание учетной записи модернизации

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

Учетные записи, использующиеся для модернизации учетных записей пользователей, групп и служб, должна быть членами группы Domain Admins (Администраторы домена) в целевом домене, если вы используете SID-History для сохранения доступа к ресурсам. Учетная запись должна быть также членом группы Administrators (Администраторы) в исходных доменах Windows NT 4.

Специальные разрешения

Одна из записей в стандартном списке разрешений на вкладке Security (Безопасность) - Special Permissions (Специальные разрешения). Вы можете предоставлять объектам Active Directory не только стандартные разрешения, но и специальные. Они более детализированы и специфичны, чем стандартные разрешения. Чтобы получить доступ к ним, щелкните на Advanced (Дополнительно) на вкладке Security (рис. 9-2). В таблице 9-1 объясняется назначение столбцов в окне.

Примечание. Кнопка Default (По умолчанию) на вкладке Advanced сбрасывает разрешения, установленные на объекте к разрешениям, заданным по умолчанию.

Рис. 9-2. Просмотр дополнительных параметров настройки защиты Advanced Security Settings для пользовательского объекта

Табл. 9-1. Столбцы конфигурации специальных разрешений

Столбец		Объяснение
Туре (Тип)		Значение устанавливается для разрешений Allow (Разрешить) или Deny (Запретить). Обычно разрешения отсортированы так, что сначала перечисляются все разрешения Deny (Запретить). Порядок сортировки может быть изменен щелчком на любом заголовке столбца. Независимо от порядка появления в этом столбце сначала всегда оцениваются разрешения Deny (Запретить).
Name (Имя)		Имя участника безопасности, к которому применяется запись АСЕ.
Permission (Разрешение)		Столбец перечисляет уровень разрешения, предоставленного участнику безопасности. Уровни разрешений могут быть стандартными, например Full Control, специальными, например, Create/Delete User Objects (Создавать/Удалять пользовательские объекты), или только Special (Специальный). Доступные типы разрешений зависят от типа объекта.
Inherited From (Унаследованный от)		Столбец указывает место, в котором установлено это разрешение.
Apply To (Применяется к)		Столбец определяет глубину применения разрешение. Она имеет разнообразные параметры настройки, включая This Object Only (Только этот объект), This Object And All Child (Этот объект и все дочерние объекты) или Only Child Objects (Только дочерние объекты).

<
Это окно перечисляет все АСЕ- записи для объекта. Во многих случаях одни и те же участники безопасности могут быть перечислены в нескольких записях АСЕ. Например, группе Authenticated Users (Удостоверенные пользователи) дано разрешение Read Permissions (Читать разрешения), Read General Information (Читать информацию общего характера), Read Personal Information (Читать личную информацию), Read Web Information (Читать веб-информацию) и Read Public Information (Читать открытую информацию) в отдельных записях АСЕ.

Вы можете добавлять и удалять участников безопасности или редактировать текущие разрешения, предоставленные участнику безопасности, используя окно Advanced Security Settings (Дополнительные параметры настройки защиты). Если вы добавляете или редактируете разрешения, предоставленные участнику безопасности, вам дается два способа для назначения разрешений. На рисунке 9-3 показан первый способ назначения разрешений на объект.



Рис. 9-3. Назначение специальных разрешений на доступ к объектам Active Directory

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

Второй способ назначения разрешений предназначен для управления параметрами настройки свойств объекта (см. рис. 9-4).



Рис. 9-4. Конфигурирование разрешений, применяемых к свойствам объектов

Вкладка Properties (Свойства) используется для назначения разрешений на индивидуальные свойства объекта, выбранного в поле Name (Имя) окна Advanced Security Settings (Дополнительные параметры настройки защиты). Например, если вы применяете разрешения к пользовательским объектам, вам предоставляется опция назначения разрешений Read и Write для каждого атрибута, доступного для данного класса объектов.

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

Списки управления доступом

Еще один компонент, включенный в защиту Active Directory, - это объект, к которому участник безопасности должен обращаться. Этот может быть другой объект Active Directory, например, организационная единица (OU), принтер или участник безопасности. Объект может быть файлом на сервере с системой Windows Server 2003 или почтовым ящиком на сервере с Microsoft Exchange 2000 Server.

Разрешения, которые предоставляются этим объектам, расположены в списке управления доступом (ACL - Access Control List), также называемом дескриптором защиты (security descriptor). Каждый объект в Active Directory или в разделе файловой системы NTFS имеет дескриптор защиты. Дескриптор защиты включает идентификатор SID участника безопасности, который владеет объектом, а также SID для основной группы объекта. Кроме того, каждый объект имеет два отдельных списка ACL: список управления разграничительным доступом (DACL — Discretionary Access Control List) и список управления системным доступом (SACL - System Access Control List). Список DACL перечисляет участников безопасности, которым были назначены разрешения на доступ к объекту, а также уровень разрешений, которые были назначены

каждому участнику безопасности. Список DACL состоит из записей управления доступом (АСЕ — Access Control Entries). Каждая запись АСЕ содержит идентификатор SID и определяет уровень доступа к объекту, который разрешен данному SID. Список АСЕ включает записи для всех типов участников безопасности. Например, учетная запись пользователя может иметь разрешение Read (Чтение) для файла, а группа защиты -разрешение Full Control (Полное управление). Список DACL для файла имеет, по крайней мере, две записи АСЕ, одну - на предоставление пользователю разрешения Read, другую - на предоставление группе разрешения Full Control.

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

Примечание. Список DACL может содержать записи АСЕ, которые предоставляют доступ к ресурсу, а также АСЕ, которые запрещают доступ. Записи АСЕ, которые запрещают доступ, всегда перечисляются первыми в ACL, так что подсистема защиты сначала оценивает их. Если АСЕ запрещает доступ к ресурсу, то подсистема защиты не оценивает другие записи АСЕ, т.е. запись АСЕ, запрещающая доступ к ресурсу, всегда отменяет любую запись АСЕ, которая предоставляет доступ определенному идентификатору SID.

Способность к взаимодействию с другими системами Kerberos

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

клиент Kerberos;

центр распределения ключей Kerberos;

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

Имеются четыре возможных сценария взаимодействия.

Клиенты Windows 2000 или Windows XP Professional могут входить на контроллер домена Windows Server 2003 и иметь доступ к ресурсам, расположенным на Windows Server 2003 или на других службах, в основе которых находится протокол Kerberos.

Клиенты Windows 2000 или Windows XP Professional могут входить на KDC-центры, не принадлежащие Windows-платформе, и иметь доступ к ресурсам, расположенным на Windows Server 2003 или на других службах, в основе которых находится протокол Kerberos.

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

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

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

Однако реализация Kerberos Windows Server 2003 позволяет легко взаимодействовать с другими реализациями Kerberos. Для этого нужно создать доверительные отношения между областями домена Windows Server 2003 и областью Kerberos, не принадлежащей Windows-платформе. Доверительные отношения сферы могут быть сконфигурированы как транзитивные или нетранзитивные, а так же как односторонние или двухсторонние. Чтобы сконфигурировать доверительные отношения с другой областью, откройте инструмент Active Directory Domains And Trusts (Домены и доверительные отношения Active Directory) и перей-

дите в окно Properties (Свойства) того домена, в котором вы хотите создать доверительные отношения. На вкладке Trusts (Доверительные отношения) щелкните на кнопке New Trust, запустив New Trust Wizard. С помощью мастера вы можете создать доверительные отношения со стороны Windows Server 2003 с другой областью Kerberos. На рисунке 8-8 показано окно Properties доверительного отношения области после его создания.



Рис. 8-8. Конфигурирование доверительного отношения между областями

Дополнительная информация. Microsoft обеспечивает пошаговое руководство для конфигурирования доверительных отношений Kerberos между областями. Это руководство, озаглавленное как «Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability» доступно на веб-сайте Microsoft по адресу http:// www.microsoft.com/technet/prodtechnol/windows2000serv/ howto/kerbstep.asp.

Сравнение доменов и зон

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

Существует два различных типа зонных файлов в DNS: зоны прямого просмотра и зоны обратного просмотра. Зона прямого просмотра используется для разрешения имен хоста к IP-адресам. Эти функциональные возможности обеспечивают записи хоста (А). Зона прямого просмотра может включать записи SOA и NS, а также записи MX, CNAME и SRV. Зона прямого просмотра используется всякий раз, когда клиент-преобразователь делает запрос DNS-серверу, чтобы найти IP-адрес сервера в сети.

Зоны обратного просмотра выполняют противоположную функцию. Она используется тогда, когда IP-адрес хоста известен, а имя хоста не известно. Зона обратного просмотра также имеет записи SOA и NS, остальная часть записей - это записи PTR. Формат записи PTR подобен записи хоста, но он обеспечивает ответ для обратного поиска. Для получения дополнительной информации о записях см. табл. 3-1.

Имя зоны прямого просмотра является именем домена. Имя зоны обратного просмотра определить более трудно, потому что она использует IP-адрес подсети, а не имя домена, в качестве границы зоны. Когда вы создаете зону обратного просмотра, вы должны дать ей имя, основанное на IP-адресе подсети. Например, если вы создаете зону обратного просмотра для подсети 192.168.1.0, то зонное имя будет L168.192.in-addr.arpa. Имя in-addr.arpa специально зарезервировано в DNS для ссылок на зоны обратного просмотра. Первая часть зонного имени является сетевым адресом, записанным в обратном порядке. Если вы создаете зону обратного просмотра для подсети класса В (150.38.0.0), имя зоны обратного просмотра будет 38.150.in-addr.arpa.

Срочная репликация

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

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

Изменение политики паролей домена.

Перемещение роли хозяина относительного идентификатора (RID) на новый контроллер домена.

Изменение безопасности локальных средств защиты (LSA - Local Security Authority), например, когда изменяется пароль компьютера контроллера домена.

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

Пользовательские изменения пароля реплицируются по другой модели. Когда пользователь изменяет пароль на контроллере домена, это

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

Стандартные разрешения

Чтобы просмотреть стандартные разрешения для любого объекта Active Directory в разделе домена каталога, обратитесь к вкладке Security (Безопасность) в окне Properties (Свойства) нужного объекта в инструменте Active Directory Users And Computers. (Если вкладка Security не видна, выберите Advanced Features (Дополнительные функции) в меню View (Вид), повторно выберите объект и откройте окно Properties). Вкладка Security(Безопасность) показывает стандартные разрешения, которые доступны для каждого объекта (см. рис. 9-1).

Рис. 9-1. Просмотр стандартных разрешений на объекте «пользователь»

Каждый класс объектов в Active Directory имеет свой набор стандартных разрешений. Например, организационная единица (OU) - это контейнерный объект, который может содержать дочерние объекты, поэтому он имеет набор разрешений, применяемых к дочерним объектам, которые не подходят для объектов «пользователь». Однако, некоторые стандартные разрешения, например, Full Control (Полный контроль), Read (Чтение), Write (Запись), Create All Child Objects (Создание всех дочерних объектов) и Delete All Child Objects (Удаление всех дочерних объектов), применимы ко всем объектам.

Некоторые объекты Active Directory имеют стандартные разрешения, которые применяются к сгруппированным наборам свойств. Например, каждый объект «пользователь» имеет несколько наборов свойств типа Public Information (Открытая информация), Personal Information (Личная информация) или Web Information (Веб-информация). Каждый из этих наборов свойств относится к набору атрибутов, так что предоставление доступа к нему обеспечивает доступ к набору атрибутов. Например, набор свойств Personal Information включает атрибуты

homePhone, homePostalAddress, streetAddress и так далее. Использование наборов свойств для назначения доступа к группам атрибутов упрощает процесс назначения разрешений.

Дополнительная информация. Чтобы найти полный список атрибутов, включенных в каждый набор свойства, сделайте поиск выражения "property sets" (включая открывающие и закрывающие кавычки) в Help And Support Center (Центр справки и поддержки). Схема Active Directory определяет то, какие атрибуты являются частью каждого свойства, установленного с помощью значения rightsGuid для категории свойства (в разделе конфигурации каталога) и значения attributesSecurityGUID для объекта схемы. Например, значение rightsGuid для cn=Personal-Information, cn=Extended-Rights, cn=conf iguration, dc=forestname равно значению attributes ecurityGUID для cn=Telephone-Number, cn=Schema, cn=Configuration, dc=forestname. Это означает, что номер телефона включен в набор свойств Personal Information.

В дополнение к стандартным разрешениям вкладка Security показывает некоторые дополнительные права, такие как Receive As, Send As, Send To (все права, связанные с Microsoft Exchange 2000 Server), Change Password и Reset Password. Список разрешений может также включать разрешение Validated Write (Запись с проверкой ее достоверности). Например, объектам Group требуется разрешение Validated Write на то, чтобы добавить/удалить себя как члена. Различие между разрешением Validated Write и обычным Write состоит в том, что Validated Write гарантирует, что записанное значение допустимо. В этом случае пользователь, имеющий разрешение добавлять/удалять себя как члена группы, сможет добавлять к группе только себя самого.

Связи сайта

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

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

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

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

График репликации (Replication schedule) — определяет, в какое время в течение дня связь сайта доступна для репликации. Заданный по умолчанию график репликации разрешает репликации в течение 24 часов в день. Однако если пропускная способность пути к сайту ограничена, репликация может происходить только в нерабочие часы.

Интервал репликации (Replication interval) - определяет интервалы времени, через которые серверы-плацдармы проверяют появление модификаций каталога на серверах-плацдармах других сайтов. По умолчанию интервал репликации для связей сайта установлен на 180 минут. Интервал репликации применяется только в соответствии с графиком репликации. Если график репликации сконфигурирован так, чтобы позволять репликации с 22:00 до 5:00 по умолчанию, то серверы-плацдармы проверяют модификации через каждые 3 часа в этом промежутке времени.

Транспортные протоколы репликации (Replication transports). Для передачи репликации связь сайта может использовать или RPC по IP, или SMTP. Дополнительную информацию смотрите в разделе «Протоколы транспортировки репликации» далее в этой главе. Эти опции обеспечивают существенную гибкость в конфигурировании репликации между сайтами. Однако существуют также некоторые ошибки, которых следует избегать. Чтобы понять, как эти опции работают вместе, рассмотрите сеть компании, показанную на рисунке 4-11.

В Active Directory Windows Server 2003 все связи сайта считаются транзитивными (transitive) по умолчанию. Как показано на рисунке 4-11, Sitel имеет связи с сайтами Site2 и Site4, a Site2 имеет связь с сайтами Site3 и Site5. Из-за транзитивной природы связей сайта это означает, что Sitel может также реплицировать информацию напрямую с сайтами Site3 и Site5.

Стоимость связей сайта определяет путь, по которому будет происходить трафик репликации по сети. Когда КСС создает топологию маршрутизации, он использует накопленную информацию о стоимости всех связей сайта для вычисления оптимальной маршрутизации. В примере, показанном на рисунке 4-11, есть два возможных маршрута между сайтами Sitel и Site5: первый маршрут — через Site2, второй маршрут — через Site4. Стоимость передачи через Site2 - 300 (100 + 200), стоимость передачи через Site4 — 700 (500 + 200). Это означает, что весь трафик репликации будет направляться через Site 2, если это подключение функционирует.



Рис. 4-11. Конфигурация связи сайта

Когда трафик репликации проходит по нескольким связям сайта, графики связей сайта и интервалы репликации объединяются для определения эффективного окна репликации и интервала. Например, эффективная репликация между сайтами Site1 и Site3 будет происходить только с 24:00 до 4:00 (это время перекрытия графиков) каждые 60 минут (интервал репликации для связи Site2-Site3).

Примечание. Если графики связей сайта не перекрываются, то между несколькими сайтами репликация все-таки возможна. Например, если связь Sitel-Site2 доступна с 2:00 до 6:00, а связь Site2-Site3 доступна от 22:00 до 1:00, изменения каталога от сайта Sitel к сайту Site3 смогут передаваться. Изменения будут посланы от сайта Sitel к Site2, а затем от сайта Site2 к сайту Site3. Однако в этом случае время ожидания репликации составило бы почти целый день, потому что изменения, реплицированные на Site2 в 2:00, не будут реплицироваться на Site3 до 22:00.

Технология инсталлятора Windows

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

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

Служба инсталлятора Windows (Msiexec. exe). Эта служба управляет фактической инсталляцией программного обеспечения на рабочей станции. Служба использует файл библиотеки динамической компоновки (DLL) с именем Msi.dll для чтения файлов пакета .msi. В зависимости от содержимого пакетного файла инсталляции программ служба копирует файлы приложений на локальный жесткий диск, создает ярлыки, изменяет записи системного реестра и выполняет все задачи, перечисленные в файле msi.

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

Примечание. Технология инсталлятора Windows не является специфичной для систем Windows Server 2003, Microsoft Windows XP Professional или Microsoft Windows 2000, хотя служба инсталлятора Windows в этих операционных системах установлена по умолчанию. Используя технологию инсталлятора Windows, приложения могут быть установлены на других компьютерах. Вы можете установить службу инсталлятора Windows на компьютерах с системами Microsoft Windows NT, Windows 95 и Windows 98. Однако использовать групповые политики для распределения программного обеспечения можно только на компьютерах с системами Windows Server 2003, Windows XP Professional и Windows 2000.

Сейчас производители программного обеспечения поставляют пакетный файл .msi для инсталляции программ со всеми новыми программными продуктами. Он известен как файл «родного» (native) инсталлятора Windows.                            t

Тестирование плана модернизации

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

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

Тестирование даст возможность определить время, необходимое для полного завершения модернизации.

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

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

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

Типы доменов и контроллеров домена

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

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

Рис. 6-6. Окно Operating System Compatibility (Совместимость операционных систем)

Рис. 6-7. Окно Domain Controller Type (Тип контроллера домена)

Если вы выберете создание нового домена, то далее нужно будет указать, создавать ли корневой домен в новом лесу, дочерний домен в существующем домене или в новом дереве домена в существующем лесу (см. рис. 6-8). Проконсультируйтесь с проектной документацией своей службы Active Directory (см. гл. 5), чтобы определить природу создаваемого домена. Чтобы создать дочерний домен в существующем домене или в новом дереве домена в существующем лесу, вы должны представить соответствующие сетевые сертификаты для продолжения инсталляционного процесса. Для создания корневого домена нового леса сетевые сертификаты не требуются.

Рис. 6-8. Окно Create New Domain (Создание нового домена)

Типы групп

В системе Windows Server 2003 имеется два типа групп, называемых группами распространения (distribution group) и группами безопасности (security group). Когда вы создаете новый объект group, вам необходимо выбрать тип создаваемой группы (см. рис. 10-5).

Рис. 10-5. Создание новой группы в инструменте Active Directory Users And Computers

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

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

Вы можете преобразовывать группы распространения в группы безопасности и обратно, пока ваш домен работает на функциональном уровне Windows 2000 native (естественный). (Для получения дополнительной информации о функциональных уровнях см. табл. 2-1, 2-2 в гл. 2.) Если группа содержит учетные записи пользователей или контакты, то объекты user или contact не изменяются, когда изменяется тип группы.

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

Типы обновлений

Существуют два типа обновлений информации Active Directory, касающейся определенного контроллера домена. Первый тип обновлений - исходное обновление (originating update). Исходное обновление выполняется при добавлении, изменении или удалении объекта на контроллере домена. Второй тип обновлений - реплицируемое обновление (replicated update). Репликация выполняется тогда, когда изменение, сделанное на одном контроллере домена, копируется на другой контроллер домена. По определению исходное обновление, касающееся любого конкретного изменения, только одно, оно выполняется на том контроллере домена, где было сделано. Затем исходное обновление копируется на все контроллеры домена, которые имеют реплику раздела Active Directory, затронутого обновлением.

Исходные обновления Active Directory происходят в следующих случаях:

к Active Directory добавлен новый объект;

из Active Directory удален существующий объект;

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

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

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

Топология межсайтовой репликации

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

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

Рис. 4-8. Пример сложной GC-репликации

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

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

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

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

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

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



Рис. 4-9. Межсайтовые объекты связи

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

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

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

Как только к организации добавляются контроллеры домена с репликами определенного раздела Active Directory, KCC автоматически начинает создавать топологию репликации. Эта топология образует кольцо репликации. На рисунке 4-2 показан пример простой сетевой структуры с тремя контроллерами в одном домене и единственном сайте.

Рис. 4-2. Простое кольцо репликации

КСС создает кольцо репликации (см. рис. 4-2), в котором каждый контроллер домена сконфигурирован с двумя входящими связями репликации. Если одна из связей недоступна, то обновление может передаваться по другой связи. Кроме того, каждый контроллер домена сконфигурирован как контроллер-источник для двух других контроллеров домена. Это создает избыточное кольцо для каждого контроллера домена.

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

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



Рис. 4-3. Кольцо репликации, включающее более семи контроллеров домена

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

Табл. 4-1. Кольца репликации в сложном сайте

Раздел каталога	Партнеры по репликации
Раздел конфигурации каталога, раздел схемы каталога	Все контроллеры домена будут включены в кольцо репликации для раздела конфигурации каталога и раздела схемы каталога, потому что они копируются на все контроллеры домена данного леса.
Раздел каталога домена Contoso.com	DCl.Contoso.com, DC2.Contoso.com, DC3.Contoso.com, DC4.Contoso.com.
Раздел каталога домена Fabrikam.com	DC5.Fabrikam.com, DC6.Fabrikam.com.
Глобальный каталог (GC)	DCl.Contoso.com, DC4.Contoso.com, DC5.Fabrikam.com.
Раздел приложений каталога AppPartitionl	DC2.Contoso.com, DC6. Fabrikam.com.1.

Дополнительную информацию смотрите в примечании ниже.



Рис. 4-4. Кольца репликации, созданные для каждого раздела каталога



Примечание. Разделы приложений каталога DNS (ForestDnsZones и DomainDnsZones) также включены в топологию репликации. Чтобы не усложнять сценарий, эти разделы на рисунке 4-4 не обозначены и не приводятся в связанной с ним таблице. В главе 3 говорилось о том, что эти разделы обрабатываются так же, как другие доменные разделы каталога. По этой же причине на рисунке 4-4 не показана топология репликации глобального каталога GC. Процесс создания кольца репликации GC немного отличается от репликации других разделов и будет описан далее.

Разделы репликации и топологию можно просмотреть с помощью инструмента Replication Monitor (Монитор репликации). Монитор репликации — это одно из инструментальных средств поддержки, которые помещены на компакт-диск Windows Server 2003. Чтобы установить инструментальные средства поддержки, запустите файл Suptools.msi из каталога Support\Tools компакт-диска Windows Server 2003. Чтобы запустить монитор репликации, в окне Run (Выполнить) напечатайте replmon. На рисунке 4-5 показана конфигурация четырех серверов в лесу, отображаемая с помощью монитора репликации.



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

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

примере   на рисунке 4-5 DCl.Contoso.com имеет объект связи с DC4.Fabrikam.com.

Один из способов просмотра свойства объекта связи состоит в использовании монитора репликации. Чтобы рассмотреть свойства входящих связей сервера, добавьте сервер к контролируемому списку серверов. Затем щелкните правой кнопкой мыши на имени сервера и выберите Show Replication Topologies (Показать топологию репликации). Щелкните на View (Вид), далее — на Connection Objects Only (Только объекты связи), а затем щелкните правой кнопкой мыши на сервере и выберите Properties (Свойства). Вкладка Inbound Replication Connections (Входящие связи репликации) показывает все входящие связи для контроллера домена, а также разделы, реплицируемые через каждую связь. Как показано на рисунке 4-6, этот объект связи используется для реплицирования глобального каталога (показан как раздел Fabrikam.com), раздела схемы каталога и раздела конфигурации каталога. Всякий раз, когда это возможно, КСС создает объект связи, пригодный для реплицирования нескольких разделов каталога.



Рис. 4-6. Отдельный объект связи, использующийся для репликации нескольких разделов каталога

Транспортные протоколы репликации

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

Использование RPC по IP при внутрисайтовой репликации. Все подключения репликации в пределах сайта должны использовать подключение RPC no IP. Это подключение является синхронным, т.е. контроллер домена может в каждый момент времени обмениваться репликой только с одним партнером по репликации. RPC-подключение использует динамическое назначение портов (dynamic port mapping). Первое RPC-подключение выполняется через порт преобразователя конечного узла RPC (RPC endpoint mapper port) (IP порт 135). Это подключение применяется для определения порта, который использует контроллер-адресат для репликации.

Совет. Если вы реплицируете информацию каталога через брандмауэр или используете маршрутизаторы с включенной функцией фильтрации портов, вы можете определить номер порта, используемый контроллерами домена для репликации. Чтобы сделать это, создайте ключ системного реестра со значением типа DWORD и укажите любой допустимый номер порта: HKEY_LO-CAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\ Parameters\TCP/IP Port.

Использование RPC no IP при межсайтовой репликации. Это RPC-подключение отличается от межсайтового подключения только тем, что по умолчанию весь трафик, передаваемый между сайтами, сжат.

Примечание. Если вы рассмотрите два типа подключений RPC по IP в инструменте администрирования Active Directory Sites And Services, то заметите, что они по-разному идентифицированы в интерфейсе. RPC no IP в пределах сайта называется RPC, a RPC no IP между сайтами называется IP.

Использование SMTP при межсайтовой репликации. SMTP может оказаться хорошим выбором в методике репликации, если вы не имеете постоянной и быстрой связи между офисами компании. SMTP использует асинхронное подключение, т.е. контроллер домена может выполнять репликации с несколькими серверами одновременно. Однако использование SMTP имеет некоторые ограничения. Во-первых, SMTP может использоваться только для репликации информации между контроллерами домена, расположенными в различных доменах. С помощью протокола SMTP можно реплицировать только раздел конфигурации каталога, раздел схемы каталога и раздел GC. Во вторых, репликация по протоколу SMTP требует, чтобы компонент SMTP в информационных службах интернета (IIS) был установлен на всех контроллерах домена, которые будут использовать SMTP для репликации. Третье ограничение состоит в том, в организации необходимо установить Microsoft Certificate Authority (MCA) (Полномочие на выдачу сертификатов). Сертификаты от МСА используются для цифровых подписей к сообщениям SMTP, которые посылаются между контроллерами домена.

Транзитивные доверительные отношения

Все домены дерева поддерживают транзитивные двухсторонние доверительные отношения с другими доменами в этом дереве. В примере, рассмотренном выше, когда домен NAmerica.Contoso.com создается как дочерний домен корневого домена Contoso.com, автоматически создаются двухсторонние доверительные отношения между доменами NAmerica.Contoso.com и Contoso.com. Через доверительные отношения любой пользователь в домене NAmerica.Contoso.com может обращаться к любому ресурсу в домене Contoso.com, на доступ к которому есть разрешение. Аналогично, если в домене Contoso.com имеются какие-либо участники безопасности (как в неназначенном корневом домене), им можно давать доступ к ресурсам домена NAmerica.Contoso.com.

В пределах леса доверительные отношения устанавливаются или как родительско-дочерние доверительные отношения, или как доверительные отношения корня дерева (tree root). Примером родительско-дочер-них доверительных отношений являются отношения между доменами NAmerica.Contoso.com и Contoso.com. Доверительные отношения корня дерева - это отношения между двумя деревьями в лесу, например, между Contoso.com и Fabrikam.com.

Все доверительные отношения между доменами леса являются транзитивными. Это означает, что все домены в лесу доверяют друг другу. Если домен Contoso.com доверяет домену NAmerica.Contoso.com и домен Europe.Contoso.com доверяет домену Contoso.com, то транзитивность указывает на то, что домен Europe.Contoso.com также доверяет домену NAmerica.Contoso.com. Поэтому пользователи в домене NAmerica. Contoso.com могут обращаться к ресурсам, имеющимся в домене Europe.Contoso.com, и наоборот. Свойство транзитивности доверительных отношений применимо к доверительным отношениям корня дерева. Домен NAmerica.Contoso.com доверяет домену Contoso.com, и домен Contoso.com доверяет домену Fabrikam.com. Поэтому домен NAmerica. Contoso.com и домен Fabrikam.com также имеют транзитивные доверительные отношения друг с другом.

Требование малых затрат рабочего времени

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

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

Участники безопасности

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

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

Учетные записи Contact

Третий тип объектов, который может использоваться для представления пользователей в Active Directory, — это объект contact (контакт). Объекты contact отличаются от объектов user и inetOrgPerson тем, что они не является участниками безопасности (security principal). Обычно объекты contact используются только для информационных целей. Чтобы создать объект contact в инструменте Active Directory Users And Computers, найдите контейнер, в котором вы хотите создать объект, щелкните на нем правой кнопкой мыши и выберите New>Contact. При создании объекта contact вы должны ввести полное имя, можно также заполнить множество атрибутов объекта, включая номера телефона и адрес.

Контакты полезны в нескольких сценариях. Например, имеется пользователь, который не является участником безопасности в вашем домене, но чья контактная информация должна быть доступной. Это могут быть консультанты, работающие в вашем офисе и не имеющие прав на вход в сеть, но их контактная информация должна храниться в компании, чтобы ее могли легко найти все сотрудники. Контактами можно пользоваться для хранения общей информации лесов. Предположим, что ваша компания слилась с другой компанией, которая уже развернула Active Directory. Можно создать доверительные отношения между двумя лесами так, чтобы совместно использовать сетевые ресурсы, но глобальный каталог (GC) каждого леса будет содержать только учетные записи этого леса. Однако ваша работа может требовать, чтобы все или некоторые учетные записи обоих лесов были видны пользователям. Для разрешения этого используется инструмент Microsoft Metadirectory Services (MMS), чтобы создать объекты contact для каждой учетной записи пользователя из другого леса и заполнить эти объекты соответствующей контактной информацией.

Дополнительная информация. Инструмент MMS доступен через Microsoft Consulting Services (Консультационная служба) или через существующего партнера MMS. Для получения дополнительной информации смотрите веб-страницу http:// www.microsoft.com/windows2000 /technologies/directory / mms/'default, asp.

Другой вариант использования объекта contact возникает при реализации Microsoft Exchange 2000 Server, который, в отличие от более ранних версий, не имеет своей собственной службы каталога. Вместо этого Exchange 2000 Server требует наличия Active Directory, и вся информация сервера хранится в каталоге Active Directory. В Exchange Server 5.5 и более ранних версиях вы можете создавать собственного получателя. Собственный получатель имеет адрес электронной почты, вы можете посылать ему почту, но у него нет почтового ящика на вашем Exchange-сервере. Если вы используете Exchange 2000 Server, то объект contact с поддержкой электронной почты заменит объект собственного получателя. Когда вы включаете почту для объекта contact, вы назначаете учетной записи адрес электронной почты, и он становится видимым для почтового клиента. Когда вы посылаете почту объекту contact, она доставляется по правильному адресу электронной почты.

Удаление Active Directory

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

Что происходит с контроллером домена, когда вы удаляете Active Directory? Удаляется база данных каталога, все услуги, необходимые для Active Directory, останавливаются и удаляются, создается локальная база данных SAM, и компьютер понижается до роли автономного сервера или сервера члена группы. Результат будет зависеть от того, является ли контроллер домена дополнительным контроллером домена или последним контроллером домена в домене или лесу.

Чтобы удалить Active Directory из контроллера домена, напечатайте dcpromo в командной строке или в диалоговом окне Run. Вначале нужно определить, является ли контроллер домена дополнительным контроллером домена или последним контроллером домена в домене. На рисунке 6-16 показано окно соответствующего мастера.

Рис. 6-16. Опция удаления последнего контроллера домена

Затем мастер инсталляции Active Directory отобразит список всех разделов приложений каталога, найденных на контроллере домена. Если этот контроллер домена - последний в домене, то он является последним источником этих данных приложений. Возможно, что вы захотите защитить эти данные, прежде чем продолжать использование мастера, который удалит эти разделы. Если контроллер домена, из которого вы удаляете Active Directory, является также сервером DNS, то там будут находиться, по крайней мере, два раздела приложений каталога, в которых хранятся зонные данные. На рисунке 6-17 смотрите пример разделов приложений DNS каталога, найденных при деинсталляции Active Directory.

После того как вы подтвердите удаление прикладного раздела каталога, вас попросят ввести новый пароль для локальной учетной записи администратора. Затем появится окно Summary (Резюме), и удаление

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

Рис. 6-17. Удаление разделов приложений DNS в каталоге

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

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

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

Папка Sysvol и все ее содержимое удаляется из контроллера домена.

Объект NTDS Settings (Параметры настройки NTDS) и перекрестные ссылки удаляются.

Служба DNS обновляется для удаления SRV записей контроллеров домена.

Создается локальная база данных SAM для обработки локальной политики безопасности.

Все службы, которые были запущены при установке Active Directory (например, Net Logon - Сетевой вход в систему), останавливаются.

Тип учетных записей компьютера изменяется с контроллера домена на сервер-член домена, и учетная запись компьютера перемещается из контейнера Domain Controllers (Контроллеры домена) в контейнер Computers (Компьютеры). Чтобы удалить Active Directory из дополнительного контроллера домена, вы должны войти в систему как член группы Domain Admins или Enterprise Admins.

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

Удаление последнего контроллера домена

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

Мастер инсталляции Active Directory проверяет, что не существует никаких дочерних доменов. Удаление Active Directory блокируется, если обнаружены дочерние домены.

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

Все объекты, связанные с этим доменом, удаляются из леса.

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

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

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

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

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

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

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

Удаление программное обеспечение при удалении пакета программ.

Первые две опции обсуждались ранее в этой главе. Последняя опция требует некоторого объяснения. Когда вы удаляете пакет программ из объекта GPO, существует возможность выбора способа управления программным обеспечением, установленным под управлением этого объекта GPO. Щелкните правой кнопкой мыши на пакете программ, находящемся в списке в Software Installation (Инсталляция программ), выберите All Tasks (Все задачи), а затем выберите Remove (Удалить). На рисунке 12-11 показано диалоговое окно, которое появляется при выборе удаления инсталляционного пакета. Если будет выбрана опция Immediately Uninstall The Software From Users And Computers (Деинсталлировать программное обеспечение у пользователей и на компьютерах), то программное обеспечение будет деинсталлироваться при следующей перезагрузке компьютера или при следующем входе пользователя в систему. Если будет выбрана опция Allow Users To Continue To Use The Software, But Prevent New Installations (Разрешить пользователям продолжать использование программного обеспечения, но предотвратить новые инсталляции), приложение не будет удалено с рабочих станций, но пользователи больше не смогут установить приложение, используя этот GPO-объект.

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

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

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

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

Модель репликации Active Directory Windows Server 2003, по существу, совпадает с той, которая используется в системе Microsoft Windows 2000, но имеет ряд существенных улучшений.

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

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

Примечание. Описанные выше преимущества доступны только в том случае, если домен работает на функциональном или на временном (interim) функциональном уровне Windows Server 2003. Функциональный уровень Windows Server 2003 доступен только тогда, когда на всех контроллерах домена в лесу выполняется Windows Server 2003. Временный функциональный уровень Windows Server 2003 доступен в том случае, когда лес содержит контроллеры домена, на которых выполняются Windows Server 2003 и Windows NT. Для получения дополнительной информации о функциональных уровнях см. гл. 7.



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

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

Примечание. Чтобы отключить сжатие или включить процедуру уведомлений для репликации между сайтами, используется инструмент ADSI Edit для модификации атрибута Options (Опции) объекта-соединения сайта (site link object) или объекта-связи (connection object). Чтобы выключить сжатие, установите значение атрибута Options (Опции) равным четырем; чтобы включить уведомления, установите это значение равным единице.

Улучшенная генерация топологии между сайтами. В системе Windows 2000 размер организации имел ограничение в 100 сайтов в лесу. Это ограничение связано со временем, которое требуется службе КСС (Knowledge Consistency Checker — модуль проверки целостности сведений), для того чтобы вычислить топологию маршрутизации для такого количества сайтов. Это ограничение в Active Directory Windows Server 2003 снято.

Управление базой данных Active Directory с помощью утилиты Ntdsutil

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

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

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

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

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

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

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

Управление группами

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

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

Управление категориями программного обеспечения

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

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

Active Directory Windows Server 2003 поставляется без каких-либо предопределенных программных категорий, так что можно создать любые. Чтобы создать категорию, откройте любой существующий объект GPO, щелкните правой кнопкой мыши на Software Installation (Инсталляция программного обеспечения) в разделе Computer Configuration или User Configuration, выберите Properties, а затем выберите вкладку Categories (Категории) (см. рис. 12-9). Программные категории применя-

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

Рис. 12-8. Отображение программных категорий в панели Add Or Remove Programs

Рис. 12-9. Конфигурирование программных категорий на GPO-объектах

Управление компьютерами

Еще один тип объектов Active Directory - это объект computer (компьютер). В Active Directory имеется два типа таких объектов. Первый - это объект domain controller (контроллер домена), который создается при назначении сервера контроллером домена. По умолчанию объекты domain controller расположены в OU Domain Controllers. Вы можете перемещать контроллеры домена из этой OU, но делать это следует с осторожностью. Многие параметры настройки безопасности контроллера домена сконфигурированы в OU Domain Controllers, и перемещение контроллера домена из этого контейнера может серьезно изменить настройку безопасности.

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

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

Примечание. Все компьютеры, на которых выполняются системы Windows NT, Windows 2000, Microsoft Windows XP Professional и Windows Server 2003, должны иметь компьютерную учетную запись в домене. Компьютеры, на которых выполняются системы Microsoft Windows 95 или Microsoft Windows 98, не имеют учетных записей.

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

Очень полезная опция позволяет любому компьютеру из Active Directory обратиться к приложению Computer Management (Управление компьютером). Найдите компьютер в инструменте Active Directory Users And Computers, щелкните правой кнопкой мыши на значке нужной рабочей станции или сервера и выберите Manage (Управление). Откроется ММС-консоль Computer Management, содержащая параметры выбранной вами рабочей станции или сервера.

Примечание. Тот факт, что вы не будете сильно заняты администрированием компьютерных объектов в Active Directory, вовсе не подразумевает, что вы не будете использовать Active Directory для управления компьютерами. Главы 11, 12 и 13 рассматривают с групповые политики, обеспечивающие мощныее инструментальные средства управления компьютерами.

Управление объектами printer

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

Управление опубликованными общими папками

Еще один объект, который можно публиковать в Active Directory - это объект shared folder (общая папка). Чтобы опубликовать общую папку в Active Directory, найдите нужный контейнер. Щелкните правой кнопкой мыши на контейнере и выберите New (HoBbm)>Shared Folder (Общая папка). Затем напечатайте имя объекта Active Directory, а также UNC-путь для общей папки. После того как в Active Directory будет создан объект shared folder, пользователи могут просматривать и искать его в Active Directory. Найдя объект shared folder, пользователи щелчком правой кнопкой мыши на объекте могут отобразить диск на общую папку.

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

Рис. 10-10. Публикация общей папки в Active Directory

Ограничение, связанное с публикацией общих папок в Active Directory, состоит в том, что, если общая папка переместится на другой сервер, то все клиенты, имеющие диски, отображенные на эту общую папку, обнаружат, что отображение больше не работает. Это произойдет, потому что при отображении клиентского диска на общую папку в Active Directory используется UNC-путь к ресурсу. Например, вы можете создать и опубликовать общую папку по имени Saleslnfo, которая указывает на \\Server1\SalesInfo. Когда пользователь находит эту общую папку в Active Directory и отображает диск, то для отображения диска используется синтаксис \\Serverl\SalesInfo. Если папка переместится, отображение диска перестанет действовать, даже если вы сделаете изменения в Active Directory так, чтобы объект указывал на новое место расположения.

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

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

---

---