Аутентифікація LDAP на CentOS 7


11

Після оновлення до CentOS 7 більше не можна входити через LDAP. У CentOS 6 я використовував пакет pam_ldap, який працював чудово, але зараз пам_ldap більше не доступний для нової версії CentOS.

Підключення через ldapsearch все ще працює добре, але спроба автентифікації через ssh не працює.

Я перевстановив пакунок nss-pam-ldapd і налаштував автентифікацію за допомогою authconfig-tui , але він все ще не працює.

Нижче я замінюю своє ім’я користувача на ім’я user.name та базу на dc = sub, dc = example, dc = org .

Моя хоста ОС - це CentOS 7. Усі наявні в даний час оновлення встановлені.

$ uname -a
Linux isfet 3.10.0-123.8.1.el7.x86_64 #1 SMP Mon Sep 22 19:06:58 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Встановлені пакети

$ rpm -qa | grep -i ldap
openldap-2.4.39-3.el7.x86_64
nss-pam-ldapd-0.8.13-8.el7.x86_64
openldap-clients-2.4.39-3.el7.x86_64

Вміст /etc/openldap/ldap.conf

URI ldap://172.16.64.25
BASE dc=sub,dc=example,dc=org

Вміст /etc/nslcd.conf

ldap_version 3
uri ldap://172.16.64.25
base dc=sub,dc=example,dc=org
ssl no

Вихід / var / log / secure

Oct  6 12:12:16 isfet sshd[3937]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.64.1  user=user.name
Oct  6 12:12:17 isfet sshd[3937]: Failed password for user.name from 172.16.64.1 port 18877 ssh2

Вихід з /var/log/audit/audit.log

type=USER_AUTH msg=audit(1412590243.286:364): pid=3912 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="user.name" exe="/usr/sbin/sshd" hostname=172.16.64.1 addr=172.16.64.1 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1412590243.287:365): pid=3912 uid=0 auid=4294967295 ses=4294967295 msg='op=password acct="user.name" exe="/usr/sbin/sshd" hostname=? addr=172.16.64.1 terminal=ssh res=failed'

Виведення команди ldapserach

$ ldapsearch -H ldap://172.16.64.25/ -D cn=Manager,dc=sub,dc=example,dc=org -W -x -b dc=sub,dc=example,dc=org -d1

ldap_url_parse_ext(ldap://172.16.64.25/)
ldap_create
ldap_url_parse_ext(ldap://172.16.64.25:389/??base)
Enter LDAP Password:
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 172.16.64.25:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 172.16.64.25:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 61 bytes to sd 3
ldap_result ld 0x7f9b07402110 msgid 1
wait4msg ld 0x7f9b07402110 msgid 1 (infinite timeout)
wait4msg continue ld 0x7f9b07402110 msgid 1 all 1
** ld 0x7f9b07402110 Connections:
* host: 172.16.64.25  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Mon Oct  6 12:04:38 2014


** ld 0x7f9b07402110 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7f9b07402110 request count 1 (abandoned 0)
** ld 0x7f9b07402110 Response Queue:
   Empty
  ld 0x7f9b07402110 response count 0
ldap_chkResponseList ld 0x7f9b07402110 msgid 1 all 1
ldap_chkResponseList returns ld 0x7f9b07402110 NULL
ldap_int_select
read1msg: ld 0x7f9b07402110 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 50 contents:
read1msg: ld 0x7f9b07402110 msgid 1 message type bind
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x7f9b07402110 0 new referrals
read1msg:  mark request completed, ld 0x7f9b07402110 msgid 1
request done: ld 0x7f9b07402110 msgid 1
res_errno: 0, res_error: <>, res_matched: <cn=Manager,dc=sub,dc=example,dc=org>
ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_err2string
ldap_bind: Success (0)
        matched DN: cn=Manager,dc=sub,dc=example,dc=org
...

Вміст _ / etc / pam.d / password-auth

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so

Вміст _ / etc / pam.d / system-auth

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so

Чи отримуєте якісь результати від запуску "getent passwd user.name" або "su - user.name"?
Енді

Користувач існує локально, але без пароля. Аутентифікація проти LDAP. / etc / passwd: user.name:x:1028:1031::/home/user.name:/bin/bash / etc / shadow: user.name: !!: 16348: 0: 99999: 7 :::
Лукаш Шульце

Не pam_ldapвикористовується інший файл, ніж /etc/openldap/ldap.conf? Я хочу сказати /etc/ldap.conf, напрочуд. Я б спробував налагодити модуль, додавши debugопцію для доданого протоколу протоколу, тобто auth sufficient pam_ldap.so use_first_pass debug. Крім того, я думаю, що питання ви затуманили вас за порадами Джоффрі. Поверніться до початкової конфігурації, якщо ви хочете, щоб інші могли вам допомогти.
Ендрю Б

Чи можете ви додати вміст /etc/ldap.conf?
Ендрю Б

Дякую! Запуск nslcd в режимі налагодження допоміг мені знайти помилку. Я написав це як відповідь.
Лукаш Шульце

Відповіді:


4

Запуск nslcd в режимі налагодження показує проблему:

$ $(which nslcd) -d
...
nslcd: [8b4567] <authc="user.name"> DEBUG: myldap_search(base="dc=sub,dc=example,dc=org", filter="(&(objectClass=posixAccount)(uid=user.name))")
...
nslcd: [8b4567] <authc="user.name"> DEBUG: ldap_result(): end of results (0 total)
nslcd: [8b4567] <authc="user.name"> DEBUG: "user.name": user not found: No such object
...

nslcd встановлює фільтр за замовчуванням. Неможливо видалити цей фільтр або встановити його в порожнє.

Оскільки жоден з моїх користувачів LDAP не має об’єктного класу, який називається posixAccount, користувачів не можна знайти, і вхід заборонено.

Щоб вирішити цю проблему, мені довелося перезаписати цей фільтр власним. Оскільки я шукаю uid , корисно встановити фільтр на атрибут, який шукається будь-коли.

Новий вміст мого /etc/nslcd.conf :

filter passwd (uid=*)
uri ldap://172.16.64.25
base dc=sub,dc=example,dc=org
ssl no

Після зміни nslcd.conf мені довелося перезапустити службу nslcd:systemctl restart nslcd

Джерело: http://lists.arthurdejong.org/nss-pam-ldapd-users/2014/msg00025.html

.

Це здається проблемою для _nss-pam-ldapd-0.8.13-8.el7.x86_64_ на CentOS 7!

$ nslcd -V
nss-pam-ldapd 0.8.13

Я намагався відтворити проблему на CentOS 6, але на цьому nss-pam-ldapd є залежності до pam_ldap, який має свій конфігураційний файл у /etc/pam_ldap.conf і, здається, не використовує /etc/nslcd.conf у спосіб, як це працює на CentOS 7.


1
Так, pam_ldapколізійні імена дуже заплутані. :( Є кілька реалізацій, на які всі претендують на ім'я цього модуля.
Andrew B
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.