OpenLDAP cn=config: No such object (32)?
I'm attempting to follow several tutorials on setting the root LDAP password (our previous sysadmin departed...abruptly), which all say more or less the same thing:
- http://sysadminnotebook.blogspot.com/2014/06/change-root-dn-password-on-openldap.html
- https://tech.feedyourhead.at/content/openldap-set-config-admin-password
- https://www.linuxwave.info/2015/07/reset-openldap-default-admin-password.html
...but getting stuck at the first step. This seems bad:
# 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)
What I've tried so far:
I can locate the data that query is intended to retrieve by digging it out of the slapd-config files:
# 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]
and confirmed that slapd is in theory set up to read from those files:
# 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
When I turn on ACL logging (and run from the command line; turning on logging from init.d makes slapd hang on start) I get this:
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
Ideas?
В ряде современных систем Linux с корневым доступом, идентифицированным 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.
Я сам наткнулся на эту проблему, но не был удовлетворен принятым ответом, поскольку он указывает объясняет причину проблемы, но очень ограничен в предоставлении фактических инструкций по ее устранению. Так что я продолжил поиск и наткнулся на эту проблему .
Предварительное условие
Мне нравится использовать этот подход SASL / EXTERNAL, и поскольку я пытаюсь создать контейнер докеров, правильная настройка slapd является частью моей намерение. Проблема в следующем: как установить права доступа на cn = config . Контейнер преобразует исходный файл slapd.conf в cn = config при первом запуске, когда в папке конфигурации, выбранной опцией -F , нет существующего cn = config ]. Таким образом, должен быть какой-то способ, чтобы 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 .