Проектирование доменной структуры

🕛 19.01.2009, 20:35

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

Домены и проект 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 2003

Деревья доменов и доверительные отношения

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

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

любом случае все домены совместно используют транзитивные доверительные отношения с другими доменами, 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. * Управление административными группами уровня домена. Как уже говорилось, администраторы в каждом домене должны иметь высокую степень доверия, потому что их действия могут вызывать последствия на уровне леса. Роль владельца домена состоит в ограничении членства административной группы уровня домена и в делегировании административных прав низшего уровня всегда, когда это возможно.