Переход с Microsoft AD на FreeIPA: план миграции без сбоев

Что меняется при переходе с AD на FreeIPA

Active Directory обычно закрывает четыре задачи: единый вход (учетные записи и пароли), группы и права, Kerberos SSO для сервисов и централизованные политики для рабочих мест. При миграции с Microsoft AD на FreeIPA заранее зафиксируйте, что должно сохраниться без изменений: кто и куда входит, какие группы дают доступ, какие приложения завязаны на Kerberos и какие требования безопасности реально используются.

Главное отличие FreeIPA в том, что это в первую очередь Linux-ориентированная платформа идентификации и политик. Она особенно хорошо подходит там, где много Linux-серверов, SSH-доступов, sudo-прав, веб-сервисов и внутренних приложений. А привычные Windows-сценарии нередко требуют дополнительных решений или компромиссов.

Если не подготовиться, чаще всего ломаются:

• вход в сервисы, которые жестко ожидают AD-атрибуты или старый realm;
• доступ к файловым шарам и принтерам, если все было построено вокруг AD и SMB;
• SSO, когда сервисные учетные записи и SPN переносят без проверки;
• привычные политики на рабочих местах, потому что прямого аналога GPO один к одному нет.

Быстрый способ понять, подходит ли FreeIPA: где у вас больше критичных зависимостей - на Linux-инфраструктуре или на Windows-рабочих местах. Если ключевые системы (серверы приложений, базы, CI, веб) живут в Linux, FreeIPA обычно дает быстрый эффект. Если почти все держится на GPO и доменном входе Windows, в план придется заложить отдельную стратегию для политик и SMB.

Для пользователей изменения обычно сводятся к доменному имени (realm), окну входа в некоторые сервисы и возможной повторной смене пароля. Для поддержки появятся типовые обращения вроде «не работает SSO», «нет доступа по группе», «хост не присоединился», поэтому заранее подготовьте короткие инструкции и сценарии диагностики.

Сбор требований и инвентаризация текущего AD

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

Сначала зафиксируйте структуру: домены и лес (если их несколько), OU, ключевые группы и модель делегирования прав. Отдельно отметьте критичные учетные записи: администраторы, break-glass, сервисные аккаунты и все, что связано с автоматизацией (скрипты, планировщики, интеграции).

Дальше составьте список сервисов, которые используют AD-аутентификацию или группы. Обычно это файловые ресурсы и печать, почта, VPN, Wi-Fi (802.1X), прокси, корпоративные приложения, терминальные фермы, а также любые системы с LDAP или Kerberos. Хорошая практика - для каждого сервиса указать владельца, текущий способ входа и критерий успешной миграции.

Отдельно проверьте инфраструктурные зависимости: DNS, NTP и сертификаты. Kerberos ломается даже от нескольких минут рассинхрона, а «наследованный» DNS в AD часто вплетен в процессы так, что это обнаруживается только при переключении.

Заранее согласуйте требования безопасности: политика паролей и блокировок, срок действия учетных записей, аудит, обязательность MFA (если она есть), требования отрасли. В госсекторе, медицине и финансах обычно особенно важны журналы входов и контроль административных действий.

Удобный короткий опросник для фиксации требований:

• Какие домены, OU и группы реально участвуют в выдаче доступов?
• Какие сервисы используют LDAP, Kerberos или DNS, и какие учетные записи там настроены?
• Где хранятся и как выпускаются сертификаты (LDAPS, Wi-Fi, VPN, веб-приложения)?
• Какие требования к паролям, аудитам и MFA обязательны?
• Какое окно обслуживания допустимо и какой простой приемлем?

Результат этапа - список объектов и сервисов с приоритетами. Он обычно экономит дни на пилоте и сильно снижает риск «тихих» отказов после переключения.

Целевая схема FreeIPA: DNS, realm, репликация и доверия

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

Сколько серверов и где размещать

FreeIPA обычно ставят минимум в двух экземплярах, чтобы отказ одного узла не остановил вход пользователей и выдачу Kerberos-билетов. Размещать их лучше в разных стойках или на разных площадках, ближе к основным сегментам сети.

