Groupware systems promote collaboration and save time by consolidating essential communication, calendaring, and coordination services in a single interface. The groupware application provides these services to a database of users and manages these users through user profiles, login credentials, and other identifying information. But many organizations today already maintain a network-wide user directory through LDAP that provides universal login and also tracks security privileges and personal data. If groupware is all about saving time by combining and consolidating effort, why maintain a groupware user database that is separate from the data maintained through the LDAP directory service?

If the services on your network all fall within the same vendor orbit, such as the tools of the Microsoft Active Directory ecosystem, coordination of groupware with the directory is relatively seamless. If, however, your network consists of independent, open source components, or if the services network came online at different times, you'll need to expend a little more effort to interface your groupware with LDAP. In this article, I highlight some important considerations for LDAP integration with some leading open source groupware alternatives.

Table 1 compares the LDAP support in the open source groupware tools Open-Xchange [1], Tine 2.0 [2], Zarafa [3], Kolab [4], EGroupware [5], Scalix [6], and Zimbra [7]. The individual systems differ visibly in the options implemented through LDAP. The lowest common denominator is authentication via the directory; some systems also provide synchronization of LDAP data into the groupware user database through address information and distribution lists to individual configurations.

Pretty Simple Installation

Connecting a groupware suite to an external LDAP directory service does not raise any significant challenges for administrators; almost all common systems have everything you need and only require some configuration. In Open-Xchange, for instance, administrators only need to install the plug-in package open-xchange-authentication-ldap, which replaces open-xchange-authentication-database. You can then configure the LDAP login using the /opt/open-xchange/etc/groupware/ldap.properties file.

The groupware official must explicitly enable and configure the connection for all systems. In Zarafa, for example, modify /etc/zarafa/server.cfg with the lines:

user_plugin = ldap
user_plugin_config = /etc/zarafa/ldap.cfg

Then configure LDAP through the settings in /etc/zarafa/ldap.cfg.

Each groupware tool requires the LDAP URL(s), an LDAP admin user, and a base DN as an entry point into the directory tree. If Active Directory is also involved, you need to specify the name of the Windows domain.

The LDAP server is a critical component for anyone handling all logins in their IT via LDAP. It is almost imperative to operate a redundant directory setup using a master-slave architecture. Many groupware suites support this configuration. Figure 1 shows an example of redundancy with Zarafa.

Figure 1: LDAP servers can operate in the cluster to ensure high availability – groupware systems such as Zarafa explicitly support cluster operations.

In most groupware systems, administrators have to expand their LDAP schema so that the directory can include further information requested by the groupware, such as address fields and special configurations for calendars or groups. Systems like Zarafa and Scalix provide an appropriate schema definition, which LDAP can easily incorporate. Two simple steps are enough for Zarafa and OpenLDAP:

cp /usr/share/doc/zarafa/zarafa.schema \
   /etc/openldap/schema/zarafa.schema
include /etc/openldap/schema/zarafa.schema

For better performance, some systems add an index to a set of attributes. The administrator might have to expand the index individually. (See the OpenLDAP server logfiles for pointers regarding how to expand the index.)

Zimbra automatically installs its own extensive schema as soon as an external LDAP connection is enabled for a Zimbra domain. Administrators can attach their own attributes to the file /opt/zimbra/conf/attrs/zimbra-attrs.xml.

Authentication via LDAP

All freshly installed groupware packages store the users along with their data, such as addresses and configurations, in a database. Kolab inherently uses LDAP in the form of the 389 directory server [8]; Zimbra uses OpenLDAP.

If you connect your groupware system to an LDAP server, you delegate user authentication to the directory. The process is transparent for users; a user typically uses an email address for logging on to a groupware system. If you delegate authentication to LDAP, a simple task like changing the password can only happen through the LDAP directory, unless the software provides some kind of programmatic interface. Zimbra [9] and Zarafa offer plugins for interacting with the directory through the groupware user interface.

Administrators can create user profiles manually, or the groupware can create profiles automatically in the LDAP directory based on predefined specifications (as shown in Figure 2). The best case scenario is for a visitor to log on and for the groupware to create and update a local account.

Figure 2: Configuring LDAP in Tine 2.0 via the Admin GUI.

Synchronizing with LDAP

The other candidates, such as Open-Xchange, Zarafa, Zimbra, and Scalix use synchronization routines that shovel the relevant user, group, and configuration data from the directory into the groupware database and perform additional tasks, such as creating mailboxes for new users (Figure 3). Generally, the synchronization routines only gain read access to the directory.

Figure 3: The central LDAP server provides relevant user data for the groupware and authenticates the logins.

With Scalix and Open-Xchange, administrators can call up this routine on the command line. A sync agreement must be drawn up in Scalix before first use. This agreement is supposed to show the trust between the directory and the groupware server. The command

omldapsync -u Agreement_Name

is then sufficient to copy modified data from the directory to the groupware server.

Zarafa usually uses just-in-time synchronization to adopt automatically a newly created user into or remove deleted users from its local database. The administrator can disable this feature for very large numbers of users and let the sync run, in a time-controlled manner, using the command

zarafa-admin --sync

Zimbra also automatically transmits user data from the external LDAP and implements two modes of operation: In Lazy mode, the transmission is performed if the user logs on. In Eager mode, this transmission happens at an agreed-upon interval.

With Open-Xchange, the administrators must first install the OX LDAP Sync tool, then configure the LDAP bind and the copying behavior in the /opt/oxldapsync/etc/ldapsync.conf file so that Open-Xchange can synchronize with OpenLDAP. The actual call is:

./oxldapsync.pl -c 1 -A \
   oxadmin -P admin_password -v -s

In Active Directory, it is a good idea to assign groupware users to a separate branch and only synchronize with this branch, so that no AD system user accounts, such as Administrator or Guest , make their way onto the groupware server.