My goodness, @mikekaganski!

bedfordr — Thu, 14 Aug 2014 17:44:43 +0000

My goodness, @mikekaganski! It seems you're onto something! Every time I look at the documentation, I understand the purpose of each line differently. I settled on all of the above based on the feedback from the ldap, and trying to get the components to return (ldap_groupdesc, ldap_memberattr, ldap_groupattr, I guess). Clearly that was an incomplete understanding. Based on your description, I think I understand what is going on.

First, I thought the process went as follows:

Search for groups and find members in that group
Query each member of group (e.g. "RYDP") and get their JID and User Description
Assign each of these query members to the group query (e.g. "RYDP")

Instead, the process seems to be:

Search for groups and find members in that group
Query each member of group (e.g. "RYDP") and get their JID and User Description and Group affiliation (again, need "RYDP")
Assign each of these query members to their affiliation (e.g. "RYDP" in the above example)

My only annoyance is that because I have to query each user's affiliation (even after I search for the memberof), I have to retain their affiliation in two places (one in a group assignment, and one in a 'department'). I can't say I really understand this process, but for now, it seems to be populating properly.

Here is what my working mod_shared_roster_ldap now looks like:

{mod_shared_roster_ldap,[
{ldap_base, "cn=Users,dc=opto,dc=lab"},
{ldap_filter, ""},
{ldap_rfilter, "(&(objectclass=Group)(description=department))"},
{ldap_groupattr, "cn"},
{ldap_gfilter, "(memberof=CN=%g,CN=Users,DC=opto,DC=lab)"},
{ldap_groupdesc, "department"}, %this is requested from each user
{ldap_memberattr, "sAMAccountName"},
{ldap_useruid, "sAMAccountName"},
{ldap_userdesc, "cn"},
{ldap_user_cache_validity, "10"},
{ldap_group_cache_validity, "10"}
]},

Thank you for your help!

See comments in the quote

mikekaganski — Thu, 14 Aug 2014 04:01:57 +0000

See comments in the quote below.

bedfordr wrote:

----ejabberd.cfg outtake-------------------------
{mod_shared_roster_ldap,[
{ldap_base, "cn=Users,dc=example,dc=com"},
{ldap_filter, ""},
{ldap_rfilter, "(&(objectclass=Group)(description=department))"}, -> Well, you seem to get the list of groups that have string "department" as their description. OK.
{ldap_groupattr, "cn"},
{ldap_gfilter, "(memberof=CN=%g,CN=Users,DC=example,DC=com)"},-> Now you find users that belong to those groups. OK.
{ldap_groupdesc, "mail"}, )"},-> Now you get the users' mails as their group names. Is this OK? They will likely go to individual groups... Well, that's not gonna prevent it from working, fix later.
{ldap_memberattr, "sAMAccountName"},)"}, -> User name is in this attribute. OK.
{ldap_memberattr_format, "CN=%u,CN=Users,DC=example,DC=com"}, -> Here it is! You tell ejabberd that the string in sAMAccountName looks like "CN=%u,CN=Users,DC=example,DC=com", and ask it to only use what is in place of "%u". Buth that's not like that! You need to omit this param, or use just "%u" here!
{ldap_ufilter, "distinguishedName=%u"}, -> This won't work either. There's no user that has DN that looks like "barf" or "test".
{ldap_useruid, "mail"}, -> This has to be sAMAccountName. Maybe there's something different now, but in some versions there had been a check that this value is the same as in ldap_memberattr.
{ldap_userdesc, "cn"},
{ldap_user_cache_validity, "10"},
{ldap_group_cache_validity, "10"}
]},
-------------------------------------

ejabberd - Comments for "yet another mod_shared_roster_ldap questions"

My goodness, @mikekaganski!

See comments in the quote