LINUX.ORG.RU
ФорумAdmin

Настройка mod_shared_roster_ldap у eJabberd 2.1.10

 , ,


0

2

На Debian 7 поднят AD на Samba4. Работает прекрасно - тут проблем нет.

На этом же сервера поднят eJabberd 2.1.10 из стандартного репозитория с авторизацией через LDAP в AD - тоже все взлетело практически и сразу.

Теперь, что бы вся толпа пользователей не искала друг-друга и не добавляла вручную нужно сделать общею группу контактов, что бы все видели всех. С mod_shared_roster все достаточно просто настраивалось через Web, тут же (с mod_shared_roster_ldap) в Web ничего настроить нельзя - только через конфиг. Не пойму, то ли mod_shared_roster_ldap не входит в версию ejabberd из коробки, то ли я чего настраиваю не так...

Пробовал так:

{mod_shared_roster_ldap,
    [
      {ldap_base, "ou=Jabber,dc=domain,dc=local"},
      {ldap_rfilter, "(cn=Group)"},
      {ldap_gnfilter, "(distinguishedName=%g)"},
      {ldap_groupattr, "distinguishedName"},
      {ldap_groupdesc, "description"},
      {ldap_gfilter, "(memberOf=%g)"},
      {ldap_memberattr, "sAMAccountName"}
    ]
}

и так:

{mod_shared_roster_ldap,
     [
       {ldap_base,              "ou=Jabber,dc=domain,dc=local"},
       {ldap_rfilter,           "(cn=Group)"},
       {ldap_filter,            ""},
       %%{ldap_gnfilter,        "(distinguishedName=%g)"},
       {ldap_ufilter,           "(&(uid=%u)     (memberOf=CN=CPS,OU=Jabber,DC=domain,DC=local))"},
       {ldap_groupdesc,         "description"},
       {ldap_memberattr_format, "uid=%u,ou=Jabber,dc=domain,dc=local"},
       {ldap_gfilter,           "(cn=Group)"},
       {ldap_groupattr,         "cn"},
       {ldap_memberattr,        "member"},
       {ldap_userid,            "uid"},
       {ldap_userdesc,          "cn"}
     ]
}

Оба варианта не работают...

В AD есть подразделение Jabber, в котором лежат пользователи которых нужно показать всем показать в группе. В этом же подразделении находится группа Group, которой принадлежать все пользователи (в этом подразделении). Варианта два - либо показывать всех пользователей подразделения, либо только тех которые ещё принадлежать и группе... Остановился на втором, но сейчас уже хоть бы как нибудь заставить появиться общею группу... Желательно конечно с пользователями внутри...

Помогите, пожалуйста, правильно настроить mod_shared_roster_ldap ?..



Последнее исправление: T1nK (всего исправлений: 1)

mod_shared_roster_ldap - вызывает маты, внимательно читай примеры, и конфиги. Я это добро точно заводил на samba4, но, может на более другой версии ejabberd. Я бы не брал версию из репов. Факт.

DALDON ★★★★★
()

Не пойму, то ли mod_shared_roster_ldap не входит в версию ejabberd из коробки

Да. Может не входить. Они его то выкидывают, то снова принимают. В целом это сторонний модуль. И глючный модуль, не даром они его выкидывают периодически.

DALDON ★★★★★
()
Ответ на: комментарий от DALDON

А откуда тогда eJabberd ставить то тогда ? Или возможно mod_shared_roster_ldap можно собрать отдельно ?

T1nK
() автор топика
Ответ на: комментарий от DALDON

Не понял, что за официальный сайт...

Есть ли какие-то способы обойтись без mod_shared_roster_ldap, воспользовавшись только mod_shared_roster ?..

T1nK
() автор топика

Тут главное внимательно соображать и спокойно. Я на этом собаку съел.

ldap_rfilter должен быть обязательно. Он определяет какие контакты будут в ростере. Следовательно

