Что касается пароля, то читаем в схеме и видим, отчего так:

DESC 'RealmedPassword (Hashes of <user>:<realm>:<secret>) begining with the hash tag like {MD5}'

Zimbra может быть можно заставить насильно указав ldap серверу, как хешировать пароли:

man 5 slapd.conf:
password-hash <hash>

Альтернативы IMHO нет. res_ldap - наколенная поделка и на данный момент найти можно только еще более наколенную.

>Zimbra может быть можно заставить насильно указав ldap серверу, как хешировать пароли

Нельзя. К сожалению, нельзя. Zimbra сама использует SSHA вместо того, чтобы дать возможность LDAP-серверу хешировать пароль тем методом, который предпочтителен для пользователя.

С res_ldap конечно основной вопрос в том, а не о...ли ли они read -> userPassword вместо того, чтобы делать BIND, т.е. auth -> userPassword? Я вообще первый раз с таким идиотизмом сталкиваюсь. честное слово.

первый раз с таким идиотизмом сталкиваюсь. честное слово.

Классический opensource :/

http://sourceforge.net/projects/asteriskadperl/

http://free.oxymium.net/Asterisk/

http://www.opennet.ru/openforum/vsluhforumID1/85694.html

НЯдеюсь, что это именно то, что Вам нужно, уважаемый тролль :)

возможно это тоже будет полезным: http://sysadminblog.ru/ldap/2011/05/27/rfc-3062-i-metod-heshirovaniya-paroley...

http://wiki.zimbra.com/index.php?title=UNIX_and_Windows_Accounts_in_Zimbra_LD...

http://vavai.net/tag/zimbra/

а вот тут http://www.liferay.com/community/forums/-/message_boards/message/105242 мне показалась интересной строчка ldap.auth.password.encryption.algorithm.types=MD5,SHA,SSHA

Ну и, ко всему прочему, можете сделать костыль, который синхронизирует два LDAP и пишет в них пароли с разным хэшем:) (Если быть точнее, то костыль должен в себе хранить хэши обоих типов, перезаписывая после синхронизации в одну сторону (Вы ведь сами намекали, что один из клиентов LDAP только читать должен) нужные поля на нужном сервере LDAP)

>возможно это тоже будет полезным: http://sysadminblog.ru/ldap/2011/05/27/rfc-3062-i-metod-heshirovaniya-paroley...

Это я же и написал, кстати :) За ссылки спасибо, сейчас зачитываюсь preauth.txt
Проблему решить не помогло, но мысль насчёт костыля вполне логичная: действительно, можно на Perl эмулировать поведение сервера каталогов (см. back-perl в составе OpenLDAP), используя этот код в качестве фронтэнда к реальному LDAP-серверу. И здесь уже, понятно, возможности становятся просто фантастическими, хотя само программирование этой штуки довольно геморройно и не факт, что цель оправдывает средства.

Perl=геморой+извращения :) это ж ежу ясно... это вам не питон

Perl как и любой язык подходит одним программистам и не подходит другим. Например, к моему стилю мышления он подходит превосходно, хотя и есть раздражающие моменты, связанные с тем, что, действительно, одно и тоже можно реализовать 10-ом различных методов (а иногда и доброй сотней), так что вместо собственно реализации задачи приходится заниматься постоянным выбором «как бы правильного» пути её реализации.
Кстати, с моей задачей скорее всего Perl'овый «сервер каталогов» (а по сути просто прокси-сервер) не справился бы: ему ведь Zimbra пароль в открытом виде не передаёт при заведении пользователя, а хеширует сначала в SSHA. А задача как раз в том, чтобы записать один пароль в два разных атрибута в двух разных форматах.

тогда см. выше. если только Вы создаёте пользователей и назначате им пароли, то сделайте 2 LDAP-сервера и скрипт, который имеет собственную БД с хэшами паролей. ну и соответственно...

