Как правильно отладить логин в оболочке в следующем случае?
Аутентификация осуществляется через конфигурацию sssd и сервер аутентификации krb5. Вход с тем же файлом .conf в Ubuntu 16.04 LTS работает отлично. Как только вы используете его с 17.04, вход в систему со всем, кроме root, приводит к перезапуску оболочки getty - / var / log / syslog состояния
getty@tty2.service: Service has no hold-off time, sheduling restert.
Stopped Getty on tty2.
Started Getty on tty2.
а в auth.log отмечено следующее:
pam_sss(login:account): Access denied for user <user>: 4 (System error)
System error
Выполнение login <user> приводит к
root@pctest# login <user>
password:
System error
root@pctest#
С помощью sssctl config-check не приводит к ошибкам, как и ожидалось от рабочей конфигурации на 16.04 LTS.
Каждый упомянутый тест проводился на автоматически настроенных и проверенных вручную, недавно установленных системах на отформатированных дисках. Дополнительные пакеты устанавливались через ubuntu-standard метапакет (окружение рабочего стола не установлено). Тем не менее, проблема также была воспроизведена на работающей системе 16.04 LTS, обновленной до 17.04.
Я не нашел подробного режима для login ни разумный способ выполнить сбойную часть входа в систему как автономный. Так что бы ты сделал?
[Edit] Рабочее решение
Решение данной проблемы:
Обходной путь для нас заключался в установке ad_gpo_access_control = permissive в разделе [domain] файла /etc/sssd/sssd.conf ...
Источник: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859445
Вам необходимо добавить debug_level = 10 во все разделы файла sssd.conf, перезапустить sssd и повторно запустить логин. Затем загляните в / var / log / sssd. Также прочтите https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
та же проблема на Ubuntu 20.04, добавив
решены проблемы, которых нет в Ubuntu 18.04 (то же сопоставление атрибутов M $ AD и RFC_2307)
Похоже, что значения по умолчанию изменились: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/sssd-gpo
Мне все еще нужно найти правильные настройки, чтобы обеспечить безопасность системы
Просто интересно, почему некоторые свежие системы Linux, подключенные к Active Directory (Debian 9), сообщили system error на su в то время как некоторые постарше не проявляли такого поведения. Настройка ad_gpo_access_control = permissive действительно заставил его работать, но основная причина заключалась в том, что новые системы имеют IP-адреса в подсети, которые не были записаны в Active Directory. Сайты и сервисы. После того как подсеть была добавлена и назначена сайту (дайте AD некоторое время для репликации), system error больше не сообщалось.
Сегодня у меня была такая же проблема с 16.04LTS.
Я могу подтвердить, что ваше решение также помогло мне.
В раздел моего домена я добавил:
ad_gpo_access_control = разрешающий
После этого он работал идеально. Похоже, что в 16.04LTS и SSSD есть ошибка. Спасибо, спасибо, спасибо, что опубликовали это решение. Я нигде не нашел информации об этой ошибке.