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

Перед реализацией сетевой среды на базе  Windows  2000 Вы должны решить, как внедрить Active Directory.

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

 

Планирование пространства имен.

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

Допустим, внешнее пространство имен DNS организации — microsoft.com. Вы можете использовать пространство имен Active Directory, соответствующее microsoft.com, или выбрать другое внутреннее пространство имен. Каждый вариант имеет свои плюсы и минусы.

Примечание:

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

 

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

Существует два варианта разработки пространства имен Active Directory: оно может соответствовать либо отличаться от имеющегося внешнего пространства имен DNS.

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

  

Служба каталогов Active Directory. Глава 1.

 

Сценарий 1. Внутреннее и внешнее пространства имен идентичны.

По этому сценарию организация использует одно и то же имя для внешнего и внутреннего пространств имен. Например, имя microsoft.com будет применяться для доступа к ресурсам как изнутри организации, так и из Интернета. Для реализации этого сценария надо соблюсти следующие условия:

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

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

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

Преимущества:

1. Имя дерева, microsoft.com, согласовано в частной сети и Интернете.
2. Появляется возможность унифицировать вход в систему — для этого пользователи локальной сети и Интернета смогут применять одно и то же имя, например userna-me@microsoft.com будет служить как регистрационное имя и как идентификатор электронной почты.

Недостатки:

1. Усложняется конфигурация — при настройке прокси – клиентов надо учесть, что внутренние и внешние ресурсы отличаются.
2. Придется следить, чтобы внутренние ресурсы случайно не стали общедоступными.
3. Вдвое усложняется управление ресурсами — например, придется дублировать записи зоны для внутреннего и внешнего разрешения имен.
4. Даже если пространство имен одно и то же, внутренние и внешние ресурсы будут представляться пользователям по-разному.

 

Сценарий 2. Внутреннее и внешнее пространства имен различаются.

По разные стороны брандмауэра — внутри и вне корпоративной сети — применяются разные имена. Например, пользователи Интернета будут видеть имя microsoft.com, а интрасети – expedia.com. Оба этих пространства имен должны быть зарегистрированы в DNS Интернета во избежание дублирования внутреннего имени в другой общей сети. Если внутреннее имя не зарезервировано и используется другой организацией, внутренние клиенты не отличат внутреннее имя от чужого публично зарегистрированного пространства имен DNS.

Будут установлены две зоны: одна будет отвечать за разрешение имен в пространстве microsoft.com, а другая в пространстве expedia.com. В результате клиенты смогут четко различать внутренние и внешние ресурсы.

Преимущества:

1. Четкая разница между внутренними и внешними ресурсами за счет применения различных доменных имен.
2. Упрощается администрирование.
3. Упрощается настройка прокси – клиентов, поскольку списки исключения при опознавании внешних ресурсов должны будут содержать только expedia.com.

Недостатки:

1. Регистрационные имена отличаются от имен электронной почты. Например, если кто-нибудь входит под именем username@microsoft.com, то адрес его электронной почты будет username@expedia.com, что неудобно.
2. В DNS Интернета придется зарегистрировать больше имен.

 

Совет:

В этом сценарии имена входа в систему различны по умолчанию. Администратор с помощью Microsoft Management Console (ММС) может изменить свойства UPN-суффикса пользователей так, чтобы имя пользователя для входа в систему совпадало с его электронным адресом.

 

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

Выбрав модель взаимодействия внутреннего и внешнего пространств имен, надо учесть и другие факторы, например объем трафика репликации по ГВС и потенциальные изменения структуры предприятия. Помимо возможности создания леса в Windows 2000, администраторы должны быть готовы оперативно корректировать архитектуру пространства имен с минимальными издержками и без остановки работы сети. Цель — получить масштабируемую архитектуру, способную адаптироваться к изменениям, обеспечивающую непрерывный доступ к внутренним и внешним ресурсам и защиту данных.

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

Соблюсти эти условия позволяет наличие трех уровней доменов:

1. корневой домен;
2. домен первого уровня;
3. домен второго уровня.

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

Корневой домен.

Это первый домен пространства имен, например expedia.com. Корневой домен (root domain) в Active Directory определяет пространство имен компании. Все внутренние домены являются частью этого домена, создавая непрерывное связное пространство имен в виде дерева доменов. Кроме того, серверы, содержащие корень пространства, скрыты за брандмауэром и, следовательно, не будут видимы из Интернета.

