Вопросы Теги

OpenLdap LDAP admin group ALC

У меня есть следующий файл LDIF для создания ldapadmins. 

dn: ou=Manager,dc=example,dc=org
objectClass: organizationalUnit
objectClass: top
ou: Manager

dn: ou=Customers,dc=example,dc=org
objectClass: organizationalUnit
objectClass: top
ou: Customers

dn: cn=customerAccountAdmin,ou=Manager,dc=example,dc=org
cn: customerAccountAdmin
objectClass: organizationalRole
objectClass: simpleSecurityObject
objectClass: top
userPassword: {SSHA}*removed*

dn: ou=Users,ou=Customers,dc=example,dc=org
objectClass: organizationalUnit
objectClass: top
ou: Users

dn: ou=Groups,ou=Customers,dc=example,dc=org
objectClass: organizationalUnit
objectClass: top
ou: Groups

Я создал следующий ldif, чтобы разрешить нескольким администраторам для администратора phpldap. (они будут управлять несколькими клиентами) 

dn: olcDatabase={1}mdb,cn=config
changetype: modify
delete: olcAccess
-
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by dn="cn=admin,dc=example,dc=org" write by anonymous auth by * none
olcAccess: {1}to * by self read by dn="cn=admin,dc=example,dc=org" write by * none
olcAccess: {2}to * by dn.base="cn=customerAccountAdmin,ou=Manager,dc=example,dc=org" write

После входа в систему администратора phpldap, customerAccountAdmin не может видеть дерево. но с точки зрения ALC он должен иметь все разрешения.

Я что-то пропускаю? Это более простой способ добиться этого?

0
задан 26 February 2020 в 11:33
1 ответ

Проблема возникает из-за порядка, в котором оцениваются директивы access :

В рамках этого приоритета директивы доступа проверяются в том порядке, в котором они появляются в конфигурационный файл. Slapd останавливается на селекторе first , который соответствует записи и / или атрибуту. Соответствующая директива доступа - это та директива, которую slapd будет использовать для оценки доступа.

(см. Access Control Evaluation ). Это означает, что ваша вторая директива - * никогда не оценивается, а первая применяется ко всем записям.

Вам следует изменить правила доступа, чтобы они выглядели так: 

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: to attrs=userPassword,shadowLastChange
  by self write
  by dn="cn=admin,dc=example,dc=org" write
  by anonymous auth
  by * none
olcAccess: to *
  by self read
  by dn="cn=admin,dc=example,dc=org" write
  by dn.base="cn=customerAccountAdmin,ou=Manager,dc=example,dc=org" write
  by * none

Альтернатива (которая сочетается с вашим предыдущий вопрос ) заключается в создании группы cn = Administrators, dc = example, dc = org и предоставлении доступа на запись ко всему членам этой группы: 

dn: cn=Administrators,dc=example,dc=org
changetype: add
cn: Administrators
objectClass: groupOfNames
member: cn=customerAccountAdmin,ou=Manager,dc=example,dc=org
member: cn=admin,dc=example,dc=org

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: to dn.exact="cn=Administrators,dc=example,dc=org"
  by dn.exact="cn=admin,dc=example,dc=org" write
  by * none
olcAccess: to attrs=userPassword,shadowLastChange
  by self write
  by group.exact="cn=Administrators,dc=example,dc=org" write
  by anonymous auth
  by * none
olcAccess: to *
  by self read
  by group.exact="cn=Administrators,dc=example,dc=org" write
  by * none
0
ответ дан 30 March 2020 в 01:32

Теги

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