Тестовый домен Active Directory на VPS: учебная лаборатория без доступа к рабочей сети

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

Дальше разберём, как собрать такой стенд на VPS, чтобы он был по-настоящему отдельным, а не «почти отдельным». Мы пройдём через одно конкретное упражнение: напишем политику, увидим, как она доходит до компьютера, нарочно ошибёмся, потеряем учётную запись и вернём её. Это намного полезнее, чем перечень всех возможностей Active Directory: после одного прожитого сценария остаётся понимание механики, а не список галочек.

Что именно мы тренируем и сколько машин для этого нужно

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

Для нашего упражнения достаточно трёх элементов:

• Контроллер домена. Он хранит каталог, отвечает на запросы аутентификации, раздаёт политики. Это единственная серверная роль, без которой лаборатории нет. Служба DNS обычно живёт на нём же, потому что клиенты находят домен именно через DNS.
• Рядом стоящий участник домена. Политику нужно на ком-то проверить. Если применять её только к самому контроллеру, вы будете смотреть на нетипичный случай: у контроллеров особые настройки и особая область действия политик. Поэтому нужна вторая Windows-машина, которая вступит в домен как обычная рабочая станция или как рядовой сервер.
• Консоль управления. Отдельная машина для неё не нужна. Оснастки управления пользователями и групповыми политиками удобно запускать прямо на контроллере: это учебный стенд, а не продуктивная среда, и привычка «администрировать только с отдельного рабочего места» тут отложена до следующего этапа.

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

Теперь про размеры. У MAATRIX планы начинаются с Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe), дальше идут Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ) и выше, вплоть до Djed. Для учебного контроллера и одного клиента разумной отправной точкой кажутся планы класса Uab: именно как точка начала, а не как обещание, что этого хватит. Сколько реально нужно вашему стенду, покажет замер: откройте диспетчер задач после установки роли и после нескольких входов и посмотрите на память и очередь диска. Если контроллер всё время упирается в оперативную память, переезжайте на план побольше; в VPS-модели это дешевле, чем мучиться на тесном.

Заметим и ещё одно полезное свойство: на VPS у вас есть root-доступ, а значит, вы сами выбираете образ и сами распоряжаетесь системой. Какие образы Windows доступны в конкретной локации, проверяйте в форме заказа: наличие образов может отличаться, и закладываться на него заранее нельзя.

Имена, которые не пересекутся ни с чем настоящим

Самая частая ошибка начинающих лабораторий не техническая, а смысловая. Человек берёт имя домена, которое «похоже на настоящее», чтобы было привычнее, а потом путается, в какую консоль он сейчас смотрит. Или хуже: берёт точно такое же имя. Два домена с одним именем в разных сетях сами по себе не конфликтуют, пока сети разделены, но в тот день, когда кто-то подключит ноутбук или VPN не туда, начнутся странности с разрешением имён и доверием.

Поэтому лабораторное имя стоит выбирать так, чтобы его невозможно было спутать с рабочим:

• не использовать имя настоящего рабочего домена и его поддомены;
• не использовать публичное имя, которым вы владеете и которое открыто в интернете: внутреннее разрешение и внешнее начнут спорить;
• взять имя из зарезервированных для тестов зон, например с окончанием .test: оно гарантированно не существует в публичном DNS. Что-то вроде ad.lab.test, а короткое имя NetBIOS сделать явным, допустим LAB.

То же касается имён компьютеров: LAB-DC01 и LAB-WS01 читаются с первого взгляда. Префикс окупается в тот момент, когда вы открываете сразу три окна удалённого доступа и пытаетесь не удалить пользователя не там.

Пользователи без чужих лиц

Соблазн скопировать структуру рабочего каталога понятен: так проще проверять, как политика отработает «у нас». Но копировать настоящих людей нельзя. Реальные имена, учётные записи, должности и адреса почты — персональные данные сотрудников. Тестовому стенду они не нужны, а на VPS, который смотрит в интернет, им тем более делать нечего. Пароли тем более: ни хэши, ни «похожие на настоящие» пароли в лабораторию не переносим.

Вместо этого описываем структуру, а не людей. Нам нужны подразделения (OU) по ролям и несколько безличных учёток. Пример схемы:

Пароли для этих учёток генерируем случайно, записываем в менеджер паролей, и ни один из них не повторяет пароль, который вы используете где-то ещё. Выглядит как перестраховка, но у лаборатории на публичном VPS ровно та же поверхность атаки, что у любого сервера в интернете, и учебное происхождение учётки её не защищает.

Сеть: как сделать лабораторию действительно закрытой

Слово «изолированная» легко произнести и трудно обеспечить. Его надо переводить в конкретные запреты. Вот что они означают для нашего стенда.

