Вступление 

Привет, Хабр! Продолжаю рассказывать про российские аналоги Microsoft Active Directory для построения корпоративных доменов. Идея этих материалов — собрать в одном месте все известные и распространённые отечественные аналоги, и чтобы человек, малознакомый или не знакомый с ними, мог выбрать нужный и сравнить ответы самих разработчиков. Да, тут на Хабре уже полно статей, но я решил сделать серию материалов, от которой можно отталкиваться, выбрать нужное решение и потом искать дальше материалы по теме. Первый материал был про российскую систему централизованного управления IT‑инфраструктурой «Ред Адм». В новом я поговорил с разработчиками ALD Pro.

Итак, встречайте разговор с директором серверного ПО «Группы Астра» Алексеем Фоменко и менеджером продукта ALD Pro «Группы Астра» Анатолием Лысовым. Мы поговорили о том, как был реализован проект, когда начался, какими он обладает фичами на конец 2025 года и можно ли на ALD Pro перейти с Windows‑инфраструктуры безболезненно. Приятного чтения!

Интервью

Когда появилась система ALD Pro и какой был запрос рынка, который привёл к её созданию? Это было до 2022 года или после?

В 2020 году наш генеральный директор Илья Сивцев отметил, что у нас большая доля рынка среди операционных систем, но из‑за кадрового дефицита и нехватки экспертизы по Linux продвигать решения сложно. Чтобы операционная система была конкурентоспособной, требовался инструмент управления, аналогичный тому, что предоставляет Microsoft. К тому моменту у нас уже было составлено техническое задание, собранное специалистами на основе требований заказчиков. Мы начали формировать команду и разрабатывать решение. Первый выпуск состоялся примерно через год, ещё до событий 2022 года.

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

Samba, на наш взгляд, не подходила для полноценного управления Linux‑инфраструктурой, а в существующих open source‑решениях, таких как FreeIPA, отсутствовала иерархия подразделений, без которой невозможно описать структуру компании. Мы понимали, что эту часть необходимо доработать — это был основной вектор развития.

Когда решение вышло на рынок, наибольший интерес неожиданно проявили крупные компании. Для них критичны требования регуляторов и риски, связанные с нарушениями в работе бизнес‑процессов, и они готовы платить за снижение этих рисков. Малые и средние компании, напротив, предпочли подождать, считая себя вне зоны внимания потенциальных атак. Крупные заказчики выдвинули иные требования: им не нужен широкий набор встроенных подсистем, поскольку у них уже есть отдельные системы мониторинга, печати и безопасности. От ALD Pro они ожидали прежде всего надёжности, масштабируемости, возможности миграции из Microsoft и совместимости с существующей инфраструктурой. Поэтому часть функций мы переработали, сделав акцент на гибкости, масштабируемости, гетерогенности и миграции.

Получается, что и FreeIPA, и Samba выросли из open source‑среды. Интересно, что именно здесь произошло разделение подходов: одна часть сообщества сделала ставку на Samba, другая — на FreeIPA. Почему всё же вы выбрали второй вариант, если в Samba уже была реализована иерархия подразделений?

Чтобы сделать правильный выбор, мы провели большое исследование. В целом картина выглядит так: Samba изначально создавалась как аналог Microsoft Active Directory под Linux, чтобы управлять Windows‑компьютерами без необходимости покупки лицензий у Microsoft. По сути, это инструмент для замещения Microsoft AD с фокусом на Windows‑среду. Многие отечественные разработчики, создавая собственные Linux‑решения, пытаются приспособить Samba для управления Linux‑компьютерами, которая изначально была предназначена для Windows. Мы пошли другим путём: поскольку наши операционные системы основаны на Linux, логичнее использовать службу FreeIPA, которая изначально разработана для управления Linux‑компьютерами. Для Windows мы оставляем нативное управление через Microsoft AD, обеспечивая интеграцию с этими доменами через модуль синхронизации и доверительные отношения.

Если добавить технический аспект, то важно учитывать, кто разрабатывал обе системы. Разработка четвёртой версии Samba, в которой впервые появилась поддержка доменов Active Directory, стала возможна после определённых судебных разбирательств, которые мотивировали компанию Microsoft открыть свои протоколы. Но те же разработчики, кто работал над Samba4, в дальшейнем запустили проект FreeIPA и таким образом, FreeIPA можно считать логическим продолжением Samba, но уже с ориентацией на Linux‑инфраструктуру. Эта же команда до сих пор остаётся основным контрибьютором Samba, в том числе в области интеграции через доверительные отношения.

