WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 | 2 || 4 | 5 |   ...   | 8 |

«С. Реймер, М. Малкер Active Directory для Windows Server 2003. Справочник администратора/Пер, с англ. — М.: «СП ЭКОМ», 2004.— 512 с: ил. ...»

-- [ Страница 3 ] --

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

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

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

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

Любые связи сайта, которые вы добавляете к мосту связей сайта, рассматриваются по отношению друг к другу как транзитивные;

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

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

Транспортные протоколы репликации 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, которые посылаются между контроллерами домена.

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

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

4-12). Вы получите доступ к опции конфигурирования сервера как привилегированного (preferred) сервера-плацдарма для передачи данных по SMTP или по IP.

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

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

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

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

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

Монитор репликации открывается с пустым инструментом управления. Перед началом работы щелкните на Edit в строке меню, чтобы добавить один или более серверов к списку контролируемых серверов. Как только серверы добавлены в список, вы можете управлять почти всеми аспектами репликации Active Directory. Например, отслеживать текущее состояние репликации, последнюю успешную репликацию или любые отказы при репликации;

вынуждать репликацию;

вынуждать КСС к повторному вычислению топологии маршрутизации. Используя инструмент мониторинга, вы можете контролировать репликации на всех контроллерах домена вашей сети. Второй полезный инструмент мониторинга репликаций - Repadmin. Он также устанавливается с помощью файла Suptools.msi. Чтобы запустить этот инструмент, в командной строке напечатайте repadmin. Инструмент Repadmin обеспечивает такие же функциональные возможное ти, как и Replication Monitor, но через интерфейс командной строки. Инструмент Repadmin дополнительно позволяет изменять топологию репликации, добавляя объекты связи.

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

Вы можете запускать инструментальные средства непосредственно из окна Help And Support Center.

Существуют два стандартных средства администрирования серверов для мониторинга и поиска неисправностей репликации. Первый инструмент -Event Viewer (Средство просмотра событий).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Владельцы леса должны обладать комбинацией технической компетенции и понимания бизнеса.

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

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

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

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

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

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

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

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

• Граница репликации. Границы домена являются границами репликации для раздела домена каталога и для информации домена, хранящейся в папке Sysvol на всех контроллерах домена. В то время как другие разделы каталога (раздел схемы, конфигурации и GC) реплицируются по всему лесу, раздел каталога домена реплицируется только в пределах одного домена.

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

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

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

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

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

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

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

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

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

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

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

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

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

Самый легкий сценарий для управления групповыми политиками — это среда отдельного домена.

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

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

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

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

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

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

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

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

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

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

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

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

Проектирование корневого домена леса Другое важное решение, которое вы должны принять при проектировании службы Active Directory большой компании, — действительно ли вы должны развернуть назначенный корневой домен (называемый также пустым корнем). Назначенный корневой домен (dedicated root domain) -это домен, который выполняет функции корневого домена леса. В этом домене нет никаких учетных записей пользователей или ресурсов, за исключением тех, которые нужны для управления лесом.

Лес с назначенным корневым доменом показан на рисунке 5-1.

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

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

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

Назначенный корневой домен требует конфигурирования, которое не применяется к другим доменам леса. Поскольку корневой домен содержит хозяина операций леса, контроллеры домена для корневого домена должны быть защищены в максимально возможной степени. Домен леса также содержит группы, которые могут изменять лес и схему. Члены административных групп в корневом домене должны иметь более высокий уровень доверия, чем в случае с любым другим доменом. Вы, вероятно, захотите использовать опцию Restricted Group (Ограниченная группа) в политике Domain Security Policy (Политика безопасности домена) для управления членством этих групп. Конфигурация DNS корневого домена должна быть настолько безопасной, насколько это возможно. Поскольку установка в корневом домене какого-либо дополнительного компьютера маловероятна, вы должны включить безопасные динамические обновления для корневого домена зоны DNS на время инсталляции контроллеров домена, а затем динамические обновления для этой зоны следует отключить.

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

