Пытаюсь настроить mod_shared_roster_ldap.
конфиг ejabber:
{mod_shared_roster_ldap,[
{ldap_base, "ou=People,ou=test,dc=local"},
{ldap_roster_cache_size, "0"},
{ldap_filter, ""},
{ldap_rfilter, "(objectClass=organizationalUnit)"},
{ldap_groupattr, "ou"},
{ldap_gfilter, "(&(objectClass=organizationalUnit)(ou=%g))"},
{ldap_groupdesc, "ou"},
{ldap_member_selection_mode, group_children},
{ldap_useruid, "cn"},
{ldap_ufilter, "(objectClass=inetOrgPerson)"},
{ldap_auth_check, off},
{ldap_userdesc, "cn"}
]},
Структура ldap:
cn=test1,ou=test123,ou=People,ou=test,dc=local
cn=ms,ou=test123,ou=People,ou=test,dc=mp,dc=local
Перепробовал различные варианты, в ростере ничего не появляется.
Помогите настроить чтобы группы брал из organizationalUnit. Схемы с flat DIT и deep DIT я настроил и они работают. Deep DIT не устраивает так как
useruid нужно брать из CN. А я хотел из mail. А в CN заносить ФИО сотрудника.
Родной модуль в принципе не
Родной модуль в принципе не способен на это.
Вам .
Поставил модуль по
Поставил модуль по ссылке.
При такой конфигурации выводится группа 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"}
Скомпилировал и установил
Скомпилировал и установил модуль. Теперь ростер заполняется, но только все находятся в одной группе 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 wrote: Вот с такой
Вот с такой конфигурацией ничего не выводится:
...
{ldap_groupattr, "objectGUID"},
{ldap_gfilter, "(objectGUID=%g)"},
...
Что неправильно в конфигурации?
К сожалению, это не проблема конфигурации. В некоторых системах (не знаю по какому принципу, моя система тоже этим страдает) фильтрация по GUID не работает. :(
только все находятся в одной группе People, хотя должны быть в группе test123.
...
{ldap_rfilter, "(&(objectClass=organizationalUnit)(ou=People))"},
Ну, а чего же ещё ждать? Вы же прямо написали: список групп состоит из объектов organizationalUnit, у которых имя People. Я подозреваю, что таких объектов у Вас один :)
Теперь небольшие доделки:
- В этой версии параметр ldap_filter не используется вообще, его можно просто убрать.
- После окончания отладки настоятельно рекомендую убрать {ldap_roster_cache_size, "0"}, иначе производительность будет страдать.
- В этой версии ldap_auth_check по умолчанию выключен, так что тоже можно убрать.
Измениил конфиг. Результат
Измениил конфиг. Результат тот же - выводится группа 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"}
Потом изменил группы test123 и test555 в LDAP. Они стали следующего вида:
dn: ou=test123,ou=People,ou=test,dc=local
objectclass: organizationalUnit
objectclass: top
ou: test123
ou: People
dn: ou=test555,ou=People,ou=test,dc=local
objectclass: organizationalUnit
objectclass: top
ou: test555
ou: People
Ростер заработал, группы появились.
Можете объяснить как работает параметр {ldap_member_selection_mode, group_children}? Он не строит дерево групп?
Как сделал я путем добавления еще одного имени OU это верно с точки зрения технологии ldap и работы модуля?
ЗЫ Только начинаю вникать в работу LDAP.
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, множественные атрибуты - это нормально, но не все
До изменения они были
До изменения они были такими:
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 находятся все пользователи.
Видимо, фильтр
Видимо, фильтр "(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_Корень
Вообще для точного "диагноза" надо смотреть логи...
Спасибо за разъяснения в
Спасибо за разъяснения в работе модуля и за помощь в настройке.
Все заработало!!!
Вот рабочая конфигурация:
{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"}
Хочу поделиться своей победой
Хочу поделиться своей победой в трехдневной битвой с сабжевым модом =)
Дано: бинарная установка 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 и к сайту нашей компании....
Буду благодарен, если подскажете где копать =)
Вы не совсем правы. Пробелов
Вы не совсем правы. Пробелов не должно быть в фильтрах, и это определяется . Между названиями и значениями параметров могут быть любые пробелы, равно как и около разнообразных скобок...
Полностью согласен. Но, как
Полностью согласен. Но, как ни странно, у меня эти настройки заработали именно тогда, когда я убрал все пробелы именно между параметрами. Возможно это какой то косяк в модуле...
Здравствуйте! Столкнулся с
Здравствуйте!
Столкнулся с аналогичной проблемой в eJabberd 2.1.10 - нужно, что бы JID брались из поля Mail, как у вас...
Если с авторизацией проблем не возникло, то mod_shared_roster_ldap настроить не получается - ошибок не видно, но и общая группа не появляется.
Уже почти неделю сижу, не знаю уже куда копать.
Почитал про указанный вами модуль, раз он подошел к 2.1.11, то надеюсь, что подойдёт и мне на 2.1.10 с Debian 6.7.
Но проблема в том, что не знаю как его собрать и подключить... eJabberd ставил из репозитория Wheezy.