Лабораторные машины не видят рабочую сеть и не видны из неё. Ни VPN-туннеля до офиса, ни маршрута на рабочую подсеть, ни общего подключения, ни «временного» доверия между доменами. Сам по себе VPS уже стоит за пределами офисной сети, и это его достоинство: у него нет физического коридора в ваш серверный шкаф. Достаточно не создавать такой коридор искусственно. Главное правило здесь простое и нарушать его не стоит: тестовый контроллер не подключают к рабочему домену ради удобства: не как дополнительный контроллер, не для копирования пользователей, не для проверки репликации. Один раз добавленный в рабочий лес контроллер начинает реплицировать изменения, и всё, что вы сломаете в лаборатории, имеет шанс стать настоящей поломкой. Если нужны данные из рабочего домена, берите структуру словами, а не объектами.

Ограничить входящие подключения. У Windows на публичном адресе открыт RDP, и сканеры находят его быстро. Чем меньше лабораторных портов смотрит наружу, тем спокойнее. Разумный минимум: удалённый доступ к машинам только с вашего адреса, а порты каталога, которыми контроллер и участник домена общаются между собой, открыты только между двумя лабораторными адресами. Как именно настроить фильтрацию, зависит от того, что предоставляет панель и сам образ; если в вашей локации доступна приватная сеть между серверами, лучше провести трафик каталога по ней и не открывать его вообще, но проверьте это в панели, а не предполагайте.

DNS. Здесь кроется второй классический подвох. Клиент находит контроллер через DNS, поэтому его сетевые настройки должны указывать на лабораторный контроллер, а не на публичный резолвер. Если на клиенте остался прежний DNS-сервер, вход в домен завершится ошибкой «домен не найден», хотя сеть работает. На самом контроллере DNS-серверу надо оставить возможность пересылать внешние запросы наружу, иначе лабораторные машины перестанут обновляться и даже скачивать инструменты. Это решение учебное и сознательное: внешние запросы разрешены, внутренние зоны ведёт только лаборатория.

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

Один опыт: политика, которую видно глазами

Теперь можно переходить к главному. Наша политика намеренно примитивна, но её результат виден без инструментов: сообщение на экране входа. В редакторе групповых политик это параметр безопасности из раздела локальных политик: «Интерактивный вход в систему: текст сообщения для пользователей, пытающихся войти в систему», плюс соседний параметр с заголовком. В английском интерфейсе он называется Interactive logon: Message text for users attempting to log on.

Порядок такой:

1. Создаём в консоли управления групповой политикой новый объект политики с понятным именем, скажем LAB-Logon-Banner. Имя должно говорить, что политика учебная.
2. В редакторе открываем конфигурацию компьютера, дальше параметры безопасности, локальные политики, параметры безопасности, и задаём заголовок и текст. Текст делаем узнаваемым: «Лабораторный стенд. Версия 1». Версия в тексте пригодится позже.
3. Привязываем объект не к корню домена, а только к подразделению Lab-Workstations. Это принципиально: даже в лаборатории стоит приучать себя к узкой привязке.

Теперь самое интересное: вторая машина вступила в домен, но ничего не показывает. Это нормальный результат, и именно он учит. Когда компьютер присоединяют к домену, его учётная запись по умолчанию создаётся в стандартном контейнере для компьютеров, а не в вашем подразделении. Политика, привязанная к Lab-Workstations, до этой учётки просто не дотягивается. Здесь и скрыта механика: политика действует на объекты, лежащие в точке привязки или ниже по дереву, а не на «весь домен, кроме тех, кто запретил».

Перемещаем учётную запись компьютера в Lab-Workstations и просим клиента обновить политику: можно перезагрузить его или воспользоваться штатным механизмом принудительного обновления. После перезагрузки экран входа показывает наш текст. Наблюдаемый результат получен: вы своими глазами увидели цепочку «объект политики → привязка → подразделение → компьютер → настройка на машине».

Три быстрых вопроса, которые стоит задать системе

Опыт можно углубить, не усложняя стенд. Вот три шага с видимым результатом:

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

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

Ошибка по плану: удалённый пользователь

Теперь о том, ради чего лаборатория нужна на самом деле. Рано или поздно кто-то удаляет не ту учётную запись. Самое неприятное в этом сценарии то, что на рабочем домене вы впервые читаете о восстановлении именно в этот день, в состоянии лёгкой паники. В лаборатории то же самое можно прожить заранее.

Упражнение: запишите у user-02 какую-нибудь заметную деталь, например описание в карточке «учебная жертва», добавьте его в группу Lab-Testers. Затем удалите учётную запись из подразделения Lab-Users. А дальше проверьте на практике, что именно у вас получилось сделать, и сравните два варианта.

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

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