Многие крупные компании развернули домены Windows NT, используя модели с одним или несколькими хозяевами домена, в которой одни домены содержали учетные записи пользователей и глобальных групп, а другие — ресурсы компании. В некоторых случаях компании имели дюжины доменов с учетными записями и сотни доменов с ресурсами. Часто домены учетных записей были организованы вокруг географических регионов или деловых подразделений, и каждый из них обычно имел один или несколько доменов ресурсов в пределах одного географического региона или делового подразделения. На рисунке 5-2 показан пример того, как может выглядеть конфигурация доменов.

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

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

Поскольку домены Active Directory могут содержать значительно больше объектов, в некоторых случаях компания могла бы соединить несколько главных доменов учетных записей в один домен Active Directory. Как только произойдет модернизация доменов учетных записей, можно реструктурировать домены ресурсов, чтобы они стали организационными единицами в домене Active Directory. Иногда домены ресурсов можно удалить. Например, некоторые компании имели домены ресурсов для инфраструктуры Exchange Server 5.5. При переходе организации к Exchange Server 2000 серверы могут быть развернуты в домене Active Directory. Когда последний сервер, на котором выполняется Exchange Server 5.5, удаляется, домен Exchange можно также удалить. На рисунке 5-3 показан возможный переход для компании, имеющей несколько доменов Windows NT 4.

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

Рис. 5-3. Обновление доменов Windows NT 4 до Active Directory Windows Server Деревья доменов и доверительные отношения По мере добавления доменов к лесу вы можете делать это в конфигурации с несколькими деревьями или в единственном дереве. Если вы добавляете домены в единственное дерево, то они будут иметь смежное пространство имен, т.е. подпадать под пространство имен корневого домена.

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

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

Но с появлением условных ретрансляторов (conditional forwarders) и сокращенных зон (stub zones) эта процедура в Windows Server 2003 упростилась.

Если вы развертываете несколько доменов, и пользователи часто обращаются к ресурсам, расположенным в других доменах или входят на них, вы, возможно, захотите добавить прямые доверительные отношения (shortcut trusts) к проекту своего домена. Прямые доверительные отношения используются для улучшения производительности при доступе к ресурсам или при входе в систему с разных доменов. По умолчанию дове- • рительные отношения между доменами в Active Directory являются или родительско-дочерними, или доверительными отношениями корня дерева. Каждая родительско-дочерняя пара совместно использует двухсторонние доверительные отношения, так же как и корни каждого дерева. Поскольку доверительные отношения транзитивны, это означает, что все домены в лесу доверяют друг другу. Однако когда пользователь входит в домен, не являющийся его домашним доменом, возможно, что процессу входа в систему придется пересекать весь путь доверительных отношений. Например, корпорация имеет структуру домена, показанную на рисунке 5-4. Если пользователь с учетной записью в домене Asia.Fab-rikam.com входит в домен Canada.NAmerica.Contoso.com Contoso.com, то начальный запрос входа в систему пойдет на контроллер домена в канадском домене. Запрос на вход в систему должен ссылаться на доверительные отношения с доменом NAmerica, затем с доменом Contoso, далее с доменом Fabrikam и, наконец, с доменом Asia. Прямые доверительные отношения могут сокращать путь доверительных отношений. Например, если прямые доверительные отношения сконфигурированы между доменами Canada и Asia, запрос на вход в систему может быть отправлен контроллеру домена в домене Asia напрямую.

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

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

Рис. 5-4. Прямые доверительные отношения могут использоваться для оптимизации доступа к ресурсам разных доменов Изменение иерархии доменов Планирование доменов следует закончить перед началом развертывания, потому что доменную конфигурацию трудно изменять после. Windows Server 2003 имеет возможность переименования доменов в лесу, работающем на функциональном уровне Windows Server 2003. Можно перемещать домен из одного дерева в другое в пределах леса, но нет возможности замены корневого домена леса. По существу, возможность переименования домена позволяет вам изменять структуру именования в лесу, но не позволяет делать более фундаментальные изменения. Например, если вы решите изменить деловые подразделения в каждом домене, вы должны переместить большое количество объектов между доменами. Для этого вы должны использовать инструмент для переме щения Active Directory (ADMT - Active Directory Migration Tool v.2) или сторонние инструментальные средства. Инструмент ADMT можно найти в папке /I386/ADMT на компакт диске Windows Server 2003.

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

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

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

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

