Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bubnov-pi

Pages: 1 ... 27 28 [29]
421
Благодаря ответу в англоязычной ветке, выяснил, что указанные учётные данные - для другого порта 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, последствия чего представить сложно, но вряд ли эти последствия не вызовут каких-либо структурных ошибок.

422
Installation and Upgrades / Re: Possible error in LDAP subsystem
« on: June 26, 2013, 02:28:15 pm »
Thank you for answer - on port 390 i've got expected data! (and it helped me to resolve my confusion with GSSAPI authentication in dovecot)
But it is still very strange, why in two semi-same (in my point of view) ldap-catalogs, we found different structures :o

423
Russian / Возможно, ошибка в подсистеме LDAP
« on: June 26, 2013, 02:12:39 pm »
Здравствуйте!

(данное сообщение - альтернативная ветка моего вопроса в английском разделе - 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/шлюз).

424
Installation and Upgrades / Possible error in LDAP subsystem
« on: June 26, 2013, 01:33:50 pm »
Hello, everybody!

I'm not sure, but I find some strange thing:
In Zentyal web interface (LDAP settings), I see "Users DN:    ou=Users,dc=test,dc=lan", but in fact, with any ldap-querying tool I can't to see this OU, there is only "cn=Users,dc=test,dc=lan", and all user accounts are placed into this Container (not Organisation unit), moreover, it is impossible to query LDAP with listed in web-interface credentials (for "adressbook" purpose, for example).
Okay, may be this shouldn't be a big problem, but in dovecot "user_attrs" parameter reads attributes from DN with "ou=", and if it changed to "cn=", occurs error.

Can somebody tell me, how it is possible? Is it a bug, or feature?

The second thing is unclear authentication mechanism with LDAP, if GSSAPI is used, but it is for my second topic.

P.S.: Described situation is on just-installed (from "zentyal-3.0-2-i386.iso" disc) for test system; Current core version: 3.0.21, with all actual updates. Active modules: 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. I explore Zentyal as alternative to our old solution with different authentication databases/user accounts on different physical servers (fileserver, mailserver and proxy/web/GW).
If some my sentences are not clear, please, ask me for more accurate definition - my English is not perfect...

425
Russian / Re: zarafa or webmail bacup&restore
« on: June 17, 2013, 09:07:14 am »
*не являюсь опытным администратором zentyal - нашему знакомству только пара дней.

Что касается резервного копирования почтовых сообщений, то они не хранятся ни в web-интерфейсе (roundcube), ни в интерфейсе Colaboration Service (zarafa) - они хранятся "в почтовом сервере" (dovecot), а названные компоненты лишь обеспечивают визуальный доступ к ним. Соответственно и создавать резервную копию/восстанавливать надо почту и всё остальное, что планируется защищать (файлы, адресные книги, календари и пр. - по желанию).
За детальной информацией по резервированию и восстановлению данных на сервере zentyal, рекомендую обращаться к любой линукс-общественности, т.к. в документации никаких сведений о возможностях резервного копирования и восстановления информации, размещаемой на сервере zentyal обнаружить не удалось - предлагается только резервирование конфигурации сервера, но не хранимых данных.

Pages: 1 ... 27 28 [29]