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.
421
Russian / Re: Возможно, ошибка в подсистеме LDAP
« on: June 26, 2013, 02:33:04 pm »
Благодаря ответу в англоязычной ветке, выяснил, что указанные учётные данные - для другого порта 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, последствия чего представить сложно, но вряд ли эти последствия не вызовут каких-либо структурных ошибок.
Что касается вопроса, ради чего было делать структуры разными для двух мест хранения практически одной и той же информации - тоже пояснили в англоязычной ветке - 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
But it is still very strange, why in two semi-same (in my point of view) ldap-catalogs, we found different structures
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/шлюз).
(данное сообщение - альтернативная ветка моего вопроса в английском разделе - 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...
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 обнаружить не удалось - предлагается только резервирование конфигурации сервера, но не хранимых данных.
Что касается резервного копирования почтовых сообщений, то они не хранятся ни в web-интерфейсе (roundcube), ни в интерфейсе Colaboration Service (zarafa) - они хранятся "в почтовом сервере" (dovecot), а названные компоненты лишь обеспечивают визуальный доступ к ним. Соответственно и создавать резервную копию/восстанавливать надо почту и всё остальное, что планируется защищать (файлы, адресные книги, календари и пр. - по желанию).
За детальной информацией по резервированию и восстановлению данных на сервере zentyal, рекомендую обращаться к любой линукс-общественности, т.к. в документации никаких сведений о возможностях резервного копирования и восстановления информации, размещаемой на сервере zentyal обнаружить не удалось - предлагается только резервирование конфигурации сервера, но не хранимых данных.