• Проектирование конфигурации Group Policy (Групповая политика) уровня домена.

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

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

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

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

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

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

Исследуя существующую инфраструктуру DNS, сделайте следующее.

• Задокументируйте все DNS-имена доменов, используемые в настоящее время в пределах компании. Сюда входят имена, использующиеся в интернете, а также внутренние имена.

• Задокументируйте все дополнительные имена, которые компания зарегистрировала в структурах власти интернета. Часто компания использует в интернете только имя.com, можно также зарегистрировать и другие имена домена высшего уровня типа.net или.org.

Вы могли бы использовать одно из этих имен домена для вашего внутреннего пространства имен.

• Задокументируйте существующую конфигурацию серверов DNS. Эта документация должна включать типы DNS-серверов, в настоящее время развернутых в сети (например DNS-серверы на базе Windows, BIND - Berkeley Internet Name Domain или Lucent VitalQIP). Кроме того, конфигурация DNS должна содержать информацию о ретрансляторах, о делегировании зон и о конфигурации основных и дополнительных серверов.

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

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

Использование одного и того же пространства имен в качестве внутреннего и внешнего пространства Некоторые компании захотят использовать одно и то же имя DNS и внутри, и снаружи. В этом случае компания должна зарегистрировать только одно DNS-имя в интернете. Например, на рисунке 5-5 показано, что компания Contoso могла бы использовать Contoso.com и внутри, и вне компании.

Рис. 5-5. Использование единственного пространства имен DNS Предостережение. Независимо от того, используете ли вы одинаковые или различные внутреннее и внешнее пространства имен, ваш внутренний сервер DNS никогда не должен быть доступен внешним клиентам. Внутренний DNS-сервер будет содержать все записи контроллера домена, а также, по возможности, записи всех компьютеров в вашей сети (если вы включите динамическую службу DNS - DDNS). Доступными из интернета должны быть только те записи, которые касаются ресурсов, предназначенных для этого доступа. Для большинства компаний список ресурсов, доступных извне, состоит из адресов серверов SMTP, Web-серверов и нескольких других серверов. Использование одного пространства имен не подразумевает, что вы должны использовать один DNS-сервер или зонный файл для внутренних и внешних задач.

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

Другое преимущество использования единого пространства имен состоит в том, что надо регистрировать только одно DNS-имя.

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

Использование различного внутреннего и внешнего пространства имен Большинство компаний использует различные внутренние и внешние пространства имен.

Например, компания могла бы использовать Contoso.com как внешнее пространство имен и имя Contoso.net или ADContoso.com для внутреннего пространства имен (см. рис. 5-6).

Примечание. Любое различие в именах домена означает, что внутри вы используете пространство имен, отличающееся от внешнего. Например, если вы используете Contoso.com как внешнее пространство имен, то Contoso.net, ADContoso.com и AD.Contoso.com — это разные пространства имен. AD.Contoso.com потребует конфигурации DNS, отличной от двух других, и все три пространства имен являются уникальными.

Рис. 5-6. Использование отдельных, внутреннего и внешнего, пространств имен Часто уникальное внутреннее пространство имен выбирается из соображений безопасности, чтобы предотвратить выставление внутреннего пространства имен в интернете. Кроме того, конфигурирование DNS и прокси упрощается в значительной степени. Главное неудобство в использовании уникального пространства имен состоит в том, что компания должна регистрировать дополнительные имена DNS у властей интернета. Хотя регистрация не является обязательным требованием, однако она рекомендуется. Если вы не зарегистрируете имя, а другая компания зарегистрирует, то ваши пользователи не смогут искать в интернете ресурсы, имеющие такое же имя домена как внутреннее пространство имен.

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

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

Рис. 5-7. Проект пространства имен DNS в отсутствие инфраструктуры DNS Практический опыт. Внутреннее и внешнее пространства имен Вопрос использования внутреннего пространства имен, отличного от внешнего, может вызвать дискуссии в компании. В некоторых случаях лучше использовать различные пространства имен, но владельцы компании могут оказывать сильное сопротивление использованию чего-либо, отличного от пространства имен интернета. Часто причина для этого — торговая марка;

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

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

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

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

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

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

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

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

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

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

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

