Автор Тема: Проблема с хитрой конфигурацией ACL  (Прочитано 17174 раз)

olegd

  • Новичок
  • *
  • Сообщений: 2
    • Просмотр профиля
Доброго всем ...
Если не затруднит, помогите разобраться с формированием листа доступа, сам что-то ни как не могу разобраться.
Суть такова: хочу реализовать следющие права доступа

1. На первом этапе пользователи из группы "ldapmanagers" могут создавать (только создавать, удалять не могут) пользовательские аккаунты в указанной ветке каталога;
2. далее нужно дать тем же пользователям из группы "ldapmanagers" права изменять значения из разрешенного списка атрибутов.

Разрешения для создания записей я сделал следуюущим образом (1-е правило):

access to dn.subtree="ou=Employees,o=mycompany.com"
        attrs=children
        by set="[cn=ldapmanagers,ou=Groups,o=mycompany.com]/memberUid & user/uid" =a
access to dn.subtree="ou=Employees,o=mycompany.com" filter=(objectClass=mycompanyEmployee)
        by set="[cn=ldapmanagers,ou=Groups,o=mycompany.com]/memberUid & user/uid" =arscdx
        by * break

Разрешения на модификацию значений аттрибутов вот таким (2-е правило):

access to dn.subtree="ou=Employees,o=mycompany.com" filter=(objectClass=mycompanyEmployee)
        attrs=l,st,street,title,postalAddress,postalCode,co,employeeType,jpegPhoto,homePhone,cellPhone
        by set="[cn=ldapmanagers,ou=Groups,o=mycompany.com]/memberUid & user/uid" write
        by * break


И, наконец, суть проблемы, в источнике которой я ни как не могу разобраться такова:
если я вношу ACL в том виде, в котором я указал в slapd.conf, то пользователям из группы "ldapmanagers" доступна возможность создания пользователей (с запретом их последуюущего их удаления), но при этом при попытке модификации значений аттрибутов LDAP-сервер возвращает "Insufficient access" и, соответственно не дает пользователю модифицировать записи.
Если я добавляю control "continue" в предпоследнюю строку первого правила, то есть привожу первое правило в такому виду:

access to dn.subtree="ou=Employees,o=mycompany.com"
        attrs=children
        by set="[cn=ldapmanagers,ou=Groups,o=mycompany.com]/memberUid & user/uid" =a
access to dn.subtree="ou=Employees,o=mycompany.com" filter=(objectClass=mycompanyEmployee)
        by set="[cn=ldapmanagers,ou=Groups,o=mycompany.com]/memberUid & user/uid" =arscdx continue
        by * break

то пользователи из группы "ldapmanagers" могут редактировать записи (начинает отрабатывать второе правило), но теряют возможность добавлять новые, то есть перестает работать первое правило.

Версия сервера у меня OpenLDAP 2.4 самописной схемой и конфигурацией в salpd.conf, крутится он в Debian Linux. Если кто-нибудь сталкивался с такой конфигурацией доступа, поделитесь, пожалуйста, решением, ато я ни как не могу найти сути проблемы.
Заранее спасибо.

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 486
    • Просмотр профиля
Re: Проблема с хитрой конфигурацией ACL
« Ответ #1 : 07 Ноябрь 2012, 07:54:07 »
Здравствуйте! На самом деле правил 3 =), и чтобы работало третье, во втором нужен control, отличный от stop -- это понятно. Правда я бы использовал break, вместо continue.  Для ou=Employees,o=mycompany.com не хватает правила для attrs=entry, но, поскольку Вы используете dn.subtree, можно попробовать вставить его в первый ACL. В общем, вот мой вариант ACL:

access to dn.subtree="ou=Employees,o=mycompany.com"
        attrs=children,entry
        by set="[cn=ldapmanagers,ou=Groups,o=mycompany.com]/memberUid & user/uid" =ar

access to dn.subtree="ou=Employees,o=mycompany.com" filter=(objectClass=mycompanyEmployee)
        by set="[cn=ldapmanagers,ou=Groups,o=mycompany.com]/memberUid & user/uid" =arscdx break
        by * break

access to dn.subtree="ou=Employees,o=mycompany.com" filter=(objectClass=mycompanyEmployee)
        attrs=l,st,street,title,postalAddress,postalCode,co,employeeType,jpegPhoto,homePhone,cellPhone
        by set="[cn=ldapmanagers,ou=Groups,o=mycompany.com]/memberUid & user/uid" write
        by * break

В первом ACL я добавил entry в attrs и r в привилегии (чтобы можно было хоть посмотреть, что вышло), во втором - break после первого условия by. Так работает (я проверил). Чует моё сердце, что можно и покрасивее что-то изобразить, но пока некогда экспериментировать.

Егор.

olegd

  • Новичок
  • *
  • Сообщений: 2
    • Просмотр профиля
Re: Проблема с хитрой конфигурацией ACL
« Ответ #2 : 07 Ноябрь 2012, 14:25:40 »
Спасибо за помощь, Егор, вот только и при этой конфигурации по-прежнему при операциях модификации аттрибутов я получаю "Insufficient access", то есть 3-й ACL игнорируется. Продолжу в соотвествии с вашими подсказками дальнейший поиск проблемы ...

