Здравствуйте, товарищи, я пытаюсь настроить mod_shared_roster_ldap и использую следующий конфиг:
{mod_shared_roster_ldap,[
{ldap_servers, ["10.0.1.80"]},
{ldap_rootdn, "CN=ldapbind,CN=Users,DC=my,DC=domain"},
{ldap_password, "P@ssw0rd"},
%%{ldap_auth_check, "off"},
{ldap_base, "CN=Users,DC=my,DC=domain"},
{ldap_rfilter, "(objectClass=group)"},
{ldap_filter, ""},
{ldap_gfilter, "(&(objectClass=group)(cn=%g))"},
{ldap_groupdesc, "name"},
{ldap_memberattr, "member"},
{ldap_memberattr_format, "cn=%u,cn=Users,dc=my,dc=domain"},
{ldap_ufilter, "(&(objectClass=user)(cn=%u))"},
{ldap_userdesc, "displayName"}
]}
он был сделан с использованием примера Deep DIT из официальной документации
Мы используем Эктив Директори, где у нас 2 группы "CN=social,CN=Users,DC=my,DC=domain" и CN=Отдел разработки ПО,CN=Users,DC=my,DC=domain"
в каждой группе есть некоторые участники, которые перечислены в полях member в аттрибутах этих групп
к сожалению, в ростере ничего не появляется, ошибок не выдаёт(((
Кроме того, я пробовал использовать пример Flat DIT из официальной документации:
{mod_shared_roster_ldap,[
{ldap_servers, ["10.0.1.80"]},
{ldap_rootdn, "CN=ldapbind,CN=Users,DC=my,DC=domain"},
{ldap_password, "P@ssw0rd"},
%%{ldap_auth_check, "off"},
{ldap_base, "CN=Users,DC=my,DC=domain"},
{ldap_rfilter, "(objectClass=user)"},
{ldap_groupattr, "department"},
{ldap_memberattr, "sAMAccountName"},
{ldap_filter, "(objectClass=user)"},
{ldap_userdesc, "displayName"}
]}
как я понимаю, в подобном конфиге еджабберд просматривает АД на наличие элементов "user" и после того смотрит на аттрибут "department" (содержание которого в дальнейшем составляет наши группы в ростере), имена наших пользователей (аккаунтов в джаббере) совпадают с полем "sAMAccountName"
и это тоже не работает
также, хочу заметить, что мы используем собственный скрипт external auth, но я не думаю, что проблема в этом
Заранее спасибо!
Вроде бы Вы делаете всё
Вроде бы Вы делаете всё правильно (в предположении, что cn пользователей соответствует пользовательской части jid, т.е. как минимум не содержат пробелов). Возможно, дело всё-таки в скрипте аутентификации. Если это так, то разкомментирование {ldap_auth_check, "off"} может исправить ситуацию.
Вообще установите уровень отладки на Info (4) или выше и запустите ejabberd в интерактивном режиме (ejabberdctl live), тогда будут отображаться запросы LDAP и их результаты. Вы по крайней мере сможете отследить, какие запросы выполняются и дают ли они ожидаемые результаты.
Спасибо, за оперативный
Спасибо, за оперативный ответ!
нет, пробелов нету - сам думал об этом, но тут всё в порядке, auth_check выключал тоже - безрезультатно
режим отладки и так включён - каждый раз смотрю в live режиме - там ничего подобного не показывает - только пишется, что, мол, пользователь авторизирован (по external), а про LDAP ничего, при этом, если в rootdn установить неверные параметры (например, пароль не тот), то тогда уже появляются сообщения, мол, invalid credentials((
Немного вот изменил конфиг -
Немного вот изменил конфиг - и никаких результатов
{mod_shared_roster_ldap,[
{ldap_servers, ["10.0.1.80"]},
{ldap_rootdn, "CN=ldapbind,CN=Users,dc=my,dc=domain"},
{ldap_password, "P@ssw0rd"},
{ldap_base, "CN=Users,dc=my,dc=domain"},
{ldap_rfilter, "(objectClass=user)"},
{ldap_groupattr, "memberOf"},
{ldap_groupattr_format,"CN=%u,CN=Users,dc=my,dc=domain"},
{ldap_memberattr, "sAMAccountName"},
{ldap_filter, "(objectClass=user)"},
{ldap_auth_check, "off"},
{ldap_userdesc, "displayName"}
]}
Невероятно! заработало,
Невероятно! заработало, попробовал включить (непонятно, как они связаны):
{mod_roster_odbc, []}
У Вас, по-видимому, вообще не
У Вас, по-видимому, вообще не был активирован ни один модуль ростера - т.е. ни mod_roster, ни mod_roster_odbc. А любой shared roster работает как надстройка над ростером - т.е. при запросе пользовательским агентом ростера пользователя ejabberd смотрит, включён ли у него какой-нибудь модуль, способный обработать этот запрос. Если есть, вызывает его. А уже этот модуль, вытащив из своей БД личные контакты пользователя, смотрит, есть ли модули общих ростеров, и если есть - вызывает их. Так что при отсутствии mod_roster(_odbc) общие ростеры никогда не будут вызваны.
Это стоило бы включить в документацию в явном виде как зависимость.
Запомню как возможную причину на будущее :)
Спасибо за комментарий!
Спасибо за комментарий! Теперь буду знать!