В нашей компании также был значительный опыт по использованию Samba. Первые эксперименты по созданию доменной структуры для Astra Linux мы проводили именно на базе глубокого анализа возможностей Samba как основного решения. Позже стало очевидно, что FreeIPA намного лучше соответствует требованиям Linux‑среды. Более того, в рамках проекта FreeIPA была разработана клиентская служба SSSD, которая в настоящее время является стандартом для обеспечения работы Linux‑компьютеров в составе домена вне зависимости от того, что используется на бэкенде — нативная FreeIPA, с которой у SSSD наилучшая интеграция, или Active Directory.

Приведите короткий наглядный пример.

Очень просто. Возьмём Windows‑компьютер и Windows‑пользователя. У них есть идентификатор безопасности (SID), который используется во всех списках доступа. В инфраструктуре Microsoft применяются именно эти Windows‑идентификаторы. В Linux же используются POSIX‑идентификаторы — UID и GID. В Samba Linux‑идентификаторы не хранятся, они пересчитываются при каждом обращении, и в зависимости от настроек конечной системы этот расчёт может отличаться. В результате один и тот же пользователь на разных Linux‑системах может иметь разные идентификаторы. Служба каталога FreeIPA, напротив, для каждого субъекта создаёт POSIX‑идентификатор и сохраняет его в каталоге, гарантируя единообразие на всех Linux‑системах. И таких примеров можно привести десятки.

Если используется ALD Pro или аналогичное решение, нужна ли вообще Windows‑машина для управления доменом? И можно ли выстроить процесс миграции постепенно — например, создать домен ALD Pro рядом с существующим Windows‑доменом и поэтапно перейти?

Наиболее правильная схема именно такая — создание отдельного домена рядом с существующей инфраструктурой и интеграция через механизм доверительных отношений. Это позволяет пользователям Microsoft Active Directory получать доступ к ресурсам домена ALD Pro на базе FreeIPA, и наоборот — пользователям ALD Pro работать с общими файлами в инфраструктуре Active Directory. Это оптимальная точка начала миграции.

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

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

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

Правильно ли понимаю, что при построении домена в итоге можно будет отказаться от существующих Windows‑машин, которыми пользуются сотрудники?

Если необходимость в Windows‑машинах сохраняется, это не проблема. Мы провели масштабное исследование по интеграции Windows‑систем в домен на базе FreeIPA. В результате разработали специальную графическую утилиту, позволяющую подключить Windows‑компьютер к домену ALD Pro буквально в несколько кликов и обеспечить максимально возможный уровень функциональной совместимости.

Таким образом, Windows‑машины можно включать в домен ALD Pro с сохранением всех базовых функций: аутентификации, авторизации, работы с доменными идентификаторами безопасности, получения Kerberos‑билетов и доступа к файловым ресурсам или другим сервисам, использующим Kerberos‑аутентификацию.

Перейдём к вопросу об администраторах. Насколько удобно специалистам, привыкшим к Windows‑инфраструктуре, переходить на ALD Pro? Ведь компетенции терять всегда рискованно, а open source‑среды часто требуют больше ручной настройки.

В этом направлении мы смогли продвинуться благодаря поддержке руководства, которое выделило значительные ресурсы на исследование лучших практик. Мы собрали большую команду инженеров — около пятнадцати человек, имевших опыт сопровождения Windows‑инфраструктур с десятками и сотнями тысяч машин. Задачей команды стало формирование набора практик, позволяющих решать те же задачи, что и в Windows‑доменах, с тем же уровнем надёжности, удобства и отказоустойчивости.

Результатом этой работы стали десятки исследований, результаты которых легли в основу открытого учебного курса. Цель курса — не обучать Linux «с нуля», а помочь опытным Windows‑администраторам понять, где подходы в Linux совпадают с привычными, где различаются, и как решать типовые задачи в новой среде. Например, при работе с DNS в Windows предусмотрено автоматическое переключение между доступными серверами для обеспечения отказоустойчивости. В Linux с закреплением предпочтительного сервера отсутствует по умолчанию, поскольку система изначально проектировалась как серверная. Однако задача решаема: одно из последних исследований нашей команды было посвящено балансировке DNS на рабочих станциях, что получило положительные отзывы в инженерном сообществе.

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