{ldap_rfilter,"(memberOf=CN=CPS,OU=Jabber,DC=domain,DC=local)"},

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

Ну и показал бы ты древо. Также смотри логи запросов к ldap. И почитай http://www.process-one.net/docs/ejabberd/guide_en.html#msrlconfigroster

uspen ★★★★★
()
Последнее исправление: uspen (всего исправлений: 2)

Это что за гадость? ldap_userid,

uspen ★★★★★
()

У меня так работает

  mod_shared_roster_ldap:
    ldap_base: "dc=root"
    ldap_rfilter: "(cn=jabber-group)"
    ldap_filter: "(ObjectClass=*)"
    ldap_gfilter: "(cn=jabber-group)"
    ldap_ufilter: "(&(uid=%u)(memberOf=cn=jabber-group,dc=root))"
    ldap_groupattr: "cn"
    ldap_groupdesc: "description"
    ldap_memberattr: "member"
    ldap_userdesc: "displayName"
    ldap_userid: "uid"
    ldap_memberattr_format_re: "cn=([\\w\\.\\-]*),ou=.*,dc=root"

ejabberd 14.07-1

sergej ★★★★★
()
Ответ на: комментарий от sergej

Там была какая-то магия не то с регекспом, не то с фильтрами. Я настроил и забыл.

sergej ★★★★★
()
Ответ на: комментарий от uspen

uspen, вот тестовое «дерево».

Пользователей выбираю так:

%% LDAP attribute that holds user ID:
{ldap_uids, [{"mail", "%u@*"}]}.

Не понял ещё как брать имя/фамилию из LDAP, что бы в списке отображался не ник, а нормальное имя... Где-то на форумах натыкался что так можно сделать, но как - не нашел.

T1nK
() автор топика
Ответ на: комментарий от sergej

