Setting up ejabberd server for Zarafa with LDAP integration

From Zarafa wiki

Contents

Introduction

This wiki article describes the installation and configuration of the ejabberd XMPP server.
Ejabberd can be integrated with Zarafa WebApp to offer instant messaging and presence functionality.

The article is based on the installation on a Red Hat or Centos server, however it can be used for other distributions.

For user management a LDAP or Active Directory can be used, however the example configuration is based on OpenLDAP.
For Active Directory some attributes might be different, so basic LDAP knowledge is required when following this howto.

Installation

Before the actual ejabberd package can be installed, the additional EPEL repository has to be added.
This yum repository is added the package can be installed:

yum update
yum install ejabberd

The system is now ready to be configured.

Configuration

Before the configuration can be done, a domain is required for the jabber server.
When the user should be able to connect their jabber clients over the internet, this domainname should be added to the public DNS server.

In this configuration the domain +jabber.example.com+ is used as example.

The main configuration of ejabberd is located in +/etc/ejabberd/ejabberd.cfg+.
In the file the following changes have to be made:

Add the jabber domain to the host section. If multiple domains are available the domains can be added seperated by a comma.

{hosts, ["jabber.example.com"]}.

To enable access to the jabber server through an encrypted connection, the certicate line has to be uncommented and the path to the SSL certificate has to be specified.
At installation a self signed certificate is created in +/etc/ejabberd/ejabberd.pem+, so this certificate can be used.

{5222, ejabberd_c2s, [
%%
%% If TLS is compiled in and you installed a SSL
%% certificate, specify the full path to the
%% file and uncomment this line:
%%
{certfile, "/etc/ejabberd/ejabberd.pem"}, starttls,
{access, c2s},
{shaper, c2s_shaper},
{max_stanza_size, 65536}
]},

To authenticate users on the jabber server the authentication method has to be configured.
In this setup the authentication can be done against a LDAP server or with the external authentication script when users are connecting from the chat plugin in the Zarafa WebApp.

To further define the LDAP server details change the following lines:
In this example only the users with an emailaddress with get access to the jabber server. The filtering can be changed to further limit users from using the jabber server.

Depending on the type of LDAP server the attributes have to be changed.
The user details can be requested from the a fat jabber client. The Zarafa WebApp chat plugin doesn't offer this feature right now.

The second module that has to be configured is the shared roster. The shared roster will create a predefined contact list for all users, so they can directly start chats with colleagues.
This shared roster should be added for the WebApp chat plugin, as the plugin can't manage the contact list right now.

To allow access to the jabber server from the internet port 5222 should be forwarded to the jabber server.
For access from the WebApp chat plugin default port 5280 is used. If the Apache webserver which serves the WebApp is the DMZ, it might be necessary to allow traffic on port 5280 on the jabber server.

Activate services

When everything is correctly configured, the jabber service can be started.

service ejabberd restart

To enable the jabber service at boot time, enable it:

chkconfig ejabberd on

After the service is started, the logfiles +/var/log/ejabberd/ejabberd.log+ can be checked for errors.
If no errors show up, a fat jabber client can be connected to test the setup.

When the configuration is done correctly, both the fat client and the WebApp should be able to login and show the configured roster.

Notes

When installing and configuring ejabberd on Debian or Ubuntu the mod_shared_roster_ldap module is missing.
To have this module enabled ejabberd has to be installed from source.
When using a current Debian or Ubuntu this seems no longer be the case.
Tested with Debian 7