Форум проекта Pro-LDAP.ru
Администрирование OpenLDAP => Конфигурационный файл slapd.conf => Тема начата: alexander от 10 Июль 2019, 20:37:50
-
Коллеги, добрый день.
Прошу помочь с решением проблемы разграничения прав доступа к каталогу 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
Подскажите в какую сторону копать?
-
Здравствуйте!
Задача слишком абстрактная: не понятно, как представлены в каталоге 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 целесообразнее использовать группы пользователей.
Если покажите примеры учёток пользователей и реальных почтовых доменов, можно попытаться придумать что-то более оптимальное.
Егор
-
Здравствуйте, Егор!
Спасибо за оперативный и содержательный ответ. Связь между 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
то до фильтрации не доходит - отображаются контакты всех доменов.
С уважением,
Александр
-
Подскажите ещё, пожалуйста, как закрыть от чтения 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) (https://pro-ldap.ru/tr/man/slapd.access.5.html)
Описание директивы access в учебнике LFRS (https://pro-ldap.ru/tr/zytrax/ch6/#access)
Глава о контроле доступа в OLAG (https://pro-ldap.ru/tr/admin24/access-control.html)
Егор