Вопросы Теги

OpenLDAP ACLs не работает

Первые вещи сначала, я в настоящее время работаю с OpenLDAP: slapd 2.4.36 на выпуске 19 Fedora (CAT Schrödinger).

Я имею, просто устанавливают openldap с конфеткой, и моя конфигурация является следующей:

##### OpenLDAP Default configuration #####
#
##### OpenLDAP CORE CONFIGURATION #####
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema

pidfile         /var/lib/ldap/slapd.pid

loglevel trace

##### Default Schema #####

database mdb
directory /var/lib/ldap/
maxsize 1073741824

suffix "dc=domain,dc=tld"
rootdn "cn=root,dc=domain,dc=tld"
rootpw {SSHA}SECRETP@SSWORD


##### Default ACL #####
access to attrs=userpassword
        by self write
        by group.exact="cn=administrators,ou=builtin,ou=groups,dc=domain,dc=tld" write
        by anonymous auth
        by * none

Я запускаю свое использование услуг OpenLDAP:

/usr/sbin/slapd -u ldap -h ldapi:/// ldap:/// -f /etc/openldap/slapd.conf

Поскольку Вы видите, что это - довольно простой ACL, которые имеют целью предоставлять доступ к userPassword, приписывают определенной группе, только для чтения, затем чтению владельца, и пишут в анонимного автора требования и отказывают в доступе всем остальным.

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

# search result
search: 2
result: 32 No such object

# numResponses: 1

вот запрос ldapsearch:

ldapsearch -H ldap.domain.tld -W -b dc=domain,dc=tld -s sub -D cn=user,ou=service,ou=employees,ou=users,dc=domain,dc=tld

Я не указывал фильтра, поскольку я хочу проверить, что ldapsearch правильно печатает только позволенный атрибут.

@SvW здесь - то, что я поставил свой slapd.conf согласно Вашему exemple и Документации OpenLDAP:

Я отредактировал свой slapd.conf со следующими правилами ACLs, устраняющими group.exact для более легкой отладки:

access to *
    by self read
    by anonymous auth
    by * none

access to attrs=userpassword
    by self write
    by anonymous auth
    by * none

но еще раз, я сталкиваюсь

32 Никаких Таких объектных ошибки

когда я пробую следующий ldapsearches:

 ldapsearch -W -s sub -D cn=user,ou=service,ou=employees,ou=users,dc=domain,dc=tld -b dc=domain,dc=tld userpassword=*

или без фильтра:

 ldapsearch -W -s sub -D cn=user,ou=service,ou=employees,ou=users,dc=domain,dc=tld -b dc=domain,dc=tld
0
задан 1 March 2018 в 23:35
2 ответа

Попробуйте с

access to attrs=userPassword

вместо вашего предыдущего

access to attrs=userpassword
-1
ответ дан 5 December 2019 в 18:48

Firefox, как известно, строго проверяет всю цепочку сертификатов, и, скорее всего, вы неправильно указали все сертификаты в цепочке. Недавно у меня была похожая проблема с Firefox и SSL сертификатом Comodo на Lighttpd, и проблема заключалась в том, что я не перечислил цепочку в ssl.ca-файле корректно.

Согласно RFC 2246, сертификат отправителя должен прийти первым, и каждый последующий сертификат должен непосредственно сертифицировать предыдущий. В итоге я получил четыре сертификата в цепочке вплоть до корня CA.

certificate_list. Это последовательность (цепочка) сертификатов X.509v3. Сертификаты отправителя сертификат должен быть первым в списке. Каждый следующий сертификат должен непосредственно свидетельствовать о том, что он предшествует ему. Потому что проверка сертификата требует распространения корневых ключей самостоятельно, самоподписанный сертификат, в котором указана корневой центр сертификации по желанию может быть исключен из цепь, при условии, что удаленный конец уже должен быть Для проверки попробуйте добавить 

access to * by * read

после первой записи ACL.

Это всё равно должно ограничить пользовательское пароль , но явно позволит вам прочитать все остальные поля (я считаю, что OpenLDAP добавляет неявно в * на * ни одного , в противном случае, смотрите раздел 8.3.4 документации -).

Редактирование:

Ограничивает ли оно поле пароля? Это не совсем понятно из Вашего комментария. Если нет, запомните ответ @Janne и проверьте правильность написания userPassword. Если он работает, то вам придется начать с него добавлять ограничения. Следующее не протестировано, но должно сработать (это может быть слишком ограничительным). 

access to * 
    by self read 
    by group.exact="cn=administrators,ou=builtin,ou=groups,dc=domain,dc=tld" write
    by * none
0
ответ дан 5 December 2019 в 18:48

Теги

Похожие вопросы