Auto-populate Wildfire buddy list using Zimbra LDAP

Good morning. I apologize if this question exists in another location on the forums or internet. I have been unable to find anything that addresses this issue directly except this post in the Zimbra forums: e

I am having an issue configuring groups in Wildfire using Zimbra’'s LDAP database. Th ultimate goal of the project is to have Wildfire auto-populate the buddy list with usernames from the Zimbra LDAP.

Zimbra’'s LDAP is set up as follows:








The only text attributes of ou=people are:




The uids are entries that contain text attributes pertaining to each user.

Here is the

Using the above LDAP config, I am able to populate the users in Wildfire. I have verified this by entering the Wildfire admin console and clicking on Users/Groups. I can see all the users from Zimbra. All is well up to this point.

Using the above config, I can see one group in Groups category of the Wildfire admin console: ‘‘people’’. The group ‘‘people’’ has no users.

I say again that the goal is to auto-populate the buddy list in Wildfire with the users in Zimbra. It is my understanding that if connected to an external LDAP, the only way to accomplish this is by using an existing group in LDAP and configuring it through the Wildfire admin console to be a Shared group. If this is incorrect, or if there is a different way of accomplishing this task, I ask the Wildfire community to lend me their support.

Thank you in advance,

Alejandro Figueroa

Hi Alejandro,

is the “people” group empty? If it is it will help a lot to add all users to this group within LDAP. Wildfire does just query LDAP and does not care if you call your group “people” or “peanuts”, so if no-one is in this group it will be empty.


Although my LDAP experience is from Active Directory the similar rules apply.

In your example, people is an Oganizational Unit, or an OU for short. It is not a group. What you will need is to define a group with members, where the uid/username is defined as part of the properties of that object.

Excerpt from the forum you included, looks like you cant easily pull in groups from Zimbra, because it may not have a concept of what one is…

robrankin wrote:

I couldn’‘t figure out how to get it to work against the Zimbra LDAP. Basically Wildfire expects group members to be either full DN’‘s, like “uid=username,ou=people,dc=example,dc=com”, or to be a simple uid, which it then appends the base DN onto. I was trying to use a distribution list as my group in Wildfire. Since the members are stored as email addresses, it didn’'t work, since an email address is neither part of the user DN nor uid.

digitaldan wrote:

Having Zimbra/Asterisk/Wildfire connected is very nice. It does look like getting groups to work will require a schema or code change.

That schema change is within your LDAP not wildfire, you might need to think about using another LDAP flavor, in order to accomplish what you are after

Thank you for your replies.

To LG:

The ou=people contains within the text attributes that I mentioned before, along with the uid entries. These uid entries appear as sub folders within the ou=people folder. Thus the LDAP hierarchy is:




____|_cn=people (text attribute)

____|_objectClass=organizationalRole (text attribute)

____|_ou=people (text attribute)

____|_uid=user1 (folder)

_____|(user text attributes)

____|_uid=user2 (folder)

_____|(user text attributes)


To wvankuyk:

I will be opening a similar thread to this one in the Zimbra forums today. Hopefully the Zimbra community can help me understand their particular LDAP setup more indepth.

I will post a link to the forum here for those that wish to follow the thread in Zimbra.


Hi Alejandro,

you may want to add a group to LDAP, like:

         uid=user1 *1
         uid=user2 *1
         cn=groupname *2
            uniqueMember: uid=user1,ou=people,dc=domain,dc=com
            uniqueMember: uid=user2,ou=people,dc=domain,dc=com
            uniqueMember: uid=...,ou=people,dc=domain,dc=com

*1 this is a user with a lot of different attributes (uid, cn, mail, …)

*2 this is a group with a lot of uniqueMember attributes