mod_shared_roster_ldap configuration to get Active Directory groups

Hi All. I'm trying to use this module with ejabberd 2.0.1 on Debian Lenny. I got the latest source I found (2005 ?) and compiled it.
LDAP authentication and mod_vcard_ldap are working fine.

What I'm trying to do is to show in jabber client all AD groups and their members
1- which Group CN name begins with 'J_"
2- to which behave the user (optional for me, but I think it is what is supposed to do at least this module , right ?)

No way to do that.

1- Here is the config :
{mod_shared_roster_ldap, [
{ldap_groupattr, "memberOf"},
{ldap_memberattr, "sAMAccountName"},
{ldap_rfilter, "(memberOf=CN=J_*)"}
]},

No group are shown in the jabber client in that case.

2- I tried then to filter to a single group :
{mod_shared_roster_ldap, [
{ldap_groupattr, "memberOf"},
{ldap_memberattr, "sAMAccountName"},
{ldap_rfilter, "(memberOf=CN=JABBER_USERS,OU=Utilisateurs,DC=rms,DC=loc)"}
]},

The group really exist and has members (including myself) :
an ldapsearch with memberof=CN=JABBER_USERS,OU=Utilisateurs,DC=rms,DC=loc as filter and sAMAccountName as attributes gives :

dn: CN=Fabrice Le Dorze,OU=Utilisateurs,DC=rms,DC=loc (It is me !!!)
dn:: Q049TWFyYyBQw6lyYXJkLE9VPVV0aWxpc2F0ZXVycyxEQz1ybXMsREM9bG9j
dn: CN=Remy Croze,OU=Utilisateurs,DC=rms,DC=loc
dn: CN=Bernard Buttard,OU=Utilisateurs,DC=rms,DC=loc

But in that case, All AD groups and members are shown in jabber client, even the ones I'm not belonging to.
Furthermore, I generates so many LDAP requests which really slow down the connexion, especially when several users are connected.

What am I doing wrong ?
I'm not sure when should be used ldap_filer and ldap_rfilter
Is my version of the module too old ? When could I get the newest ?
Should I upgrade to the latest stable version of ejabberd ?

Thank you for your help.

> Is my version of the module

> Is my version of the module too old ? When could I get the newest ?

You can find the newest here: http://www.ejabberd.im/mod_shared_roster_ldap
In any case, that module didn't get changes in a lot of time.

> Should I upgrade to the latest stable version of ejabberd ?

Sorry, I don't know details about this module. Just an idea: you can install a newer ejabberd in your work machine (not on the server machine where the main ejabberd 2.0.1 is runnning), setup this module, and test if that works or not.

I used the debian lenny

I used the debian lenny backports to get ejabberd 2.0.5 and tried the shared_roster_ldap configurations I tried with 2.0.1.
My module version is the newest one from http://www.ejabberd.im/mod_shared_roster_ldap.
Nothing changed : in the first case, no groups are shown, in the second one, all groups are shown, not only the one specified by ldap_rfilter.

I tried another way to do by using mod_shared_roster module : I extract chosen AD groups and members thanks to ldap requests and add them with ejabberdctl. But it requires to write a synchronization tool (I will do it in last resort) ; furthermore, I found no way to display group members with their LDAP CN (firtname lastname) instead of their JID.

So getting a working automatic synchronization with AD groups through this module would be more convenient.

I have no time to get skills in Erlang

Can somebody help ?

Hi, Recently we have

Hi,

Recently we have integrated Ejabberd with Active Directory and users getting contacts by using Mod_shared_roster_ldap module in server.

But user can't able to customize the roster contacts(Grouping)as they want..

Kindly confirm is possible to fix or if any other remedy.

Version : Ejabberd 1.9

Thanks in advance.

mod_shared_roster_ldap configuration

I had a lot of troubles trying to figure out how the mod works and how it should be configured. So here's what I could find out.

It has the following options:

  1. ldap_servers
  2. ldap_port
  3. ldap_base
  4. ldap_rootdn
  5. ldap_password
  6. ldap_filter
  7. ldap_rfilter
  8. ldap_groupattr (default is "cn")
  9. ldap_groupdesc (default is "cn")
  10. ldap_userdesc (default is "cn")
  11. ldap_memberattr (default is "memberUid")
  12. ldap_memberattr_format (default is "%u")

The first 7 options default to higher-level options (including ldap_rfilter, though I don't know if there exist such higher-level setting). Of them, the first 5 are self-explaining and have the same meaning as at the top level.
When the mod loads it reads these options, and then creates the Filter (that will be used afterwards in steps 2, 3, 4 and 5):
(&(&([ldap_memberattr]=[ldap_memberattr_format])([ldap_groupattr]=%g))[ldap_filter])
When the mod is called to get the shared roster for a user it does the following:

  1. Creates the list of groups to display: Using the ldap_rfilter, it gets the ldap_groupattr's of matching records to create this list.
  2. For each item (group) in this list, it finds all users that belong to it: Using the Filter where "%u" is replaced with "*" and "%g" is replaced with the item, it gets the ldap_memberattr's of matching records, then for each found value finds the user part of it (using ldap_memberattr_format), then checks if such a user exists on the server, and if it does, add it to userlist.
  3. To find the display name of a shared roster group: Using the same filter as in step 2, it gets the ldap_groupdesc of matching records.
  4. To find the display name of a shared roster user: Using the Filter where "%u" is replaced with user and "%g" is replaced with "*", it gets the ldap_userdesc of matching records.
  5. To find if a user belongs to a group: Using the Filter where "%u" is replaced with user and "%g" is replaced with group, it gets the "dn" attribute of matching records. If search brings records, it means the user belongs to the group.

So, in your case, the groups that should be displayed are all the "memberOf"s of all who is "(memberOf=CN=JABBER_USERS,OU=Utilisateurs,DC=rms,DC=loc)", and it's difficult to say what is the contents of your groups as you haven't defined ldap_filter here, so the global one is used, and you may build the resulting query yourself.

What to the intensive network traffic, it's related to the described mode of operation, that makes at least 1 search to get the group list (my logs show 2 searches), at least 2 searches for each group (to get its members and to get its display name), and at least 2 searches for each user (to find out if it exist on server, and to get its display name), plus maybe more.

Best regards,
Mike.

Syndicate content