Форум проекта Pro-LDAP.ru
Администрирование OpenLDAP => Вопросы безопасности => Access Control List (ACL) => Тема начата: 2life от 08 Август 2019, 11:50:50
-
Добрый день,
установлен Ubuntu Server 19.04 x64, настраиваю OpenLDAP первый раз, так что сильно не бейтеJ.
Сервер работает без ошибок:
root@fssrv2:/etc/ldap/schema# tail -f /var/log/slapd.log
Aug 8 08:49:34 fssrv2 slapd[23811]: daemon: shutdown requested and initiated.
Aug 8 08:49:34 fssrv2 slapd[23811]: slapd shutdown: waiting for 0 operations/tasks to finish
Aug 8 08:49:34 fssrv2 slapd[23811]: DIGEST-MD5 common mech free
Aug 8 08:49:34 fssrv2 slapd[23811]: DIGEST-MD5 common mech free
Aug 8 08:49:34 fssrv2 slapd[23811]: slapd stopped.
Aug 8 08:49:34 fssrv2 slapd[26823]: ...done.
Aug 8 08:49:34 fssrv2 slapd[26830]: * Starting OpenLDAP slapd
Aug 8 08:49:34 fssrv2 slapd[26844]: @(#) $OpenLDAP: slapd (Ubuntu) (Jul 26 2019 17:21:00) $#012#011Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>
Aug 8 08:49:34 fssrv2 slapd[26846]: slapd starting
Aug 8 08:49:34 fssrv2 slapd[26830]: ...done.
adm1n@fssrv2:~$ sudo ldapsearch -QLLL -Y EXTERNAL -H ldapi:/// -b 'cn=config' dn
dn: cn=config
dn: cn=module{0},cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: cn={4}autofs,cn=schema,cn=config
dn: olcBackend={0}mdb,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}mdb,cn=config
Содержимое файла nssproxy.acl.ldif, впрочем как и в примере на сайте
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to *
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth" manage
by * break
-
add: olcAccess
olcAccess: {1}to attrs=userPassword
by self write
by anonymous auth
-
add: olcAccess
olcAccess: {2}to *
by self read
by dn.base="cn=nssproxy,ou=users,dc=domain,dc=lan" read
Получаю такую ошибку:
root@fssrv2:/etc/ldap/schema# ldapmodify -xWD cn=admin,dc=domain,dc=lan -f nssproxy.acl.ldif
Enter LDAP Password:
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Insufficient access (50)
Поиск из мануала не отрабатывает:
root@fssrv2:/etc/ldap/schema# ldapsearch -xLLLWD cn=admin,dc=domain,dc=lan "(objectClass=*)"
Enter LDAP Password:
No such object (32)
Права у пользователя admin должны быть, так как весь каталог создавался им же. При установке отказался от пакета sudo-ldap, не очень понимаю зачем он там нужен. Так же сертификаты сделал, но что-то с ними не работает :)
-
Здравствуйте! Как я понял, Вы хотите разобраться, почему у пользователя cn=admin,dc=domain,dc=lan нет прав на изменение конфигурации сервера OpenLDAP. Дело в том, что есть конфигурационный каталог cn=config и есть пользовательский каталог dc=domain,dc=lan. Они содержат разную информацию и у каждого из них своё разграничение доступа. Пользователь cn=admin,dc=domain,dc=lan, как я понимаю, это Ваша административная учётная запись (в терминологии OpenLDAP -- rootDN) для пользовательского каталога, у неё полные права на выполнение любых действий в каталоге с контекстом именования dc=domain,dc=lan. Но эта запись не имеет никакого отношения (и, соответственно, никаких прав) к конфигурационному каталогу cn=config.
Вы собираетесь внести изменения в настройку сервера OpenLDAP путём модификации записи olcDatabase={1}mdb,cn=config (как видите, эта запись входит в контекст именования cn=config). Соответственно, Вам нужно выполнить это действие либо от имени rootDN каталога cn=config, либо от имени другого пользователя, имеющего права на модификацию каталога cn=config. Надеюсь, не очень путано объяснил.
По умолчанию в Ubuntu с каталогом cn=config можно произвести любые действия, подключившись по протоколу ldapi:/// от имени системной учётной записи root. Вы, кстати, делали это, когда с помощью команды ldapsearch выводили содержимое каталога cn=config. Для ldapmodify ситуация аналогичная:
$ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f nssproxy.acl.ldif
В данном случае используется подключение к каталогу не от имени записи в каталоге, а аутентификация делегируется стороннему механизму. Это так называемая SASL-аутентификация, конкретно в этом случае с использованием механизма EXTERNAL.
Егор
-
Спасибо ) Вы решили этот мой вопрос. Пhодолжаю изучать OpenLDAP дальше. Для этого создам новую тему, т.к. кое-где уже застрялJ