Если говорить конкретно о переходе Windows‑администраторов, мы старались максимально сохранить знакомую терминологию и сценарии работы. Используются те же принципы, что и в Microsoft Active Directory: групповые политики, структура подразделений, работа с объектами пользователей и компьютеров. Однако определённая специфика Linux всё же остаётся. Например, здесь нет реестра, вместо него папка /etc с конфигурационными файлами в различных форматах, а значит, параметры конфигурации нужно применять по‑другому. Администратору придётся адаптироваться к иной логике, но общий подход к управлению остаётся близким к привычному.

В ALD Pro есть графическая оболочка, или всё реализовано преимущественно через консоль, как сейчас часто делают многие решения?

Если сравнить с Microsoft Active Directory, то, хотя там не используется веб‑интерфейс, технология взаимодействия между клиентским приложением и сервером основана на тех же принципах — через HTTP (имеется в виду WinRM). Поэтому мы не стали изобретать собственные протоколы: разработали полноценный веб‑портал с удобным и функциональным интерфейсом. Дополнительные инструменты поставляются в виде утилит командной строки. Сначала мы решаем задачу в общем виде, проверяем её корректность через сообщество, а затем интегрируем в графический интерфейс.

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

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

Отдельно отмечаем, что пользователи ALD Pro имеют возможность напрямую влиять на развитие продукта. В отличие от Microsoft, где невозможно запросить изменение интерфейса под конкретные нужды, отечественные заказчики могут предложить доработку, и если она действительно повышает удобство, то уже в следующем релизе изменения внедряются.

То есть в ALD Pro реализован тот же принцип доступа администраторов к инструментам, что и в Microsoft: есть разграничение ролей, групповые политики и управление правами, и всё это доступно через графический интерфейс.

А как обстоит дело с молодыми компаниями? Есть ли среди заказчиков небольшие организации, которые с самого начала выбирают не Microsoft, а ALD Pro? Насколько удобно для таких компаний разворачивать домен с нуля?

Мы считаем, что решения «Группы Астра» действительно удобны для внедрения даже в небольших компаниях. Прежде всего — за счёт полноты документации и развитой системы поддержки. У ALD Pro есть справочный центр, обучающие курсы, активное сообщество и графические утилиты для ввода машин в домен и веб‑инетрфейс для последующего администрирования. Такой комплексный подход позволяет рассматривать ALD Pro не просто как технологический продукт, а как готовое решение с инфраструктурой вокруг него.

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

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

Чем ALD Pro отличается от конкурентов, в чём его ключевые преимущества — те самые «киллер‑фичи»? Например, есть российские решения, где реализована функция «лесов»?

Некоторые решения на рынке заявляют поддержку «лесов» (forest), но реализуют это просто за счёт отключения встроенных проверок в Samba, что фактически нарушает корректность работы инфраструктуры. Такие обходные пути приводят к тому, что часть критически важных механизмов, например, глобальный каталог, перестаёт работать как положено. В результате могут возникать проблемы с аутентификацией пользователей: каталоги не содержат полных данных об универсальных группах, эта информация не включается в Kerberos‑билеты, поэтому распределение прав доступа становится непредсказуемым, и зависит от того, через какой контроллер домена была выполнена аутентификация.

Мы подошли к задаче иначе — не стали механически воспроизводить концепцию «леса» из Microsoft Active Directory, а проанализировали её смысл. По сути, лес решает две практические задачи:

1. Изоляция паролей внутри периметра конкретного домена — повышение безопасности.

2. Деление инфраструктуры на несколько доменов для снижения нагрузки на контроллеры и уменьшения требований к аппаратным ресурсам.

Эти функции в ALD Pro мы реализовали с помощью доверительных отношений между доменами, что позволяет объединять несколько доменов в одно пространство без необходимости создавать полноценные леса с репликацией общей схемы каталога. Базовая служба FreeIPA не позволяет устанавливать доверительные отношения между своими доменами, а в ALD Pro это уже реализовано. Таким образом, наше решение обеспечивает те же преимущества, что и леса, но без их сложности и рисков.

Вторая ключевая «киллер‑фича» ALD Pro — это высокопроизводительный механизм групповых политик. В отличие от службы каталога FreeIPA, где реализованы только базовые политики безопасности, в ALD Pro реализован полноценный масштабируемый механизм групповых политик, с помощью которого можно управлять любыми настройками рабочих станций. Групповые политики работают по классической pull‑модели Active Directory, обеспечивают устойчивость при потере связи между площадками и каждый контроллер позволяет управлять тысячами клиентов.

