ACL в slapd.conf

[alexander]

Коллеги, добрый день.

Прошу помочь с решением проблемы разграничения прав доступа к каталогу OpenLDAP.
В каталог экспортируется адресная книга почтового сервера. Схема формируется сторонним ПО и изменить её без потери функциональности невозможно. В табличном виде содержимое каталога выглядит так:

o=org,c=US
   ou=unit
      mail=a@test1.ru
      mail=b@test1.ru
      mail=c@test1.ru
      mail=10@test2.ru
      mail=20@test2.ru
      mail=30@test2.ru
      mail=x@test3.ru
      mail=y@test3.ru
      mail=z@test3.ru
     
Вопрос: как сформулировать ACL "access to" в slapd.conf так, чтобы ограничить доступ к адресной книге на основании домена в поле mail? Т.е. чтобы авторизованному пользователю было разрешено просматривать только контакты из явно указанного ему домена, а не всех. Например, user1 имел доступ только к контактам с mail=*@test1.ru, user2 только к mail=*@test2.ru и т.д.

Конструкция
access to dn="mail=*@test1.ru,ou=unit,o=org,c=US"
      by users read
не работает — пользователь не видит даже ou=unit

Подскажите в какую сторону копать?

[egor]

Здравствуйте!

Задача слишком абстрактная: не понятно, как представлены в каталоге user1 и user2, какая связь между ними и реальными почтовыми доменами (вряд ли же по номеру пользователя и номеру почтового домена =) )?

В такой постановке как сейчас, задачу можно решить регулярными выражениями (test1 связать с user1 по цифре 1 в конце). В реальных условиях такое, скорее всего, не подойдёт. Пока вижу решение задачи в использовании фильтра в условии <what> директивы access, типа такого:

Код: [Выделить]

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

access to dn.children="ou=unit,o=org,c=US" filter=(mail=*@test1.ru)
  by dn="uid=user1,ou=Users,o=org,c=US" read
  by * none

access to dn.children="ou=unit,o=org,c=US" filter=(mail=*@test2.ru)
  by dn="uid=user2,ou=Users,o=org,c=US" read
  by * none

access to dn.children="ou=unit,o=org,c=US"
  by * none

access to *
  by self write
  by * read

Вместо конкретных учёток в условии <who> директивы access целесообразнее использовать группы пользователей.

Если покажите примеры учёток пользователей и реальных почтовых доменов, можно попытаться придумать что-то более оптимальное.

Егор

[alexander]

Здравствуйте, Егор!

Спасибо за оперативный и содержательный ответ. Связь между user1 и domain1 совершенно произвольная, устанавливаемая волюнтаристски C uid=user1 не заработало, а с cn=user1 получилось.

И самое главное - конструкция access to dn.children="ou=unit,o=org,c=US" filter=(mail=*@test1.ru) действительно производит требуемую фильтрацию доступа. Теперь пользователь user1 видит только *@test1.ru, а user2 только *@test2.ru Большое спасибо!

Использовать группы в условии <who> директивы access в моём случае нет необходимости - на каждый домен будет одна единая учётная запись для подключения к адресной книге.

Подскажите ещё, пожалуйста, как закрыть от чтения user1/user2 все остальные ou кроме явно описанного?

Если убрать

Код: [Выделить]

access to *
  by self write
  by * read

то открывается только корень - o=org,c=US без содержимого.

Если добавить

Код: [Выделить]

access to dn="ou=unit,o=org,c=US"
  by dn="cn=user1,ou=Users,o=org,c=US" read
  by * none
то до фильтрации не доходит - отображаются контакты всех доменов.

С уважением,
Александр

[egor]

Подскажите ещё, пожалуйста, как закрыть от чтения user1/user2 все остальные ou кроме явно описанного?

Опять же, всё зависит от структуры каталога. В общем случае, предполагая, что записи user1 и user2 лежат в ou=Users,o=org,c=US, можно сделать так (поменялось последнее правило):

Код: [Выделить]

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

access to dn.children="ou=unit,o=org,c=US" filter=(mail=*@test1.ru)
  by dn="cn=user1,ou=Users,o=org,c=US" read
  by * none

access to dn.children="ou=unit,o=org,c=US" filter=(mail=*@test2.ru)
  by dn="cn=user2,ou=Users,o=org,c=US" read
  by * none

access to dn.children="ou=unit,o=org,c=US"
  by * none

access to *
  by dn.children="ou=Users,o=org,c=US" search
  by self write
  by * read


Если убрать ...
Если добавить ...

Добавлять и убирать правила ACL нужно с умом: они применяются одно за другим, и поэтому, добавив или убрав правило, можно разрушить всю цепочку. Механизм ACL OpenLDAP очень гибкий и мощный, но достаточно сложный, с ним нужно разбираться. Несколько ссылок:
man slapd.access(5)
Описание директивы access в учебнике LFRS
Глава о контроле доступа в OLAG

Егор