LINUX.ORG.RU
ФорумAdmin

PAM/NSS через TLS


0

1

Доброго времени суток. Есть проблема, заключается она в следующем.
Есть 4 машины на ALTLinux. На всех настроен логин через LDAP (с помощью PAM/NSS). И почему-то на двух из них логин работает, а на двух других нет.
При этом на всех прекрасно работает getent user (user находится в LDAP), ldapsearch также работает через TLS. Логично предположить, что с сертификатами проблем нет.
Содержимое конфигов pam_ldap.conf и nss_ldap.conf на всех машинах идентично.
pam_ldap.conf

base dc=uriit,dc=local
uri ldap://ldap.uriit.ru
rootbinddn cn=pamnss,ou=services,dc=uriit,dc=local
port 389
scope sub
timelimit 5
bind_timelimit 5
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberUid
ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/openldap/ssl/cacert.pem
tls_cert /etc/openldap/ssl/newcert.pem
tls_key /etc/openldap/ssl/newkey.pem
nss_ldap.conf
base dc=uriit,dc=local
uri ldap://ldap.uriit.ru
rootbinddn cn=pamnss,ou=services,dc=uriit,dc=local
port 389
scope sub
timelimit 5
bind_timelimit 5
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberUid
ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/openldap/ssl/cacert.pem
tls_cert /etc/openldap/ssl/newcert.pem
tls_key /etc/openldap/ssl/newkey.pem
В тот момент, когда пытаюсь залогиниться с неработающей машины, после ввода пароля система крепко задумывается (из логов видно, что пытается подключиться к LDAP):
May 30 18:18:41 ldap sshd[7229]: Accepted password for nlepehin from 192.168.11.118 port 1245 ssh2
May 30 18:18:42 ldap -bash: nss_ldap: reconnecting to LDAP server (sleeping 4 seconds)...
После раздумий выдает:
[I have no name!@ldap ~]$
При этом пароль он может сверять, как видно из первой строчки лога выше. И если ввести неверный пароль он тут же скажет, что он неверен.
Мне кажется, что pam отрабатывает, а ошибка связана с NSS.

[I have no name!@ldap ~]$

Проблема только в этом? Или в чем?

zgen ★★★★★ ()

Права на файлы смотрите, пользователю с «no name» не хватает прав, чтобы прочитать libnssldap.conf или ldap.secret

zgen ★★★★★ ()
Ответ на: комментарий от borisych

крутая идея...

Всё зависит от конфигурации. само собой, если в ldap.secret пароль менеджера с правом записи, то к нему доступ давать не нужно.

nscd запущен?

Это не ко мне. Но если запущен - замочить.

zgen ★★★★★ ()
Ответ на: комментарий от zgen

[I have no name!@ldap ~]$ Проблема только в этом? Или в чем?

Да, проблема в этом. Это говорит о том, что где-то ошибка, не правда ли? =)И логин по полторы минуты меня не устраивает.
в ldap.secret лежит не admin, а специально созданный аккаунт.
Даже если бы лежал admin, это не вопрос данной темы. Это вопрос безопасности.
Вот права на файлы:

-rw-------  1 root root        * May 30 18:12 ldap.secret
-rw-r--r--  1 root root     9556 May 30 15:29 nss_ldap.conf
-rw-r--r--  1 root root     8833 May 30 15:28 pam_ldap.conf
На всех машинах данные права идентичны.
И да,
[root@pki etc]# service nscd stop
Service nscd is not running.                                  [PASSED]

niklep ()
Ответ на: комментарий от niklep

Это говорит о том, что где-то ошибка, не правда ли? =)

Конечно! Это говорит о том, что права на файлы у вас выданы неверные. Если бы я использовал linux почаще, я бы указал конкретные файлы. А так у вас банально после входа проблемного пользователя getent passwd не работает, отсюда и проблемы. Показывайте nss_ldap.conf

И логин по полторы минуты меня не устраивает.

В nss_ldap.conf:
bind_timelimit 2
bind_policy soft

И, вероятно, login по полторы минуты уйдет в прошлое.

