☰

Пользователь LDAP не существует при запуске «su»

tag-icon • tag-icon rhel ldap sssd
Пользователь LDAP не существует при запуске «su»

Я пытаюсь настроить аутентификацию LDAP в соответствии с инструкциями в книге Сандера Ван Вугта RHCSA/RHCE для RHEL7. В главе 6 он объясняет, что при использовании authconfig-tuiпараметра FORCELEGACYустановлено значение yesв /etc/sysconfig/authconfig. Это должно настроить nslcdвместо sssd.

Я не вижу, чтобы это происходило. Возможно, так было в 7.0 или даже 7.1, но в 7.3 опция установлена ​​на noafter using authconfig-tui.

Если я отложу в сторону nslcdпутаницу sssdи попытаюсь выполнить упражнение, которое приводит к запуску su - laraаутентификации через LDAP для указанного пользователя, я просто получу:

su: user lara does not exist

Я проверил, что сервер FreeIPA отвечает на запросы с помощью ldapsearchи при этом подтвердил, что пользователь находится в LDAP. Мне кажется, однако, что это suне аутентификация против LDAP, а вместо этого /etc/passwd.

Моя PAM system-authконфигурация включает sssdзаписи, которые кажутся необходимыми:

auth        sufficient    pam_sss.so forward_pass
account     [default=bad success=ok user_unknown=ignore] pam.sss.so
password    sufficient    pam_sss.so use_authtok
session     optional      pam_sss.so

Мой /etc/nsswitch.confфайл содержит:

passwd:    files sss
shadow:    files sss
group:     files sss

Услуга sssdактивна.

Нет никаких записей в журнале /var/log/*или /var/log/sssd/*. Фактически, ни один из sssdжурналов ничего не содержит.

РЕДАКТИРОВАТЬ

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

Я могу аутентифицироваться как пользователь lara, если я sshзахожу на сервер LDAP. Поэтому я знаю, что LDAP на самом деле работает.

Я также посмотрел на PAMконфигурацию для su. Это загрузка system-authфайла:

auth        substack        system-auth
account     include         system-auth
password    include         system-auth
session     include         system-auth

поэтому он должен неявно использовать pam_sss.soмодуль.

Хотя до сих пор не могу разобраться.

ПРАВКА 2

Имея возможность войти на сервер IPA локально или через SSH с пользователем lara, я решил сравнить pam-файлы на нем с файлами на клиенте. Единственное отличие, которое я смог определить, это то, что клиент содержал broken_shadowзапись pam_unix.soучетной записи. Я удалил ее и даже перезагрузил, но это ничего не исправило.

Как отключить broken_shadow? Я ничего не могу найти по этому поводу.

решение1

Это может быть не связано, но я следую тем же путем (с клиентским сервером собственного создания) и мне удалось исправить это, выполнив следующие действия:

  1. Проверка всего соответствует тому, что я установил в authconfig-tui в /etc/sssd/sssd.conf
  2. Установка разрешений для /etc/sssd/sssd.conf на 0600 (после этого все заработало сразу) - я не уверен, почему это имело значение, учитывая, что это предоставляет пользователю только права на чтение и запись, но я нашел это в руководстве Oracle по настройке клиента SSSD для RHEL7:https://docs.oracle.com/cd/E52668_01/E54669/html/ol7-sssd-ldap.html

EDIT: Возможное объяснение:https://pagure.io/SSSD/sssd/issue/1413

Связанный контент