Практичная схема для большинства организаций:

• 2 сервера FreeIPA (основной + реплика) на одной площадке;
• 3 сервера, если есть филиалы и нужна более устойчивая работа при обрывах связи;
• отдельная тестовая среда (узел или VM), чтобы безопасно проверять изменения.

DNS лучше продумать сразу. Встроенный DNS FreeIPA удобен, когда вы хотите управлять зонами из одного места и быстро поднимать записи для сервисов. Внешняя DNS-инфраструктура подходит, если DNS уже жестко регламентирован или разделен между командами. Частая схема: внешний DNS остается главным, а FreeIPA получает отдельный поддомен и полностью управляет им.

Trust, имена и совместимость с AD

Если миграция идет поэтапно, может понадобиться доверие (trust) к AD, чтобы часть пользователей и сервисов продолжала работать на старом домене. Это помогает спокойнее пройти период, когда Windows-рабочие места еще не готовы к смене источника аутентификации.

План имен лучше зафиксировать документом до установки:

• realm (обычно в верхнем регистре) и DNS-домен (в нижнем);
• формат логина и UPN, чтобы не получить сюрпризы в почте и приложениях;
• правила для служебных учетных записей и SPN;
• соглашения по именам хостов и сервисов.

Не забудьте про время и резервные копии. Kerberos чувствителен к рассинхрону часов, поэтому настройте NTP на всех серверах и клиентах и проверьте допустимый дрейф. Заранее определите, как вы делаете бэкапы FreeIPA (включая ключи, сертификаты и DNS-зоны) и как быстро сможете восстановиться.

Подготовка данных: пользователи, группы и атрибуты

Перед переносом приведите данные в порядок. Если мигрировать «как есть», вы получите те же проблемы, только в новой системе: лишние учетные записи, непонятные группы и права, которые никто не контролирует.

Начните с уборки в AD. Обычно всплывают забытые учетные записи бывших сотрудников, тестовые логины, дубликаты и группы «на всякий случай». Чаще всего помогают простые правила: отключать неиспользуемые учетные записи (например, без входов 90-180 дней), удалять пустые группы без владельца, разбирать дубликаты и обязательно разметить сервисные аккаунты (где используются и кто владелец).

Дальше нужна нормализация атрибутов. В FreeIPA часто важны uid, mail, givenName/sn и понятное отображаемое имя. Типичная проблема: у части сотрудников в e-mail остался старый домен, а логины заведены в разных форматах (ivanov, i.ivanov, ivanov_i). Лучше решить это заранее и завести таблицу соответствий.

Отдельно проверьте админские права. Посмотрите, кто входит в привилегированные группы AD и где реально используются встроенные роли. Нередко выясняется, что «Domain Admin» выдавали ради доступа к файлам или принтеру, и это можно заменить более узкими правами.

Наконец, составьте план соответствия: OU из AD не переносятся один к одному, поэтому заранее решите, что станет группами, а что - правилами доступа (HBAC) и правами в FreeIPA. Для пилота выберите небольшую, но типичную выборку (например, 20-30 пользователей из разных отделов и 2-3 сервисные учетные записи), чтобы увидеть реальную картину.

Миграция пользователей и групп: что переносим и как

Самое важное - договориться, какие учетные записи действительно нужны. Обычно переносят сотрудников и подрядчиков, группы доступа и часть сервисных учеток. Компьютерные учетные записи из AD чаще не переносят один в один: Linux-хосты проще заново подключить к FreeIPA, а для Windows-рабочих мест заранее выбрать сценарий совместимости.

Что переносить

Минимальный набор:

• пользователи (логин, ФИО, почта, отдел, телефон, статус);
• группы (имена, назначение, владельцы, членство);
• сервисные учетные записи, которые реально используются и имеют владельца;
• правила по срокам действия и блокировкам (если применимо).

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

С группами и вложенностью лучше быть прагматичными. Вложенные группы иногда переносятся, но структуру часто стоит упростить: меньше уровней, понятные имена, отдельные группы «доступа» и «рассылок».

Проверка и план отката

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

