Hi there,
I have a "little" problem I'm trying to solve for weeks, so I hope you can help me...
It's about the ejabberd configuration with LDAP on our own server.
With webinterface, the ejabberd start, vcard and login, everything is shown right.
But the problem is, that the client we're using (Pidgin) only shows the uid instead of the full name/common name, although if in the ejabberd.cfg the attribute "ldap_userdesc" is set as "cn", not "uid".
But if I click on "get information", it shows (via module vcard I guess) all attributes right: the full name, the e-mail and so on, but in list there's still only the uid I see.
Example with the user "Tux Penguin":
uid=tpenguin
cn=Tux Penguin
mail=t.penguin@example.com
ou=XMPP
Pidgin shows:
in list:
tpenguin
when I click on "get information":
Full name: Tux Penguin
E-mail: t.penguin@example.com
I've already tried to set any other attributes in the config file, but it still doesn't work...
Here the part of the ejabberd.cfg:
{mod_shared_roster_ldap,
[
%% Base filter for lookups %% ou=JabberGroups
{ldap_base, "ou=XMPP,dc=example,dc=com"},
{ldap_rfilter, "(objectClass=*)"},
{ldap_filter,""},
{ldap_ufilter,"(uid=%u)"},
{ldap_groupattr,"cn"},
%%{ldap_groupdesc,"description"},
{ldap_memberattr,"memberUid"},
%%{ldap_memberattr_format, "uid=%u,ou=XMPP,dc=example,dc=com"},
{ldap_useruid, "uid"},
%%{ldap_auth_check, "on"},
{ldap_userdesc,"cn"}
%% END mod_shared_roster_ldap
]
}
]}.The directory looks like this:
dn:dc=example,dc=com
->
# XMPP OrganizationUnit
dn:ou=XMPP,dc=example,dc=com
objectClass=organizationalUnit
ou=XMPP
->
# ROSTER GROUPS
dn:cn=Group1,ou=XMPP,dc=example,dc=com
cn=Group1
objectClass=posixGroup
objectClass=top
memberUid=tpenguin
dn:cn=Group2,ou=XMPP,dc=example,dc=com
cn=Group2
objectClass=posixGroup
objectClass=top
memberUid=mexample
->
# USER 1
dn:uid=tpenguin,ou=people,ou=OrganizationUnit1,dc=example,dc=com
cn:Tux Penguin
objectClass:inetOrgPerson
objectClass:OpenLDAPperson
objectClass:organizationalPerson
objectClass:pilotPerson
objectClass:mozillaOrgPerson
objectClass:person
objectClass:posixAccount
objectClass:shadowAccount
sn:tpenguin
uid:tpenguin
# USER 2
dn:uid=mexample,ou=people,ou=OrganizationUnit2,dc=example,dc=com
cn:Mister Example
objectClass:inetOrgPerson
objectClass:OpenLDAPperson
objectClass:organizationalPerson
objectClass:pilotPerson
objectClass:mozillaOrgPerson
objectClass:person
objectClass:posixAccount
objectClass:shadowAccount
sn:mexample
uid:mexample
# ROSTER LIST IN PIDGIN
Group1
=> tpenguin
Group2
=> mexample
Does anyone know how I can solve this and see the full names with Pidgin?
Thanks for your help!
Your problem is with the
Your problem is with the '{ldap_useruid, "uid"}' item I think. Change that to cn:
{ldap_useruid, "cn"},That should fix your problem.
2mengesb: I suppose you don't
2mengesb:
I suppose you don't understand what you suggest. The ldap_useruid must correspond to the data in ldap_memberattr of the ldap_gfilter.
2OP:
I'm not sure if this has something to to the problem,
but your data shows that in no phase the shared roster contains the properly formed jid (i.e. "user@server"). You may check for the xml data that your client gets.
I would try to make a mixed roster for a user, where some roster items were from ldap shared roster, and some added manually, and inspect the xml data that is recieved and sent by your client when getting the roster from server (e.g. on logon).
I suppose that your client doesn't use the additional (optional) information in the roster (ldap_userdesc), and just uses the jid to get the vcard, from which it will get the display string (e.g. your client may have a user-definable field which is to show in user list). Then, if your roster contains items with invalid jid, it is unable to get the relevant vcard.
However, something is wrong with this: as you say, you are able to get the correct information when clicking "get information". This is inconsistent with my idea.
By the way, you haven't shown other data that is relevant: seems like some of your fields are set at a higher level, one of them being the abovementioned ldap_gfilter.
mikekaganski
2mengesb:
I suppose you don't understand what you suggest. The ldap_useruid must correspond to the data in ldap_memberattr of the ldap_gfilter.
says nothing about ldap_memberattr matching anything. Its true I'm not quite up to par understanding some of these mappings, hence I've asked for help in my own thread trying to work on my shared roster, but that doesn't mean i'm any less right or wrong; I'm simply going by what I've setup that shows the right display name.
http://www.process-one.net/do
I didn't mean to offend you. However, that proposition didn't make any sense.
c4r0l1n3 wrote: Hi
Hi there,
{mod_shared_roster_ldap,[
%% Base filter for lookups %% ou=JabberGroups
{ldap_base, "ou=XMPP,dc=example,dc=com"},
{ldap_rfilter, "(objectClass=*)"},
{ldap_filter,""},
{ldap_ufilter,"(uid=%u)"},
{ldap_groupattr,"cn"},
%%{ldap_groupdesc,"description"},
{ldap_memberattr,"memberUid"},
%%{ldap_memberattr_format, "uid=%u,ou=XMPP,dc=example,dc=com"},
{ldap_useruid, "uid"},
%%{ldap_auth_check, "on"},
{ldap_userdesc,"cn"}
%% END mod_shared_roster_ldap
]
}
]}.
In comparrison to my shared roster config:
{mod_shared_roster_ldap,[{ldap_base, "ou=Company,dc=example,dc=com"},
{ldap_groupattr, "cn"},
{ldap_groupdesc, "description"},
{ldap_memberattr, "memberUid"},
{ldap_rfilter, "(objectClass=*)"},
{ldap_ufilter, "(uid=%u)"},
{ldap_useruid, "uid"},
{ldap_userdesc, "displayName"},
{ldap_filter, ""}
]},
Looks like my base config difference is '{ldap_userdesc,"displayName"}'
Needless to say I've been trying hard at my AD configuration (which is a small snip above). Our AD is a little more complex than a flat roster. Unfortunately I'm not able to get my groups showing right... not sure why... still working on it; but that 'displayName' should help you potentially; unless that's a Windows AD specific thing.