Samba 4.15 и AES-256 Kerberos: тестируем AD DC на Linux как альтернативу Windows Server

Вопрос про альтернативы Active Directory мы слышим чаще, чем раньше. Не потому что Windows Server вдруг стал плохим - а потому что клиенты начинают считать лицензии и смотреть на матрицу зарубежного стека целиком. Samba AD DC в этом контексте всплывает регулярно: «а вот говорят, она уже нормальная». Мы решили проверить на 4.15, вышедшей в конце 2021 года, а не рассказывать по памяти про 4.x образца 2018-го.

Что изменилось в 4.15

Ключевое в этом релизе - доработка Kerberos. Samba 4.15 добавляет полноценную поддержку AES-256-CTS-HMAC-SHA1-96 (entype 18) на уровне KDC. До этого AES-шифрование в Samba было, но с ограничениями: ряд клиентов, особенно на Windows 10 21H2 и новее с включёнными политиками усиленного Kerberos, мог получать неожиданные ошибки при аутентификации. В 4.15 это выровняли.

Второе заметное: samba-tool наконец получил нормальный интерфейс для управления GPO - не весь функционал GPMC, но базовые операции (создание, линковка, редактирование атрибутов) теперь через CLI без плясок с Python-скриптами. Для скриптованного управления небольшим доменом это снижает порог вхождения.

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

Что мы подняли

Тестовый стенд: два виртуальных сервера на AlmaLinux 8.5, один - DC, второй - дополнительный DC. Samba 4.15.3 из официального репозитория Samba Team для el8. Домен тестовый, но конфигурация приближена к реальной: DNS на самой Samba (не bind), sysvol на обоих DC, несколько Windows 10 21H2 в качестве членов домена.

Установка и поднятие домена занимает около получаса, если делать по документации и не пропускать шаги. Где можно было споткнуться - и мы споткнулись - это настройка NTP: если ntpd или chronyd запущены до того, как Samba настроена как источник времени для домена, получаешь конфликт, который не всегда очевиден в логах. Решается порядком запуска служб, но лучше знать заранее.

# Проверка уровня функциональности домена после поднятия
samba-tool domain level show

# Проверка доступных encryption types для Kerberos
samba-tool domain exportkeytab /tmp/test.keytab --principal=host/dc1.test.local
klist -e -k /tmp/test.keytab

После поднятия второго DC - репликация через samba-tool drs replicate работает без сюрпризов. Синхронизация sysvol через rsync+cron (стандартный способ для Samba AD DC, не DFS-R) настраивается за 15 минут.

Где работает без оговорок

Для небольшой инфраструктуры - 50-100 пользователей, несколько сотен рабочих станций на Windows и Linux - Samba AD DC в 4.15 закрывает базовый набор:

• Аутентификация Windows-клиентов. Вход в домен, Kerberos-тикеты, NTLM-fallback - всё ожидаемо работает с Windows 10 21H2.
• Групповые политики. Базовые GPO применяются: настройки реестра, скрипты, параметры безопасности. Не все ADMX-шаблоны одинаково хорошо парсятся инструментами на Linux, но через стандартный GPMC с Windows-машины - нормально.
• DNS-интеграция. Встроенный DNS Samba справляется с обслуживанием домена; динамические обновления от Windows-клиентов регистрируются.
• Linux-клиенты через SSSD. Вход на AlmaLinux/Ubuntu через доменные учётки, sudo-правила через AD-группы - всё работает, как и ожидалось.

Где нужна осторожность

Не всё гладко, и это честно признавать.

SYSVOL-репликация - самое уязвимое место. В Windows AD - DFS-R, в Samba - rsync по крону. Это работает, но это не атомарная репликация: при плохом тайминге возможна рассинхронизация политик между DC. Для одного-двух DC в одной локации - терпимо. Для нескольких площадок с медленными каналами - источник головной боли.

Доверительные отношения (trusts) с Windows AD - сложнее. Если у клиента уже есть Windows AD и нужно поднять Samba-домен рядом с трастом - это возможно, но требует аккуратной настройки и проверки. В нашем тесте мы это не разворачивали, не хотим делать вид, что всё тривиально.

Управление через привычный MMC. ADUC, GPMC, DNS Manager - всё это работает с Windows-машины, подключённой к Samba-домену. Но часть расширенных вкладок и атрибутов может вести себя неожиданно. Опытный администратор, который знает, чего ожидать, справится. Тот, кто привык к Windows AD как к чёрному ящику, будет удивлён несколько раз.

Сертификаты и ADCS - в Samba нет встроенного аналога. Если инфраструктура опирается на автовыдачу машинных сертификатов через домен - нужен отдельный PKI (EJBCA, Step CA и подобные), что добавляет операционную нагрузку.

Где мы готовы рекомендовать

На практике картина такая: для новой небольшой инфраструктуры без legacy-требований - Samba AD DC на 4.15 это жизнеспособный вариант. Сопровождение такого домена не сильно сложнее, чем Windows AD того же масштаба, если команда понимает, с чем работает.

Для миграции с существующего Windows AD - надо считать риски по конкретному клиенту. Если там сложная GPO-структура, ADCS, Exchange в домене или нестандартные схемы - это отдельный проект, не просто «поднимаем Samba и переносим объекты».

AES-256 в 4.15 - это не просто галочка. Для клиентов, у которых Windows 10 начинает отказываться от RC4 (а Microsoft планомерно повышает требования к шифрованию в новых версиях), это снимает один реальный барьер для Samba как полноценного KDC.

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