In the Directory

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.

Figure 4: Scalix adds its own elements to the Windows management interface.

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).

Figure 5: Creating a Zarafa contact in Active Directory.

• 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.