Замена Microsoft Active Directory 2026: ALD Pro, FreeIPA, Samba DC — сравнение
Гайд для CIO: переход с Microsoft Active Directory на отечественные службы каталогов. Сравнение ALD Pro, FreeIPA, Samba DC. Миграция групповых политик, бюджет, сроки.
Microsoft Active Directory в России до 2022 года — фундамент корпоративной ИТ-инфраструктуры в 95%+ компаний размером 500+ человек. Аутентификация пользователей, групповая политика, управление АРМ, доступ к файловым серверам, к Exchange, к SharePoint — всё держалось на AD. С 2022 года продление лицензий Windows Server (на котором работают контроллеры AD) ограничено, а с 1 января 2025 года использование Windows Server на значимых объектах КИИ запрещено указом Президента №166. Параллельно работодатели массово переводят парк АРМ с Windows на Astra Linux и РЕД ОС — что делает AD не только лицензионно проблемным, но и функционально неполным (групповые политики Windows не работают для Linux-АРМ).
Эта статья — для CIO и архитектора инфраструктуры, ведущих программу миграции с Microsoft AD. Внутри: сравнение трёх ключевых альтернатив (ALD Pro, FreeIPA, Samba DC), методология миграции групповых политик, сценарии адаптации приложений-клиентов, реалистичные сроки и бюджеты, типовые ошибки.
Три альтернативы Microsoft AD на 2026 год
В реестре Минцифры около десятка продуктов класса «служба каталогов и аутентификации». Реальный выбор для замены Microsoft AD сводится к трём.
ALD Pro (Astra Group). Коммерческий продукт, разработан с 2021 года как прямая замена Microsoft AD. Сертифицирован ФСТЭК, в реестре Минцифры. Архитектура совместима с AD на уровне Kerberos и LDAP, есть собственный механизм групповых политик для Astra Linux-АРМ, встроенный DNS, репликация между контроллерами, веб-консоль администрирования, делегирование прав, аудит. Главный выбор для среднего и крупного российского бизнеса в 2026 году — почти все крупные программы импортозамещения AD идут на ALD Pro.
FreeIPA (Red Hat). Open-source проект Red Hat, основан на 389 Directory Server и MIT Kerberos. Зрелый, стабильный, активно развивается с 2011 года. Хорошо работает в Linux-окружении, есть веб-интерфейс администрирования, поддерживает Kerberos-trusts с AD для смешанных сред. Главные ограничения: 1) GPO для Windows-АРМ не поддерживаются (для Linux-АРМ свой механизм). 2) Нет официального вендора с поддержкой в России — компании используют сообщество или собственные команды. 3) Не в реестре Минцифры. Подходит для технологических компаний с большим Linux-парком и собственной командой Linux-инженеров.
Samba DC. Open-source реализация AD-протокола на стороне Linux. Сохраняет максимальную совместимость с AD: групповые политики работают для Windows-АРМ почти как нативные, репликация совместима с AD на уровне протокола. Главные ограничения: 1) Меньше зрелости в части корпоративного администрирования — большая часть управления через командную строку. 2) Нет официального вендора с поддержкой и SLA. 3) Не в реестре Минцифры. Подходит для гибридных Windows + Linux-парков, где нужно сохранить совместимость с GPO и нет ресурсов на ALD Pro.
Сравнительная таблица:
| Критерий | ALD Pro | FreeIPA | Samba DC |
|---|---|---|---|
| Реестр Минцифры | Да | Нет | Нет |
| Сертификация ФСТЭК | Да | Нет | Нет |
| Коммерческая поддержка | Astra Group | Сообщество / Red Hat | Сообщество |
| GPO для Linux-АРМ | Свой механизм | Свой механизм | Нет нативной поддержки |
| GPO для Windows-АРМ | Через шаблоны | Ограниченно | Да (близко к AD) |
| Kerberos / LDAP | Полная | Полная | Полная |
| Веб-консоль | Да | Да | Нет (CLI) |
| Подходит для | Корпорации, госсектор | Технологические компании | Гибридные среды |
| Лицензия | Per-user / per-server | Free | Free |
| Зрелость экосистемы подрядчиков | Высокая | Средняя | Средняя |
Дальше в статье основной фокус — ALD Pro, как лидер рынка. По FreeIPA и Samba DC методология миграции аналогична, отличия — в инструментах и в наличии вендорской поддержки.
Что в Active Directory приходится замещать
Чтобы понимать объём миграции, разделим AD на функциональные компоненты:
1. Каталог пользователей и групп (LDAP-уровень). Учётные записи, группы безопасности, OU-структура, атрибуты пользователей. Это самая простая часть миграции — экспорт и импорт. Все три альтернативы поддерживают.
2. Аутентификация Kerberos. Тикеты, билеты на сервисы, SPN-имена. Стандартный протокол, работает в любой Kerberos-инфраструктуре. ALD Pro, FreeIPA, Samba DC — все поддерживают.
3. DNS-инфраструктура. AD-зоны DNS, SRV-записи для нахождения контроллеров и сервисов. ALD Pro и FreeIPA имеют встроенный DNS. Samba DC — внешний BIND. Миграция — отдельный мини-проект.
4. Групповые политики (GPO). Самая сложная часть. Microsoft GPO — собственная технология, не поддерживается в Linux-решениях напрямую. ALD Pro реализует аналогичный механизм для Astra Linux-АРМ. Для Windows-АРМ в смешанной среде нужны альтернативные подходы.
5. Доверительные отношения между доменами. Cross-realm trusts в Kerberos поддерживаются всеми решениями, но настройка отличается. Для лесов с 3+ доменов проектирование trust-структуры — отдельная работа.
6. Интеграция с приложениями. 30-60% корпоративных приложений завязаны на AD-аутентификацию через Kerberos, LDAP, NTLM или собственные интеграции. Каждое приложение требует адаптации.
7. PKI и сертификаты. AD Certificate Services (AD CS) — внутренний центр сертификации для S/MIME, SSL, аутентификации по смарт-картам. Замещается на КриптоПро УЦ, Trusted PKI, либо открытые решения (EJBCA, smallstep CA).
Миграция групповых политик: что переносится, что переписывается
Это центральная задача миграции AD. У большой компании накапливается 50-200 GPO, охватывающих настройки безопасности, развёртывание ПО, мапирование сетевых дисков, ограничения АРМ, конфигурацию приложений.
Аудит GPO на этапе предпроектного обследования разделяет их на четыре категории.
Категория 1: устаревшие и неиспользуемые GPO (20-40%). Накопились за 10+ лет, давно не применяются, но политики действующие. Выбрасываются.
Категория 2: базовые настройки безопасности и доступа (20-30%). Минимальная длина пароля, блокировка после неудачных попыток, разрешения на сетевые ресурсы, время сессии. Переносятся в ALD Pro / FreeIPA с минимальной адаптацией.
Категория 3: специфические настройки приложений (30-40%). Параметры Office, настройки браузера, конфигурация бизнес-приложений. Часть из них не нужна в новой среде (Astra Linux вместо Windows, МойОфис вместо Office). Оставшиеся переписываются под целевую ОС — обычно через Ansible-плейбуки, MDM или собственный механизм политик ALD Pro.
Категория 4: развёртывание ПО (10-20%). GPO Software Installation — установка MSI-пакетов. В Linux-среде заменяется на пакетные менеджеры (apt, yum) с централизованными репозиториями или на MDM-решения (Astra Manager, FreeIPA с расширениями).
Реалистичный коэффициент переноса — 60-80% политик мигрируют в новый механизм, 20-30% становятся не нужны, 10-15% переписываются на другие инструменты управления (Ansible, конфигурационные шаблоны).
Адаптация приложений-клиентов
В корпоративной среде 30-60% приложений используют AD-аутентификацию. План адаптации составляется на этапе предпроектного обследования.
Сценарий A: LDAP-аутентификация. Большинство современных приложений (1С, СЭД, корпоративные порталы) работают с любым LDAP-совместимым каталогом. Адаптация — изменение строки подключения и базы поиска. Тестирование, минимальные изменения.
Сценарий B: Kerberos-аутентификация (single sign-on). Приложения, использующие Kerberos для SSO (например, веб-приложения через SPNEGO), работают с любой Kerberos-инфраструктурой. Адаптация — настройка SPN, выпуск keytab-файлов, обновление конфигурации.
Сценарий C: NTLM или Windows Authentication. Приложения, использующие NTLM или Integrated Windows Authentication, требуют переход на Kerberos или SAML/OIDC. Доработка приложения или внедрение федеративного провайдера (Keycloak, Blitz Identity Provider).
Сценарий D: Прямой API AD (ADSI, расширение схемы). Самый сложный сценарий — приложения, которые используют специфический API AD (например, для расширения схемы каталога). Переписывание под API целевого каталога или замена приложения.
Сценарий E: Аутентификация через Federation (SAML, OIDC). Современный подход — поверх каталога стоит федеративный провайдер (Keycloak, Blitz Identity Provider), который проксирует аутентификацию. При смене каталога меняется только источник для провайдера, приложения не трогаются. Это лучшая стратегия для долгосрочной устойчивости — рекомендуется внедрять параллельно миграции AD.
Сценарий смешанной инфраструктуры AD + ALD Pro
Полный одномоментный переключение в большой организации редко возможен. Стандартный сценарий — параллельная работа AD и ALD Pro в течение 6-18 месяцев.
Архитектурные варианты:
Вариант 1: Cross-realm Kerberos trust. ALD Pro доверяет AD и наоборот. Пользователи одного домена получают доступ к ресурсам другого через стандартный Kerberos. Простая настройка, проверенная архитектура.
Вариант 2: Параллельные каталоги с синхронизацией. Учётные записи синхронизируются между AD и ALD Pro через скрипты или специализированные продукты. Каждый пользователь существует в обоих каталогах. Сложнее в управлении, но гибче в переходный период.
Вариант 3: Federation через SAML/OIDC. Над AD и ALD Pro стоит федеративный провайдер (Keycloak). Пользователи входят в приложения через провайдер, который сам решает, куда обращаться за аутентификацией. Гибкая архитектура, но требует внедрения провайдера.
В большинстве крупных программ используется комбинация вариантов 1 и 3: cross-realm trust для типовых сценариев и Keycloak для критичных веб-приложений.
Сроки и бюджет миграции AD
Реалистичные диапазоны для российских компаний на 2026 год.
| Размер компании | Размер инфраструктуры AD | Срок | Бюджет |
|---|---|---|---|
| 500-1500 чел. | 1 домен, базовые GPO | 4-7 мес | 3-8 млн ₽ |
| 1500-5000 чел. | Лес из 2-3 доменов, активные GPO | 7-12 мес | 8-20 млн ₽ |
| 5000+ чел. | Многодоменный лес, сложные GPO, trusts | 12-18 мес | 20-50 млн ₽ |
Структура бюджета:
- Лицензии ALD Pro (per-user или per-server) — 25-35%
- Проектирование архитектуры и Предпроектное обследование — 10-15%
- Миграция учётных записей и групп — 10-15%
- Миграция групповых политик — 20-30%
- Адаптация приложений под новый каталог — 10-15%
- Обучение администраторов — 5-10%
Этапы программы миграции
Этап 1: Аудит и проектирование (4-6 недель). Инвентаризация леса AD, аудит GPO, реестр приложений с AD-интеграцией, проектирование целевой архитектуры. Артефакт — миграционный план с roadmap.
Этап 2: Пилотное внедрение (2-3 месяца). Развёртывание ALD Pro в тестовом контуре, миграция 50-100 пилотных пользователей, тестирование критичных приложений, отработка процедур восстановления.
Этап 3: Миграция учётных записей и групп (1-2 месяца). Экспорт-импорт каталога, синхронизация пользовательских атрибутов, миграция групп.
Этап 4: Миграция групповых политик (2-4 месяца). Параллельно с этапом 3. Аудит, перенос, тестирование на пилотных АРМ.
Этап 5: Параллельная работа AD и ALD Pro (1-2 месяца). Большинство пользователей перешли в ALD Pro, AD остаётся для специфических кейсов и legacy-приложений.
Этап 6: переключение и сопровождение (1-2 месяца). Отключение AD, SLA-сопровождение на 3-6 месяцев.
Типовые ошибки
Ошибка 1: Недооценка GPO-портфеля. В план включают только миграцию пользователей и групп, GPO — «потом». Реальный объём — 20-30% бюджета. Без аудита и проектирования миграции GPO программа удваивается.
Ошибка 2: Игнорирование приложений-клиентов. Реестр приложений с AD-интеграцией не составляется. На переключение несколько критичных бизнес-приложений перестают работать. Предпроектное обследование должно включать реестр всех приложений.
Ошибка 3: Big-bang переключение. Попытка перейти в одну ночь. На крупной компании это всегда заканчивается частичным откатом. Параллельная работа AD и ALD Pro на 2-6 месяцев — стандарт.
Ошибка 4: Отсутствие плана по Windows-АРМ. Программа миграции AD идёт параллельно с миграцией парка на Astra Linux. Если эти программы не синхронизированы, получается, что Windows-АРМ остаются с GPO от AD, а Astra-АРМ работают с ALD Pro — фактически две параллельные инфраструктуры.
Ошибка 5: Игнорирование PKI и AD CS. AD Certificate Services отвечает за внутренние сертификаты (S/MIME, SSL, смарт-карты). При миграции эта функция должна быть замещена (КриптоПро УЦ, EJBCA), иначе ломаются почта, корпоративные порталы, аутентификация по сертификатам.
Смежные программы импортозамещения — см. реестр Минцифры 2026, миграция с Oracle на Postgres Pro, план импортозамещения 2026-2028.
FAQ о замена Active Directory
Что выбрать для замены Active Directory: ALD Pro, FreeIPA или Samba DC?
ALD Pro — коммерческий продукт Astra Group, разработан как прямая замена Microsoft AD с фокусом на корпоративное использование. Сертифицирован ФСТЭК, в реестре Минцифры. Поддерживает все ключевые сценарии AD: Kerberos, LDAP, групповые политики (через собственный механизм), DNS-интеграция, репликация между контроллерами. Главный выбор для среднего и крупного бизнеса. FreeIPA — open-source решение Red Hat, зрелое и стабильное, хорошо работает в Linux-окружении, но требует команды Linux-инженеров и не имеет прямого аналога групповых политик AD. Хорошо подходит для технологических компаний с Linux-парком. Samba DC — open-source реализация AD на стороне Linux. Совместимость с AD выше, чем у FreeIPA, групповые политики поддерживаются почти как в AD. Подходит для смешанных Windows + Linux парков. На 2026 год выбор большинства корпоративных программ — ALD Pro, для технологических компаний — FreeIPA, для гибридных парков — Samba DC.
Можно ли мигрировать с Microsoft AD без потери групповых политик?
Это самый сложный вопрос миграции AD. Microsoft GPO — собственная технология, не поддерживается напрямую в Linux-решениях. ALD Pro реализует аналогичный механизм через собственную систему политик, которая применяется к АРМ на Astra Linux. При этом политики для Windows-АРМ в ALD Pro не работают — Windows-клиенты остаются на AD или используют альтернативные механизмы (MDM, Group Policy через локальные шаблоны). FreeIPA имеет ограниченную поддержку GPO через расширения. Samba DC сохраняет совместимость с GPO, но требует тщательной настройки. На практике в смешанных средах GPO разбиваются на: 1) Базовые настройки безопасности и доступа — переносятся в новую систему. 2) Специфические настройки приложений — переписываются под целевую ОС (Astra Linux). 3) Устаревшие политики — выбрасываются (обычно 20-40% корпоративных GPO не используются). Полный паритет один-в-один невозможен, но 70-85% функционала переносится.
Сколько занимает миграция с Microsoft AD?
Срок зависит от размера инфраструктуры, количества доменов и контроллеров, а также от глубины использования GPO. Реалистичные сроки на 2026 год: компания 500-1500 человек, один домен, базовые GPO — 4-7 месяцев. Компания 1500-5000 человек, лес из 2-3 доменов, активное использование GPO — 7-12 месяцев. Компания 5000+ человек, многодоменный лес, сложные GPO, доверительные отношения с другими доменами — 12-18 месяцев. Этапы: аудит и проектирование (4-6 недель), пилотное внедрение на тестовом контуре (2-3 месяца), миграция учётных записей и групп (1-2 месяца), миграция групповых политик (2-4 месяца), параллельное использование AD и нового каталога (1-2 месяца), переключение и сопровождение (1-2 месяца).
Сколько стоит миграция Microsoft AD?
Реалистичные диапазоны на 2026 год: компания 500-1500 человек, один домен — 3-8 млн рублей. Компания 1500-5000 человек, средний лес — 8-20 млн рублей. Компания 5000+ человек, многодоменный лес — 20-50 млн рублей. Структура бюджета: лицензии ALD Pro или коммерческой поддержки FreeIPA — 25-35% (модель per-user или per-server); проектирование архитектуры — 10-15%; миграция учётных записей и групп — 10-15%; миграция групповых политик — 20-30%; адаптация приложений под новый каталог — 10-15%; обучение администраторов — 5-10%. Бюджет в значительной степени определяется глубиной использования GPO — если их сотни и они активно используются, стоимость удваивается.
Что делать с приложениями, которые жёстко связаны с AD?
В корпоративной среде 30-60% приложений используют AD-аутентификацию через Kerberos или LDAP. Подходы к адаптации: 1) Приложения с LDAP-аутентификацией — обычно работают с любым LDAP-совместимым каталогом без изменений. ALD Pro и FreeIPA — стандартные LDAP-каталоги. 2) Приложения с Kerberos-аутентификацией — работают с любой Kerberos-инфраструктурой, нужна корректная настройка SPN и keytab-файлов. 3) Приложения с интеграцией через WinAuth / NTLM — требуют доработки. Для большинства приложений можно настроить SAML или OIDC-провайдера поверх каталога (Keycloak, Blitz Identity Provider). 4) Приложения с прямым использованием API AD (например, для расширения схемы) — переписывание под API целевого каталога. На этапе предпроектного обследования составляется реестр всех приложений с AD-интеграцией с планом адаптации для каждого. Это критическая работа — без неё миграция остаётся технически возможной, но бизнес-приложения перестают работать.
Какая роль DNS в миграции AD?
AD-инфраструктура жёстко связана с DNS — контроллеры регистрируются в DNS, приложения находят сервисы через SRV-записи. При миграции DNS должна сопровождать переход: 1) Существующая AD-зона DNS либо мигрируется в новый каталог (ALD Pro имеет встроенный DNS, FreeIPA тоже), либо остаётся на отдельном DNS-сервере (BIND, PowerDNS, KeaDHCP). 2) Параллельно с AD и новым каталогом DNS обслуживает обе зоны — клиенты находят и старые, и новые сервисы. 3) При полном переключение DNS переключается на обслуживание только новой инфраструктуры. На практике DNS — отдельный мини-проект внутри миграции AD, занимает 2-4 недели для типовой компании.
Можно ли построить смешанную инфраструктуру AD + ALD Pro?
Да, это реалистичный сценарий на переходный период 6-18 месяцев. Архитектурные варианты: 1) Доверительные отношения между AD и ALD Pro через Kerberos cross-realm trust — пользователи одного домена получают доступ к ресурсам другого. 2) Параллельные каталоги с синхронизацией учётных записей через скрипты или продукты (Avanpost, Indeed, или собственные интеграции). 3) Federation через SAML/OIDC — пользователи AD аутентифицируются на сервисах ALD Pro через федерацию. Большинство крупных программ используют комбинацию: на 6-12 месяцев параллельная работа с синхронизацией, постепенный перенос приложений и пользователей в ALD Pro, после чего AD выводится из эксплуатации. Полный одномоментный переключение в больших организациях редко работает.