Группа администрирования OpenLdap LDAP 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 он должен иметь все разрешения.

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

Источник

1 ответ

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

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

(см. Оценка контроля доступа). Это означает, что ваш второй to * Директива никогда не оценивается, и первая применяется ко всем записям.

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

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 group и предоставить доступ на запись ко всему членам этой группы:

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

РЕДАКТИРОВАТЬ: стоит упомянуть, важно, чтобы вы использовали replace: olcAccess или удалите перед добавлением, если вы все еще используете значение по умолчанию olcAccess. add: olcAccess без удаления по умолчанию olcAccess не работает, поскольку не отменяет его.

Источник
Другие вопросы по тегам