Лес доменов Active Directory: что это, когда нужен второй домен и когда хватит одного

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

Что такое лес доменов и чем он отличается от домена

Начну с определения, потому что в запросах «лес доменов» вижу ту же путаницу, что и у клиентов на встречах: лес и домен принимают за одно и то же, а потом строят вокруг этого странные схемы. Лес (forest) — самая внешняя граница Active Directory. Внутри него живут пользователи, компьютеры, группы и все домены, а общим на весь лес остаётся то, что нельзя разделить: схема каталога, конфигурация, список доменов и сайтов. Домен — единица поменьше, в нём хранятся учётные записи, действуют свои политики паролей и свои администраторы. Если вы обращались к нам за аудитом Active Directory, то помните: первым делом я смотрю именно на эту структуру, потому что все остальные решения вырастают из неё.

Лес всегда начинается с одного домена. Он называется корневым доменом леса (forest root domain), и у него есть особенность, о которой забывают: именно в нём живут группы Schema Admins и Enterprise Admins. По документации Microsoft, Enterprise Admins уполномочена менять инфраструктуру леса — добавлять дочерние домены, настраивать сайты, авторизовать DHCP-серверы, ставить корпоративные центры сертификации, — а сама группа автоматически добавляется во встроенную группу Administrators каждого домена леса и даёт полный доступ к настройке всех контроллеров домена. Иными словами, один человек в этой группе имеет власть над всеми доменами сразу, сколько бы их ни было.

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

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

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

Лес или домен: где на самом деле проходит граница безопасности

Документация Microsoft различает две цели, которых хотят добиться, разделяя каталог: автономия и изоляция. Автономия — это когда подразделение управляет своей частью каталога само, но признаёт, что администраторы более высокого уровня в лесу могут вмешаться. Изоляция — когда другие администраторы не могут ни вмешаться, ни получить доступ к данным. Автономии добиваются делегированием: отдельным OU, правами на группы, групповыми политиками. Изоляция требует отдельного леса. Эту разницу я проговариваю на каждом проекте, потому что слово «отдельный» клиенты слышат как «отдельный домен», а нужен бывает либо просто OU, либо вообще другой лес.

В том же руководстве Microsoft есть жёсткая формулировка, которую я цитирую директорам, когда они просят «посадить партнёра в нашу сеть в свой домен»: домены в одном лесу не следует разворачивать с целью изолировать бизнес-единицы, которые не доверяют друг другу. Все, кто администрирует домены леса, должны быть доверенными лицами. Если вы не готовы дать человеку в руки ключи ко всему лесу, ему нельзя быть администратором домена даже в «его» отдельном домене.

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

Скажу и про то, чего не нужно делать. Не нужно делить домены по географии, если у вас два-три офиса, связанные нормальным каналом: для этого есть сайты Active Directory, они управляют репликацией и тем, к какому контроллеру подключается клиент. Не нужно создавать отдельный «тестовый» домен внутри боевого леса: тесты ломают схему, а схема общая. Тестовый лес — отдельная виртуальная лаборатория, а не поддомен в рабочем.

Когда одного домена достаточно — а это почти всегда

Мой ответ на вопрос «сколько доменов нужно офису на 12, 30 или 50 рабочих мест» всегда один: один лес, один домен. Причины практические. Каждый домен — это минимум два собственных контроллера домена, чтобы отказ одного сервера не остановил вход пользователей, а значит, ещё железо или виртуальные машины, лицензии на Windows Server, резервные копии, мониторинг и человеческое внимание на обновления. Плюс политика паролей и групповые политики придётся настраивать отдельно в каждом домене, а доверительные отношения между доменами в одном лесу создаются автоматически, но поддержка многодоменного поиска и глобального каталога добавляет вопросов, на которые малому офису некому отвечать.

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

Что делать вместо второго домена, если руководство просит разделить отделы? Заводите OU по отделам или площадкам. Под каждое подразделение создаёте группу администраторов с делегированными правами на конкретный OU: сброс паролей, добавление компьютеров, управление группами. На OU вешаете свои групповые политики — например, ограничение запуска программ для кассы и отдельный набор для бухгалтерии. Если нужны особые требования к паролям для небольшой группы, например для администраторов, есть детализированные политики паролей (fine-grained password policy), которым второй домен не нужен. По текущей документации Microsoft для них нужен функциональный уровень домена Windows Server 2012 или выше, применяются они только к пользователям и глобальным группам безопасности, а создаются в Active Directory Administrative Center или командлетом New-ADFineGrainedPasswordPolicy.

