ejabberd - Comments for "SOLVED: Помощь в настройке mod_shared_roster_ldap"

Здравствуйте! Столкнулся с

TlnK — Sun, 12 Oct 2014 06:11:01 +0000

Здравствуйте!
Столкнулся с аналогичной проблемой в eJabberd 2.1.10 - нужно, что бы JID брались из поля Mail, как у вас...
Если с авторизацией проблем не возникло, то mod_shared_roster_ldap настроить не получается - ошибок не видно, но и общая группа не появляется.
Уже почти неделю сижу, не знаю уже куда копать.

Почитал про указанный вами модуль, раз он подошел к 2.1.11, то надеюсь, что подойдёт и мне на 2.1.10 с Debian 6.7.
Но проблема в том, что не знаю как его собрать и подключить... eJabberd ставил из репозитория Wheezy.

Полностью согласен. Но, как

Daggers — Sat, 09 Jun 2012 12:19:33 +0000

Полностью согласен. Но, как ни странно, у меня эти настройки заработали именно тогда, когда я убрал все пробелы именно между параметрами. Возможно это какой то косяк в модуле...

Вы не совсем правы. Пробелов

mikekaganski — Fri, 08 Jun 2012 20:44:33 +0000

Вы не совсем правы. Пробелов не должно быть в фильтрах, и это определяется стандартом строкового представления фильтров LDAP. Между названиями и значениями параметров могут быть любые пробелы, равно как и около разнообразных скобок...

Хочу поделиться своей победой

Daggers — Fri, 08 Jun 2012 13:51:43 +0000

Хочу поделиться своей победой в трехдневной битвой с сабжевым модом =)
Дано: бинарная установка ejabberd-2.1.11 на CentOS 5.5. Авторизация пользователей по email, который неикак не совпадает с именем пользователя в домене, а просто прописан в поле "mail", откуда и подхватывает юзеров postfix и dovecot.
Бился-бился, когда победил, то понял, что в параметрах модуля НЕ ДОЛЖНО БЫТЬ ПРОБЕЛОВ. Получившийся конфиг модуля:

{mod_shared_roster_ldap,[
{ldap_groupattr,"department"},
{ldap_groupdesc,"department"},
{ldap_rfilter,"(&(memberOf=CN=JabberUsers,CN=Users,DC=flame,dc=local)(|(userAccountControl=66050)(userAccountControl=66048)(userAccountControl=512)))"},
{ldap_memberattr,"mail"},
{ldap_user_cache_validity,1}, %% Эту и следующую строчку можно убрать,
{ldap_group_cache_validity,1}, %% разницы с ними и без что-то не видно
{ldap_useruid,"mail"},
{ldap_memberattr_format,"%u@domain.ru"},
{ldap_userdesc,"displayName"}
]},

Теперь ищу какого-нить веб-клиента, чтобы его прикрутить к roundcube и к сайту нашей компании....
Буду благодарен, если подскажете где копать =)

Спасибо за разъяснения в

mi4igan — Thu, 24 May 2012 14:02:12 +0000

Спасибо за разъяснения в работе модуля и за помощь в настройке.

Все заработало!!!

Вот рабочая конфигурация:
{ldap_base, "ou=People,ou=test,dc=local"},
{ldap_rfilter, "(objectClass=organizationalUnit)"},
{ldap_groupattr, "ou"},
{ldap_gfilter, "(&(objectClass=organizationalUnit)(!(ou=People))(ou=%g))"},
{ldap_groupdesc, "ou"},
{ldap_member_selection_mode, group_children},
{ldap_useruid, "mail"},
{ldap_useruid_format, "%u@domain.local"},
{ldap_userdesc, "cn"}

Видимо, фильтр

mikekaganski — Thu, 24 May 2012 13:45:18 +0000

Видимо, фильтр "(objectClass=organizationalUnit)", применённый к "ou=People,ou=test,dc=local", даёт в качестве результата не только подобъекты, но и сам корневой объект. Для того, чтобы этого избежать, можно изменить фильтр так:
{ldap_gfilter, "(&(objectClass=organizationalUnit)(!(ou=Peple)))"},
т.е. все OU, кроме тех, имя которых People. Правда, при этом нужно ещё убрать лишнее имя из подобъектов.