Домены первого уровня.

Этот уровень модели отвечает за создание доменных имен, которые не изменяются даже при внутренней реорганизации предприятия. Простейший вариант – давать названия таким доменам, исходя из географических или политических границ, например noamer.expedia.com или europe.microsoft.com. Это также поможет сократить трафик репликации, поскольку сведения о пользователе в Северной Америке не нужно размещать на сервере Active Directory в Европе. Впрочем, серверы глобального каталога позволят найти ресурсы в Европе даже пользователю из Северной Америки.

Доверительные отношения между корневым доменом и всеми доменами первого уровня делают ресурсы доступными для всех ветвей дерева доменов. Следовательно, пользователь в noamer.expedia.com, может получить доступ к ресурсу в europe.microsoft.com.

 

Служба каталогов Active Directory.

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

Предполагается, что имя домена первого уровня неизменно. Вот пример правил именования:

AFRICA

(Африка)

CORPIT

(Штаб-квартира компании)

EUROPE

(Австрия, Бельгия, Венгрия, Голландия, Греция, Дания, Ирландия, Испания, Италия, Норвегия, Польша, Португалия, Россия, Румыния, Словакия, Словения, Финляндия, Хорватия, Чешская Республика, Швейцария, Швеция.)

JVT

(Совместные предприятия)

MEAST

(Объединенные Арабские Эмираты, Израиль,Саудовская Аравия, Турция)

NOAMER

(США и Канада)

NOPAC

(Гонконг и Web-узлы к северу от него (Япония, Китай, Корея, Тайвань))

PARTNERS

(Деловые партнеры и компании-подрядчики)

SOAMER

(Мексика, Центральная Америка и Южная Америка)

SOPAC

(Web-узлы южнее Гонконга, включая Индийский полуостров за исключением Афганистана)

Внимание! Эти правила именования — лишь пример, согласованный со стандартом ISO 3166. Организация вправе выбрать любые правила именования, соответствующие политике и потребностям.

 

Домены второго уровня.

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

Используйте те же правила именования при создании ОП в доменах — это позволит при необходимости повысить ОП до уровня домена с минимальными издержками.

При именовании сайтов в пределах Соединенных Штатов, стандарт ISO 3166 не применяется. Вместо этого применяйте двухбуквенные почтовые коды. Единственное исключение – Калифорния, чье двухбуквенное сокращение (СА) аналогично коду Канады по стандарту ISO. Поэтому при создании доменов в Калифорнии используйте сокращение CALIF.

Например, usa.noamer.microsoft.com — домен второго уровня, a ny.usa.noamer.micro-soft.com — его дочерний домен.

   

Планирование организационных подразделений.

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

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

 

Создание структуры ОП.

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

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

Рекомендации по разработке структуры ОП:

1. Создавайте ОП для делегирования административных полномочий.
2. Структура ОП должна быть логичной и осмысленной — это поможет администраторам ОП наиболее эффективно выполнять свои задачи.
3. Создавайте ОП для внедрения политики безопасности.
4. Создавайте ОП, чтобы ограничить видимость опубликованных ресурсов для определенных пользователей.
5. Структуры ОП должны быть относительно статичными. Кроме того, ОП придают гибкость пространству имен, помогая приспособиться к изменяющимся потребностям предприятия.
6. Не размещайте в ОП слишком много дочерних объектов.
7. Приступив к разработке структуры ОП, старайтесь строго придерживаться выбранных правил именования ОП и объектов: имена должны быть иерархичны, статичны и готовы к применению в любом домене предприятия.
8. Не размещайте в ОП слишком много дочерних объектов — это замедлит поиск и выполнение навигационных запросов.

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

 

Структура иерархии ОП.

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

Объектно-ориентированная модель деления на ОП.

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

Географическая модель деления на ОП.

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

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

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

Модель деления на ОП по проектам.

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

 

Планирование сайта.

До этого момента Вы разрабатывали логическую структуру домена и ОП. Успешное внедрение сети Windows 2000 Server на базе Active Directory во многом зависит от физической структуры, которая разграничивается сайтами.

Сайт (site) — это совокупность одной или нескольких IP-подсетей, соединенных высокоскоростными каналами связи. Зачастую сайт имеет те же границы, что и ЛВС или ГВС сеть, как, например, сети ОСЗ SONET (155 Мб/с) или ТЗ (45 Мб/с).

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

Вход в сеть.

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

 

Резюме.

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