Единственный повод пересмотреть «один домен» в малом офисе — смена владельцев или слияние: когда вы покупаете компанию вместе с её собственным каталогом, встаёт вопрос, как их объединять. Чаще всего вопрос решается миграцией пользователей и компьютеров в свой домен и выводом чужого, а не вечным существованием двух. Тут пригодится опыт, описанный в материале про миграцию Active Directory на новые контроллеры: принципы переноса ролей и проверки репликации одни и те же.

Когда нужен второй домен, а когда — отдельный лес

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

Отдельный лес нужен там, где требуется изоляция. Microsoft описывает три модели. Организационный лес — когда учётные записи и ресурсы управляются независимо, это обычная схема, и каждая AD-среда содержит как минимум один такой лес. Лес ресурсов — отдельный лес для ресурсов с доверием от других лесов, он даёт изоляцию служб: пример из документации — производственная площадка, которая должна продолжать работу, даже если остальная сеть выйдет из строя. Лес с ограниченным доступом — для данных, компрометация которых имеет тяжёлые последствия: доверия нет, у пользователей две учётные записи и две рабочие станции. Для офисов до 50 мест второй и третий варианты — экзотика, но первый вы уже имеете.

Связь между лесами строится через доверительные отношения (forest trust). Это односторонние или двусторонние доверия, при которых пользователи одного леса получают доступ к ресурсам другого, не заводя там отдельных учётных записей. Список существующих доверий в любой момент можно посмотреть командой Get-ADTrust, а если нужен только список доверий через консольную утилиту — netdom query trust. Параметры настройки (фильтрация SID, избирательная аутентификация, транзитивность) зависят от версии и типа доверия, поэтому я всегда сверяю их с текущей документацией перед настройкой, и вам советую то же.

Показательный сценарий для малого бизнеса — два юридических лица, у которых общее помещение и общий ИТ-подрядчик. Сразу хочется сделать общий лес с двумя доменами. Я так не делаю: если у компаний нет полного взаимного доверия администраторов, общий лес недопустим по логике Microsoft. Либо у каждой своё хозяйство и доверие через лес-к-лесу при реальной необходимости, либо одна из них вообще не входит в домен и работает по своим учётным записям. Часто второй вариант проще и дешевле.

Отдельный лес — серьёзные затраты: ещё два контроллера, ещё один DNS, свои политики, свои резервные копии и отдельная работа по поддержке доверия. Я прикидываю это без иллюзий: для нас в АйТи-Фреш развёртывание нового леса с двумя контроллерами и базовой структурой — это рабочий день или два плюс эксплуатация на годы. Если задачу можно решить без него, я её решаю без него.

Как посмотреть свой лес: команды PowerShell и функциональные уровни

Прежде чем что-то менять, посмотрите, что у вас уже есть. На любом контроллере домена или на машине с RSAT откройте PowerShell и выполните команды ниже. Get-ADForest показывает корневой домен, список доменов леса, глобальные каталоги, сайты, функциональный уровень и владельцев двух ролей уровня леса. Get-ADDomain — то же для текущего домена: уровень, родителя, дочерние домены и три роли домена.

Get-ADForest | Format-List Name,RootDomain,Domains,ForestMode,SchemaMaster,DomainNamingMaster,GlobalCatalogs,Sites
Get-ADDomain | Format-List DNSRoot,NetBIOSName,Forest,ParentDomain,ChildDomains,DomainMode,PDCEmulator,RIDMaster,InfrastructureMaster

Если в Domains одна строка и ChildDomains пуст — у вас один домен в лесу, и это нормальная картина для малого офиса. Если доменов несколько, задайте себе честный вопрос: кто и зачем их создавал, и не остались ли они от прежнего подрядчика.

Роли FSMO — это пять ролей хозяев операций. Две на лес (Schema Master и Domain Naming Master) и три на каждый домен (PDC Emulator, RID Master, Infrastructure Master). По рекомендации Microsoft роли уровня леса держат на контроллере в корневом домене леса и держат запасной контроллер на случай отказа. Чтобы увидеть владельцев ролей одной командой из командной строки с повышенными правами, есть netdom query fsmo. Доверительные отношения смотрим так:

netdom query fsmo
Get-ADTrust -Filter *
netdom query trust

Пустой вывод Get-ADTrust означает, что внешних и междоменных доверий нет — как раз то, что я ожидаю увидеть у клиента с одним доменом.