При использовании {ldap_member_selection_mode, group_children}, контакты ищутся по всему поддереву каждого объекта-группы. Поэтому если группы имеют такую структуру:

OU_Корень
-> OU_1
--> User1
--> User2
-> OU_2
--> User3

То список групп будет

OU_Корень
OU_1
OU_2,

а пользователи в каждой группе:

OU_Корень: User1, User2, User3
OU_1: User1, User2
OU_2: User3

Теперь, если посмотреть на ростер, он будет выглядеть примерно так:
User1: группы OU_Корень, OU_1
User2: группы OU_Корень, OU_1
User3: группы OU_Корень, OU_2

И если клиент отображает, скажем, только первыю группу из списка групп пользователя, то в этом случае в ростере окажется только одна группа. Возможно, что манипуляции с объектами OU привели к тому, что теперь сервер LDAP выдаёт список в другой последовательности, и тогда ростер выглядит так:
User1: группы OU_1, OU_Корень
User2: группы OU_1, OU_Корень
User3: группы OU_3, OU_Корень

Вообще для точного "диагноза" надо смотреть логи...

До изменения они были

mi4igan — Thu, 24 May 2012 13:11:01 +0000

До изменения они были такими:
dn: ou=test123,ou=People,dc=local
objectclass: organizationalUnit
objectclass: top
ou: test123

dn: ou=test555,ou=People,ou=test,dc=mp,dc=local
objectclass: organizationalUnit
objectclass: top
ou: test555

Причем если добавить "ou: People" только к одной группе, то в ростер появляются группы test123 и test555.

Сейчас посмотрел на разных клиентах, при старых OU.
В miranda выводится только группа People.
В kopete, Pidgin и Pandion 3 группы: People, test123, test555. В группе People находятся все пользователи.

mi4igan wrote: Потом изменил

mikekaganski — Thu, 24 May 2012 12:44:36 +0000

mi4igan wrote:

Потом изменил группы test123 и test555 в LDAP. Они стали следующего вида:
dn: ou=test123,ou=People,ou=test,dc=local
objectclass: organizationalUnit
objectclass: top
ou: test123
ou: People

...

Ростер заработал, группы появились.
Можете объяснить как работает параметр {ldap_member_selection_mode, group_children}? Он не строит дерево групп?
Как сделал я путем добавления еще одного имени OU это верно с точки зрения технологии ldap и работы модуля?

А можно поподробнее, как выглядели OU до изменения?

Дерево групп не строится. На данный момент нет возможности отображать вложенность групп, все группы будут на верхнем уровне. Если элемент относится к нескольким группам, это будет отражено в ростре, но от клиента зависит, покажет ли он это

Два имени - это не правильно, но чтобы сделать правильно, сначала нужно разобраться, почему не заработало сразу. С точки зрения LDAP, множественные атрибуты - это нормально, но не все

Измениил конфиг. Результат

mi4igan — Thu, 24 May 2012 11:48:36 +0000

Измениил конфиг. Результат тот же - выводится группа People и все сотрудники в ней.
{ldap_base, "ou=People,ou=test,dc=local"},
{ldap_roster_cache_size, "0"},
{ldap_rfilter, "(objectClass=organizationalUnit)"},
{ldap_groupattr, "ou"},
{ldap_gfilter, "(&(objectClass=organizationalUnit)(ou=%g))"},
{ldap_groupdesc, "ou"},
{ldap_member_selection_mode, group_children},
{ldap_useruid, "mail"},
{ldap_useruid_format, "%u@rregion.ru"},
{ldap_user_cache_validity, 10},
{ldap_group_cache_validity, 10},
{ldap_userdesc, "cn"}

dn: ou=test555,ou=People,ou=test,dc=local
objectclass: organizationalUnit
objectclass: top
ou: test555
ou: People

ЗЫ Только начинаю вникать в работу LDAP.

