ejabberd - Comments for "mod_shared_roster_ldap, не могу вывести имена пользователей в нормальном виде"

Здравствуйте! У меня немного

gard — Mon, 15 Oct 2012 04:00:28 +0000

Здравствуйте!
У меня немного другая ситуация.Самба хранит учетные записи в LDAP, однако домена нет, поэтому unix-группы не "примапплены" к доменным группам и в LDAP хранятся только записи о unix-группах, а не о доменных. То есть unix-пользователи имеют доп атрибуты Samba-пользователей, а вот unix-группы нет, они в чистом виде unix-групп, к примеру:

dn: cn=Admins,ou=Groups,dc=urfu
objectClass: posixGroup
cn: Admins
gidNumber: 10007
description: Group account
structuralObjectClass: posixGroup
entryUUID: d62149e8-a874-1031-87c4-a99e1628b3e4
creatorsName: cn=admin,dc=urfu
createTimestamp: 20121012045549Z
entryCSN: 20121012045549.600062Z#000000#000#000000
modifiersName: cn=admin,dc=urfu
modifyTimestamp: 20121012045549Z

Возможно, это решение на основе доменных групп мне поможет в дальнейшем, вдруг где-то нужен будет именно домен на Samba. А сегодня я протестировал ваше первое решение - все великолепно работает, в pidgin все пользователи вывелись по cn. Большое Спасибо! =)

Я тут погуглил по поводу

mikekaganski — Sun, 14 Oct 2012 06:16:51 +0000

Я тут погуглил по поводу групп в самболдапе. Если не ошибаюсь, группа выглядит примерно так (взято из http://lists.samba.org/archive/samba/2010-January/153134.html):

dn: cn=Domain Admins,ou=Group,dc=themusiclink,dc=net
description: Netbios Domain Administrators
sambaSID: S-1-5-21-957249707-1866601452-441284377-512
sambaGroupType: 2
displayName: Domain Admins
structuralObjectClass: posixGroup
entryUUID: 1a60146c-cfad-102d-96b0-6fd9fc452718
creatorsName: cn=Manager,dc=themusiclink,dc=net
createTimestamp: 20090507234700Z
gidNumber: 512
cn: Domain Admins
userPassword:: e2NyeXB0fXg=
objectClass: posixGroup
objectClass: top
objectClass: sambaGroupMapping
memberUid:
memberUid:
memberUid:
entryCSN: 20091028001757Z#000001#00#000000
modifiersName: cn=Manager,dc=themusiclink,dc=net
modifyTimestamp: 20091028001757Z

Если это так, то Вам вовсе не надо было идти такими извилистыми путями.
Самое главное - что в этом объекте есть множественный атрибут memberUid.
Тогда всё делается так:

{mod_shared_roster_ldap,[
 {ldap_base, "ou=Users,dc=urfu"},
%1. Избавьтесь от бессмысленных дефолтов:
{ldap_filter, ""},
%2. Определите список групп, т.е. получите те объекты, из которых потом вычлените идентификаторы групп
{ldap_rfilter, "(objectClass=sambaGroupMapping)"},
%3. Какой атрибут полученных объектов собственно содержит идентификаторы групп
{ldap_groupattr, "gidNumber"},
%4. Теперь модуль собрал все возможные gidNumber'ы в единый список и будет по одному опрашивать каждую группу на предмет её имени и её списка пользователей. Определим запрос к отдельной группе:
{ldap_gfilter, "(&(objectClass=sambaGroupMapping)(gidNumber=%g))"},
%5. Чтобы узнать отображаемое имя, зададим соответствующий атрибут.
{ldap_groupdesc, "displayName"},
%6. Определим, где хранятся идентификаторы пользователей-членов данной группы
{ldap_memberattr, "memberUid"},
%7. Теперь у нас есть список групп с их именами, и для каждой группы есть список идентификаторов пользователей. Надо опросить каждого пользователя на предмет его отображаемого имени
{ldap_ufilter, "(&(objectClass=sambaSamAccount)(uid=%u))"},
%8. Где у этого пользователя идентификатор (идёт в jid, должен соответствовать ldap_memberattr), и где отображаемое имя
{ldap_useruid, "uid"},
{ldap_userdesc, "cn"}
%The end
]}

Преимущества этого подхода:
1. Определяются имена групп.
2. Производительность: в первом подходе каждый пользователь возвращался трижды: при построении списка групп возвращались все пользователи, при опросе группы возвращались все пользователи группы, и при опросе пользователей. Здесь при построении списка групп возвращаются два объекта-группы, при опросе групп возвращается один объект-текущая группа, а пользователи опрашиваются только в третьей стадии. (Ну, конечно, при десяти пользователях это не принципиально, но если их сто тысяч...)

Простите, ковырял конфиг на

gard — Fri, 12 Oct 2012 12:01:24 +0000

Простите, ковырял конфиг на работе, пришел домой, а конфиг то не взял. Придется ждать до понедельника, когда смогу добратья до рабочего компьютера. Но кое что сказать могу. В jid попадает uid пользователя, то есть для вышеприведенной записи в LDAP это будет bukinist@smb.urfu. Под таким именем пользователь прекрасно логинится на ejabberd-сервер. Насчет gidNumber - не совсем одинаковый. К примеру пока что есть две группы: Admins (gidNumber: 10007) и Office (gidNumber: 10008). Обе группы пользователей должны и могут логиниться в ejabberd. Чтобы в ростере не было групп с именами 10007 и 10008 я банально использовал {ldap_groupdesc, "description"}, который у каждого пользователя одинаково содержит строку "User Account". То есть групп много, а в ростере просто одна. Я просто не знаю как jabber'у передать не номера групп, а их реальные имена, т.к. в атрибутах пользователя присутствует только номер группы, а не ее имя. Имя группы содержится в LDAP-записи для этой группы, а это уже совсем другая запись. Но в принципе мне хватит и плоского списка пользователей, потому что пользователей всего-ничего, около десятка человек.

Посмотрел листинг вашего решения, кажется понял логику работы модуля. Судя по всему все именно так, и это должно сработать. На выходе как я понимаю так и получится плоский список пользователей в одной группе "User account", если же убрать {ldap_groupdesc, "description"}, то получится 2 группы, обозванные как 10007 и 10008. Спасибо большое! Жаль, что испытать получится только в понедельник. По результатам - отпишусь. =)

