Привет, Хабр!
Меня зовут Дмитрий Макаров, я руководитель продукта MULTIDIRECTORY — российской службы каталогов с ядром собственной разработки.
После ухода Microsoft с российского рынка многие инженеры и администраторы столкнулись с вопросом: чем заменить Active Directory? При этом ещё нужно сохранить совместимость и привычные инструменты, обеспечить надежность и безопасность. Samba и FreeIPA казались логичным выбором, но на практике часто оказывались либо сильно устаревшими, либо слишком сложными для использования.
Мы решили начать с нуля и создать службу каталогов, которая сочетала бы знакомый функционал AD с современным стеком, гибкой архитектурой и возможностью интеграции в гибридные инфраструктуры. Так началась история MULTIDIRECTORY (MD).
Почему начали с чистого листа
На старте мы рассмотрели все популярные решения — OpenLDAP, Samba AD-DC, FreeIPA, 389 Directory Server. Но у каждого из них оказались ограничения, не позволяющие построить действительно масштабируемую и отказоустойчивую систему.
Почему не Samba?
Samba — проект, глубоко осевший в эпохе Windows NT, чьи корни уходят во времена ранних версий Windows Server. Несмотря на свою популярность среди Linux-пользователей, этот инструмент имеет ряд существенных недостатков, которые делают его малопригодным для современных высоконагруженных инфраструктур:
Доменные контроллеры
Контроллеры доменов Samba спроектированы таким образом, что плохо справляются с высокими нагрузками. Это особенно заметно при увеличени�� числа пользователей и сервисов внутри инфраструктуры.
Масштабируемость
Расширение сети на большее количество серверов требует значительных усилий и затрат ресурсов. Добавление новых узлов — трудоёмкий процесс со сложной конфигурацией, необходимо проводить долгие настройки каждого нового элемента системы.
Устаревший стек
Проект исторически развивается на языке C и в 90-е годы это было естественным возможным решением. Сегодня такой технологический стек усложняет развитие продукта, повышает стоимость поддержки и делает внедрение современных практик безопасности и масштабирования трудоёмким. Работа с низкоуровневым кодом затрудняет быстрые изменения и интеграцию новых возможностей, тогда как современные решения требуют гибкости, модульности и расширяемости.
Почему не FreeIPA?
FreeIPA — это open-source-проект для управления пользователями, политиками и аутентификацией, ориентированный прежде всего на Linux-инфраструктуру. Он действительно закрывает многие базовые сценарии, но при этом имеет ряд архитектурных особенностей и ограничений, которые становятся серьёзным препятствием при использовании в корпоративных средах.
Плоская структура организации
В FreeIPA отсутствует привычная для многих иерархическая структура подразделений (OU), как в Active Directory. Все объекты — пользователи, группы, компьютеры — размещаются в общей плоской структуре. Это может быть удобно для простых сценариев, но становится существенным ограничением при масштабировании или необходимости разграничения прав доступа между подразделениями, филиалами или бизнес-единицами.
Производительность
Из-за сложной архитектуры и большого количества промежуточных слоёв FreeIPA работает медленнее, чем специализированные решения. Каждая операция проходит через многочисленные компоненты, что замедляет работу всей системы в целом.
Обслуживание
Обновления и поддержка становятся настоящим испытанием, поскольку изменения в одном компоненте могут привести к непредвиденным последствиям в других частях проекта. Здесь нужно поддерживать высокий уровень экспертизы инженеров.
Сложности с интеграцией
Решение FreeIPA слабо совместимо с экосистемой Windows и Active Directory. Двусторонние доверительные отношения (trust) реализованы ограниченно и нестабильно, что мешает полноценной интеграции в гибридные инфраструктуры. Настройка таких связей требует тонкой ручной работы, часто сопровождается багами и вызывает трудности при эксплуатации.
Асинхронное ядро службы каталогов MULTIDIRECTORY
Мы отказались от идеи наследовать чужой код и решили писать своё ядро на Python. У этого языка зрелая экосистема, высокая читаемость и нет санкционных рисков, как у .NET или Go-приложений.
MULTIDIRECTORY строится как модульная система с веб-интерфейсом на FastAPI и асинхронной моделью обработки запросов через asyncio. Это даёт стабильную производительность даже при высокой нагрузке.
Сервис разделён на несколько независимых компонентов — LDAP-каталог, MIT Kerberos, DNS (Bind9), Kea DHCP, SaltStack и административный API. Такое разделение упрощает масштабирование и обновление.
Схема LDAP адаптирована под Microsoft Active Directory, поэтому большинство приложений и сервисов видят MD как знакомое AD и работают без изменений. Для интеграции с внешними системами реализован REST API, который позволяет управлять пользователями, группами и политиками через стандартные HTTP-запросы, что удобно для автоматизации и внедрения в существующую инфраструктуру.
Хранение данных: PostgreSQL вместо LDAP-БД
Вместо специализированных LDAP-хранилищ мы выбрали PostgreSQL — стабильную, гибкую и хорошо поддерживаемую систему. Это позволило использовать инструменты, знакомые большинству инженеров: например, мониторинг, резервное копирование и репликацию.
Для надёжности применяется архитектура Master-Replica на базе Patroni: при сбое основного узла система автоматически переключается на резервный. Синхронная репликация исключает потерю данных, а совместимость с российскими форками (Postgres Pro, Jatoba и др.) обеспечивает локальную поддержку.
Контейнеризация и деплой
Чтобы упростить жизнь администраторам, мы упаковали MD в Docker-контейнеры. Это позволило значительно сократить время запуска инфраструктуры — теперь буквально за считанные минуты можно развернуть рабочую версию приложения на любом сервере или рабочей станции.
Преимущества подхода:
Универсальность: приложения работают на стандартной операционной системе Linux Debian, которая известна своей надёжностью и проверена временем
Простота настройки: чтобы запустить систему, нужно поменять всего один специальный файл настроек (docker-compose.yml) или создать конфигурационные файлы для управления контейнерами, например, в Kubernetes
Совместимость: MD запускается одинаково хорошо на любых компьютерах, где установлен Docker — неважно, используете вы Windows, macOS или разные версии Linux
Масштабирование: удобное масштабирование и управление с помощью Kubernetes
Единая точка истины
Вся информация в службе каталогов MULTIDIRECTORY хранится централизованно в единой базе данных, что кардинально отличается от Active Directory. В AD каждый развёрнутый контроллер домена обладает собственной базой данных, и для поддержания согласованности между ними осуществляется постоянный процесс обмена информацией (процесс репликации).
В MD всё логичнее: здесь используется единая база данных. Это упрощает администрирование системы, поскольку отсутствуют проблемы с конфликтующими версиями данных и ошибками, возникающими вследствие некорректной репликации.
Модель данных MD позволяет администраторам гибко добавлять собственные атрибуты, не ломая при этом само ядро. Такой подход повышает удобство управления системой и снижает риск возникновения ошибок при внесении изменений в схему данных.
Что MD дает инженеру
Служба каталогов MULTIDIRECTORY была создана как ответ на ограничения существующих решений вроде Samba и FreeIPA. В ней реализовано всё, что действительно нужно администраторам, без избыточной сложности.
В MD сохранён базовый функционал Active Directory, но на современном технологическом стеке с удобным интерфейсом и поддержкой двухфакторной аутентификации через решение MULTIFACTOR — оно работает для всех протоколов без внешних модулей и адаптеров.
Система устойчива к сбоям, быстро разворачивается и проста в обслуживании. Доступны две версии — Community (бесплатная версия с базовым функционалом) и Enterprise (с максимальным набором функций для организаций с повышенными требованиями к безопасности). Связаться с разработчиками и получить консультацию напрямую можно в Telegram-чате.
Что в итоге
MULTIDIRECTORY — это результат нашего решения пересобрать службу каталогов, опираясь на реальный опыт эксплуатации и современные принципы проектирования, а не просто российская замена Active Directory.
Если вы хотите мигрировать с AD, работаете с FreeIPA или просто интересуетесь архитектурой каталогов — попробуйте MD, поэкспериментируйте и расскажите в Telegram-чате, что вам показалось удачным, а что требует доработки. Обратная связь от инженеров для нас очень важна.
А если вы хотите узнать больше о продукте и увидеть его в действии, приглашаем вас 4 декабря в 11:00 (МСК) на вебинар «Твоя безопасность. Твои правила. Твой контроль. Всё о службе каталогов MULTIDIRECTORY».
В прямом эфире расскажем:
— почему сегодня важно переходить на российские решения;
— как устроена архитектура и функционал MULTIDIRECTORY в версиях Community и Enterprise;
— как работают групповые политики;
— каким образом реализована безопасность через ролевую модель;
— как управлять парольными политиками;
— и как работает 2FA на отечественных ОС.
Регистрируйтесь и подключайтесь!
Комментарии (31)
ildarz
13.11.2025 11:20В MD всё логичнее: здесь используется единая база данных.
Из разряда "как попытаться выдать недостаток за достоинство". Искренне надеюсь, что ваши специалисты на самом деле не думают, что мультимастер структура AD - это потому, что ребята не знали, как "логично" сделать.
Orky
13.11.2025 11:20Там я выше написал, что можно сделать единую геораспределённую базу, да, это пипец непривычно, но по сути классное решение, ведь вы разделяете зону хранения и зону обработки данных на разные инстансы, а не так, как сделано в АД: один инстанс - одно хранилище, которое еще надо научить нормально синхронизироваться
Romain6G
13.11.2025 11:20Из разряда "как попытаться выдать недостаток за достоинство". Искренне надеюсь, что ваши специалисты на самом деле не думают, что мультимастер структура AD - это потому, что ребята не знали, как "логично" сделать.
Multimaster‑структура AD — это историческая особенность архитектуры. Она была разработана в 2000 году под специфические задачи: работу с непостоянными каналами связи (спутниковые линии, филиалы с ограниченной связью) с так называемыми окнами доступности.
Отсюда и функционал репликации по расписанию в течение суток, который кажется избыточным в современных реалиях.В современном мире, при стабильных постоянных каналах связи, схема master → multireplica полностью покрывает все сценарии: аутентификация, авторизация. Никакой особой логики здесь нет — просто исторический дизайн учитывал условия и ограничения того времени.
aegoroff
13.11.2025 11:20В современном мире, при стабильных постоянных каналах связи
вот это фундаментальное заблуждение - каналы связи между регионами были и есть ненадежны по определению, и далеко не всегда они быстрые
ildarz
13.11.2025 11:20В современном мире, при стабильных постоянных каналах связи
Мы тут как раз недавно с коллегами обсуждали, как бы нам реализовать работу офиса клиента в одной маленькой северной деревеньке, куда проводной интернет всё проводят и проводят уже несколько лет в режиме "через четыре года здесь будет город-сад". Причем как раз с AD-то как раз проблем ровно ноль из-за "исторических особенностей архитектуры", а вот со всем остальным... Так что спасибо, что просветили насчет "современного мира".
Vedomir
13.11.2025 11:20Интересно, а какие санкционные риски у .net и Go по сравнению с Python?
Orky
13.11.2025 11:20Кстати, хороший вопрос. Формально .net - под санкциями, но .net core - нет ) Так что, чую, это чисто дело времени, когда его подбанят. Насчёт Го не в курсе, если честно
Vedomir
13.11.2025 11:20Уже лет пять как нет .net core отдельного, начиная с 5 версии .net core стал просто .net и полностью открытым проектом, а развитие ветки 4.х было остановлено. На днях уже 10 версия вышла.
И современный .net такой же открытый проект как и Python.
Romain6G
13.11.2025 11:20Интересно, а какие санкционные риски у .net и Go по сравнению с Python?
Санкционные риски напрямую зависят не только от языка, а от экосистемы и юрисдикции. .NET — продукт Microsoft, целиком под контролем американской корпорации. Даже при наличии .NET Core с открытым исходным кодом, зависимость от инфраструктуры (NuGet, tooling, Visual Studio, лицензии) остаётся высокой.
Go — развивается под управлением Google, что тоже создаёт риски.Python — полностью открытый, развивается международным сообществом под управлением Python Software Foundation, зарегистрированной как некоммерческая организация. В нём нет корпоративного вендора, способного одномоментно ограничить использование или распространение.
Busla
13.11.2025 11:20Почему вы считаете, что только корпоративный вендор может ограничивать использование и распространение?
Andrei9385
13.11.2025 11:20Samba-DC: По умолчанию при инициализации домена используется база данных TDB.
- TDB: Максимальный размер составляет 4 ГБ, поскольку базы данных используют 32-разрядные структуры. Поэтому в крупной организации с 100 тысяч объектов и больше стоит сменить базу данных на LMDB.
- LMDB: Начиная с Samba 4.9, контроллер домена можно настроить для хранения своих данных в формате LMDB вместо формата TDB. Поскольку LMDB является настоящей 64-разрядной базой данных, максимальный размер ограничен только объемом памяти, доступной в системе.Я видел внедрения до 5000 пользователей и не видел проблем с производительностью.
Romain6G
13.11.2025 11:20LMDB действительно снимает ограничение по размеру базы, но не решает главные проблемы Samba — архитектурные.
Проект исторически создавался как реализация протоколов Windows NT в Linux-среде. Со временем в него “дописывали” поддержку AD, Kerberos и LDAP, но эти компоненты остались слабо связанными и разношерстными по архитектуре.
Репликация и обработка политик реализованы в однопоточном режиме, а кэширование и индексация данных крайне ограничены. На десятках тысяч объектов наблюдаются задержки репликации и рост времени отклика LDAP. Это подтверждается тестами крупных организаций и интеграторов.
mexxy
13.11.2025 11:20Samba — проект, глубоко осевший в эпохе Windows NT, чьи корни уходят во времена ранних версий Windows Server.
Samba 4.23 поддерживает SMB по протоколу QUICK. Это показывает, что проект SAMBA развивается и идет в ногу со временем.
NotMusk
13.11.2025 11:20У samba есть одна проблема из которой вытекают все остальные.
Главным функциональным заказчиком samba является французское правительство. За какие фичи оно заплатило, то в samba и запилят. У проекта samba сейчас нет цели полностью повторить технологии Microsoft. Есть цель обслужить один конкретный кейс, за который платят.
Отсюда и такая неоднородность и разброс. Что-то в samba до сих пор на уровне NT.
Поэтому, если вы что-то строите на samba, учитывайте, что это далеко не MS AD и готовьтесь самостоятельно лезть в код на C и дорабатывать под себя.
ВТБ со своим Эллис это попытался сделать (сейчас проект мертв)
aegoroff
Геораспределенную систему или систему работающую под большой нагрузкой в с таким подходом точно не построите, впрочем у вас питон, поэтому тут про нагрузки и говорить не приходится.
Orky
Не, ну да, постгрес, конечно, не подвергается нормальному геораспределению, лол.
aegoroff
Дело не только в постгресе - вы же не будете из Москвы делать запросы в Омск или наоборот. Коли приложение рассчитано на работу с реляционной БД, это всегда расчет на то, что база где-то рядом. Репликация данных должна быть на уровне приложения и тогда особого толку от использования РСУБД нет никакого, коли у каждого узла она будет своя.
aegoroff
Немного фигню написал - получается что вы геораспределение сняли со своего приложения, и хотите переложить на СУБД, - ну что же - немного странный подход
Romain6G
Геораспределённый кластер на PostgreSQL прекрасно строится с помощью Patroni со схемой master–replica.
Для удалённых филиалов можно использовать реплику в режиме read-only для аутентификации и авторизации, а master — для операций записи. Даже при обрыве связи с master филиал остаётся полностью работоспособен в локальных сценариях.
Что касается нагрузок и Python — здесь важно понимать масштаб.
Даже у крупнейших компаний в России количество активных пользователей не превышает сотен тысяч. Например, если взять инфраструктуру компании с численностью порядка 400 000 пользователей, — такая нагрузка без проблем обслуживается Python-сервисами при правильной архитектуре.
Python давно используется в высоконагруженных системах — от брокеров сообщений до крупных web-сервисов. Его легко масштабировать горизонтально: микросервисная архитектура, асинхронные фреймворки, балансировка через Nginx/Traefik, worker-пулы для фоновых задач и т.п.
aegoroff
Ну то есть получается что все это переложили на плечи СУБД, как вариант наверно можно, но сопровождение такой системы так себе занятие, особенно когда начинаются проблемы, и уж они точно не будут проще, чем вариант с честным AD
ildarz
А AD - мультимастер. И это не просто так.
То есть вы предлагаете реализовать крайне специфичный и редко используемый в реальности сценарий RODC, но игнорируете наиболее распространенный. Так себе замена.
Wundarshular
Но ведь при master-replica точка записи у вас только одна, а в остальных "местах" только чтение, и я не очень понимаю, как это решает проблему геораспределённости ваших пользователей. Изменения всё равно нужно сначала доставить на мастер, а потом докатить до ближайшей реплики. Те. какое-либо обновление будет довольно продолжительным. Вы исходите из предположения, что активная запись в БД происходит значительно реже чем массовое чтение?
Вообще, конечно, назвать решение multimaster, но использовать master-replica БД мне кажется хитрым маркетинговым ходом.
NotMusk
Правильно написали, географически распределенность и устойчивость к разделению. Условно, если у вас разоралась связь между филиалами, то контроллер в Новоосибе не сможет обслуживать пользователей, если его БД в Москве.
Да и гонять запросы между кд в Новосибе и бд в Москве через узкий канал между филиалами - такая себе идея, это очень большие потери пакетов = ошибки в бд и низкая производительность. Хотя у postgresql, в принципе, низкая производительность в задачах ldap (низкая частота записи, высокая чтения, и поиска)