mi4igan wrote: Вот с такой

mikekaganski — Thu, 24 May 2012 10:24:25 +0000

mi4igan wrote:

Вот с такой конфигурацией ничего не выводится:
...
{ldap_groupattr, "objectGUID"},
{ldap_gfilter, "(objectGUID=%g)"},
...
Что неправильно в конфигурации?

К сожалению, это не проблема конфигурации. В некоторых системах (не знаю по какому принципу, моя система тоже этим страдает) фильтрация по GUID не работает. :(

mi4igan wrote:

только все находятся в одной группе People, хотя должны быть в группе test123.
...
{ldap_rfilter, "(&(objectClass=organizationalUnit)(ou=People))"},

Ну, а чего же ещё ждать? Вы же прямо написали: список групп состоит из объектов organizationalUnit, у которых имя People. Я подозреваю, что таких объектов у Вас один :)
Теперь небольшие доделки:
- В этой версии параметр ldap_filter не используется вообще, его можно просто убрать.
- После окончания отладки настоятельно рекомендую убрать {ldap_roster_cache_size, "0"}, иначе производительность будет страдать.
- В этой версии ldap_auth_check по умолчанию выключен, так что тоже можно убрать.

Скомпилировал и установил

mi4igan — Thu, 24 May 2012 06:39:39 +0000

Скомпилировал и установил модуль. Теперь ростер заполняется, но только все находятся в одной группе People, хотя должны быть в группе test123. Конфигурация такая:
{ldap_base, "ou=test,dc=local"},
{ldap_roster_cache_size, "0"},
{ldap_filter, ""},
{ldap_rfilter, "(&(objectClass=organizationalUnit)(ou=People))"},
{ldap_groupattr, "ou"},
{ldap_gfilter, "(&(objectClass=organizationalUnit)(ou=%g))"},
{ldap_groupdesc, "ou"},
{ldap_member_selection_mode, group_children},
{ldap_useruid, "mail"},
{ldap_useruid_format, "%u@test.ru"},
{ldap_auth_check, off},
{ldap_userdesc, "cn"}

Вот с такой конфигурацией ничего не выводится:
{ldap_base, "ou=test,dc=local"},
{ldap_roster_cache_size, "0"},
{ldap_filter, ""},
{ldap_rfilter, "(&(objectClass=organizationalUnit)(ou=People))"},
{ldap_groupattr, "objectGUID"},
{ldap_gfilter, "(objectGUID=%g)"},
{ldap_groupdesc, "ou"},
{ldap_member_selection_mode, group_children},
{ldap_useruid, "mail"},
{ldap_useruid_format, "%u@rregion.ru"},
{ldap_auth_check, off},
{ldap_userdesc, "cn"}

Что неправильно в конфигурации?

Поставил модуль по

mi4igan — Wed, 23 May 2012 13:55:36 +0000

Поставил модуль по ссылке.
При такой конфигурации выводится группа People, хотя ожидал что будет test123.
{ldap_base, "dc=mp,dc=local"},
{ldap_filter, ""},
{ldap_rfilter, "(&(objectClass=organizationalUnit)(ou=People))"},
{ldap_groupattr, "ou"},
{ldap_gfilter, "(&(objectClass=organizationalUnit)(ou=%g))"},
{ldap_groupdesc, "ou"},
{ldap_member_selection_mode, group_children},
{ldap_useruid, "cn"},
{ldap_userdesc, "cn"}

При другой конфигурации невыводится ничего:
{ldap_base, "dc=mp,dc=local"},
{ldap_filter, ""},
{ldap_rfilter, "(&(objectClass=organizationalUnit)(ou=People))"},
{ldap_groupattr, "objectGUID"},
{ldap_gfilter, "(objectGUID=%g)"},
{ldap_groupdesc, "ou"},
{ldap_member_selection_mode, group_children},
{ldap_useruid, "cn"},
{ldap_userdesc, "cn"}

Родной модуль в принципе не

mikekaganski — Wed, 23 May 2012 12:31:23 +0000

Родной модуль в принципе не способен на это.
Вам сюда.