Active Directory: леса доверия вместо слияния доменов

В феврале один из наших клиентов - дистрибьютор, около ста пятидесяти человек - купил небольшую производственную компанию. Примерно шестьдесят сотрудников, свой домен AD, свой сервер, свой системный администратор. Генеральный директор спросил нас: как теперь с доменами быть, сливаем?

Мы ответили: не торопитесь. И объяснили почему.

Почему слияние - не всегда ответ

Слить два леса AD в один технически возможно. Это называется миграция с использованием ADMT - Active Directory Migration Tool. Переносишь пользователей, компьютеры, группы, перекидываешь SID-историю чтобы права не рассыпались, перенастраиваешь все GPO, ждёшь пока всё устаканится. Звучит аккуратно, на практике - несколько недель работы и добрый шанс что что-то сломается в самый неудобный момент.

Но главная проблема не техническая. Дочерняя компания - отдельное юрлицо с отдельным руководством. IT-отдел там собственный, со своими задачами и зонами ответственности. Если слить домены в один лес, придётся либо давать им Enterprise Admin в общем лесу - это слишком много, - либо городить сложную систему делегирования на уровне OU. И всё равно получишь ситуацию, когда администратор дочки технически может добраться до объектов головной конторы.

Клиент это понял сразу. Решили идти через Forest Trust.

Что такое доверие между лесами

Windows Server 2003 ввёл Forest Trust - двустороннее или одностороннее доверие между двумя отдельными лесами AD. Это не то же самое, что External Trust между доменами: здесь транзитивность работает через весь лес, то есть пользователь из любого домена дочернего леса может получить доступ к ресурсам в любом домене родительского - если ему явно дать права.

Ключевое слово - явно. По умолчанию Forest Trust даёт только возможность аутентификации. Авторизация - отдельный шаг, ресурсы нужно открывать вручную. Это важно: само по себе доверие не делает пользователей одного леса видимыми или доступными в другом. Нужно добавить конкретный аккаунт или группу из леса Б в ACL ресурса в лесу А.

Что настроили

Схема получилась такой:

• Два отдельных леса с разными корневыми доменами - условно holding.local и factory.local.
• Двустороннее Forest Trust между корневыми доменами.
• Selective Authentication - режим, при котором пользователи из factory.local не могут автоматически ходить на серверы holding.local. На каждом ресурсе нужно явно разрешить «Allowed to authenticate» для нужных аккаунтов или групп.

Selective Authentication - это отдельная галочка при настройке доверия, и мы её включили намеренно. Без неё пользователи из доверенного леса могут проходить аутентификацию на любом сервере, что создаёт неочевидный риск: кто-то из дочки случайно или намеренно зашёл куда не нужно.

С Selective Authentication всё наоборот: по умолчанию закрыто, открываем только то что нужно.

Делегирование без пересечения

Это и было главным результатом. Администратор factory.local - полный хозяин своего леса. Может создавать пользователей, группы, GPO, OU, делать что угодно в своём домене. При этом он физически не видит объекты holding.local в оснастках - чужой лес для него закрыт. Никакого общего пароля Enterprise Admin, никакого доступа к схеме или конфигурации головного леса.

Общими сделали только то, что реально нужно для совместной работы:

• Общий файловый ресурс - папка с документами для совместной работы, куда добавили нужные группы из factory.local.
• Почта - Exchange стоит только в holding.local, для пользователей factory.local настроили доступ через GAL Synchronization, чтобы они видели друг друга в адресной книге.
• Принтер в переговорной, которой пользуются обе компании.

Всё остальное - разделено. Серверы дочки, её файлопомойка, её внутренние ресурсы - от головного офиса не видны и не доступны.

Что пошло не сразу

Честно: первый час после создания доверия пользователи из factory.local не могли попасть на общий ресурс, хотя доверие было настроено и выглядело рабочим. Оказалось две вещи одновременно.

Первая - забыли про DNS. Forest Trust требует, чтобы оба леса видели DNS-зоны друг друга. Настроили conditional forwarder: в holding.local добавили форвардер на DNS factory.local и наоборот. После этого оба леса начали резолвить имена в чужом домене.

Вторая - Selective Authentication. Создали доверие, добавили пользователей в ACL папки, но не поставили им «Allowed to authenticate» на самом файл-сервере. Аутентификация падала раньше, чем дело доходило до проверки прав. После того как добавили эту запись - всё заработало.

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

Итог

Forest Trust с Selective Authentication - разумный способ дать двум независимым компаниям работать вместе, не смешивая при этом их администрирование. Каждый IT-отдел рулит своим, ничего лишнего не видит, общий список ресурсов - явный и контролируемый.

Слияние доменов имеет смысл, когда компании действительно сливаются в одну - с единым управлением, единым IT. Если же юридическая и управленческая граница остаётся - технически её тоже стоит сохранить.

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