Даже если бы лежал admin, это не вопрос данной темы. Это вопрос безопасности.

Совершенно очевидно, что это вопрос безопасности, однако за ради поиска сути проблемы (т.е. дебага) можно и дать право на чтение, например так:

Создаем пользователя в ldap, помещаем его в специальную группу, этой группе и даем право на чтение ldap.secret

Ну это если вы конечно заинтересованы в поиске проблемы.

zgen ★★★★★ ()
Ответ на: комментарий от zgen

Долгий логин уйдет после того, как источник проблемы будет устранен. Там, где логин нормально работает, он не долгий.
В том-то и дело, что даже

-rw-rw-rw-  1 root root        * May 30 16:00 ldap.secret
не решает проблемы.

Просто мне не понятно, на какие файлы права могут быть не верно выданы. Ибо на те файлы, что приходят в голову сразу (мы все тут про них говорим), права на всех машинах идентичны.
И да, зря не упомянул, что без TLS везде все работает прекрасно.

niklep ()

На что только люди не готовы, лишь бы не покупать божественную инфраструктуру AD

guyvernk ()
Ответ на: комментарий от niklep

Т.е. одну проблему мы решили, осталось разобраться с ihnn.

Покажите slapd.conf без комментариев (только пароль не нужно)

zgen ★★★★★ ()
Ответ на: комментарий от zgen

slapd.conf

concurrency 32
defaultsearchbase "dc=uriit, dc=local"
gentlehup on
sizelimit -1
loglevel -1
password-hash {SSHA}
pidfile                 /var/run/slapd.pid
argsfile                /var/run/slapd.args
rootDSE /etc/openldap/rootdse.ldif
threads 32
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /etc/openldap/ssl/cacert.pem
TLSCertificateFile /etc/openldap/ssl/newcert.pem
TLSCertificateKeyFile /etc/openldap/ssl/newkey.pem
TLSVerifyClient demand
include /etc/openldap/slapd-access.conf

slapd-access.conf:

.....
access to dn="ou=People,dc=uriit,dc=local"
        by dn="cn=pamnss,ou=Services,dc=uriit,dc=local" read

access to dn="ou=Groups,dc=uriit,dc=local"
        by dn="cn=pamnss,ou=Services,dc=uriit,dc=local" read
.....

niklep ()
Ответ на: комментарий от niklep

И да, вспомнилась старая проблема. Когда-то я на нее забил, теперь вспомнил.
Дело в том, что поиск по базе LDAP через TLS работает. Но если делать

openssl s_client -connect host.domain.ru:389  -CAfile /etc/openldap/ssl/cacert.pem -cert /etc/openldap/ssl/newcert.pem -key /etc/openldap/ssl/newkey.pem -cipher SSLv2
то получаю ошибку рукопожатия. Вот и думаю, критично ли это.

niklep ()
Ответ на: комментарий от niklep

Если все так, как вы говорите, а именно

1) с этим же сервером LDAP другие nss_ldap-tls клиенты работают нормально
2) если на проблемном сервере отключить ldap-tls то тоже все нормально

значит остается предположить, что что-то не так с правами на

tls_cacertfile /etc/openldap/ssl/cacert.pem
tls_cert /etc/openldap/ssl/newcert.pem
tls_key /etc/openldap/ssl/newkey.pem

Либо отключайте проверку tls клиента/сервера и проверяйте без неё.

zgen ★★★★★ ()
Ответ на: комментарий от niklep

то получаю ошибку рукопожатия. Вот и думаю, критично ли это.

Как вариант, для проверки:
/etc/openldap/ldap.conf:

TLS_REQCERT never

а в nss_ldap.conf:

tls_checkpeer no

zgen ★★★★★ ()
Ответ на: комментарий от zgen

Спасибо большое за помощь, проблема была в правах на папку
/etc/openldap/ssl
привел права в соответствие, и все заработало.
P.S. Действительно ведь, стоило обратить внимание на то, что ldapsearch через TLS работал только от рута...

niklep ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.