План отката фиксируйте заранее: на время пилота держите AD доступным, не удаляйте объекты в AD и переключайте системы по очереди. Если что-то ломается, вы возвращаете конкретный сервис на вход через AD и разбираете проблему без остановки всей компании.

Kerberos в FreeIPA: SSO и сервисные учетные записи

Kerberos в FreeIPA отвечает за единый вход (SSO): пользователь один раз получает билет и дальше заходит на серверы и сервисы без повторного ввода пароля. Чтобы это стабильно работало после миграции, сначала проверьте базу: корректный realm, доступность KDC и синхронизацию времени на всех узлах. Даже разница в 5 минут способна сорвать вход.

Дальше определите, какие сервисы должны принимать Kerberos-аутентификацию. Для каждого такого сервиса создаются сервисные принципалы и ключи (обычно через keytab). Чаще всего это SSH-доступ к Linux, веб-приложения (HTTP) и файловые сервисы.

Типовые SSO-сценарии

В Linux пользователь получает билет (например, при входе в сессию), после чего SSH на другие хосты проходит по GSSAPI. Для веб-приложений обычно используют SPNEGO: браузер применяет Kerberos, и сервис видит пользователя без формы логина. На внутренних порталах это заметно снижает число обращений по сбросу паролей.

Keytab: хранение и ротация

Keytab - это фактически «пароль сервиса», поэтому обращайтесь с ним как с секретом. Храните keytab только на том сервере, где он нужен, не пересылайте его по почте и не кладите в общие сетевые папки. Ведите учет, где какие keytab используются, и планируйте ротацию. При подозрении на компрометацию ключи сервиса нужно перевыпустить.

Для диагностики полезна простая логика: если kinit не получает билет, сначала проверьте DNS (имя и обратная зона), затем время (ошибка clock skew), и только потом права и состояние учетной записи. Часто проблема не в Kerberos, а в неверном имени сервиса в принципале или в устаревшем keytab после перевыпуска ключей.

Политики и контроль доступа: аналоги привычных GPO

В AD многие привыкли к одному рычагу управления - GPO. В FreeIPA логика другая: вместо «одной большой политики» вы собираете правила из нескольких блоков. Это часто даже удобнее, потому что проще объяснить, почему доступ есть у одних и нет у других.

Чем заменить GPO

В FreeIPA управление доступом обычно строится на сочетании групп, хостов и правил:

• HBAC (Host-Based Access Control): кто может входить на какие серверы и по каким сервисам (например, SSH).
• Sudo rules: кто и на каких хостах может выполнять команды с повышенными правами.
• Host groups: объединение серверов по роли, чтобы применять правила пакетно.
• RBAC: делегирование админских функций без выдачи полного доступа к каталогу.

Пример: группа «Админы Linux» получает право входа только на хост-группу prod-linux через HBAC, а через sudo rules - возможность перезапускать сервисы, но без лишних полномочий. Такое правило получается точным и проверяемым.

Пароли, аудит и сертификаты

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

Аудит лучше включать сразу и договориться, кто его просматривает. Обычно контролируют изменения членства в привилегированных группах, выдачу и изменение прав sudo и HBAC, операции с ключевыми сервисными учетными записями, а также события выпуска и отзыва сертификатов.

Плюс FreeIPA - встроенный CA. Он может автоматически выпускать сертификаты для хостов и сервисов по правилам, что упрощает TLS внутри инфраструктуры и снижает число ошибок при продлении.

Интеграция с Linux: подключение хостов и единые права

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

Обычно достаточно настроить SSSD и выполнить join в realm. После этого сервер начинает проверять пользователей через FreeIPA, а кэш SSSD помогает пережить кратковременные проблемы со связью. Домашние каталоги можно создавать автоматически при первом входе или выдавать по сети (например, через automount), чтобы путь пользователя был одинаковым на разных серверах.

Единые группы и права

Права удобнее строить от групп: доступ к серверам, sudo и ограничения по хостам. HBAC помогает ответить на простой вопрос: кто имеет право входить на какой сервер и по какому сервису (SSH, консоль и т.д.).

