Планирование инфраструктуры DNS и структуры OU

Цель лекции: Дать представление о процессах планирования доменного пространства имен и создания структуры организационных единиц.

Проектирование инфраструктуры DNS

В службе Active Directory домены имеют DNS-имена. Прежде чем использовать DNS в сети, необходимо спланировать пространство имен 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 необходимо выполнить следующие действия [ 13 ] :

• задокументировать все DNS-имена доменов, используемые в настоящее время в пределах компании. Сюда входят имена, встречающиеся в Интернете, а также внутренние имена;
• задокументировать все дополнительные имена, которые компания зарегистрировала для возможности использования в Интернете;
• задокументировать существующую конфигурацию серверов DNS. Эта документация должна включать типы DNS-серверов, в настоящее время развернутых в сети. Кроме того, конфигурация DNS должна содержать информацию о ретрансляторах, о делегировании зон и о конфигурации основных и дополнительных серверов.

Выбор доменных имен DNS

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

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

Для внедрения Active Directory существуют два вида пространств имен (внутреннее и внешнее), при этом пространство имен Active Directory совпадает с заданным зарегистрированным пространством имен DNS или отличается от него [ 4 ] :

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

Проектирование структуры OU

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

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

Организационное подразделение позволяет [ 4 ] :

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

Не следует создавать структуру OU исключительно ради того, чтобы просто иметь какую-то структуру: OU используются в определенных целях. К этим целям относятся [ 3 ] :

• делегирование административного управления объектами. Правильно разработанная структура OU позволяет администраторам эффективно делегировать полномочия. Каждое OU по умолчанию наследует разрешения, заданные для родительского OU. Аналогично объекты, содержащиеся в OU, наследуют разрешения, заданные для этого OU (и для каждого из его родителей). Наследование - эффективный способ предоставить или делегировать разрешения на доступ к объектам. Преимущество наследования в том, что администратор может управлять разрешениями на доступ ко всем объектам в OU, задавая разрешения для самого OU, а не конфигурируя все дочерние объекты по отдельности;
• ограничение видимости объектов. В некоторых организациях определенные объекты должны быть скрыты от определенных администраторов или пользователей. Даже если запретить изменение атрибутов объекта, пользователи, имеющие доступ к контейнеру с таким объектом, все равно смогут видеть, существует ли этот объект. Однако можно скрыть объекты, поместив их в OU и ограничив круг пользователей, которые имеют разрешение на список содержимого (List Contents) для этой OU. Тогда объекты, помещенные в контейнер, будут невидимы пользователям, не имеющим этого разрешения;
• управление применением групповой политики. Групповая политика позволяет применять одни и те же параметры конфигурации сразу к нескольким объектам. С ее помощью можно определять параметры пользователей (например, ограничения, налагаемые на пароли) или компьютеров. При использовании групповой политики создается объект групповой политики (Group Policy Object, GPO) - объект, связанный с доменом, сайтом или OU и содержащий параметры конфигурации, которые требуется применить.

Возможности ОП облегчат обеспечение безопасности и выполнение любых административных задач.

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

OU служит контейнером, в который можно поместить ресурсы и учетные записи домена. Затем можно назначить OU административные разрешения и позволить содержащимся в нем объектам наследовать эти разрешения. OU могут содержать любые объекты следующих типов [ 3 ] : пользователи; компьютеры; группы; принтеры; приложения; политики безопасности; общие папки; другие OU.

Планирование иерархии OU

При планировании иерархии ОП важно соблюсти следующие правила [ 4 ] :

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

Существует много способов структурирования ОП в организации. На этапе планирования развертывания Active Directory важно определить, какая модель ляжет в основу иерархии ОП. Например, существуют следующие модели классификации ОП в иерархии ОП [ 4 ] :

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

Следует уделять особое внимание верхнему уровню структуры OU, который всегда должен отражать относительно неизменную часть структуры предприятия, чтобы его не приходилось изменять в случае реорганизации. Так, следующие типы структуры верхнего уровня основаны на постоянных характеристиках предприятия, изменение которых маловероятно [ 3 ] :

• Физические участки. В филиалах, физически расположенных в разных местах (особенно, когда компания действует на обширной территории, например в нескольких странах), часто имеются свои ИТ-отделы, поэтому у филиалов разные требования к администрированию. Создание отдельного OU верхнего уровня для каждого филиала - один из вариантов архитектуры, основанной на задачах; в зависимости от местонахождения определяются разные административные задачи.
• Типы административных задач. Структура верхнего уровня, основанная на административных задачах, относительно постоянна. Какие бы реорганизации не происходили в компании, основные типы административных задач вряд ли сильно изменятся.
• Типы объектов. Как и структура, основанная на задачах, структура, в которой OU верхнего уровня соответствуют типам объектов, обеспечивает устойчивость архитектуры к изменениям.

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

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

Стандартные модели структуры OU

Наряду с перечисленными выше моделями классификации ОП в иерархии ОП можно использовать следующую терминологию (см. рис. 7.1) для стандартных моделей [ 3 ] :

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

увеличить изображение
Рис. 7.1. Модели построения структуры организационных единиц