Кроме того, система расширяема: администраторы могут добавлять собственные параметры политик, импортировать и экспортировать их между инфраструктурами, а также использовать встроенные средства автоматизации через HTTP API. Эти инструменты позволяют создавать сценарии быстро и с высокой степенью гибкости — уровень, которого сложно достичь при разработке на Bash или Python.

Таким образом, ALD Pro выделяется двумя технически значимыми преимуществами:

— реализацией доверительных отношений, покрывающих задачи лесов;

— собственной реализацией групповых политик корпоративного уровня.

У вас уже реализованы какие‑то решения «из коробки»? Есть LAPS? Если у заказчика возникают какие‑то нестандартные, «экзотические» требования, возможно ли их добавить?

Да, у нас из коробки доступны сотни параметров групповых политик, одних только параметров ФСТЭК порядка 40 штук. Если у заказчика появляются специфические требования, партнёр может разработать необходимые параметры политик самостоятельно.

Решение LAPS уже есть в составе продукта ALD Pro и более того, оно реализовано именно так, как это сделано в MS Active Directory. Это важно, поскольку не у всех служб каталога, которые заявляют наличие LAPS, это решение работает так, как нужно. Мы делаем акцент не только на наличии отдельных функций, но и на количестве управляемых настроек. Если говорить о параметрах, их сотни, но число настроек операционной системы, которыми мы реально управляем, превышает тысячу. Более того, мы — один из немногих вендоров, кто целенаправленно инвестирует усилия в выработку лучших практик и в интеграцию. У нас уже более ста интеграций с наиболее востребованными приложениями. Мы можем показать, как они работают, объяснить, как настраивать, предоставить инструкции. Наша экосистема — это не только продукты «Астры». Развивая свою службу каталога, мы очень плотно сотрудничаем с технологическими партнёрами.

Что произойдёт, если небольшой заказчик начнёт строить инфраструктуру сразу на службе каталогов ALD Pro?

Это идеальный сценарий. Заказчик не столкнётся ни с какими трудностями при развёртывании решения и сразу же станут доступны все базовые функции аутентификации, авторизации и управления. Кроме того, из коробки он получит семь востребованных подсистем: репозиторий deb‑пакетов, файловый сервер, сервер печати, DHCP‑сервер, PXE‑сервер для установки ОС по сети, аудит и мониторинг. Это уже встроенные лучшие практики, которые мы включили в продукт. Дополнительно заказчик получит интеграцию с экосистемой «Группы Астра» и десятками совместимых решений от российских разработчиков и open source‑сообщества. Мы намеренно развиваем это направление, чтобы инфраструктуру можно было собрать по принципу конструктора: готовая основа — и лишь специфические элементы настраиваются силами интегратора или собственной командой заказчика.

Перейдём к вопросу управления. Мы уже говорили о Windows, но, кроме Astra Linux, есть ещё «Ред ОС», «Альт» и другие российские дистрибутивы. Насколько удобно с ними работать и можно ли централизовано ими управлять через ALD Pro?

Моновендорный подход, когда инфраструктура строится из решений одного поставщика, безусловно, наиболее удобен: он обеспечивает полную совместимость и снижает затраты на обучение, внедрение и сопровождение. Однако на практике заказчики не всегда могут следовать лучшим практикам — иногда из‑за исторических причин или ранее принятых решений. Мы это учитываем. Astra Linux сегодня занимает более 76% рынка, но мы также добавили поддержку RedOS и ALT Linux, что в совокупности покрывает свыше 90% российских систем. Для этих платформ есть полноценный клиент ALD Pro, обеспечивающий работу централизованную настройку через механизм групповых политик, а также инструмент для оказания удалённой технической поддержки.

Если говорить о других Linux-дистрибутивах отечественной разработки, для них всегда доступен нативный клиент FreeIPA со службой SSSD — это базовый компонент для обеспечения работы Linux в составе домена. Клиент позволяет реализовать все основные функции: аутентификацию, авторизацию и применение ключевых политик безопасности.

