Univention Corporate Server (UCS) — установка простого и удобного LDAP сервера с web-панелью и его связка с Nextcloud / Хабр

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

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

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

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

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

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

BASE  dc=example,dc=comURI  ldap://ldap-srv.example.comTLS_CACERT /etc/ssl/certs/rootca.crtTLS_REQCERT demandTLS_CRLFILE /etc/ssl/rootca.crlTIMELIMIT 15TIMEOUT  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 nslcdgid nslcduri ldap://ldap-srv.example.combase dc=example,dc=combinddn cn=nssproxy,ou=users,dc=example,dc=combindpw пароль.пользователя.nssproxyrootpwmoddn cn=admin,dc=example,dc=combase group ou=groups,dc=example,dc=combase passwd ou=users,dc=example,dc=combase shadow ou=users,dc=example,dc=combind_timelimit 5timelimit 10idle_timelimit 60ssl start_tlstls_reqcert allowtls_cacertfile /etc/ssl/certs/rootca.crtnss_initgroups_ignoreusers bin,daemon,games,lp,mail,nobody,nslcd,root,sshd,sync,uucpnss_initgroups_ignoreusers sys,man,news,proxy,www-data,backup,list,irc,gnats,landscape

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

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

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

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

passwd:         compat ldapgroup:          compat ldapshadow:         compat ldaphosts:          files dnsnetworks:       filesprotocols:      db filesservices:       db filesethers:         db filesrpc:            db filesnetgroup:       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 22Protocol 2HostKey /etc/ssh/ssh_host_rsa_keyHostKey /etc/ssh/ssh_host_dsa_keyHostKey /etc/ssh/ssh_host_ecdsa_keyHostKey /etc/ssh/ssh_host_ed25519_keyUsePrivilegeSeparation yesKeyRegenerationInterval 3600ServerKeyBits 1024LogLevel INFOLoginGraceTime 120PermitRootLogin without-passwordStrictModes yesRSAAuthentication yesPubkeyAuthentication yesIgnoreRhosts yesRhostsRSAAuthentication noHostbasedAuthentication noPermitEmptyPasswords noChallengeResponseAuthentication noX11Forwarding yesX11DisplayOffset 10PrintMotd noPrintLastLog yesTCPKeepAlive yesAcceptEnv LANG LC_*Subsystem sftp /usr/lib/openssh/sftp-serverUsePAM yesAddressFamily inetAllowGroups sysadmin test.groupSyslogFacility AUTHPRIVPasswordAuthentication yesAllowTcpForwarding noClientAliveInterval 120ClientAliveCountMax 2

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

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

$  ssh [email protected]
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=configchangetype: modifyadd: olcDbIndexolcDbIndex: default pres,eq-add: olcDbIndexolcDbIndex: uid-add: olcDbIndexolcDbIndex: cn,sn pres,eq,sub-add: olcDbIndexolcDbIndex: objectClass eq-add: olcDbIndexolcDbIndex: memberUid eq-add: olcDbIndexolcDbIndex: uniqueMember eq-add: olcDbIndexolcDbIndex: uidNumber-add: olcDbIndexolcDbIndex: 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 на клиенте