Рис. 5-10. Конфигурирование DNS путем добавления дочерних доменов к существующим доменам Интеграция с существующей инфраструктурой DNS Практически все большие компании уже имеют установленную инфраструктуру DNS. Во многих случаях DNS используется для разрешения имен серверов UNIX или для обеспечения потребности пользователей в услугах DNS для доступа в интернет. Иногда услуги DNS обеспечиваются DNS серверами BIND, выполняющимися на UNIX-серверах. Поскольку существует зависимость Windows NT от имен NetBIOS и от службы имен интернета для Windows (WINS), в противоположность именам хостов и DNS, многие Windows-администраторы мало касаются службы DNS. Ситуация изменилась с выпуском Active Directory систем Windows 2000 и Windows Server 2003. В главе 3 говорилось о том, что Windows Server 2003 требуется служба DNS для того, чтобы клиенты могли находить контроллеры домена.

Поэтому критическим моментом при обсуждении проекта Active Directory становится вопрос о размещении службы DNS.

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

Необходимость в службе DNS для Active Directory заставит вас организовать взаимодействие с текущей инфраструктурой DNS.

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

Такая возможность, конечно, существует. Единственное требование для DNS - сервер должен поддерживать записи SRV. Вы, вероятно, захотите, чтобы серверы DNS также поддерживали динамические обновления (особенно, если вы планируете регистрировать все IP адреса клиентов в DNS) и дополнительные (incremental) зонные передачи. Если текущая инфраструктура использует BIND серверы DNS, серверы BIND 8.1.2 поддерживают записи SRV и динамические обновления.

Сервер BIND 8.2.1 поддерживает дополнительные зонные передачи. Если вы используете одну из этих версий BIND, то вы можете продолжать использование DNS-серверов BIND. (Если вы используете DNS-серверы Lucent VitalQIP, то версии 5.2 и более поздние совместимы с BIND 8.2.2.) Практический опыт. Выбор сервера DNS Вопрос о том, использовать ли DNS-серверы системы Windows Server 2003 или DNS-серверы не от компании Microsoft, может вызвать горячую дискуссию и не привести к удовлетворительному результату. Большие компании в течение многих лет пользовались DNS-серверами BIND, DNS-администраторы грамотны, опытны и не хотят переходить к службе DNS на платформе Microsoft. Они выражают беспокойство по поводу стабильности, надежности и безопасности службы DNS на серверах Microsoft.

Один из подходов к решению этого вопроса состоит в следующем: на самом деле не имеет значения, чем обеспечивается DNS-служба. Пока DNS-серверы поддерживают записи SRV, Active Directory Windows Server 2003 может работать с любым сервером DNS. Критичным является то, что служба DNS всегда должна быть доступной. Если она перестанет работать в рабочее время, клиенты или серверы не смогут найти контроллера домена Active Directory. Поэтому вопрос можно поставить так: «Какой DNS-сервер обеспечит надежность, необходимую для работы Active Directory?».

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

Многие компании решили оставаться с DNS-серверами BIND, и эти серверы обеспечили требуемые функциональные возможности без каких-либо проблем.

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

Второй вариант объединения DNS Windows Server 2003 с BIND состоит в развертывании обоих типов DNS. Многие компании используют DNS-серверы BIND как основной сервер имен для внутреннего пространства имен. Например, компания Contoso может использовать BIND при разрешении имен для Contoso.com. Если она решит развертывать Active Directory и использовать DNS-сервер на базе Windows Server 2003, существует множество вариантов. Если компания Contoso захочет использовать Contoso.com как DNS-имя Active Directory, она может переместить основную зону на DNS-сервер на базе Windows Server 2003 и поддерживать DNS сервер BIND в качестве дополнительного сервера имен. Или DNS-сервер на базе Windows Server 2003 мог бы стать дополнительным сервером имен к DNS-серверу BIND.

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

Однако если вы планируете использовать интегрированные зоны Active Directory, то DNS-зона BIND должна быть сконфигурирована как дополнительная зона. Интегрированная зона Active Directory не может быть дополнительной зоной.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом случае необходимо проектировать структуру OU, базируясь на структуре 1Т управления, а не на структуре управления бизнесом.

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

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

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

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

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

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

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

