Модели построения лесов и детализация доменной структуры

Применение нескольких лесов

Леса представляют собой крайние границы зон безопасности. Между лесами невозможно административное управление или пользовательский доступ, если на то нет явного разрешения в конфигурации. Для этого предназначен тип доверия, введенный в Windows Server 2003, - доверие к лесу (forest trust), применяемый при управлении отношениями между двумя лесами.

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

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

Случаи реализации нескольких лесов

Реализация модели построения нескольких лесов допускается в следующих случаях [ 3 ] :

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

Недостатки структуры из нескольких лесов

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

Архитектура с несколькими лесами имеет следующие недостатки [ 3 ] .

• При поиске ресурсов от пользователей требуется более высокий уровень подготовки. С точки зрения пользователя, поиск ресурсов в рамках одного леса сравнительно прост благодаря единому глобальному каталогу. При наличии нескольких лесов существует несколько глобальных каталогов, и пользователям приходится указывать, в каком лесу вести поиск ресурсов.
• Сотрудники, которым требуется входить на компьютеры, включенные во внешние леса, должны указывать при входе основное имя пользователя (User Principal Name, UPN) по умолчанию. От таких сотрудников также требуется более высокий уровень подготовки.
• Администраторам приходится хранить несколько схем.
• Для каждого леса используются отдельные контейнеры конфигурации. Изменения в топологии необходимо реплицировать в другие леса.
• Любую репликацию информации между лесами приходится настраивать вручную. Администраторы должны конфигурировать разрешение DNS-имен между лесами, чтобы обеспечить функционирование контроллеров доменов и поддержку поиска ресурсов.
• Администраторам приходится настраивать списки управления доступом (ACL) к ресурсам, чтобы соответствующие группы из разных лесов могли обращаться к этим ресурсам, а также создавать новые группы, чтобы можно было использовать роли одних лесов в других лесах.
• Часто для наблюдения за отдельными лесами и управления ими нужен дополнительный персонал, а значит расходуются средства на подготовку большего штата сотрудников и на оплату их труда.

Детализация доменной структуры

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

• Вариант 1 "Повторение существующей доменной структуры".
• Вариант 2 "Несколько лесов, минимальное количество доменов".
• Вариант 3 "Единый лес".

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

Домен для миграции существует в отдельном лесу. Необходимо создание двух учетных записей для каждого пользователя центрального офиса и регионального пользователя: одну в создаваемом домене, другую - в существующем. Все ресурсы DMZ (а также front-end почтовые сервера) располагаются в дочернем домене (DMZ Internal VLAN). При этом доступ учетных записей пользователей из существующего домена к ресурсам нового домена автоматически запрещен на уровне доверительных отношений между доменами. Учетным записям пользователей в мигрируемом домене дано право доступа к почтовому ящику соответствующего пользователя в создаваемом домене. Почтовые ящики пользователей находятся на сервере нового домена (LAN центрального офиса). Для упрощения создания двойной учетной записи можно использовать продукт "Microsoft Metadirectory Service" (MMS).

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

Плюсы данного варианта:

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

Минусы:

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

Несколько лесов, минимальное количество доменов

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

Необходимо создание двух учетных записей для каждого пользователя центрального офиса и регионального пользователя: одну в новом домене, другую - в существующем домене. Все ресурсы DMZ (а также front-end почтовые серверы) располагаются в создаваемом домене (DMZ Internal VLAN). Контроллеры нового домена находятся в зонах LAN и DMZ. При этом доступ учетных записей пользователей из существующего домена к ресурсам создаваемого домена, находящимся в зоне LAN, должен быть запрещен выставлением прав доступа к объектам нового домена и/или правилами на брандмауэре. Учетным записям пользователей в мигрируемом домене дано право доступа к почтовому ящику соответствующего пользователя в создаваемом домене. Почтовые ящики пользователей находятся на сервере нового домена (LAN центрального офиса). Для упрощения создания двойной учетной записи можно использовать продукт "Microsoft Metadirectory Service" (MMS), позволяющий синхронизовать объекты различных каталогов.

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

Плюсы данного варианта:

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

Минусы:

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

Единый лес

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

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

Данный вариант построения Active Directory позволяет избежать ведения двух учетных записей для каждого пользователя. Все ресурсы DMZ (а также front-end почтовые серверы) располагаются в дочернем домене (DMZ Internal VLAN). Почтовые ящики пользователей находятся на сервере нового домена (LAN центрального офиса). Учетные записи пользователей центрального офиса заведены в создаваемом домене. Учетные записи мобильных пользователей, требующих доступ к ресурсам зоны DMZ Internal, заведены в дочернем домене. Для таких пользователей доступ к ресурсам будет ограничен с применением прав доступа пользователей и групповой политики дочернего домена. В частности, используя группу Domain Users дочернего домена, возможно настроить автоматический первоначальный запрет доступа к ресурсам Active Directory для новых пользователей для повышения безопасности системы.

Плюсы данного варианта:

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

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

Назначение владельцев доменов

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

Роль владельца домена состоит в управлении индивидуальным доменом [ 13 ] .

• Создание политик безопасности уровня домена. Это включает политику паролей, политику блокировки учетных записей и политику аутентификации по протоколу Kerberos.
• Проектирование конфигурации групповой политики (Group Policy) уровня домена. Владелец домена может проектировать групповую политику для всего домена и делегировать право связывать групповую политику с администратором уровня OU.
• Создание в домене OU-структуры высокого уровня. После этого задача создания подчиненных OU может быть передана администраторам уровня OU.
• Делегирование административных прав в пределах домена. Владелец домена должен установить административную политику уровня домена (включая политики схем именования, проекта групп и т. д.), а затем делегировать права администраторам уровня OU.
• Управление административными группами уровня домена. Как уже говорилось, администраторы в каждом домене должны иметь высокую степень доверия, потому что их действия могут вызывать последствия на уровне леса. Роль владельца домена состоит в ограничении членства административной группы уровня домена и в делегировании административных прав низшего уровня всегда, когда это возможно.

Краткие итоги

В этой лекции дано описание различных моделей (с указанием достоинств и недостатков) построения лесов Active Directory:

• Вариант 1 "Единый лес, каждый регион - отдельное дерево".
• Вариант 2 "Единый лес, административный корневой домен, каждый регион - домен".
• Вариант 3 "Единый лес, каждый регион - дочерний домен центрального домена".

Приведены случаи реализации нескольких лесов и указаны недостатки структуры Active Directory, состоящей из нескольких лесов.

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

• Вариант 1 "Повторение существующей доменной структуры".
• Вариант 2 "Несколько лесов, минимальное количество доменов".
• Вариант 3 "Единый лес".

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

• создавать политики безопасности уровня домена;
• проектировать конфигурацию групповой политики (Group Policy) уровня домена;
• создавать в домене OU-структуру высокого уровня;
• делегировать административные права в пределах домена;
• управлять административными группами уровня домена.