OpenLDAP и Ubuntu на практике > Настройка аутентификации пользователей через OpenLDAP на клиенте

5. Настройка аутентификации пользователей через OpenLDAP на клиенте

Где работаем: ldap-client

Перейдём к настройке клиентской рабочей станции. Для начала установим необходимые пакеты:

#  apt-get install ldap-utils libnss-ldapd libpam-ldapd

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

URI сервера LDAP: ldap://ldap-srv.example.com;
База поиска сервера LDAP: dc=example,dc=com;
Имена настраиваемых служб: group,netgroup,passwd,shadow.

Прежде чем делать запросы к LDAP-серверу, проверим параметры клиента в /etc/ldap/ldap.conf:

BASE  dc=example,dc=com
URI  ldap://ldap-srv.example.com
TLS_CACERT /etc/ssl/certs/rootca.crt
TLS_REQCERT demand
TLS_CRLFILE /etc/ssl/rootca.crl
TIMELIMIT 15
TIMEOUT  20

Конечно, для того, чтобы всё заработало, сертификат нашего Certificate Authority (rootca.crt) и CRL-файл (rootca.crl) должны быть на месте.

Проверим работоспособность простым запросом. Результат опустим (Вы должны увидеть всё DIT):

$  ldapsearch -xZZLLLWD cn=nssproxy,ou=users,dc=example,dc=com
Enter LDAP Password:
dn: dc=example,dc=com
...

Поправим конфигурацию нашей локальной службы имён LDAP в файле /etc/nslcd.conf. Измените значение директивы bindpw на пароль записи cn=nssproxy,ou=users,dc=example,dc=com, который мы задавали ранее:

uid nslcd
gid nslcd
uri ldap://ldap-srv.example.com
base dc=example,dc=com
binddn cn=nssproxy,ou=users,dc=example,dc=com
bindpw пароль.пользователя.nssproxy
rootpwmoddn cn=admin,dc=example,dc=com
base group ou=groups,dc=example,dc=com
base passwd ou=users,dc=example,dc=com
base shadow ou=users,dc=example,dc=com
bind_timelimit 5
timelimit 10
idle_timelimit 60
ssl start_tls
tls_reqcert allow
tls_cacertfile /etc/ssl/certs/rootca.crt
nss_initgroups_ignoreusers bin,daemon,games,lp,mail,nobody,nslcd,root,sshd,sync,uucp
nss_initgroups_ignoreusers sys,man,news,proxy,www-data,backup,list,irc,gnats,landscape

Краткое описание использованных директив:

С помощью директивы base мы сообщаем демону nslcd, где в DIT искать ту или иную информацию;
bind_timelimit ограничивает время на установление соединения с сервером пятью секундами;
timelimit устанавливает максимальное время ожидания ответа от сервера в 10 секунд;
idle_timelimit заставит nslcd разорвать соединение с сервером, если в течении минуты в соединении не было никакой активности;
ssl заставляет клиента использовать TLS при подключении к серверу;
tls_reqcert и tls_cacertfile подобны директивам TLS_REQCERT и TLS_CACERT в конфигурации /etc/ldap/ldap.conf (необходимость проверки сертификата сервера и путь к корневому сертификату для выполнения проверки);
nss_initgroups_ignoreusers описывает пользователей системы, поиск которых не нужно производить в DIT (чтобы мы могли работать с машиной при проблемах с доступом к серверу каталогов). В значение этой директивы следует внести имена всех общесистемных пользователей.

Поменяем права доступа к nslcd.conf, потому что теперь в нём хранится информация для аутентификации:

#  chmod 600 /etc/nslcd.conf
#  chown nslcd:nslcd /etc/nslcd.conf

Проверим содержимое /etc/nsswitch.conf:

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis ldap

Убедимся в том, что демон nslcd запускается при старте системы и перезапустим его:

#  update-rc.d nslcd defaults
 System start/stop links for /etc/init.d/nslcd already exist.
#  service nslcd restart
 * Starting LDAP connection daemon nslcd  [ OK ]

Убедимся, что в системе ldap-client НЕТ учётной записи с именем nssproxy. Следующая команда должна выполняться без результата:

$  grep nssproxy /etc/passwd

Убедимся так же, что кэширующий демон службы имён загружается при старте системы и перезапустим его:

#  update-rc.d nscd defaults
 System start/stop links for /etc/init.d/nscd already exist.
#  service nscd restart
 * Restarting Name Service Cache Daemon nscd
   ...done.

Сделаем пару запросов к LDAP-серверу, используя настроенную нами систему:

$  getent passwd test.user
test.user:x:1101:1101:Test User:/home/test.user:/bin/bash
$  getent group test.group
test.group:*:1101:

