Форум проекта Pro-LDAP.ru
Интеграция => Учётные записи в *nix системах => Тема начата: syntetix от 12 Март 2018, 11:58:46
-
Коллеги, добрый день.
Помогите пожалуйста разобраться с проблемой аутентификации на CentOS 6.9.
Проблема заключается в следующем: при попытке консольного входа на клиентскую рабочую станцию выдается сообщение login incorrect
Диагностические сообщения с рабочей станции.
Пользователь, под которым должен быть осуществлен вход.
[root@lws01 log]# getent passwd | grep jdoe
jdoe:x:10005:10000:Jane Doe:/home/jdoe:/bin/bash
Обращение к каталогу осуществлено с рабочей станции, от имени пользователя под которым следует войти.
[root@lws01 log]# ldapsearch -xD "uid=jdoe,ou=users,ou=legolab,dc=legolab,dc=local" -w 33333 -b "ou=users,ou=legolab,dc=legolab,dc=local" "givenName=Jane"
# extended LDIF
#
# LDAPv3
# base <ou=users,ou=legolab,dc=legolab,dc=local> with scope subtree
# filter: givenName=Jane
# requesting: ALL
#
# jdoe, users, legolab, legolab.local
dn: uid=jdoe,ou=users,ou=legolab,dc=legolab,dc=local
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
givenName: Jane
sn: Doe
description: HR
employeeType: HR manager
telephoneNumber: 100
mobile: +1 999 100-100-100
homePostalAddress: NY, Brooklyn, 100
homePhone: 10000
displayName: Jane Doe
uidNumber: 10005
loginShell: /bin/bash
homeDirectory: /home/jdoe
gidNumber: 10000
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Установленные на рабочей станции пакеты.
[root@lws01 log]# rpm -qa | grep ldap
openldap-2.4.40-16.el6.x86_64
openldap-clients-2.4.40-16.el6.x86_64
pam_ldap-185-11.el6.x86_64
nss-pam-ldapd-0.7.5-32.el6.x86_64
SELinux
[root@lws01 log]# getenforce
Disabled
Iptables
[root@lws01 log]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Вывод /var/log/secure
Mar 12 14:52:39 lws01 login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= user=jdoe
Mar 12 14:52:39 lws01 login: pam_ldap: error trying to bind (Inappropriate authentication)
Mar 12 14:52:41 lws01 login: FAILED LOGIN 1 FROM (null) FOR jdoe, Authentication failure
Заранее спасибо за ответы и комментарии.
-
Здравствуйте! Во-первых, бросается в глаза, что у Вас установлены и pam_ldap, и nss-pam-ldapd -- это две разных системы, предназначенные для выполнения одной и той же функции -- получения учёток из каталога (NSS) и выполнения аутентификации в операционке с использованием записей каталога (PAM) (посмотрите здесь (https://pro-ldap.ru/forum/index.php?topic=55.msg235#msg235)). Вполне вероятно, они влияют друг на друга. Предлагаю удалить pam_ldap, возможно после этого сразу заработает (NSS-часть же у вас работает, судя по выводу getent).
Если нет, то нужно заглянуть в файл /etc/ldap.conf -- настройки демона nslcd из пакета nss-pam-ldapd. Было бы неплохо и его показать, ну или, хотя бы, прислать в личку. Есть еще вариант, что проблемы с ACL в OpenLDAP -- тот пользователь, от которого работает nslcd может не обладать нужными правами для выполнения подключения. В общем, пришлите /etc/ldap.conf, попробуем разобраться.
Егор
-
Егор, добрый день.
Насколько я понимаю модули pam_ldap и nss-pam-ldap являются взаимосвязанными в системах Red Hat. По крайне мере:
[root@lws01 ~]# yum remove pam_ldap-185-11.el6.x86_64
Loaded plugins: fastestmirror
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package pam_ldap.x86_64 0:185-11.el6 will be erased
--> Processing Dependency: /lib64/security/pam_ldap.so for package: nss-pam-ldapd-0.7.5-32.el6.x86_64
--> Restarting Dependency Resolution with new changes.
--> Running transaction check
---> Package nss-pam-ldapd.x86_64 0:0.7.5-32.el6 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
=============================================================================================================================================================================================================================================
Package Arch Version Repository Size
=============================================================================================================================================================================================================================================
Removing:
pam_ldap x86_64 185-11.el6 @c6-media 154 k
Removing for dependencies:
nss-pam-ldapd x86_64 0.7.5-32.el6 @c6-media 454 k
Transaction Summary
=============================================================================================================================================================================================================================================
Remove 2 Package(s)
Installed size: 609 k
Is this ok [y/N]:
Файл ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
TLS_CACERTDIR /etc/openldap/cacerts
URI ldap://ldap01.legolab.local/
BASE dc=legolab,dc=local
Файл конфигурации nslcd
uid nslcd
gid ldap
# This comment prevents repeated auto-migration of settings.
uri ldap://ldap01.legolab.local/
base dc=legolab,dc=local
binddn uid=nssproxy,ou=users,ou=legolab,dc=legolab,dc=local
bindpw 33333
ssl no
tls_cacertdir /etc/openldap/cacerts
Пользователь nssproxy обладает правами на чтение всего содержимого каталога. Вывод приводить не стал, но проверил посредством ldapsearch на клиенте.
P.S. Спасибо за оперативные ответы.
-
Для полноты картины приведу конфигурацию slapd.conf
slapd.conf
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
pidfile /var/run/openldap/slapd.pid
loglevel -8
disallow bind_anon
require authc
moduleload back_bdb.la
database bdb
suffix "dc=legolab, dc=local"
rootdn "cn=johndoe,dc=legolab,dc=local"
rootpw 11111
directory /var/db/openldap/legolab
access to attrs=userPassword
by anonymous auth
by * break
access to *
by dn.base="uid=nssproxy,ou=users,ou=legolab,dc=legolab,dc=local" read
by * break
access to attrs=userPassword,uid,mobile,homePostalAddress,homePhone,cn,employeeType,cn,givenName,sn
by group.exact="cn=legolabUsers,ou=groups,ou=legolab,dc=legolab,dc=local" none
by * break
access to attrs=userPassword,uid,cn
by group.exact="cn=hrstaff,ou=groups,ou=legolab,dc=legolab,dc=local" none
by * break
access to attrs=userPassword,uid,cn
by group.exact="cn=hr,ou=groups,ou=legolab,dc=legolab,dc=local" none
by * break
access to dn.subtree="ou=servers,ou=legolab,dc=legolab,dc=local"
by group.exact="cn=itstaff,ou=groups,ou=legolab,dc=legolab,dc=local" write
by users none
by * break
access to dn.subtree="ou=printers,ou=legolab,dc=legolab,dc=local"
by group.exact="cn=helpdesk,ou=groups,ou=legolab,dc=legolab,dc=local" write
by * break
access to *
by group.exact="cn=itstaff,ou=groups,ou=legolab,dc=legolab,dc=local" write
by users read
by * break
index uid eq
index cn,gn,mail eq,sub
index sn eq,sub
index ou eq
cachesize 2000
checkpoint 128 15
-
Проблема была решена.
Если кто то будет решать подобный квест, то следует иметь ввиду что для корректного взаимодействия механизма аутентификации PAM и LDAP в дистрибутивах CentOS 6.x (по крайне мере в 6.9 точно) необходимо установить привязку в файле pam_ldap.conf посредством использования директив binddn и bindpw. Я для привязки использовал такие же учетные данные и как для службы nslcd.
-
для корректного взаимодействия механизма аутентификации PAM и LDAP в дистрибутивах CentOS 6.x (по крайне мере в 6.9 точно) необходимо установить привязку в файле pam_ldap.conf посредством использования директив binddn и bindpw. Я для привязки использовал такие же учетные данные и как для службы nslcd.
Всё логично, ведь настраивается сразу два пакета: и nslcd и pam_ldap. Вопрос: почему так устроено в redhat, ведь вполне можно было обойтись чем-то одним? Как мне кажется, так они стараются продвинуть свою систему аутентификации sssd.
Кстати, ACL выглядят, мягко скажем, избыточно. Можно оптимизировать.
Егор
-
Добрый день.
Логично, но совершенно не очевидно. Хотя может только для меня. Но мне простительно, я в мире Linux новичок -).
ACL можно описать одним словом - чушь -). Никакого отношения к реальности они не имеют, это проба пера и эксперименты.
А насчет SSSD я думаю что Вы полностью правы. Red Hat такой Red Hat.