Создание проекта 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, подобные распределенной файловой системе (DFS - Distributed File System), можно добавить к сети для ограничения трафика, связанного с доступом клиентов к местному сайту.

Инфраструктура организации сети и проектирование сайта Поскольку проектирование сайта сильно зависит от организационной инфраструктуры сети, первый шаг в создании проекта состоит в документировании этой инфраструктуры.

Документирование должно включать:

• схемы топологии глобальной (WAN) и локальной сети (LAN), детализирующие сеть корпорации, в которых содержится информация о полной пропускной способности и доступной пропускной способности между всеми офисами компании;

• список всех офисов компании, в которых компьютеры связаны через высокоскоростные сетевые соединения. Определение высокоскоростного подключения меняется в зависимости от таких факторов, как количество пользователей в офисах компании, общее количество объектов в домене и доменов в лесу. Кроме того, нужно определить, какая часть из полной полосы пропускания сети доступна для репликации. В большинстве случаев сетевые подключения в пределах сайта должны иметь скорость доступной полосы пропускания 512 Кб/с. В крупной компании в качестве минимальной скорости сетевого подключения в пределах сайта устанавливается скорость в 10 Мб/с;

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

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

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

Каждый сайт должен иметь контроллер домена, а большинство из них -и 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 Мб/с до 1,544 Мб/с От 1,544 Мб/с до 512 Кб/с От 512 Кб/с до128 Кб/с От 128 Кб/с до 56 Кб/с Меньше 56 Кб/с Используя информацию, приведенную в таблице 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, вы выключаете транзитивность связей сайта, т.е. все связи сайтов в организации больше не являются транзитивными. Если после этого понадобятся мосты между связями сайта, их необходимо будет сконфигурировать вручную. Используйте эту опцию осторожно!

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

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

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

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

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

Windows Server 2003 имеет несколько нововведений, которые делают развертывание Active Directory в этом сценарии более легким, чем в Windows 2000.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В главе 2 говорилось, что база данных каталога хранится на жестком диске контроллера домена в файле Ntds.dit. В процессе инсталляции Windows Server 2003 файл Ntds.dit сохраняется в папке %systemroot %\system32 на локальном диске. В процессе инсталляции Active Directory-файл Ntds.dit копируется в место, идентифицированное во время инсталляции, или в заданную по умолчанию папку %systemroot %\NTDS, если не определено другое место. При наличии файла Ntds.dit, скопированного на жесткий диск в процессе инсталляции Windows Server 2003, Active Directory может быть установлена в любое время без необходимости обращаться к инсталляционной среде.

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

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

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

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

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

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

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

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

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

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

Перед установкой службы Active Directory вы должны сконфигурировать параметры настройки протокола интернета в окне Local Area Connection Properties (Свойства локальных подключений).

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

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

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

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

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

Если DNS уже установлена в сети, проверьте ее конфигурацию, чтобы она могла поддерживать Active Directory. Для этой проверки можно использовать команду Dcdiag (доступна как часть набора инструментальных средств, созданного при установке файла \Support\Tools\ Support.msi с компакт-диска Windows Server 2003). Наберите команду:

dcdiag/test:dcpromo/dnsdomain:domainname/newforest Теперь вы сможете удостовериться, что DNS-сервер является официальным для домена domainname и может принимать динамические обновления для новых контроллеров домена. Для получения дополнительной информации об использовании инструмента dcdiag напечатайте dcdiag/? в командной строке.

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

Если вы будете устанавливать службу сервера DNS одновременно с Active Directory, сконфигурируйте установки сервера DNS на компьютере, чтобы указать себя перед установкой Active Directory. Откройте окно Internet Protocol (TCP/IP) Properties (Свойства протокола интер нета) и установите адрес сервера Preferred DNS Server (Привилегированный сервер DNS) на IP адрес локального компьютера (см. рис. 6-1).

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

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

Глобальная группа Domain Admins (Администраторы домена) имеет такой уровень разрешений.

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

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

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

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

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

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

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

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

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

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

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

Pages:     | 1 | 2 || 4 | 5 |   ...   | 8 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.