В какой-то момент возникает соблазн пойти коротким путём: сделать снимок виртуальной машины до ошибки и просто откатиться. Выглядит логично, но с контроллером домена это не так просто. По описанию виртуализации AD DS у Microsoft, снимок виртуальной машины не рекомендуется как замена поддерживаемого резервного копирования контроллера домена. Причина в устройстве каталога: каждое изменение получает порядковый номер (USN), на который опираются другие контроллеры при репликации. Откат виртуальной машины возвращает номера назад, и контроллер может начать выдавать уже использованные значения. Для защиты от этого существует механизм VM-GenerationID: на совместимом гипервизоре AD DS способна обнаружить откат и применить меры против повторного использования USN. Но «способна, если гипервизор совместим» — это не то, на что стоит опираться вслепую; у вашего хостинга может быть другая платформа, и проверять её поддержку нужно отдельно.

В нашей лаборатории из этого следует аккуратный вывод, а не запрет. Поскольку в стенде один контроллер и реплицироваться ему не с кем, риск повторного использования USN для вас остаётся скорее теоретическим, и возврат к снимку — удобный способ быстро вернуть учебное состояние. Но привычку считать снимок резервной копией домена лучше не закреплять: на рабочем домене из нескольких контроллеров она обходится дорого. Хорошая лабораторная формула такая: снимок — для быстрой повторяемости стенда, поддерживаемая резервная копия — для разговора о восстановлении.

Как прочитать причину, а не просто вернуть учётку

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

• Пока учётка была удалена, что видел клиент? Попробуйте войти под user-02 на второй машине. Как выглядит сообщение об ошибке и как оно отличается от сообщения о неверном пароле?
• Вернулся ли пользователь в исходное подразделение и в исходные группы?
• Изменился ли у него идентификатор безопасности? Возвращённый из корзины объект сохраняет прежний, а созданный заново — получает новый, и права, выданные по старому идентификатору, на него уже не действуют.

Последний пункт отличает «похожую» учётку от «той же самой». Права на папки, назначенные по идентификатору, не переходят на пересозданного пользователя, и в лаборатории это легко проверить: дайте user-02 доступ к общей папке на клиентской машине, удалите и пересоздайте, затем попробуйте открыть. Вы получите ответ, который иначе узнали бы от пострадавшего сотрудника.

Лаборатория, которую можно пересобрать за вечер

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

Что именно фиксировать:

• Состояние машин. Когда домен создан, клиент вступил в него, структура подразделений готова, но тестовых политик ещё нет, сделайте снимок обеих машин в этот момент. Как и сказано выше, это инструмент повторяемости лаборатории, а не резервная копия домена. Будет ли в вашем плане доступна функция снимков, определите по панели и форме заказа; готовые автоматические резервные копии для всех тарифов считать данностью нельзя.
• Текстовый паспорт. Короткий файл: имя леса и домена, имена машин, адреса, схема подразделений, список учёток, где лежат пароли (в менеджере, а не в файле). Паспорт пригодится, если придётся пересобрать лабораторию с нуля, а снимка под рукой не окажется.
• Журнал опытов. По строке на упражнение: что меняли, что ожидали, что получили. Через месяц вы не вспомните, почему политика «не работала», а запись «компьютер лежал в контейнере по умолчанию» избавит от повторной траты вечера.

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

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

Что дальше проверять на таком стенде

Когда базовый опыт отработан, лаборатория открывает много соседних тем. Можно сделать вторую политику и посмотреть, как они конкурируют, если привязаны на разных уровнях дерева. Можно настроить фильтрацию по группе безопасности и увидеть, что политика применяется не ко всем, кто лежит в подразделении. Можно подключить к каталогу сторонний сервис: например, потренироваться в проверке пользователей VPN через каталог — подробно эта схема разобрана в статье про аутентификацию VPN-пользователей через Active Directory (NPS/RADIUS). Прогонять такой опыт на стенде вместо рабочего домена безопаснее: ошибка в правилах не заблокирует настоящих сотрудников.

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

Что касается самой площадки, VPS подходит для этой задачи по простым причинам: вы получаете машину с NVMe-диском и root-доступом, можете заказать её на нужный срок, а при необходимости взять план побольше или добавить вторую машину под клиента. По публичному предложению MAATRIX доступны локации UK, US, RU и FR, оплата возможна картой РФ и через СБП, а сам сервер создаётся автоматически через пару минут после оплаты. Для лаборатории это удобно: стенд не нужно планировать неделями. Не забывайте только проверить в форме заказа, какой образ ОС доступен в выбранной локации, прежде чем строить на нём планы.

Право на ошибку как свойство стенда

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

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