Спасибо, попробую из sid стянуть посмотреть... Жаль что в wheezy старая ((

T1nK
() автор топика
Ответ на: комментарий от sergej

Видимо, я что-то очень не так делаю...

Установил eJabberd 14.07 из jessie - ок, поставился, что надо подтянулось вроде, а дальше ласты - получается только добиться подключения к LDAP (наверное)

Дальше, при попытке авторизоваться через Web-морду, говорит что не знает учетки, через клиент вообще что-то непонятное...

2014-10-07 23:01:46.932 [warning] <0.538.0>@ejabberd_web_admin:process:238 Access of <<"tink@domain.ru">> from <<"192.168.0.164">> failed with error: <<"inexistent-account">>
2014-10-07 23:02:00.602 [warning] <0.538.0>@ejabberd_web_admin:process:238 Access of <<"tink@domain.local">> from <<"192.168.0.164">> failed with error: <<"inexistent-account">>
2014-10-07 23:02:13.306 [warning] <0.538.0>@ejabberd_web_admin:process:238 Access of <<"TinK@domain.local">> from <<"192.168.0.164">> failed with error: <<"inexistent-account">>
2014-10-07 23:02:37.474 [info] <0.532.0>@ejabberd_listener:accept:313 (#Port<0.8882>) Accepted connection 192.168.0.164:54590 -> 192.168.0.196:5222
2014-10-07 23:02:37.529 [info] <0.540.0>@ejabberd_c2s:wait_for_auth:664 ({socket_state,gen_tcp,#Port<0.8882>,<0.539.0>}) Failed legacy authentication for tink@domain.local/QIP from IP 192.168.0.164

Вот часть конфига, которую я правил:

hosts:
  - "domain.ru"
  - "domain.local"

## auth_method: external

auth_method: ldap
ldap_servers:
   - "samba.domain.local"
ldap_encrypt: none
ldap_port: 389
ldap_rootdn: "CN=tink,OU=Jabber,DC=domain,DC=local"
ldap_base: "OU=Jabber,DC=domain,DC=local"
ldap_uids:
   - "mail": "%u@*"
language: "ru"
acl:
  admin:
     user:
         - "tink": "domain.local"

Курю ман http://www.process-one.net/docs/ejabberd/guide_en.html#ldap, но прогресса пока нет (((

T1nK
() автор топика
Ответ на: комментарий от T1nK

Что ты за вантузовые окошки показываешь?... ldapsearch на dn нужен.

Имена юзеров вместо ников в ростере показывает атрибут в ldap_userdesc

{ldap_uids, [{«mail», «%u@*»}]}.

муть

uspen ★★★★★
()
Ответ на: комментарий от uspen

Пробовал по разному получить общую группу, но безрезультатно.

В том числе, по постам: https://www.ejabberd.im/node/7754

Вот выполнил:

# extended LDIF
#
# LDAPv3
# base <OU=Jabber,DC=1domain,DC=local> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# Group1, Jabber, 1domain.local
dn: CN=Group1,OU=Jabber,DC=1domain,DC=local
objectClass: top
objectClass: group
cn: Group1
instanceType: 4
whenCreated: 20141011165421.0Z
uSNCreated: 3821
name: Group1
objectGUID:: dAeFFcPIaE2gx6PaFdnjXQ==
objectSid:: AQUAAAAAAAUVAAAAWCeorR8vCTnxUrisWwQAAA==
sAMAccountName: Group1
sAMAccountType: 268435456
groupType: -2147483646
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=1domain,DC=local
member: CN=test,OU=Jabber,DC=1domain,DC=local
member:: Q0490JzQsNGI0LAsT1U9SmFiYmVyZCxEQz0xZG9tYWluLERDPWxvY2Fs
member:: Q0490JPQvtGI0LAsT1U9SmFiYmVyZCxEQz0xZG9tYWluLERDPWxvY2Fs
member: CN=TinK,OU=Jabber,DC=1domain,DC=local
member: CN=qwerty,OU=Jabber,DC=1domain,DC=local
description:: 0JPRgNGD0L/Qv9CwMQ==
mail: group_a@mail.ru
whenChanged: 20141011170604.0Z
uSNChanged: 3825
distinguishedName: CN=Group1,OU=Jabber,DC=1domain,DC=local

# TinK, Jabber, 1domain.local
dn: CN=TinK,OU=Jabber,DC=1domain,DC=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: TinK
givenName: TinK
instanceType: 4
whenCreated: 20141011165320.0Z
displayName: TinK
uSNCreated: 3806
name: TinK
objectGUID:: Nrf3uSpS1ECTblKcK5Y8sQ==
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAWCeorR8vCTnxUrisWAQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: tink
sAMAccountType: 805306368
userPrincipalName: tink@1domain.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=1domain,DC=local
pwdLastSet: 130575200000000000
userAccountControl: 66048
memberOf: CN=Group1,OU=Jabber,DC=1domain,DC=local
mail: tink@mail.ru
whenChanged: 20141011175140.0Z
uSNChanged: 3836
distinguishedName: CN=TinK,OU=Jabber,DC=1domain,DC=local

# Jabber, 1domain.local
dn: OU=Jabber,DC=1domain,DC=local
objectClass: top
objectClass: organizationalUnit
ou: Jabber
instanceType: 4
whenCreated: 20141011165134.0Z
whenChanged: 20141011165134.0Z
uSNCreated: 3794
name: Jabber
objectGUID:: ubFF+dCC0Ual+SLyVm0vvw==
objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=1domain,D
 C=local
uSNChanged: 3795
distinguishedName: OU=Jabber,DC=1domain,DC=local

# \D0\93\D0\BE\D1\88\D0\B0, Jabber, 1domain.local
dn:: Q0490JPQvtGI0LAsT1U9SmFiYmVyZCxEQz0xZG9tYWluLERDPWxvY2Fs
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn:: 0JPQvtGI0LA=
givenName:: 0JPQvtGI0LA=
instanceType: 4
whenCreated: 20141011165217.0Z
displayName:: 0JPQvtGI0LA=
uSNCreated: 3796
name:: 0JPQvtGI0LA=
objectGUID:: bD35loojVU+eetv1pA1w8g==
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAWCeorR8vCTnxUrisVgQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: gosha
sAMAccountType: 805306368
userPrincipalName: gosha@1domain.local
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=1domain,DC=local
pwdLastSet: 130575199370000000
userAccountControl: 66048
memberOf: CN=Group1,OU=Jabber,DC=1domain,DC=local
mail: jabber_gosha@mail.ru
whenChanged: 20141011175204.0Z
uSNChanged: 3837
distinguishedName:: Q0490JPQvtGI0LAsT1U9SmFiYmVyZCxEQz0xZG9tYWluLERDPWxvY2Fs

# search result
search: 2
result: 0 Success

# numResponses: 10
# numEntries: 9

Все пользователи собраны в «Group1», соответственно название группы в идеале должно браться из «description» (т.е. пользователи должны видеть её как «Группа1»).

Вижу что все пользователи перечислены в «member», а группа у каждого пользователя указана в «memberOf».

Идентификаторы пользователей берутся из «mail» (например у пользователя «gosha» mail «jabber_gosha@mail.ru», а отображаемое имя «Гоша» - идентификатора jabber: jabber_gosha).

Для аутентификации пользователей достаю из LDAP так:

{auth_method, ldap}.
{ldap_servers, ["1domain.local"]}.
{ldap_port, 389}.
{ldap_rootdn, "CN=TinK,OU=Jabber,DC=1domain,DC=local"}.
{ldap_password, "Pa$$w0rd"}.
{ldap_base, "OU=Jabber,DC=1domain,DC=local"}.
{ldap_uids, [{"mail", "%u@*"}]}.
Общую группу пытаюсь получить так как описал выше:
  {mod_shared_roster_ldap, [
      {ldap_base, "ou=Jabber,dc=1domain,dc=local"},
      {ldap_filter, ""},
      {ldap_rfilter, "(cn=Group1)"},
      {ldap_gnfilter, "(distinguishedName=%g)"},
      {ldap_groupattr, "distinguishedName"},
      {ldap_groupdesc, "description"},
      {ldap_gfilter, "(memberOf=%g)"},
      {ldap_memberattr, "mail"},
      {ldap_useruid, "uid"},
      {ldap_userdesc, "cn"}
  ]},

T1nK
() автор топика
Ответ на: комментарий от uspen
{ldap_uids, [{«mail», «%u@*»}]}.

почему это путь?

Мне нужно только имя ящика, и неважно какой там домен (кстати, он не обязан совпадать с доменом Active Directory и/или сайта).

И, соответственно, как я понимаю, мне нужно получить идентификаторы пользователей и для mod_shared_roster_ldap... Только не пойму как...

Кстати, mod_vcard_ldap нужно настраивать что бы mod_shared_roster_ldap работал, или только что бы видеть карточки пользователей ?

T1nK
() автор топика
Ответ на: комментарий от T1nK

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

Но опять же непонятно, как собирать этот модуль и подключать, и актуально ли это в eJabberd 2.1.10 (на сайте модуля последним указан ejabberd 2.1.8)...

T1nK
() автор топика
Ответ на: комментарий от T1nK

{ldap_filter, «„}, - убрать.
{ldap_rfilter, “(cn=Group1)»}, - не вижу у юзера с mail: tink@mail.ru такой cn, следовательно он не попадет в ростер.
ldap_gnfilter - что такое не знаю и знать не хочу.
{ldap_groupattr, «distinguishedName»}, - не верный выбрал атрибут. Я же писал, что должен быть ОБЩИЙ атрибут (у всех в одной группе ОДИН и ТОТ ЖЕ)
{ldap_groupdesc, «description»}, - ок
{ldap_gfilter, "(memberOf=%g)«}, - не могу подсказать, но gfilter фильтрует группы, а не их членов, если не ошибаюсь. Вообще любые фильтры кроме rfilter я бы не советовал использовать, только запустают тебя, да и нужны они в крайних сложных случаях. Прочитай док сначала... {ldap_useruid, „uid“}, - Круто... теперь найди такой атрибут у себя.

Короче ты напастил и сам не понял чего. СИЛЬНО вкури доку...

uspen ★★★★★
()
Последнее исправление: uspen (всего исправлений: 1)
Ответ на: комментарий от uspen

Рекомендую самому выступить в роли сервера и с ldapsearch по своей же конфе делать запросы и смотреть на результат. Также смотреть логи запросов и их ПОРЯДОК! Это важно, так как это логика сервера (модуля mod_shared_roster_ldap) Он сначала спрашивает одно потом другое.. почитай, давал ссылку.

uspen ★★★★★
()
Ответ на: комментарий от uspen

Нашел старую документацию (в которой, в отличии от новой, у меня отобразились все картинки): http://ejabberd-msrl.alioth.debian.org/doc/0.5.3/msrl.html По ней написал такой конфиг:

{mod_shared_roster_ldap,[
    {ldap_base, "OU=Jabber,DC=1domain,DC=local"},
    {ldap_rfilter, "(objectClass=user)"},
    {ldap_groupattr, "company"},
    {ldap_groupdesc, "company"},
    {ldap_memberattr, "sAMAccountName"},
    %%{ldap_filter,  "(objectClass=user)"},
    %%{ldap_useruid, "sAMAccountName"},
    {ldap_userdesc, "displayName"}
  ]},
И... ЭВРИКА!!!! Оно заработало... Правда логику я так и не понял, кроме того, что выбираются элементы подразделения типа «пользователь» и группируются по одному из атрибутов (для этого заполнил «Организация» у каждой учетки).

Это круто! Хотя бы потому что уже видны все учетки... Но мне нужно их группировать по принадлежности к группам AD, да и пускать в жабер, только входящих в эти же группы.

Попробую вторую схему (описанную в инструкции по ссылке чуть ниже), может заработает... наивно так надеюсь...

Для фильтрации учеток которым можно пользоваться жабером нужно воспользоваться {ldap_filter, «„} описанным в блоке LDAP аутентификации, верно?

T1nK
() автор топика
Ответ на: комментарий от T1nK

Для фильтрации учеток которым можно пользоваться жабером нужно воспользоваться {ldap_filter, «„} описанным в блоке LDAP аутентификации, верно?

Верно.

Чета я глянул на твое древо...я не супер спец в этих LDAP, но что-то не то. Как так у тебя получилось, что CN=GROUP1 и CN=TINK находятся в одной OU... Вот и не получается у тебя. Может я и ошибаюсь. Но логично делать OU=GROUPS,OU=JABBER в ней CN=GROUP1 CN=GROUP2 ... и т.д. в этих группах уже MEMBERUID=USER1 MEMBERUID=USER2

uspen ★★★★★
()
Ответ на: комментарий от uspen

Я по разному делал - и в одном OU собирал группы и пользователи, и в двух разных вложенных... Специально в последнем уже варианте, перед тем как писать на форум упростил уже все по максимому - положив их в одну группу. Но да, в реальном домене пользователи и группы разнесены по OU для удобства работы.

Только сейчас когда увидел дерево и правила для него что-то наконец стало получаться... До этого логика параметров от меня совершенно ускользала, сейчас только начинает что-то проясняться.

Самым сложным пожалуй будет собрать и подключить другую версию модуля, что бы научить его доставить идентификаторы пользователей из Mail по формату... А то сейчас они не хорошо берутся из sAMAccountName, то есть совпадают с логином учеток.

T1nK
() автор топика
Ответ на: комментарий от T1nK

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

uspen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.