In the Directory

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.

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.

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.

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.

Particular Features of Active Directory

Three steps are typically required before you can connect a groupware system to Microsoft's Active Directory (AD) for the centralized user management and single sign-on:

• Expand the schema
• Expand the AD GUI
• (Optionally) configure Kerberos.

Administrators of Scalix and Zarafa can configure groupware settings within the Windows management interface (Figure 4), whereas Zimbra has the Authentication Configuration wizard in its Admin GUI. The administrator only has to specify the AD domain and the access codes to the MS AD, along with the credentials for a user who has access permissions for the AD. The wizard does the rest.

Address Books and Contacts in the LDAP

Scalix, Zarafa, Open-Xchange, Zimbra, and Kolab can manage other objects above and beyond user, group, and corporate data in the LDAP, retrieving the information and making it available to the groupware users:

• The Global Address List (GAL): Users can search this list for addresses; the groupware delegates the search operation to LDAP. (Dynamic) subgroups are formed via LDAP filters.
• Contact information: Track information on users stored in LDAP (Figure 5).

• Distribution lists: For sending email to groups of addresses.
• Dynamic user groups: Mostly based on (definable) LDAP filters. With dynamic groups, it is possible to separate (virtually) groupware users from LDAP users who have nothing to do with the groupware. However, Zarafa advises against the overuse of such filters with Microsoft AD connected because it leads to long response times.

Before Open-Xchange users receive access to the contact information, they must first adopt the groupware. The system administrator installs the open-xchange-contact-storage-ldap plugin and adjusts the configuration to the local conditions, such as mapping the contact attributes.

Mapping

It is one of the very rare (yet happy) moments when a administrator can install both an LDAP directory and a groupware tool on a brand new site at the same time. A more likely scenario is that the directory service has been around for a while, has gradually adapted to local peculiarities and inquiring applications, and is well stocked with a variety of data. Connecting your groupware system to an existing directory is much more common and significantly more challenging. An analysis of the attributes of both partners is required when merging your groupware system with an existing LDAP installation. Different groupware systems handle the situation differently. Tine 2.0 stores the IDs of its users in the LDAP attribute entryUUID, but locally in the database field account_id. The administrator must migrate all Tine 2.0 IDs to the entryUUID if an existing Tine 2.0 user database needs to migrate to the LDAP.

The situation is similar for Scalix: The administrator must match the global unique ID to the Active Directory's objectGUID. The administrator can read the relevant user data in LDIF format using a omldapsearch command and modify the data to fit using a script.

The reverse case leads to manual work – if an existing AD server needs to be connected with users and groups using Scalix. You'll need to populate several attributes in the AD in advance so that Scalix can import them: scalixMailboxClass, scalixMailnode, and scalixScalixObject. A script in the Scalix wiki helps automate this process [10].

Most groupware applications have the ability to adapt the mappings of found LDAP attributes, such as group membership or individual address data, to predetermined local fields. For example, Zarafa lets you configure basic mappings directly in ldap.cfg; Listing 1 shows an example.

ldap_user_search_filter = (zarafaAccount=1)
ldap_user_unique_attribute = uidNumber
ldap_user_unique_attribute_type = text
ldap_fullname_attribute = cn
ldap_loginname_attribute = uid
ldap_emailaddress_attribute = mail
ldap_emailaliases_attribute = zarafaAliases
ldap_password_attribute = userPassword

The administrator can perform further mappings, perhaps for individual address fields, in the /etc/zarafa/ldap.propmap.cfg file. Zimbra administrators can configure mappings either via the GUI or using the Zmprov command line interface [11] to edit GAL mappings using the attribute zimbraGalLdapAttrMap.

Combined, Yet Separated

The groupware admin typically maintains the user base with normal LDAP tools. However, some products also help; for example, Scalix extensions make it possible to add or remove mailboxes in the AD. You can also manage groups (mail nodes) and domains, allocate privileges, change languages, or set quotas.

Such advanced capabilities do not alter the fact that the administrator has to work with two GUIs – one for the groupware and one for LDAP. Kolab and Zarafa, in combination with the Univention Corporate Server (UCS) Debian-based server OS, are exceptions. The integration kit Zarafa4UCS looks after the integration of groupware in the UCS management system [12] (Figure 6). The LDAP connection essentially consists of creating an advanced schema in the UCS. The UCS administrator then manages Zarafa users and configuration in the GUI.

Conclusions

Willing system admins should expect quite a bit of work to plan and merge an existing groupware system with an existing LDAP directory. You will also need to get used to the fact that data fusion in the LDAP service does not automatically result in centralization of administration tools for the vast majority of systems. Kolab and Zarafa piggybacked on UCS prove that all-in-one admin GUIs are possible.