Видно, что процесс slapd слушает не только локальный адрес, но и сокет /var/run/slapd/ldapi. Здесь есть еще один «подводный камень», который, возможно, будет иметь значение для владельцев дистрибутивов, отличных от SuSE. Дело в том, что традиционно LDAP запускается от соответствующего пользователя.

# ps -eo user,args | grep slapd | grep -v grep | head -n 1

ldap /usr/lib/openldap/slapd -h ldapi:///

ldap://127.0.0.1:389/ -u ldap -g ldap

И несмотря на это, сокет для связи создается от пользователя root и с правами, ограничивающими доступ к нему от иных пользователей и групп, но с установленным битом «set user ID». Вроде все верно, только расположен он внутри директории, доступной лишь для ldap.ldap.

# ls -als /var/run/slapd

total 24

   4 drwx------    4 ldap     ldap         4096 Jun 12 13:04 .

   4 drwxr-xr-x   20 root     root         4096 Jun 12 23:02 ..

   0 srwx------    1 root     root            0 Jun 12 13:04 ldapi

   4 drwx------    2 ldap     ldap         4096 Sep 24  2003 openldap-data

   4 drwx------    2 ldap     ldap         4096 Sep 24  2003 openldap-slurp

   4 -rw-r--r--    1 ldap     ldap           76 Jun 12 13:04 slapd.args

   4 -rw-r--r--    1 ldap     ldap            5 Jun 12 13:04 slapd.pid

Процесс kdc в SuSE запускается от пользователя root, и поэтому нет никаких проблем с подключением к сокету для связи с LDAP. Если в некоторой системе приняты иные соглашения, то недоступность локального сокета, созданного LDAP, со стороны процесса kdc может быть причиной отказа Kerberos. Для исправления этого надо просто поменять права доступа у сокета после запуска slapd.

Подключенный через локальный сокет Kerberos имеет исключительно доверительные права на доступ к базе LDAP. Но это нужно только для режима наполнения базы данными. Для регулярной работы Kerberos, аутентификации и выдачи билетов достаточно иметь доступ на чтение. То есть всегда остается возможность «заморозить» состояние базы Kerberos. Хотя верно это лишь для применяемой версии Heimdal, которая не обновляет индексы в базе при выдаче билетов, и, естественно, в таком случае станет невозможным изменение паролей принципалов.

Настраиваем Kerberos

Создадим файл управления службой Kerberos. Рабочей областью Kerberos (в оригинале realm) назначим OFFICE.LOCALNET и ограничим перечень прослушиваемых адресов внутрисетевыми. Должно получиться так:

# cat /etc/krb5.conf

[kdc]

        database = {

                dbname = ldap:ou=KerberosPrincipals,dc=office,dc=localnet

                log_file = /var/heimdal/log

                acl_file = /var/heimdal/kadmind.acl

        }

        addresses = 127.0.0.1 192.168.0.1