Active Directory: Ваша собственная Active Directory

Со времени первого выпуска Active Directory в составе Windows 2000 Server более чем десять лет эта проверенная временем служба управления каталогами помогала организациям сохранять порядок в хаосе. Большиство организаций (хотя есть и исключения) придерживаются самой прямолинейной стратегии — использовать самую простую версию развертывания Active Directory, которая решает базовые задачи организации.

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

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

Доменная структура

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

Домены пользователей

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

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

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

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

Домены ресурсов

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

Домены ресурсов приносят максимум пользы, если относиться к ним как к доменам управления. Например, вы можете создать выделенный лес Active Directory, который предназначен исключительно для управления серверами Hyper-V. Есть ряд причин, почему так делается.

Первая причина — управление. System Center Operations Manager 2012 (и ряд других решений для управления) могут управлять серверами только если они являются членами одного домена Active Directory. Очень нежелательно включать серверы Hyper-V в основной домен, потому что все контроллеры основного домена представляют собой виртуальные машины. Вы ведь не хотите оказаться в ситуации, когда невозможно войти в систему сервера Hyper-V, потому что виртуальные контроллеры домена недоступны? Размещение серверов Hyper-V в выделенном лесу управления в Active Directory отлично решает эту проблему.

Другой причиной создания домена ресурсов для серверов Hyper-V может быть появление новой функциональности в версии Hyper-V 3.0. В Hyper-V 3.0 появится возможность реплицировать виртуальные машины между узлами. Подобная репликация это не одно из реализаций отказоустойчивого кластера, а решение на случай аварийного восстановления, позволяющее хранить актуальные копии своих виртуальных машин на другом узле. Тогда если что-то произойдет с дисковым массивом или основным узлом Hyper-V, у вас будет резервная копия своих виртуальных машин, к которой можно будет вернуться.

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

Кстати, домены ресурсов и пользователей не исключают друг друга. Некоторые компании создают сочетания доменов пользователей и ресурсов в одно лесу Active Directory.

Географическая топология

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

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

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

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

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

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

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