MARKET: DOMAIN SERVICES — SAMBA ACTIVE DIRECTORY DC И FREEIPA Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство по установке и выбору Domain Services Последнее обновление: 09.09.2026 СТАТУС КОМПОНЕНТА Domain Services — отдельный Market-модуль. Он не входит в Control Center Core и устанавливается только при необходимости. ЧТО МЫ НАСТРОИМ Инструкция помогает выбрать между Samba Active Directory Domain Controller и FreeIPA, подготовить DNS/NTP, установить соответствующий вариант модуля, выполнить первичную проверку и подготовить backup/HA. ВЫБОР ВАРИАНТА Критерий | Samba AD DC | FreeIPA Основной сценарий | Active Directory-совместимый домен, особенно Windows-среда | Централизованная identity для Linux/Unix-среды Ключевые технологии | AD-compatible LDAP/Kerberos/DNS и связанные доменные функции | LDAP/Kerberos/host identity и Linux-centric policy Windows domain join | Основной сценарий | Не следует считать полной заменой AD-домена без отдельной интеграционной архитектуры Linux identity | Возможна в AD-сценарии | Основной сценарий Выбор | Когда нужен AD-compatible domain | Когда нужен Linux/Unix identity domain Не устанавливайте Samba AD DC и FreeIPA в один и тот же DNS/realm namespace без заранее спроектированной и официально поддерживаемой интеграции. ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ Требование | Значение Market | Доступен и Healthy FQDN | Стабильное имя каждого domain node DNS | Продуман authoritative/forwarding design NTP | Время синхронизировано на серверах и клиентах IP | Стабильный адрес или reservation Ports | [ТРЕБУЕТ УТОЧНЕНИЯ: официальный список по варианту] Backup | Настроен до ввода пользователей/объектов Capacity | Проверен Capacity Planner Права | Module + Domain administration АРХИТЕКТУРА Вариант A: Clients → DNS/Kerberos/LDAP → Samba AD DC role → directory data Вариант B: Linux/Unix hosts → DNS/Kerberos/LDAP → FreeIPA role → identity/policy data Domain Services зависят от корректных DNS и времени. Ошибки DNS/NTP часто выглядят как ошибки аутентификации. ПЕРЕД НАЧАЛОМ 1. Выберите один вариант на основании сценария, а не знакомства с названием. 2. Зафиксируйте domain/realm naming policy. 3. Проверьте, не существует ли уже домен/realm с тем же именем. 4. Подготовьте DNS delegation/authoritative plan. 5. Убедитесь, что FQDN каждого server node разрешается правильно. 6. Проверьте NTP. 7. Создайте backup Control Center перед установкой stateful domain role. Linux-проверки: ```bash hostnamectl getent hosts timedatectl status ``` Ожидаемый результат: Имя однозначно разрешается, время синхронизировано. Шаг 1. Установка Market-модуля Установите Domain Services через Market по документу 14. Проверьте: - signature; - compatibility; - permissions; - capacity; - network requirements. Не устанавливайте системные пакеты Samba/FreeIPA вручную в обход module lifecycle, если роль управляется Control Center. Шаг 2. Выбор Samba AD DC или FreeIPA На экране конфигурации [Уточнить название элемента интерфейса] выберите один backend/variant. До подтверждения проверьте: - domain DNS name: ; - realm: ; - server FQDN: ; - site/network scope; - DNS integration mode; - backup target; - placement. [ТРЕБУЕТ УТОЧНЕНИЯ: точные поля wizard]. РАЗДЕЛ A. SAMBA ACTIVE DIRECTORY DC Шаг A1. Планирование домена Определите: - DNS domain: ; - realm: ; - NetBIOS/short name, если используется: ; - первый DC FQDN: ; - DNS forwarding/upstream policy. Не используйте имя, конфликтующее с существующей DNS-зоной, без ясного authoritative design. Шаг A2. Создание AD domain role 1. Выберите Samba AD DC. 2. Укажите подтвержденные domain parameters. 3. Укажите placement. 4. Проверьте DNS/NTP preflight. 5. Просмотрите permissions/network impact. 6. Создайте Change. 7. Дождитесь Job. 8. Проверьте Module Health. [ТРЕБУЕТ УТОЧНЕНИЯ: exact provisioning fields, password/bootstrap flow и DNS modes]. Ожидаемый результат: Создан управляемый AD-compatible domain controller, его directory/DNS/Kerberos функции Healthy в терминах модуля. Шаг A3. Проверка клиента До массового domain join используйте один тестовый endpoint. Проверьте на клиенте: - DNS указывает на подходящую доменную DNS-службу согласно архитектуре; - время синхронизировано; - SRV/service discovery работает [ТРЕБУЕТ УТОЧНЕНИЯ: рекомендуемые команды для поддерживаемых Windows/Linux клиентов]; - тестовый join выполняется штатным способом ОС/Control Center. Не переводите весь парк на новый домен до успешного pilot. Шаг A4. Добавление дополнительного DC Для production domain services рекомендуется отказоустойчивая модель, если она поддерживается текущей версией модуля. 1. Подготовьте второй Healthy node. 2. Проверьте DNS/NTP/connectivity. 3. Добавьте дополнительную DC role через module lifecycle. 4. Дождитесь directory/DNS replication. 5. Проверьте Health. 6. Проведите controlled failover test. [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживаемое число DC, replication monitoring и role placement rules]. РАЗДЕЛ B. FREEIPA Шаг B1. Планирование realm Определите: - DNS domain: ; - Kerberos realm: ; - first server FQDN: ; - DNS integration mode; - managed host scope. FreeIPA следует выбирать как Linux/Unix identity platform, а не как скрытую попытку получить полный Windows AD domain без оценки различий. Шаг B2. Создание FreeIPA role 1. Выберите FreeIPA. 2. Укажите domain/realm. 3. Укажите placement. 4. Проверьте DNS/NTP. 5. Просмотрите network/permission impact. 6. Создайте Change. 7. Дождитесь Job. 8. Проверьте Health. [ТРЕБУЕТ УТОЧНЕНИЯ: exact provisioning fields/bootstrap credential/DNS modes]. Шаг B3. Подключение тестового Linux host До массового enrollment: 1. выберите тестовый host; 2. проверьте DNS и NTP; 3. выполните поддерживаемую module/OS enrollment procedure [ТРЕБУЕТ УТОЧНЕНИЯ]; 4. проверьте user identity/authentication; 5. проверьте host policy, если используется; 6. только после pilot расширяйте rollout. Шаг B4. Дополнительная replica 1. Подготовьте второй Healthy node. 2. Проверьте capacity/DNS/NTP. 3. Добавьте replica через поддерживаемую процедуру. 4. Дождитесь replication Healthy. 5. Проведите controlled failure test. [ТРЕБУЕТ УТОЧНЕНИЯ: replica topology/limits/failover]. DNS ПРЕДУПРЕЖДЕНИЕ: изменение DNS для Domain Services может повлиять на всю инфраструктуру. Что изменится: Клиенты будут использовать domain-specific DNS records для обнаружения authentication/directory services. Риск: Неверная delegation/forwarder configuration может нарушить как доменный, так и обычный DNS. Проверка: ```bash getent hosts ``` Для SRV/authoritative диагностики используйте поддерживаемые DNS-инструменты организации; точная команда зависит от наличия `dig`/`nslookup` и клиентской ОС. Rollback: Верните предыдущую DNS delegation/client DNS policy. Не удаляйте domain data только ради отката DNS. NTP Если часы расходятся, Kerberos-аутентификация может перестать работать. Все domain servers и clients должны иметь согласованный источник времени согласно организационной политике. ```bash timedatectl status ``` BACKUP И RESTORE Directory data являются stateful и критичными. 1. Используйте module-aware backup, а не произвольное копирование внутренних файлов. 2. Проверяйте restore в изолированной среде. 3. Учитывайте согласование нескольких replicas/DC. 4. Не восстанавливайте stale copy отдельного DC/replica поверх живого domain без официальной recovery procedure. [ТРЕБУЕТ УТОЧНЕНИЯ: Samba/FreeIPA module backup/restore semantics]. УДАЛЕНИЕ DOMAIN ROLE Перед removal: - проверьте, что роль не последняя; - перенесите/реплицируйте directory/DNS data; - проверьте clients/DNS dependencies; - выполните backup; - используйте штатный demotion/removal flow. ПРЕДУПРЕЖДЕНИЕ: простое удаление VM/узла не является корректным demotion domain controller/replica. ПРОВЕРКА - [ ] выбран правильный backend; - [ ] domain/realm naming зафиксирован; - [ ] DNS исправен; - [ ] NTP synchronized; - [ ] первый domain node Healthy; - [ ] test client успешно подключен; - [ ] массовый rollout не начат до pilot; - [ ] backup создан и restore протестирован; - [ ] для production предусмотрена replica/DC redundancy, если поддерживается; - [ ] Audit фиксирует domain lifecycle. ТИПОВЫЕ ОШИБКИ Симптом | Возможная причина | Проверка | Решение Domain login не работает | DNS/NTP неверны | resolution/time | восстановить DNS/NTP до изменения identity data Client не находит domain | SRV/DNS delegation | DNS diagnostics | исправить authoritative/forwarding design Replica не синхронизируется | сеть/время/version/data issue | Module Health | устранить причину; не форсировать stale restore Удален последний DC/replica | неверный decommission | topology/backup | disaster recovery по подтвержденному backup Windows-сценарий выбран на FreeIPA без проекта интеграции | неверный выбор платформы | requirements | использовать Samba AD DC либо спроектировать поддерживаемую интеграцию РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - выбирайте платформу по типу identity ecosystem; - проектируйте DNS и NTP до domain provisioning; - используйте минимум два domain nodes/replicas, когда модуль и требования это поддерживают; - храните backup отдельно и тестируйте restore; - domain role changes выполняйте по одному; - сначала pilot, потом массовый join/enrollment; - не используйте один и тот же namespace для конкурирующих directory systems без официальной архитектуры. ИТОГ Samba AD DC и FreeIPA являются альтернативными направлениями Domain Services для разных сценариев. Корректная установка начинается с выбора identity model, DNS/NTP design и pilot; stateful domain roles управляются через Market lifecycle, replication, backup и контролируемый decommission. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - точные supported Samba/FreeIPA versions; - wizard fields; - ports; - DNS integration modes; - password/bootstrap flows; - client join/enrollment procedures; - replica/DC topology; - backup/restore; - demotion/removal semantics; - support matrix Windows/Linux clients.