Я пытаюсь следовать нескольким руководствам по установке корневого пароля LDAP (наш предыдущий системный администратор ушел ... внезапно), которые все говорят примерно одно и то же:
... но застрял на первом этапе. Это кажется плохим:
# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
No such object (32)
Что я пробовал до сих пор:
Я могу найти данные, которые должен получить запрос, извлекая их из файлов slapd-config:
# find /etc/ldap/slapd.d -type f -exec grep Root {} +
/etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif:olcRootDN: cn=admin,cn=config
/etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif:olcRootPW: {SSHA}[xxxxxx hash redacted xxxxxx]
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcRootDN: cn=admin,dc=example,dc=com
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcRootPW: {SSHA}[xxxxxx hash redacted xxxxxx]
и подтвердил, что slapd теоретически настроен для чтения из этих файлов:
# ps -ef | grep slapd
openldap 2244 1 0 Oct26 ? 00:00:16 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
Когда я включаю ведение журнала ACL (и запускаю его из командной строки; включение ведения журнала из init.d приводит к зависанию slapd при запуске), я получаю следующее:
5bdb2ef2 => access_allowed: search access to "cn=config" "entry" requested
5bdb2ef2 => acl_get: [1] attr entry
5bdb2ef2 => acl_mask: access to entry "cn=config", attr "entry" requested
5bdb2ef2 => acl_mask: to all values by "gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth", (=0)
5bdb2ef2 <= check a_dn_pat: *
5bdb2ef2 <= acl_mask: [1] applying none(=0) (stop)
5bdb2ef2 <= acl_mask: [1] mask: none(=0)
5bdb2ef2 => slap_access_allowed: search access denied by none(=0)
5bdb2ef2 => access_allowed: no more rules
Идеи?
Я сам наткнулся на эту проблему, но не был удовлетворен принятым ответом, поскольку он указывает на причину проблемы, но очень ограничен в предоставлении фактических инструкций о том, как ее исправить. Поэтому я продолжал искать и споткнулся Эта проблема.
Мне нравится использовать этот подход SASL / EXTERNAL, и поскольку я пытаюсь создать контейнер докеров, правильная настройка slapd является частью моих намерений. Проблема в том, как установить права доступа на cn=config. Контейнер преобразует исходный файл slapd.conf в cn=config при первом запуске, когда нет существующего cn=config в папке конфигурации, выбранной опцией -F. Так что должен быть способ получить cn=config настройка разрешений по желанию.
С помощью rootDN кажется странным, поскольку он настроен в рамках другой базы данных и в соответствии с ранее полученными cn=config конфигурация по-прежнему привязана к другой базе данных.
К тому же cn=config настроен на предоставление none разрешения для всех, кто имеет доступ ко всему в базе данных по адресу cn=config. Проверить файл /your/config/dir/cn=config/olcDatabase={0}config.ldif:
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 e01f7658
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: a85462ad-0102-456d-a2d7-e6d082b7e613
creatorsName: cn=config
createTimestamp: 20190429143842Z
entryCSN: 20190429143842.339724Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20190429143842Z
В нем четко говорится olcAccess: {0}to * by * none так что я почти уверен, что использую rootDN тоже не помогает.
На существующем сервере LDAP применяется другое правило доступа:
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
Итак, это то, что мне нужно в моем случае!
При конвертации из slapd.conf в cn=config slapd и его инструменты принимают частичную конфигурацию итоговой базы данных. olcDatabase={0}config это результирующее DN для базы данных с именем config. Поэтому добавьте конфигурацию для этой базы данных в свой файл. Следующий отрывок, добавленный в конец моего файла slapd.conf, был взят из проблемы, связанной ранее:
database config
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * read
Не упустите возможность удалить любую существующую папку конфигурации поэтому обновленный файл slapd.conf будет преобразован в cn=config снова.
В ряде современных систем Linux root, как определено SASL/EXTERNAL так как gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth либо rootDN или имеет manager разрешения при установке openldap-server / slapd.
Для вашей существующей установки это не так.
Если вы знаете пароль для различных rootDN, используйте их. В противном случае замените свой rootDN (или его пароль) на то, что вы можете использовать. Вам придется сделать это за пределами LDAP, отредактировав /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif или аналогичный и перезапустив slapd.