Для того, чтобы проверить доступность информации о пароле потребуется выполнить getent от имени пользователя root:

#  getent shadow test.user
test.user:*:15140:0:99999:7:::0

Не беспокойтесь, хэш пароля мы видеть не должны.

Отлично, всё работает! Вышеприведённые результаты команд означают, что система ldap-client может осуществлять поиск по данным пользователей и групп в нашем каталоге OpenLDAP.

Создадим домашний каталог нашего тестового пользователя и установим для него права доступа:

#  mkdir /home/test.user
#  chown test.user:test.group /home/test.user

Запустим в отдельном терминале вывод журнала аутентификации:

#  tail -f /var/log/auth.log

В другом терминале выполним:

$  su - test.user

Мы должны получить приглашение командной строки пользователя test.user.

Теперь попробуем зайти на машину ldap-client по сети с использованием ssh под учётной записью test.user.

Демон ssh в конфигурации по-умолчанию должен работать с поддержкой PAM (и, соответственно, поддерживать аутентификацию через LDAP). Но на всякий случай приведём рабочую конфигурацию /etc/ssh/sshd_config:

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 1024
LogLevel INFO
LoginGraceTime 120
PermitRootLogin without-password
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

AddressFamily inet
AllowGroups sysadmin test.group
SyslogFacility AUTHPRIV
PasswordAuthentication yes
AllowTcpForwarding no
ClientAliveInterval 120
ClientAliveCountMax 2

Часть файла до пустой строки — конфигурация по-умолчанию. Далее — добавленное нами. Обратите внимание на строку с директивой AllowGroups. С помощью неё мы ограничиваем список групп пользователей, которые могут быть аутентифицированы через ssh. За информацией по остальным директивам обратитесь к документации.

Проверим работу с использованием какой-нибудь третьей машины. Например, выполним на нашем DNS-сервере (dns-srv):

$  ssh test.user@ldap-client.example.com
Password:
test.user@ldap-client:~$

Вывод последней команды сокращён. Если появляется приглашение командной строки, значит всё в порядке!

Где работаем: ldap-srv

Давайте заглянем в /var/log/slapd.log на нашем сервере. Мы можем обнаружить там следующие строки:

ldap-srv slapd[1304]: <= mdb_equality_candidates: (objectClass) not indexed
ldap-srv slapd[1304]: <= mdb_equality_candidates: (uid) not indexed

С помощью следующей команды мы можем убедиться, что в нашем каталоге пока нет никаких индексов:

$  ldapsearch -xZZLLLWD cn=admin,dc=example,dc=com -b olcDatabase={1}mdb,cn=config olcDbIndex
Enter LDAP Password:
dn: olcDatabase={1}mdb,cn=config

Это значит, что в нашей базе данных надо создать индексы для атрибутов из журнала /var/log/slapd.log. Поэтому создадим ещё один LDIF-файл 5-posixAccount.indexes.ldif и запишем в него:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: default pres,eq
-
add: olcDbIndex
olcDbIndex: uid
-
add: olcDbIndex
olcDbIndex: cn,sn pres,eq,sub
-
add: olcDbIndex
olcDbIndex: objectClass eq
-
add: olcDbIndex
olcDbIndex: memberUid eq
-
add: olcDbIndex
olcDbIndex: uniqueMember eq
-
add: olcDbIndex
olcDbIndex: uidNumber
-
add: olcDbIndex
olcDbIndex: gidNumber eq

Зачем мелочиться? Укажем по-больше индексируемых атрибутов. И загрузим конфигурацию в наш каталог:

$  ldapadd -xZZWD cn=admin,dc=example,dc=com -f posixAccount.indexes.ldif
Enter LDAP Password:
modifying entry "olcDatabase={1}mdb,cn=config"

Проверим результат изменений:

$  ldapsearch -xZZLLLWD cn=admin,dc=example,dc=com -b olcDatabase={1}mdb,cn=config olcDbIndex
Enter LDAP Password:
dn: olcDatabase={1}mdb,cn=config
olcDbIndex: default pres,eq
olcDbIndex: uid
olcDbIndex: cn,sn pres,eq,sub
olcDbIndex: objectClass eq
olcDbIndex: memberUid eq
olcDbIndex: uniqueMember eq
olcDbIndex: uidNumber
olcDbIndex: gidNumber eq

Отлично! Теперь в журнале /var/log/slapd.log не должно быть ошибок.

OpenLDAP и Ubuntu на практике > Настройка аутентификации пользователей через OpenLDAP на клиенте

Pro-LDAP.ru 2015 г. Последнее изменение страницы — 3 мая 2015 г. Вопросы и предложения принимаются на форуме проекта.