Мы осторожно подходим к вопросу совместимости с другими операционными системами. Технологически это возможно — в основе клиента ALD Pro действительно лежит служба SSSD, и он может работать на любой Linux‑системе. Но у нас продуктовый подход: если мы заявляем совместимость, то только с конкретной версией операционной системы. Каждая версия ALD Pro тестируется с конкретной версией ОС, и мы можем гарантировать, что все политики работают именно в этом сочетании.

Некоторые вендоры заявляют, что они совместимы со всеми системами, но мы считаем важным делать это аккуратно. Совместимость подтверждается только там, где продуктовая команда реально проводила испытания. Поэтому мы прямо указываем, с какими версиями отечественных операционных систем совместима конкретная сборка ALD Pro.

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

Мы предоставляем возможность писать групповые политики под другие российские операционные системы, но не считаем это своей основной продуктовой задачей. Базовый набор политик мы разрабатываем сами, а инструменты для расширения передаём вендорам.

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

Любой вендор может заявлять о совместимости, но на практике, например, при установке обновлений операционной системы Astra Linux, сторонние разработчики не смогут поддерживать её механизмы безопасности и управлять параметрами через групповые политики. Точно так же и мы не можем управлять обновлениями «Альт» или «Ред ОС». Поэтому заявления о полной взаимной управляемости всегда нужно воспринимать с осторожностью.

Раз уж речь зашла об управлении, стоит вспомнить, что Microsoft традиционно предлагает не только домен, но и сопутствующую инфраструктуру: почтовый сервер, сервер печати, корпоративный портал вроде SharePoint. Поэтому логично возникает вопрос о взаимодействии ALD Pro с почтовыми серверами. В Windows‑доменаx почти всегда присутствует сервер Exchange, обеспечивающий тесную интеграцию, и важно понять, как это решено здесь. Есть у вас такая интеграция?

Да, в нашем случае рядом с ALD Pro можно развернуть почтовый сервер RuPost. У него есть собственный почтовый клиент, полностью совместимый с инфраструктурой Linux.

Подход компании заключается в том, что интеграции в первую очередь создаются для собственных решений, чтобы обеспечить полную совместимость экосистемы и своевременное обновление при выходе новых версий. После этого мы расширяем поддержку и на другие популярные сторонние продукты. Так, помимо RuPost, у нас реализованы решения для взаимодействия с VK Mail и CommuniGate.

Что касается Exchange, мы понимаем, что он у заказчиков может оставаться в инфраструктуре ещё долго. Поэтому мы проработали возможность интеграции и с ним. Используется технология Linked Mailbox, применяемая в Microsoft: Exchange физически находится в конкретном домене MS AD, а пользователи из других доменов делегируют права на доступ к связанным почтовым ящикам. Мы доработали наш компонент, чтобы в PAC‑сертификате Kerberos‑билеты появлялась вся необходимая информация для корректной работы с Exchange.

Таким образом, при необходимости пользователи ALD Pro могут получать доступ к почтовым ящикам, размещённым на серверах Exchange в домене Active Directory.

И тогда вопрос про безопасность. Можно ли в ALD Pro реализовать аппаратные механизмы аутентификации — использование карт, ключей, токенов? Есть ли конкретные кейсы интеграции с решениями вроде OTP или PTA?

Учитывая, что мы активно работаем с банками, двухфакторная аутентификация была одна из первых задач, которую мы решали. Мы тесно сотрудничаем с технологическими партнёрами — компаниями «Аладдин» и SafeTech,которые отвечают за развитие и сертификацию своих решений, а мы обеспечиваем их интеграцию с ALD Pro.

На практике это выглядит так: используется токен или смарт‑карта, на которой генерируется пара ключей — открытый и закрытый. Закрытый ключ остаётся на карте, а открытый подписывается удостоверяющим центром, например, Aladdin eCA. Сертификат записывается и на карту, и в службу каталога. Далее через расширение протокола Kerberos PKINIT обеспечивается двухфакторная аутентификация без ввода пароля: сотрудник прикладывает карту или подключает токен и вводит пин‑код. Это позволяет реализовать максимально безопасный вход в систему.

Заключение

Ну что же, надеюсь, удалось рассказать вкратце о решении, о том, какие есть нюансы настройки на начальных этапах и с чем можно интегрировать ALD Pro. От себя хочу добавить, что мне интересно будет через несколько лет поговорить с разработчиками (всех решений), чтобы увидеть разницу. Материал по ещё нескольким решениям аналогов Microsoft Active Directory и доменных структур уже в работе. Спасибо за прочтение!