Чтобы не запутаться, заранее договоритесь об именовании хостов, hostgroup и групп пользователей. Чем понятнее и единообразнее названия, тем меньше ошибок при поддержке.

Обслуживание и контроль после подключения

Добавьте регулярные задачи: обновления клиента (sssd, ipa-client), ротация keytab для сервисов и автоматизация (например, через Ansible), чтобы подключение и базовые настройки были повторяемыми.

После подключения каждого сервера проверьте вход тестового пользователя, получение групп, работу sudo по правилам (а не через локальный /etc/sudoers), применение HBAC, создание домашнего каталога и синхронизацию времени.

Совместимость с Windows-рабочими местами и SMB

Заранее решите, какие задачи Windows должны работать как раньше, а где допустимы изменения. FreeIPA отлично закрывает Linux и Kerberos, но Windows-доменные сценарии он не заменяет напрямую. Поэтому совместимость обычно строят как набор решений под конкретные кейсы.

Чаще всего без лишней боли удается поддержать доступ к файловым шарам по SMB, печать через сервер печати (если он не завязан на AD-логику), Wi-Fi по 802.1X через RADIUS (если FreeIPA хранит учетные записи), а также единую смену пароля при продуманной синхронизации или trust.

С SMB и файловыми шарами почти всегда нужна Samba. Если шары живут на Linux, Samba становится точкой, где сходятся права: с одной стороны учетные записи и группы из FreeIPA, с другой - Windows-клиенты. Важно не пытаться копировать ACL из AD «как есть», а заранее согласовать модель доступа: какие права задаются группами, кто владелец папок, как оформляются общие каталоги отделов. Тогда права будут предсказуемыми и для Windows, и для Linux.

Если нужен AD-совместимый вход на Windows (присоединение к домену, привычные доменные профили), обычно выбирают один из вариантов: оставить AD для рабочих мест и настроить trust с FreeIPA, либо сделать гибрид, где FreeIPA ведет Linux и сервисы, а AD остается центром для Windows. Вариант с отдельным Samba AD DC тоже встречается, но требует аккуратной поддержки и четких границ ответственности.

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

Пилот, тестирование и поэтапное переключение

Пилот нужен, чтобы проверить FreeIPA на живых задачах и не «уронить» всех сразу. Для проекта обычно достаточно небольшой, но показательной группы: 15-40 пользователей, несколько типовых ролей и хотя бы одно важное приложение.

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

План тестов держите коротким, но строгим:

• вход на рабочую станцию и на Linux-серверы, проверка блокировок;
• смена пароля и восстановление доступа при ошибках;
• доступ к ресурсам и приложениям по группам;
• SSO по Kerberos для ключевых сервисов, проверка сервисных учетных записей;
• работа при временной недоступности сети.

Заранее определите метрики успеха. Например: не более 3-5 инцидентов в неделю на пилоте, реакция первой линии до 15 минут, исправление критичных проблем в течение рабочего дня.

Переключение делайте поэтапно: либо по отделам, либо по сервисам. Если смешивать оба подхода одновременно, возрастает риск хаоса в правах и диагностике.

Подготовьте поддержку: в первые дни вопросов будет много, и большинство повторяется. В типовом наборе - проблемы входа (время, пароль, блокировки, кэш), доступ по группам, сбои SSO (ticket, SPN/сервисный принципал), задержки применения смены пароля (политика и репликация), а также ошибки «вне офиса» (настройки офлайн-логина и сроки кэша).

Если вы делаете проект с участием системного интегратора, полезно выделить отдельное окно эскалации на время пилота. У GSE.kz, например, есть системная интеграция и круглосуточная техническая поддержка, что помогает быстрее разбирать инциденты в период переключения.

Частые ошибки при миграции и как их избежать

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

Kerberos: время и DNS

Kerberos очень чувствителен к времени и DNS. Если часы на серверах FreeIPA, Linux-хостах и Windows-рабочих местах расходятся даже на несколько минут, SSO начинает сыпаться: появляются неожиданные запросы пароля, ошибки при доступе к шарам, отваливаются сервисы.