Функциональные уровни определяют возможности леса и домена и то, какие версии Windows Server могут работать на контроллерах. На рабочие станции и рядовые серверы они не влияют. Согласно документации, сейчас поддерживаются уровни Windows Server 2012 R2, 2016 и 2025. Windows Server 2019 и 2022 используют в качестве последнего именно уровень 2016, поэтому при контроллерах на 2019/2022 поднять уровень выше 2016 нельзя. Есть и обратное ограничение, о котором вспоминают при покупке нового сервера: контроллер на Windows Server 2025 не работает на уровне 2012 R2, поэтому перед его вводом лес и домен нужно поднять минимум до 2016. Уровень 2025 требует, чтобы все контроллеры работали на Windows Server 2025, и добавляет необязательную возможность — страницы базы данных по 32 КБ. Для уровня 2016 домен должен реплицировать SYSVOL через DFSR, а не через FRS.

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

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

Install-ADDSForest -DomainName "lab.example.com" -DomainNetbiosName "LAB" -InstallDns

По умолчанию DNS-сервер при создании леса ставится в любом случае, а первый контроллер использует адрес 127.0.0.1 как предпочитаемый DNS — это тоже указано в документации.

Кейс: спортивный клуб на 12 рабочих мест и вопрос про второй домен

Ко мне обратился спортивный клуб «Сила и воля»: 12 рабочих мест — ресепшн, тренерская, бухгалтерия и кабинет директора. Был один сервер Windows Server с ролью контроллера домена, и запрос звучал так: «Мы сдаём часть помещения в аренду массажному кабинету, у них три компьютера. Подрядчик предложил завести им второй домен, чтобы они не лезли в наши папки». Звучало логично, и поэтому я проверил, что на самом деле стоит за предложением. Начал с Get-ADForest и Get-ADDomain: один лес, один домен, один контроллер, и тот работал без резервного партнёра.

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

Решение заняло два рабочих дня. Я добавил второй контроллер в тот же домен как виртуальную машину на другом хосте, перенёс на него роли уровня домена и проверил репликацию. Для арендатора выделил отдельный сегмент сети с выходом в интернет и без доступа к серверам клуба; компьютеры арендатора остались вне домена, на локальных учётных записях. Внутри домена клуба я разнёс пользователей по OU «Ресепшн», «Тренеры» и «Бухгалтерия», настроил для бухгалтерии отдельные права на папки через группы и делегировал администратору клуба сброс паролей только в этих OU. Затраты клуба — два рабочих дня моего времени и лицензия Windows Server для второй виртуальной машины-контроллера; отдельной инфраструктуры под второй домен покупать не пришлось.

Итог: вместо дорогой схемы клуб получил отказоустойчивый единый домен и понятные границы. Выгоднее всего оказалось то, что вопрос «нужен ли нам второй домен» закрылся фактами, а не мнениями: структура леса была перед глазами, а Microsoft прямо говорит, что для недоверенных сторон домены в одном лесу не годятся. Через три месяца, когда у клуба сломался хост, вход пользователей продолжал работать с оставшегося контроллера. Обо всём, что делать после поломки контроллера, у нас есть отдельный материал про восстановление виртуальных контроллеров домена.

Типичные ошибки с лесами и доменами и что делать в первую очередь

Самая частая ошибка — второй домен «для порядка». Его заводят, чтобы отделить бухгалтерию или филиал, и через год у компании два набора контроллеров, две политики паролей и вечная путаница, в каком домене лежит нужный пользователь. На деле тот же эффект давали OU и делегирование. Вторая по частоте — один контроллер на весь домен. Мой минимум: два контроллера в каждом домене, на разных физических хостах, с проверенной репликацией и резервной копией состояния системы. Третья — неосторожное членство в Enterprise Admins и Schema Admins: эти группы должны быть пустыми в обычное время, а человека добавляют в них на время операции.

Отдельно упомяну корзину Active Directory. Если вы собираетесь удалять и переносить объекты при перестройке структуры, включите её заранее — удалённый пользователь или группа восстанавливаются со всеми атрибутами и членством. Она относится к возможностям уровня леса, поэтому прочитайте материал про корзину Active Directory и сверьте условия включения со своей версией. Для малого офиса это почти всегда правильное решение.

Мой порядок действий, если вы читаете это и не уверены в своей структуре. Первое: посмотрите лес и домен командами выше и запишите результат. Второе: убедитесь, что контроллеров не меньше двух и репликация идёт. Третье: проверьте, кто состоит в Enterprise Admins, Schema Admins и Domain Admins, и уберите лишних. Четвёртое: только после этого обсуждайте реструктуризацию, и то лишь если есть конкретная задача, которую нельзя решить OU и делегированием. На всё это уходит пара часов, а решение потом принимается на фактах. Если нужна помощь, мы в АйТи-Фреш делаем такую проверку как отдельный небольшой проект.

Частые вопросы