SSSD вместо winbind: перевели Linux-серверы клиента на нормальную авторизацию в AD

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

Что не так с winbind

Winbind - часть Samba, и в этом и проблема. Чтобы Linux просто присоединился к AD и пускал доменных пользователей, приходится тащить в систему целый стек Samba с его конфигурацией, nmbd, smbd и winbindd. Для сервера, который не является файловым сервером и не расшаривает ничего по SMB, это избыточно.

Два конкретных сценария, которые регулярно доставляли неприятности:

• Winbindd зависал без видимой причины - RPC-сессия к DC протухала, а демон не переинициализировался корректно. PAM честно возвращал authentication failure, пользователи не могли зайти.
• Кеширования учётных данных - в том смысле, чтобы уже авторизованные пользователи могли войти при недоступном DC - в штатной конфигурации winbind не было. Обрыв связи с DC = никто не заходит. Для серверов в удалённой площадке с нестабильным каналом это было серьёзной проблемой.

Smb.conf, который нужен для работы winbind в AD-режиме, постепенно превращался в документ, где треть настроек - попытки обойти очередной edge case.

SSSD: другой подход

SSSD (System Security Services Daemon) появился в RHEL раньше, но в RHEL 6 он стал нормально поддерживать AD как identity provider. Идея принципиально другая: один демон, который умеет LDAP, Kerberos и в том числе AD напрямую - без Samba в качестве прослойки.

Главное, что нас интересовало: кеширование. SSSD кеширует учётные данные локально, и если DC недоступен - пользователь может войти с кешированными данными. Это именно то, чего всегда не хватало в winbind-конфигурации.

Настройка оказалась компактнее, чем ожидали. Основные шаги:

• Ввод машины в домен через net ads join - этот шаг остался, Kerberos-тикет нужен в любом случае.
• sssd.conf - один файл вместо связки smb.conf + nsswitch.conf + ручных правок pam.d. Описываешь домен как AD-провайдер, указываешь параметры кеша, и это работает.
• PAM и NSS - SSSD подключается через стандартные pam_sss и nss_sss, никаких pam_winbind и winbind в nsswitch.

Отдельно порадовало, что SSSD умеет id_provider = ad и auth_provider = ad как встроенные типы - не нужно разруливать LDAP и Kerberos как два отдельных бэкенда и руками соединять их логику.

Что получилось на практике

Перевели три сервера клиента. Всё прошло без drama, но с несколькими наблюдениями.

Первое - кеширование работает так, как описано в документации. Отключили сетевой интерфейс на тестовом сервере, попробовали зайти под доменным пользователем, который логинился раньше - вход прошёл. Это не маленькое дело для инфраструктуры с удалённой площадкой.

Второе - атрибуты пользователей из AD подтягиваются аккуратнее. В winbind периодически возникали ситуации, когда uid/gid маппинг вёл себя непредсказуемо на разных серверах - особенно если winbind-конфигурация чуть различалась. SSSD с явным ldap_id_mapping = true даёт детерминированные идентификаторы через алгоритм из SID.

Третье - на ldap-поиск (getent passwd user@domain, id user) SSSD отвечает быстрее winbind при холодном кеше. Субъективно заметно.

Из неудобств: sssd.conf нужен root:root 600, и если права выставлены неправильно - демон просто не стартует с неочевидным сообщением в логе. Потеряли несколько минут на первом сервере именно на это.

Куда дальше

На трёх серверах работает неделю, жалоб нет. Winbind из системы убрали полностью - Samba на этих хостах была нужна только для winbindd, теперь в ней нет необходимости. Следующий шаг - посмотреть на sudo-интеграцию через sssd: централизованные sudo-правила в AD-атрибутах вместо раскиданных sudoers-файлов по серверам выглядит интересно, если это работает стабильно.