Вы не указали, что отсюда

mikekaganski — Fri, 12 Oct 2012 11:29:10 +0000

Вы не указали, что отсюда должно идти в jid. Для ясности следовало привести здесь вашу работающую секцию аутентификации через LDAP. Предположу, что это - uid.

Также неясно, у всех ли пользователей одинаковые gidNumber, и всегда ли description однозначно соответствует gidNumber'у. Предположу, что есть взаимно однозначное соответствие.

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

{mod_shared_roster_ldap,[
 {ldap_base, "ou=Users,dc=urfu"},
%1. Избавьтесь от бессмысленных дефолтов:
{ldap_filter, ""},
%2. Определите список групп, т.е. получите те объекты, из которых потом вычлените идентификаторы групп
{ldap_rfilter, "(objectClass=sambaSamAccount)"},
%3. Какой атрибут полученных объектов собственно содержит идентификаторы групп
{ldap_groupattr, "gidNumber"},
%4. Теперь модуль собрал все возможные gidNumber'ы в единый список и будет по одному опрашивать каждую группу на предмет её имени и её списка пользователей. Определим запрос к отдельной группе:
{ldap_gfilter, "(&(objectClass=sambaSamAccount)(gidNumber=%g))"},
%5. Этот запрос фактически (в Вашем случае) выдаст список пользователей с одинаковым gidNumber. Чтобы узнать отображаемое имя, зададим соответствующий атрибут. Обратите внимание: нам нужно одно имя, а будет получено множество строк (по одной на каждого пользователя). Модуль в этом случае просто возьмёт то, которое окажется последним в списке.
{ldap_groupdesc, "description"},
%6. Определим, где хранятся идентификаторы пользователей-членов данной группы
{ldap_memberattr, "uid"},
%7. Теперь у нас есть список групп с их именами, и для каждой группы есть список идентификаторов пользователей. Надо опросить каждого пользователя на предмет его отображаемого имени
{ldap_ufilter, "(&(objectClass=sambaSamAccount)(uid=%u))"},
%8. Где у этого пользователя идентификатор (идёт в jid, должен соответствовать ldap_memberattr), и где отображаемое имя
{ldap_useruid, "uid"},
{ldap_userdesc, "cn"}
%The end
]}