Типичная картина: id user@corp.company.ru возвращает UID и группы, пароль верный, а SSH отвечает «Permission denied». Если в конфиге стоит access_provider = ad, первым делом смотрю на групповые политики. Параметр ad_gpo_access_control по умолчанию равен enforcing: SSSD читает GPO, привязанные к компьютеру, и применяет к Linux-входу те же права, что Windows.
- SSH и cockpit по умолчанию сопоставлены с правом «Разрешить вход в систему через службу удалённых рабочих столов» (RemoteInteractiveLogonRight). Если хоть одна применяемая политика задаёт это право, войдут только перечисленные в нём пользователи и группы.
- Консольный вход,
su и графические менеджеры входа сопоставлены с правом «Локальный вход в систему» (InteractiveLogonRight).
- Встроенные группы AD, например Administrators с SID S-1-5-32-544, SSSD в правилах GPO игнорирует — участие в них доступа не даёт.
- Если контейнер групповой политики недоступен SSSD на чтение, вход по умолчанию запрещается (
ad_gpo_ignore_unreadable = False).
На переходный период я включаю режим permissive: правила вычисляются, но не применяются, а в syslog пишется, кого бы не пустили. Для этих сообщений нужен уровень отладки трассировки. Когда в логах чисто, возвращаю enforcing.
[domain/corp.company.ru]
access_provider = ad
ad_gpo_access_control = permissive
# свой PAM-сервис в список для удалённого входа:
# ad_gpo_map_remote_interactive = +my_pam_service
Если GPO для Linux не нужны вовсе, есть значение disabled, но тогда ограничение по группам делаю через access_provider = simple и simple_allow_groups, как в примере выше.
