Возможно, ошибка в подсистеме LDAP

[bubnov-pi]

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

(данное сообщение - альтернативная ветка моего вопроса в английском разделе - http://forum.zentyal.org/index.php/topic,16582.0.html)
Хотел поинтересоваться соображениями и наблюдениями общественности - обнаружил странность в конфигурации LDAP на Zentyal 3:
В вэб-интерфейсе Zentyal я наблюдаю такие параметры ldap:
Base DN:    dc=test,dc=lan
Root DN:    cn=zentyal,dc=test,dc=lan
Password:    VMTczzH8KybgMsbWtXhk
Read-only root DN:    cn=zentyalro,dc=test,dc=lan
Read-only password:    O8p0XRzIaLpdWwKEVxE1
Users DN:    ou=Users,dc=test,dc=lan
Groups DN:    ou=Groups,dc=test,dc=lan
(всё привожу как есть - всё равно машина в тестовой среде, так что пароли показать не страшно)
В приведённой таблице смущает два момента:
1. С приведёнными учётными данными (Root DN и Read-only root DN) мне не удалось авторизоваться на ldap-сервере ни удалённо, с соседней машины, ни локально, ldapsearch
2. "Users DN:" начинается с "ou=Users", но по факту (подключившись созданным в вэбке пользователем) в каталоге ldap я наблюдаю не "Подразделение" (ou), а "Контейнер" (cn), называющийся Users, соответственно и поиск приходится вести не в ou=Users,dc=test,dc=lan, а в cn=Users,dc=test,dc=lan
При этом, в конфигурации, например, dovecot, используются именно приведённые в вэб-интерфейсе данные (как для авторизации, так и для поиска данных пользователей), и если там вручную изменить ou на cn, при авторизации клиентов выдаётся ошибка (на этапе чтения user_attrs), то есть где-то существует именно OU "Users".

Есть у кого-нибудь соображения, бага это, или так сделано по каким-то скрытым от моего понимания причинам?

Почему обратил внимание на данную нестыковку - если использовать авторизацию в почте через GSSAPI, тот самый dovecot пытается получить дополнительные параметры пользователя (настройки квотирования) подставляя в поле поиска "mail", указанное пользователем имя входа, то есть, для пользователя "mailuser" в моём случае будет подставлено "mailuser@TEST.LAN", что в общем случае не соответствует действительности - адрес почты пользователя может отличаться от имени входа в домен, да и вообще, realm авторизации Kerberos не имеет ни малейшего отношения к виртуальному почтовому домену, в котором у пользователя находится ящик. Проблема с dovecot решается элементарной правкой конфига, изменяя как параметры подключения к LDAP, так и правило сопоставления имени пользователя - либо с sAMAccountName, либо с userPrincipalName, но вот квоты тогда не работают - видимо, они хранятся "в другом каталоге" ldap (содержимое которого для меня остаётся загадкой).

P.S.: Проблема наблюдается на свежеустановленном из образа "zentyal-3.0-2-i386.iso" тестовом сервере; Текущая версия: 3.0.21, со всеми обновлениями. Активные модули: Network, Firewall, Antivirus, DHCP, DNS, Backup, Events, Logs, Mail Filter, Monitoring, NTP, VPN, Users and Groups, Web Server, FTP, Mail, File Sharing, HTTP Proxy, Webmail, Printer Sharing. Zentyal изучается как возможная замена текущего "зоопарка" с разными точками авторизации, на физически разных машинах (файлсервер, почтовик и proxy/web/шлюз).

[bubnov-pi]

Благодаря ответу в англоязычной ветке, выяснил, что указанные учётные данные - для другого порта ldap, после чего проблему с авторизацией dovecot удалось победить минимальной кровью - после доработки фильтра в ldap-конфиге до вида user_filter = (&(objectClass=CourierMailAccount)(|(uid=%n)(mail=%u))) всё заработало.

Что касается вопроса, ради чего было делать структуры разными для двух мест хранения практически одной и той же информации - тоже пояснили в англоязычной ветке - zentyal начал использовать "AD-подобную" базу для хранения учётных данных пользователей начиная с версии 3, из-за перехода на SAMBA 4, но часть функционала (пока) не портирована в новую схему, из-за чего появилась вторая "копия" учётных данных.

Судя по всему, многие, кто столкнулся с проблемами работы с ldap после перехода с версии 2 на 3, попали как раз на проявление этого нюанса.

На всякий случай, помещаю ремарку и в русской ветке: На zentyal версии 3.0 используется две базы данных ldap - одна отвечает на порту 389 - её структура имитирует структуру ldap Active Directory, для доступа к ней можно авторизовываться пользователями, созданными в вэб-интерфейсе zentyal, но она не пускает служебных пользователей zentyal и zentyalro (отображаемых на страничке настроек ldap в web-интерфейсе), вторая слушает запросы на порту 390, это "историческое" хранилище данных, содержащее настройки jabber, asterisk и т.п., основная часть сервисов использует именно эту базу. Как происходит копирование данных между двумя копиями ldap, доподлинно выяснить не удалось, но изменения в одной базе отражаются на содержимом второй.

Из этого положения вытекает несколько следствий, например, что создавать новых пользователей средствами Microsoft (при использовании домена) небезопасно - возможно совпадение ключевых полей для "исторической" базы ldap, последствия чего представить сложно, но вряд ли эти последствия не вызовут каких-либо структурных ошибок.