я ни как не пойму почему не работает версия модуля от 03.08.2011г. и вообще он способен работать с OpenLDAP ? В общем конфиг такой:
{mod_shared_roster_ldap, [
{ldap_servers, ["192.168.100.7"]},
{ldap_group_base, "ou=testing,ou=addressbook,dc=example,dc=com"},
{ldap_rfilter, "(objectClass=organizationalUnit)"},
%%{ldap_groupattr, "ou"},
{ldap_gfilter, "(&(objectClass=organizationalUnit)(ou=%g))"},
{ldap_groupdesc, "description"},
{ldap_member_selection_mode, group_children},
{ldap_ufilter, "(&(objectClass=inetOrgPerson)(cn=%u))"},
{ldap_userdesc, "displayName"},
{ldap_auth_check, off}
%%{ldap_useruid, "cn=%u"}
]},в логах ежика никаких ошибок нет, вообще никаких рапортов.
структура ldap http://s1.ipicture.ru/uploads/20110818/TB1JrU45.png
ткните пальцем, совсем голову сломал
{ldap_member_selection_mode,
Обратите внимание, что в Вашей конфигурации используется режим выбора объектов-пользователей - подобъектов объекта-группы. При этом не нужен вообще "(cn=%u)" (это описано на странице ).
Следует раскомментировать ldap_groupattr.
При беглом просмотре других проблем, вроде, не должно быть.
Однако нужно обратить внимание, что по умолчанию ldap_useruid имеет значение "cn", а ldap_useruid_format - "%u", то есть у Ваших inetOrgPerson должны быть cn такие, что они составляют пользовательскую часть jid (т.е. части перед @). Я предполагаю, что этот же атрибут используется Вами для построения jid и в разделе аутентификации. Если же cn не является допустимой строкой для пользовательской части jid (например, содержит пробелы), ничего не заработает, нужно будет выбрать другой атрибут для ldap_useruid.
Насчёт "и вообще он способен работать с OpenLDAP ?" - на самом деле обновленный модуль должен быть более универсальным и обеспечивать большую гибкость при работе с любым LDAP. Он не "затачивался" под какую-то конкретную систему, AD служил лишь отправной точкой в определении общих недостатков модуля.