DNS дает похожие эффекты: неверные записи A/AAAA, SRV, PTR или порядок резолвинга (когда клиенты продолжают спрашивать старый AD DNS) приводят к тому, что машина «видит» не тот realm и не тот KDC.

Перед пилотом проверьте минимум: единый источник NTP, SRV-записи Kerberos и LDAP в зоне, корректные PTR для серверов FreeIPA и порядок DNS-серверов, который получат рабочие места. И обязательно протестируйте вход на 2-3 типовых сервисах, а не только в консоль.

Данные и права: перенос «как есть» почти всегда мстит

Если переносить каталог без чистки, вы тащите дубликаты, старые логины, группы «на всякий случай» и вложенности, которые никто уже не понимает. В итоге часть пользователей получает лишний доступ, а часть теряет нужный.

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

Не менее опасны организационные ошибки: смешанные роли администрирования, слишком широкие права и аудит, который не может ответить на вопрос «кто и зачем» менял правила.

И главное - отсутствие плана отката. Нужны назначенные ответственные, понятный сценарий возврата на AD (хотя бы временно) и готовая поддержка в день переключения. Если миграцию делаете вместе с подрядчиком, отдельно проговорите окно работ, критерии успешности и условия отката до начала пилота.

Короткий чеклист перед запуском и после переключения

Перед запуском

• Собран инвентарь: домены, OU, группы, сервисные учетные записи, зависимости приложений, список критичных серверов.
• Поднят тестовый контур FreeIPA с копией данных (пусть даже частичной) и согласованными критериями успеха.
• Согласованы окна работ и план отката: кто принимает решение и как быстро вернуть входы через AD.
• Зафиксированы правила именования и атрибутов (логины, UPN, e-mail), подготовлен список исключений.
• Определена политика паролей: как будет проходить сброс или принудительная смена, как уведомляются пользователи и владельцы сервисов.

Перед переключением проверьте DNS-записи, NTP-синхронизацию, Kerberos (выдачу тикетов), доступ к нужным ресурсам, keytab для сервисов и корректные SPN.

Сразу после переключения

Первые 24-72 часа важнее всего. Ловите проблемы по фактам:

• мониторьте входы (процент успешных логинов, типовые ошибки Kerberos, блокировки, задержки);
• ведите единый журнал инцидентов с владельцами и принятыми решениями;
• проверьте права на ключевых файловых ресурсах и приложениях (группы, sudo-правила, доступ к общим папкам);
• фиксируйте изменения и включите аудит;
• выводите старые контроллеры AD только после стабилизации и серии контрольных проверок.

Следующие шаги: план работ на 30-60 дней и поддержка

Миграцию на FreeIPA проще вести как проект с четким набором функций, которые обязаны заработать в день 1. Составьте короткий список сервисов, от которых зависит работа сотрудников, и закрепите владельцев, которые подтвердят тесты.

В день 1 обычно важно, чтобы предсказуемо работали вход в Linux по доменным учетным данным, смена пароля, базовые доступы (SSH, sudo, файловые шары, если они есть), SSO на ключевые внутренние веб-сервисы (если используете Kerberos), а также сервисные учетные записи для своих задач (джобы, бэкапы, мониторинг) и понятная процедура восстановления доступа через helpdesk.

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

Примерный план на 30-60 дней:

• Неделя 1-2: финальная инвентаризация, пилот, исправление атрибутов и групп.
• Неделя 2-3: перенос сервисных аккаунтов, ключей Kerberos, проверка SSO.
• Неделя 3-4: расширение пилота, подготовка инструкций и автоматизации подключения.
• Неделя 4-6: поэтапное подключение подразделений, контроль инцидентов.
• Неделя 6-8: чистка, аудит прав, финальная документация.

Отдельно запланируйте инфраструктуру: минимум два узла FreeIPA, резервное копирование, мониторинг и регулярную проверку восстановления. Если нужна помощь с проектированием и внедрением, GSE.kz (gse.kz) может закрыть системную интеграцию и поддержку, а при необходимости - поставить серверную инфраструктуру под ваши задачи.