В качестве ликбеза, может ли на эти ACL (они внесены в backend секцию конфига) влиять следуюущие предопределенные правила из глобальных директив конфигурационного файла ?

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

access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read

Заранее всем спасибо.

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 486
    • Просмотр профиля
Re: Проблема с хитрой конфигурацией ACL
« Ответ #3 : 08 Ноябрь 2012, 05:09:04 »
Здравствуйте! У меня все работает как надо =). Вот тестовый slapd.conf:

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/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args
       
access to *
        by self read
        by users read
        by anonymous auth

access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read

#######################################################################
# BDB database definitions
#######################################################################

database        bdb
suffix          "o=mycompany.com"
directory       /var/openldap/mycompany.com
rootdn          "cn=Manager,o=mycompany.com"
rootpw          secret
       
access to dn.subtree="ou=Employees,o=mycompany.com"
        attrs=children,entry
        by set="[cn=ldapmanagers,ou=Groups,o=mycompany.com]/memberUid & user/uid" =ar
       
access to dn.subtree="ou=Employees,o=mycompany.com" filter=(objectClass=inetOrgPerson)
        by set="[cn=ldapmanagers,ou=Groups,o=mycompany.com]/memberUid & user/uid" =arscdx continue
        by * break
       
access to dn.subtree="ou=Employees,o=mycompany.com" filter=(objectClass=inetOrgPerson)
        attrs=jpegPhoto,homePhone,mobile
        by set="[cn=ldapmanagers,ou=Groups,o=mycompany.com]/memberUid & user/uid" write
        by * break
Поскольку Вашего класса у меня не было, я использовал inetOrgPerson и его атрибуты, но суть та же.

Вот первоначальное содержимое DIT:
dn: o=mycompany.com
objectClass: organization
o: mycompany.com

dn: ou=Employees,o=mycompany.com
objectClass: organizationalUnit
ou: Employees

dn: uid=egor,ou=Employees,o=mycompany.com
objectClass: inetOrgPerson
objectClass: posixAccount
uid: egor
cn: Egor
sn: Egor
uidNumber: 1001
gidNumber: 1000
homeDirectory: /home/egor
userPassword: egor
mobile: 89xxxxxxxxx

dn: ou=Groups,o=mycompany.com
objectClass: organizationalUnit
ou: Groups

dn: cn=ldapmanagers,ou=Groups,o=mycompany.com
objectClass: posixGroup
cn: ldapmanagers
gidNumber: 1000
memberUid: egor

Теперь я пытаюсь добавить такого пользователя:
dn: uid=olegd,ou=Employees,o=mycompany.com
objectClass: inetOrgPerson
uid: olegd
cn: Oleg
sn: D
mobile: 89xxxxxxxxx

# ldapadd  -x -D 'uid=egor,ou=Employees,o=mycompany.com' -W -f ./002-new_user.ldif
Enter LDAP Password:
adding new entry "uid=olegd,ou=Employees,o=mycompany.com"

Занёсся =). Теперь откорректируем его:
dn: uid=olegd,ou=Employees,o=mycompany.com
changetype: modify
replace: mobile
mobile: +79xxxxxxxxx

# ldapmodify  -x -D 'uid=egor,ou=Employees,o=mycompany.com' -W -f ./003-modify_user.ldif
Enter LDAP Password:
modifying entry "uid=olegd,ou=Employees,o=mycompany.com"

Все опять сработало =).

Проверки на slapacl:
# slapacl -f /etc/openldap/slapd.conf -v -D 'uid=egor,ou=Employees,o=mycompany.com' -b "ou=Employees,o=mycompany.com"
authcDN: "uid=egor,ou=employees,o=mycompany.com"
entry: =ar
children: =ar
objectClass=organizationalUnit: =0
ou=Employees: =0
structuralObjectClass=organizationalUnit: =0
entryUUID=539e9a9f-4b1c-4bc7-9d2e-4a471561ccb6: =0
creatorsName=cn=manager,o=mycompany.com: =0
createTimestamp=20121107234031Z: =0
entryCSN=20121107234031.220046Z#000000#000#000000: =0
modifiersName=cn=manager,o=mycompany.com: =0
modifyTimestamp=20121107234031Z: =0

# slapacl -f /etc/openldap/slapd.conf -v -D 'uid=egor,ou=Employees,o=mycompany.com' -b "uid=olegd,ou=Employees,o=mycompany.com"
authcDN: "uid=egor,ou=employees,o=mycompany.com"
entry: =ar
children: =ar
objectClass=inetOrgPerson: =arscxd
uid=olegd: =arscxd
cn=Oleg: =arscxd
sn=D: =arscxd
structuralObjectClass=inetOrgPerson: =arscxd
entryUUID=3a0a179f-8ff0-41ca-b09b-d20dcadb4b77: =arscxd
creatorsName=uid=egor,ou=Employees,o=mycompany.com: =arscxd
createTimestamp=20121107234143Z: =arscxd
mobile=+79xxxxxxxxx: write(=wrscxd)
entryCSN=20121107234158.275632Z#000000#000#000000: =arscxd
modifiersName=uid=egor,ou=Employees,o=mycompany.com: =arscxd
modifyTimestamp=20121107234158Z: =arscxd
Всё согласно ACL (см., например, атрибут mobile).

Егор