Форум проекта Pro-LDAP.ru
Администрирование OpenLDAP => Вопросы безопасности => Access Control List (ACL) => Тема начата: mister87 от 19 Апрель 2013, 17:18:43
-
Всем здравствуйте!
Прошу помощи в решении задачи, я новичок в освоении LDAP, но задача срочная.
Необходимо настроить доступ к данным LDAP так, чтобы у суперпользователя -- на редактирование всех записей, а у пользователей -- просмотр только своих данных и редактирование только пароля!
Заранее благодарен за ответы и советы!
-
Здравствуйте! Если под суперпользователем подразумевается тот, DN которого определён в конфигурации как rootDN (olcRootDN), то для него не надо определять никаких прав -- он всегда имеет полные права на всё. В этом случае ACL будут выглядеть так:
access to attr=userPassword
by self write
by anonymous auth
by * none
access to *
by * read
Если у суперпользователя какая-то отдельная запись, тогда ACL будет выглядеть так:
access to attr=userPassword
by self write
by dn.base="cn=superuser,dc=mycompany,dc=ru" write
by anonymous auth
by * none
access to *
by dn.base="cn=superuser,dc=mycompany,dc=ru" write
by * read
Если у Вас динамическая конфигурация то второй случай будет выглядеть так (первый адаптируйте сами):
dn: olcDatabase={1}bdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to attr=userPassword
by self write
by dn.base="cn=superuser,dc=mycompany,dc=ru" write
by anonymous auth
by * none
olcAccess: {1}to *
by dn.base="cn=superuser,dc=mycompany,dc=ru" write
by * read
Егор
-
Егор, спасибо большое! По первому варианту удалось, все получилось! Получается авторизованные пользователи могут редактировать только свой пароль! Остальное на чтение!
А подскажите пожалуйста, как сделать, чтоб они видели только свою учетку, я пользуюсь phpldapadmin. После авторизации, они видят всю БД LDAP, а хочется чтоб только свою учетку!
Или может посоветуете еще более удобный клиет, желательно web-интерфейс.
-
Здравствуйте! ACL чтобы можно было видеть только свою запись:
access to attr=userPassword
by self write
by anonymous auth
by * none
access to *
by self read
by * search
Насчёт клиентов посмотрите здесь (http://pro-ldap.ru/sources/index.html#clients).
Егор
-
А как реализовать, пользователь имел возможность все свои данные редактировать, а остальных не видел!
Что-то не получилось у меня!
-
Очевидно, так:
access to attr=userPassword
by self write
by anonymous auth
by * none
access to *
by self write
by * search
Можно даже короче:
access to *
by self write
by anonymous auth
by * search
Егор
-
Егор, спасибо огромное!
-
Егор, разрешите еще раз потревожить!
Вот раз уж я уже разрешил пользователям редактировать пароль, далее тут подумал, а почему бы не попробовать подключить проверку формата измененного пароля, ну например, думаю формат такой: от 6-ти символов, и только большие и маленькие буквы?
Подскажите, пожалуйста, возможно ли такое реализовать? Если да, то как, как-то включить проверку устанавливаемого пароля по регэкспу?
-
Здравствуйте! Вам надо к свой базе данных прикрутить наложение ppolicy, тогда можно будет применять к паролям различные ограничения. Почитайте здесь (http://pro-ldap.ru/tr/zytrax/ch6/ppolicy.html), в конце страницы есть примеры. Не слишком просто, но разобраться можно, мы тут с одним товарищем настраивали историю паролей, можете посмотреть (http://pro-ldap.ru/forum/index.php?topic=27.0).
Егор
-
Егор, спасибо! Буду разбираться. Если возникнут вопросы, буду задавать!
Еще раз спасибо Вам за помощь!
-
Доброго времени суток!
В общем покопал и как я понял, то для реализации задуманного, чтоб пароль состоял из 6-ти символов и только буквы большие и маленькие, то используются след аттрибуты:
1) pwdMinLength - для определения длины
2) pwdCheckQuality и pwdCheckModule - для выставления нестандартного расширения политик, в моем случае это большие и маленькие буквы.
С первым вроде более менее понятно, а вот со вторым сложнее - не нашел никакого нормального описания.
Может что посоветуете?
-
Здравствуйте! В pwdCheckModule должна быть указана библиотека проверки паролей. Из ныне поддерживаемых самая известная -- от проекта LTB (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-password), почитайте, там хорошее описание. Библиотеку можно либо скомпилировать из исходников, либо, если у Вас centos (или другая производная redhat) -- скачать готовый rpm-пакет. Исходники и rpm можно получить на этой странице (http://ltb-project.org/wiki/download/).
Егор
-
Егор, не подскажешь, сейчас пытаюсь наложить политику, он мне выдает:
ldapadd -x -W -D cn=config -f policyAdd.ldif
Enter LDAP Password:
adding new entry "olcOverlay=ppolicy,olcDatabase={1}bdb,cn=config"
ldap_add: Invalid syntax (21)
additional info: objectClass: value #0 invalid per syntax
Наложение политики, взял из Вашего поста (http://pro-ldap.ru/forum/index.php?topic=27.msg66#msg66).
-
Здравствуйте! Скорее всего Вы не загрузили динамический модуль или не добавили набор схемы данных, необходимые для этого наложения. Если у Вас динамическая конфигурация, то посмотрите здесь (http://pro-ldap.ru/books/diving/begin/overlay.html). Если статическая -- добавьте в начало slapd.conf (до определения баз данных):
include /etc/openldap/schema/ppolicy.schema
moduleload ppolicy.la
Егор
-
Егор, доброго времени суток!
Вроде что-то начало получаться, но есть снова проблемы. Что сделал:
1) Проверил схему - применена
2) Подключение модуля ppolicy:
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/openldap
olcModuleLoad: ppolicy.la3) Установил библиотеку
check_password.so
Сразу же настроил ее
4) Наложение политики:
dn: olcOverlay=ppolicy,olcDatabase={2}bdb,cn=config
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=PPolicy Default,ou=System,dc=mycompany,dc=ru
5) Политика:
dn: cn=PPolicy Default,ou=System,dc=mycompany,dc=ru
objectClass: applicationProcess
objectClass: pwdPolicy
cn: PPolicy Default
pwdAttribute: 2.5.4.35
pwdInHistory: 3
pwdCheckModule: check_password.so
pwdCheckQuality: 1
При добавлении в базу самой политики вот что:
# ldapadd -x -W -D cn=config -f ppolicyDefault.ldif
Enter LDAP Password:
adding new entry "cn=PPolicy Default,ou=System,dc=mycompany,dc=ru"
ldap_add: Object class violation (65)
additional info: attribute 'pwdCheckModule' not allowed
В чем может быть причина? Из-за чего он не может найти атрибут pwdCheckModule?
-
Здравствуйте! Попробуйте так:
dn: cn=PPolicy Default,ou=System,dc=mycompany,dc=ru
objectClass: applicationProcess
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
cn: PPolicy Default
pwdAttribute: 2.5.4.35
pwdInHistory: 3
pwdCheckModule: check_password.so
pwdCheckQuality: 1
Егор
-
Егор, доброго Вам времени суток!
Сначала с прошедшими Вас праздниками!!!
В общем возвращаюсь к вопросу, т.к. не было времени заниматься, появлялись другие приоритетные задачи!!!
По Вашей рекомендации, последней:
dn: cn=PPolicy Default,ou=System,dc=mycompany,dc=ru
objectClass: applicationProcess
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
cn: PPolicy Default
pwdAttribute: 2.5.4.35
pwdInHistory: 3
pwdCheckModule: check_password.so
pwdCheckQuality: 1
Спасибо! Удалось добавить.
Пытаюсь поставить готовый пакет, но не получается, хочет openldap-ltb. Когда пытаюсь поставить open-ltb.ругается на openldap-servers :(
Что можете посоветовать?
Позже нашел, вот этот пакет (http://ftp://fr2.rpmfind.net/linux/mageia/distrib/cauldron/i586/media/core/release/openldap-check_password-1.1-2.mga3.i586.rpm), вроде тоже похоже. Но все сделал, но так и не работает! :(
-
Здравствуйте! Честно говоря, судя по предыдущим постам, я думал что с установкой Вы уже справились. У меня нет под рукой centos, поэтому я скомпилировал LTB-библиотеку из исходников в Ubuntu 12.04, скопировал готовый файл check_password.so туда, где лежат все модули от slapd, создал файл /etc/ldap/check_password.conf :
minPoints 3
useCracklib 0
minUpper 2
minLower 4
minDigit 1
minPunct 0
Потом исправил политику по умолчанию в DIT чтобы было так:
dn: cn=PPolicy Default,ou=System,dc=mycompany,dc=ru
objectClass: applicationProcess
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
cn: PPolicy Default
pwdAttribute: userPassword
pwdInHistory: 3
pwdCheckModule: check_password.so
pwdCheckQuality: 1
Собственно, после этого стало работать:
# ldappasswd -x -D 'uid=egor,ou=Users,dc=mycompany,dc=ru' -w 123 -s 1234
Result: Constraint violation (19)
# ldappasswd -x -D 'uid=egor,ou=Users,dc=mycompany,dc=ru' -w 123 -s 111aaa
Result: Constraint violation (19)
# ldappasswd -x -D 'uid=egor,ou=Users,dc=mycompany,dc=ru' -w 123 -s 111aaA
Result: Constraint violation (19)
# ldappasswd -x -D 'uid=egor,ou=Users,dc=mycompany,dc=ru' -w 123 -s 1aaaaAA
Последний пароль ldappasswd принял.
Вероятно, у Вас не совпала версия OpenLDAP с той, с которой товарищ собирал rpm. Соберите из исходников, должно заработать.
Егор
-
Егор, подскажите, пожалуйста, с какими параметрами собирали?
-
Здравствуйте! Последовательность действий в моём случае:
1. Сначала я убедился, что заголовочного файла cracklib у меня нет, установил стандартный пакет для Ubuntu и ещё раз проверил -- теперь файл на месте:
# whereis crack
crack:
# apt-get install libcrack2-dev (для rpm-систем тут будет другая команда)
...
# whereis crack
crack: /usr/include/crack.h
2. Далее я выяснил свою версию slapd, скачал и распаковал исходники OpenLDAP:
# slapd -V
...
# wget ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/
...
# tar xzf ./openldap-2.4.28.tgz -C /tmp/
3. После этого я скомпилировал openldap:
# cd /tmp/openldap-2.4.28
# ./configure
...
# make
...
4. Дальше я скачал и распаковал ltb-библиотеку
# wget http://tools.ltb-project.org/attachments/download/51/ltb-project-openldap-ppolicy-check-password-1.1.tar.gz
...
# tar xzf ./ltb-project-openldap-ppolicy-check-password-1.1.tar.gz -C /tmp/openldap-2.4.28/
5. Теперь, собственно, сборка:
# cd /tmp/openldap-2.4.28/ltb-project-openldap-ppolicy-check-password-1.1
# make CONFIG="/etc/ldap/check_password.conf" LDAP_INC="-I/tmp/openldap-2.4.28/include/ -I/tmp/openldap-2.4.28/servers/slapd"
...
Параметр CONFIG указывался, поскольку в Ubuntu стандартные настройки OpenLDAP лежат в /etc/ldap (а не в /etc/openldap). В параметре LDAP_INC указал пути на только что скомпилированные библиотеки OpenLDAP.
Дальше всё как я описал в предыдущем посте (http://pro-ldap.ru/forum/index.php?topic=54.msg218#msg218).
Егор
-
Егор, добрый день!
Огромное спасибо, благодаря Вашему совету и подробному описанию, мне удалось победить в данном направлении LDAP!
Но теперь следующая проблема встала предо мной, в консоли все здорово работает, а вот если через клиент (сейчас я использую LDAP Account Manager) могу менять пароль на какой угодно, правила не работают. Подскажите, что можно сделать, чтоб правило работало и в клиенте?
-
Здравствуйте! Есть мнение, что в LAM смена пароля выполняется с помощью обычной операции modify, когда значение атрибута заменяется на другое, а ldappasswd использует операцию LDAP Password Modify Extended Operation (RFC 3062 (http://tools.ietf.org/html/rfc3062)). Поэтому при изменении пароля в LAM условия наложения ppolicy не применяются. Посмотрите, может быть в настройках LAM есть какая-нибудь опция типа "использовать RFC 3062 при смене пароля".
Егор
-
Егор, доброго времени суток!
Наконец-то снова дошли руки до настройки.
Все успешно настроил, в LAM оказывается все это делается в настройках самого приложения, выставил нужные параметры = политикам установленным на сервере и все!!!
Еще раз спасибо!!!
-
Егор, разрешите вопрос.
Для общего развития?
Немного отлучусь назад по нашему диалогу. По правам на просмотр ldap. Я по Вашим советам сделал следующее:
access to *
by self write
by anonymous auth
by * searchт.е. доступ на чтение и изменение только к своих данных.
Сейчас задумался, в перспективе, сделать, чтоб у конкретного пользователя были права, на чтение всей БД, у остальных на чтение запись только своих. Подскажите, как это будет выглядеть?
-
Здравствуйте! Если у конкретного пользователя должен быть доступ на чтение всей базы, включая парольные атрибуты, то можно так:
access to *
by self write
by dn.base="uid=someuser,ou=Users,dc=mycompany,dc=ru" read
by anonymous auth
by * search
Если доступ на чтение всего, кроме парольных атрибутов, то так:
access to attr=userPassword
by self write
by anonymous auth
by * none
access to *
by self write
by dn.base="uid=someuser,ou=Users,dc=mycompany,dc=ru" read
by * search
В принципе, эти ACL из категории простейших. Не хочу показаться бестактным, но может стоит почитать теорию ACL в OLAG (http://pro-ldap.ru/tr/admin24/access-control.html) или в LFRS (http://pro-ldap.ru/tr/zytrax/ch6/#access)?
Егор
-
Егор, доброго времени суток!
Спасибо Вам огромное за помощь! Без Вас я бы еще долго разбирадся бы.
-
Егор, здравствуйте.
Помогите настроить ACL на следующую задачу:
LDAP будет использоваться только как адресаная книга, но для нескольких доменов. Необходимо чтобы у каждого домена был свой суперпользователь с полными правами, а другие пользователи каждого домена получали доступ к только к своей книге на чтение по паролю (мне видится просто единый отдельный пользователь с паролем только на чтение).
Текущий конфиг (пока заведен только один домен):
access to * by * write
database bdb
cachesize 200
suffix "dc=example,dc=ru"
rootdn "cn=admin,dc=example,dc=ru"
rootpw {SSHA}H08zq1G+kmYoYDGjxEAzlUhUfgxv+qom
directory /var/lib/ldap
index objectClass eq,pres
index cn,sn,uid eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index pgpCertID,pgpKeyID,pgpKeyType,pgpUserID,pgpKeyCreateTime sub,eq
index pgpSignerID,pgpSubKeyID,pgpKeySize,pgpKeyExpireTime sub,eq
index pgpDisabled,pgpRevoked eq
index homePhone,mobile eq
index mail eq
access to attr=userPassword
by self write
by anonymous auth
by dn.base="cn=admin,dc=example,dc=ru" write
by * none
access to attrs=userPassword
by self
by anonymous auth
by dn.regex="cn=(.+),ou=ab,dc=example,dc=ru" write
access to *
by dn.regex="cn=(.+),ou=ab,dc=example,dc=ru" write
-
Здравствуйте!
LDAP будет использоваться только как адресаная книга, но для нескольких доменов. Необходимо чтобы у каждого домена был свой суперпользователь с полными правами, а другие пользователи каждого домена получали доступ к только к своей книге на чтение по паролю (мне видится просто единый отдельный пользователь с паролем только на чтение).
Честно говоря, не совсем понятно, что Вы имеете ввиду под терминами "домен", "книга", "суперпользователь домена", "пользователи домена" и "единый отдельный пользователь". Если ACL строится под структуру дерева каталога (а это, если я правильно понял, как раз Ваш случай), что для грамотного составления ACL требуется знать эту самую структуру дерева. Короче говоря, если это не секрет, приведите свою структуру: те записи, которые должны получать доступ и те записи, к которым доступ нужен. Если секрет -- пишите в личку.
Егор
-
Не секрет.
Как я это себе представляю:
есть адресная книга LDAP для нескольких организаций с доменами example.ru и primer.ru.
Пользователи каждой из организаций должны иметь доступ только к своей адресной книге и только на чтение. Также у каждой организации должен быть свой пользователь с правами на изменение всех атрибутов и добавление новых записей (только в свою книгу).
-
Под доменом я понимаю базовые уровни дерева (dc=example,dc=ru; dc=primer,dc=com).
-
Здравствуйте! Если Вы не хотите сознаваться, я рискну погадать на кофейной гуще =).
У Вас на сервере будут облуживаться два DIT (каталога) с корневыми записями dc=example,dc=ru и dc=primer,dc=com, они заведены в интересах двух разных организаций. Соответственно, у каждого DIT будет своя административная запись rootDN.
В каждом из них будет ветка под адресную книгу, где будут храниться сведения (почта, телефоны) клиентов каждой из организаций. В первом случае это будет ou=ab,dc=example,dc=ru для адресной книги и cn=client1,ou=ab,dc=example,dc=ru для записи клиента, во втором случае это будет ou=ab,dc=primer,dc=com для адресной книги и cn=client2,ou=ab,dc=primer,dc=com для записи клиента.
Вы хотите перепоручить кому-то в каждой организации вести эти адресные книги, но не хотите при этом давать ему права rootDN, поэтому заводите отдельную запись с правами за изменение каталога, например, сn=ab_maker,dc=example,dc=ru и сn=ab_maker,primer,dc=com.
Наконец, Вы не хотите предоставить к этим DIT анонимный доступ, чтобы люди из разных организаций не могли прочитать адресные книги друг друга, поэтому Вы запрещаете анонимный доступ и заводите пользователя с паролем и правами только на чтение адресной книги, например, сn=ab_reader,dc=example,dc=ru и сn=ab_reader,primer,dc=com, а затем раздаёте сведения об этих записях и их паролях людям в соответствующих организациях, которые будут читать эти книги.
Я Вас правильно понял?
Егор
-
Сам докопался до, наверное, банальнейшего правила:
access to *
by self
by anonymous auth
by dn="uid=test,ou=addressbook,ou=services,dc=example,dc=ru" read
Где test - общий пользователь с паролем для доступа к книге на чтение. Вроде пока работает так как мне нужно.
Остался вопрос как реализовать несколько базовых уровней (для каждой органиазции). Т.е. чтобы в дереве присутствовали example.ru, primer.com и т.д.
-
Егор, Вы просто читаете мои мысли )))
-
Здравствуйте!
Сам докопался до, наверное, банальнейшего правила:
access to *
by self
by anonymous auth
by dn="uid=test,ou=addressbook,ou=services,dc=example,dc=ru" read
IMHO, так будет правильнее (исходя из тех предпосылок, что я привёл в прошлом посте):
access to dn.children="ou=ab,dc=example,dc=ru"
by anonymous auth
by dn="cn=ab_maker,dc=example,dc=ru" write
by dn="cn=ab_reader,dc=example,dc=ru" read
by * none
Для второго DIT, соответственно, по аналогии.
Остался вопрос как реализовать несколько базовых уровней (для каждой органиазции). Т.е. чтобы в дереве присутствовали example.ru, primer.com и т.д.
Поскольку корневые записи (а правильнее будет сказать, контексты именования) этих DIT разные, то нужно заводить два разных DIT в составе одного LDAP-сервера и для каждого определять свои ACL. Как завести два DIT можно посмотреть в LFRS (http://pro-ldap.ru/tr/zytrax/ch11/multi-dit.html).
Егор
-
Егор, спасибо большое за помощь. Буду ковыряться дальше.
-
Егор, еще вопрос по ACL:
вот на такое правило:
access to dn.children="ou=addressbook,dc=example,dc=ru"
by anonymous auth
by dn="cn=ab_admin,dc=example,dc=ru" write
by dn="cn=ab_read,dc=example,dc=ru" read
by * none
slaptest ругается на первую строчку правила: "warning: no by clause(s) specified in access line"
Вроде все правильно указано, что ему не нравится ?
-
Заменил на dn.base="dc=example,dc=ru" и зарабтало.
По логике этого должно хватить.
Для второго DIT просто укажу другой dn.base
-
Здравствуйте!
Заменил на dn.base="dc=example,dc=ru" и зарабтало.
По логике этого должно хватить.
Как раз по логике это неравноценная замена -- Вы ограничиваете доступ к разным частям дерева. Убедитесь, что у ab_admin есть право на запись, а у ab_reader его нет.
Егор
-
Как раз по логике это неравноценная замена -- Вы ограничиваете доступ к разным частям дерева. Убедитесь, что у ab_admin есть право на запись, а у ab_reader его нет.
Егор
Права проверил, работают корректно.
Егор, помогите пожалуйста разобраться - в Вашей редакции ACL
access to dn.children="ou=addressbook,dc=example,dc=ru"
by anonymous auth
by dn="cn=ab_admin,dc=example,dc=ru" write
by dn="cn=ab_read,dc=example,dc=ru" read
by * none
slaptest ругается на первую строчку правила: "warning: no by clause(s) specified in access line"
В чем уязвимость если я использую мой вариант (с учетом того, что для разных DIT разные rootdn и разные пароли для пользователей) ?
-
Здравствуйте! Я тут поэкспериментировал немного с ACL, вышло что-то в таком духе (slapd.conf):
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
database mdb
suffix "dc=example,dc=ru"
directory ./mdb
rootdn "cn=admin,dc=example,dc=ru"
rootpw admin
maxsize 1073741824
# Разрешаем аутентификацию по userPassword
access to attrs=userPassword
by anonymous auth
by * none
# Разрешаем ab_admin ДОБАВЛЯТЬ записи в addressbook
# (но не саму запись addressbook)
access to dn.base="ou=addressbook,dc=example,dc=ru" attrs=children
by dn="cn=ab_admin,dc=example,dc=ru" write
by * none
# Разрешаем ab_admin ИЗМЕНЯТЬ записи в addressbook
# а ab_reader ЧИТАТЬ записи в addressbook
# (но не саму запись addressbook)
access to dn.children="ou=addressbook,dc=example,dc=ru"
by dn="cn=ab_admin,dc=example,dc=ru" write
by dn="cn=ab_reader,dc=example,dc=ru" read
by * none
# Остальные записи просматривать запрещено
access to *
by users search
by * none
LDIF, с которого я инициализировал каталог (init.ldif):
dn: dc=example,dc=ru
objectClass: organization
objectClass: dcObject
dc: example
o: example
dn: cn=ab_admin,dc=example,dc=ru
objectClass: inetOrgPerson
cn: ab_admin
sn: ab_admin
userPassword: ab_admin
dn: cn=ab_reader,dc=example,dc=ru
objectClass: inetOrgPerson
cn: ab_reader
sn: ab_reader
userPassword: ab_reader
dn: ou=addressbook,dc=example,dc=ru
objectClass: organizationalUnit
ou: addressbook
dn: cn=client1,ou=addressbook,dc=example,dc=ru
objectClass: inetOrgPerson
cn: client1
sn: client1
mail: boss@some.org
Запускаю slapd, инициализирую каталог от имени rootDN:
# /usr/lib/openldap/slapd -h 'ldap://127.0.0.1:9000' -f ./slapd.conf
# ldapadd -H 'ldap://127.0.0.1:9000' -f ./init.ldif -x -D 'cn=admin,dc=example,dc=ru' -w admin
adding new entry "dc=example,dc=ru"
adding new entry "cn=ab_admin,dc=example,dc=ru"
adding new entry "cn=ab_reader,dc=example,dc=ru"
adding new entry "ou=addressbook,dc=example,dc=ru"
adding new entry "cn=client1,ou=addressbook,dc=example,dc=ru"
Поиск от анонима, ab_reader, ab_admin:
# ldapsearch -x -LLL -H 'ldap://127.0.0.1:9000' -b 'dc=example,dc=ru'
No such object (32)
# ldapsearch -x -LLL -H 'ldap://127.0.0.1:9000' -b 'dc=example,dc=ru' -D 'cn=ab_reader,dc=example,dc=ru' -w ab_reader
dn: cn=client1,ou=addressbook,dc=example,dc=ru
objectClass: inetOrgPerson
cn: client1
sn: client1
mail: boss@some.org
# ldapsearch -x -LLL -H 'ldap://127.0.0.1:9000' -b 'dc=example,dc=ru' -D 'cn=ab_admin,dc=example,dc=ru' -w ab_admin
dn: cn=client1,ou=addressbook,dc=example,dc=ru
objectClass: inetOrgPerson
cn: client1
sn: client1
mail: boss@some.org
Всё штатно. Попромуем добавить/изменить записи в адресной книге, для этого создадим modify.ldif:
dn: cn=client2,ou=addressbook,dc=example,dc=ru
changetype: add
objectClass: inetOrgPerson
cn: client2
sn: client2
mail: dima@some.org
dn: cn=client1,ou=addressbook,dc=example,dc=ru
changetype: modify
replace: mail
mail: manager@some.org
Попробуем применить его от анонима ab_reader, ab_admin:
# ldapmodify -x -H 'ldap://127.0.0.1:9000' -f ./modify.ldif
modifying entry "ou=addressbook,dc=example,dc=ru"
ldap_modify: Strong(er) authentication required (8)
additional info: modifications require authentication
# ldapmodify -x -H 'ldap://127.0.0.1:9000' -f ./modify.ldif -D 'cn=ab_reader,dc=example,dc=ru' -w ab_reader
adding new entry "cn=client2,ou=addressbook,dc=example,dc=ru"
ldap_add: Insufficient access (50)
additional info: no write access to parent
# ldapmodify -x -H 'ldap://127.0.0.1:9000' -f ./modify.ldif -D 'cn=ab_admin,dc=example,dc=ru' -w ab_admin
adding new entry "cn=client2,ou=addressbook,dc=example,dc=ru"
modifying entry "cn=client1,ou=addressbook,dc=example,dc=ru"
Всё как положено. Последний тест -- пробуем изменить саму запись addressbook. Создадим modify2.ldif:
dn: ou=addressbook,dc=example,dc=ru
changetype: modify
add: description
description: Address Book
Попробуем применить его от имени ab_admin:
# ldapmodify -x -H 'ldap://127.0.0.1:9000' -f ./modify2.ldif -D 'cn=ab_admin,dc=example,dc=ru' -w ab_admin
modifying entry "ou=addressbook,dc=example,dc=ru"
ldap_modify: Insufficient access (50)
Все тесты прошли успешно.
Егор
-
Егор, еще раз спасибо. Обязательно попробую Ваш вариант.