В связке Asterisk и LDAP есть крайне неприятный момент: мало того, что res_ldap.c требуется читать атрибут, содержащий пароль, так ещё и формат этого атрибута не совпадает с форматом userPassword. Я не знаю, то ли создатели res_ldap'а страдают маразмом, то ли просто с LDAP знакомы по наслышке, но они предлагают читать из атрибута пароля MD5-hash в том виде, в котором его выдаёт md5sum (шестнадцатерчный дамп реального хэша то бишь). В поле userPassword при использовании MD5 формат совершенно другой: это base64-кодированный хэш. Вот только даже без учёта гемороя синхронизации двух атрибутов, содержащих один и тот же пароль, мы ещё ни коим образом не можем полагаться на то, что приложения, формирующие поле userPassword, будут делать это в MD5. Например, Zimbra кодирует в SSHA, и никакими коврижками её использовать MD5 вместо SSHA не заставить. В общем... может, кто сталкивался уже с такой проблемой али даже и знает кто - есть ли для Asterisk'а альтернативы res_ldap'у

ЕМНИП в SIP используется аутентификация challenge-response, так что SIP-сервер никогда не получает пароли пользователей открытым текстом в своё распоряжение. И поэтому он не может просто так аутентифицироваться на LDAP-сервере от имени пользователей. А его собственный хеш «содержит» не только пароль, но и ещё что-то, так что он всё-равно не совместим с LDAP'овским...

Цитата из cases studies с сайта Digium, довольно таки интересное чтиво:

LAIKA's Information Systems team, led by Mahlon, capitalized on Asterisk's broad feature set and foundation for custom integration and customization.

Managing hundreds of constantly changing users can be a difficult task, even for modern PBX and Unified Communications systems. To solve this problem, LAIKA smartly integrated Asterisk with their existing OpenLDAP user management system. Now, as new users are provisioned with IT credentials, phone extensions, voicemail, and other custom attributes are generated automatically as well. LAIKA instantly recognized the potential of this type of integration. “We have phone preference toggles as LDAP attributes, for things like «I don't want to participate in the site-wide Polycom intercom» or «I want voicemail delivered to my email,» states Smith.

The innovation and imagination did not cease at user automation, however. LAIKA used Asterisk's flexibility to develop ground-breaking applications to make the end-user experience even richer. Through a Firefox plugin, LAIKA was able to provide «click-to-call» functionality to enrich its employees' web experience. «You can just click, and your phone auto- dials,» explains Smith. «It's an amazing productivity booster and a great show-off feature to users that might not understand the immediate benefit of VOIP integration.»

LAIKA connects to the public telephone network through a digital PRI interface. Needing an ultra-reliable connection to the telephone network, LAIKA exclusively uses Digium hardware

В серьёзном продакшене используется, но не без допиливания, конечно. Можно поспрашать в списки рассылки.

>ЕМНИП в SIP используется аутентификация challenge-response

Не знал, спасибо за наводку, это сильно меняет дело. К сожалению... У меня ещё какие-то надежды оставались... :(

ЕМНИП в SIP используется аутентификация challenge-response

Может содержать, но у меня это просто md5sum'ы. IMHO у всех, кто юзает Ast+LDAP абсолютно также.

Не знал, спасибо за наводку, это сильно меняет дело. К сожалению... У меня ещё какие-то надежды оставались... :(

Вообще в SIP могут и пароли открытым текстом использоваться, но это небезопасно и по умолчанию нигде не используется. В принципе, совместно с SIPS (SSL/TLS) это должно быть безопасно. Можно попробовать копнуть в этом направлении...

вместе с gosa идет схема gofon
в ней есть goFonPIN, который использую для хранения пина для войсмэйла\авторизации
в АД думаю аналогично есть поля, которые можно для этого использовать.
для freeswitch писал интерфейс под xmlrpc. можно тупо генерить файлы directory по крону.

Solved.

Распаковываем /opt/zimbra/lib/ext/sambapassword/sambapassword.jar, декомпилим, добавляем по своему разумению, запаковываем в зад, рестартим зимбру, меняем пароль, проверяем в лдапе и довольные идем керосинить...???...PROFIT!

Идея хорошая, а слабо ещё не забыть потом в зад сообществу в виду нгормального патча вернуть? А то существование подобного функционала в рамках одной компании - как-то не комильфо.

s/виду нгормального/виде нормального/