Привет всем!
Уже совсем замучался, наверное что-то не так делаю, пытаюсь читать документацию, но толи с английским неважно, толи просто не догоняю. В общем дело обстоит так. Есть учетные записи типа sambaSamAccount в LDAP (стоит самба с учетками в LDAP, хотя и не домен) и ejabberd настроен видеть учетные записи тоже из LDAP, видит он их прекрасно.. но.. Итак, учетная запись в LDAP к примеру вот такая:
dn: uid=bukinist,ou=Users,dc=urfu
structuralObjectClass: account
entryUUID: d7503004-a874-1031-87ce-a99e1628b3e4
creatorsName: cn=admin,dc=urfu
createTimestamp: 20121012045551Z
objectClass: account
objectClass: posixAccount
objectClass: sambaSamAccount
gidNumber: 10008
sambaNTPassword: 9B2F370415DFA96F24E58C190B6A3042
description: User account
uidNumber: 10009
cn:: 0J3QsNC00LXQttC00LAg0JzQuNGF0LDQudC70L7QstC90LA=
loginShell: /bin/false
sambaAcctFlags: [U ]
sambaPwdLastSet: 1350017751
sambaSID: S-1-5-21-4231628449-694983756-2302091911-1014
uid: bukinist
gecos: bukinist
homeDirectory: /home/bukinist
sambaPasswordHistory: 00000000000000000000000000000000000000000000000000000000
00000000
displayName: bukinist
userPassword:: e1NTSEF9WEMzSTVyRThxaXVFcFlTaHFLejJ5enVVTUVhblc0YjQ=
entryCSN: 20121012080842.916723Z#000000#000#000000
modifiersName: cn=admin,dc=urfu
modifyTimestamp: 20121012080842Z
В ней атрибуту cn присвоено значение "Надежда Михайловна", тут оно просто отображается в таком виде. Мне нужно вывести в ростер пользователей такого типа так, чтобы они отображались нормальными русскими именами. Как уже понятно, эти имена хранятся в cn для каждого пользовтеля. А вот моя неудачная попытка их вывести:
{mod_shared_roster_ldap,[
{ldap_base, "ou=Users,dc=urfu"},
{ldap_filter, "(objectClass=sambaSamAccount)"},
{ldap_rfilter, "(objectClass=sambaSamAccount)"},
{ldap_ufilter, "(&(objectClass=sambaSamAccount)(cn=%u))"},
{ldap_groupattr, "gidNumber"},
{ldap_groupdesc, "description"},
{ldap_memberattr, "gidNumber"},
{ldap_ufilter, "cn"},
{ldap_userdesc, "cn"},
{ldap_useruid, "cn"} ]}
Выручайте друзья, я уже кажется все перепробовал. Так как группы пользователей представляют из себя число, то я сделал через ldap_groupdesc вывод имени группы "User account". А вот получить для вывода в качетсве имен cn не могу.
Вы не указали, что отсюда
Вы не указали, что отсюда должно идти в 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
]}
Простите, ковырял конфиг на
Простите, ковырял конфиг на работе, пришел домой, а конфиг то не взял. Придется ждать до понедельника, когда смогу добратья до рабочего компьютера. Но кое что сказать могу. В jid попадает uid пользователя, то есть для вышеприведенной записи в LDAP это будет . Под таким именем пользователь прекрасно логинится на 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. Спасибо большое! Жаль, что испытать получится только в понедельник. По результатам - отпишусь. =)
Я тут погуглил по поводу
Я тут погуглил по поводу групп в самболдапе. Если не ошибаюсь, группа выглядит примерно так (взято из ):
dn: cn=Domain Admins,ou=Group,dc=themusiclink,dc=netdescription: 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. Производительность: в первом подходе каждый пользователь возвращался трижды: при построении списка групп возвращались все пользователи, при опросе группы возвращались все пользователи группы, и при опросе пользователей. Здесь при построении списка групп возвращаются два объекта-группы, при опросе групп возвращается один объект-текущая группа, а пользователи опрашиваются только в третьей стадии. (Ну, конечно, при десяти пользователях это не принципиально, но если их сто тысяч...)
Здравствуйте! У меня немного
Здравствуйте!
У меня немного другая ситуация.Самба хранит учетные записи в LDAP, однако домена нет, поэтому unix-группы не "примапплены" к доменным группам и в LDAP хранятся только записи о unix-группах, а не о доменных. То есть unix-пользователи имеют доп атрибуты Samba-пользователей, а вот unix-группы нет, они в чистом виде unix-групп, к примеру:
dn: cn=Admins,ou=Groups,dc=urfuobjectClass: 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. Большое Спасибо! =)