ejabberd - Comments for "Problem with showing full usernames -> mod_shared_roster_ldap"

http://www.process-one.net/do

mikekaganski — Mon, 11 Jul 2011 21:35:40 +0000

http://www.process-one.net/docs/ejabberd/guide_en.html#msrlattrs

Quote:

ldap_useruid: The name of the attribute which holds the ID of a roster item. Value of this attribute in the roster item objects needs to match the ID retrieved from the ldap_memberattr attribute of a group object. Retrieved from results of the “User Filter”. Defaults to cn.

I didn't mean to offend you. However, that proposition didn't make any sense.

c4r0l1n3 wrote: Hi

mengesb — Mon, 11 Jul 2011 20:10:30 +0000

c4r0l1n3 wrote:

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.

mikekaganski

mengesb — Mon, 11 Jul 2011 14:53:45 +0000

mikekaganski wrote:

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.

http://www.process-one.net/docs/ejabberd/guide_en.html#htoc62 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.

2mengesb: I suppose you don't

mikekaganski — Sun, 10 Jul 2011 01:05:03 +0000

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.

Your problem is with the

mengesb — Sat, 09 Jul 2011 21:01:39 +0000

Your problem is with the '{ldap_useruid, "uid"}' item I think. Change that to cn:

{ldap_useruid, "cn"},