Kolab Groupware and LDAP
Kolab Groupware makes extensive use of LDAP, and has unique capabilities that,
should you choose to use them, may require the use of a particular LDAP server
implementation as a result.
To allow you the greatest flexibility (you do not have to decide today), Kolab
ships the community version of Red Hat Directory Server, called
389 Directory Server (formerly known as Fedora Directory Server).
Kolab Groupware uses LDAP for, among other things:
Authentication of users and services, through
Mail Exchangers to decide whether to accept or reject messages, and how to
route accepted messages based on information contained in LDAP,
the authoritative list of mailboxes to be maintained in IMAP, through
the Global Address Book for users, distribution groups, contacts, shared
folders and resources,
In Kolab 3.0, for single parent domain deployments only, translation of the
authentication ID into the authorization ID (a process called
In Kolab 3.1 and later, for multi- parent domain deployments, translation of
the authentication ID into the authorization ID (a process called
canonification) for the web client only.
In Kolab 3.2 and later, for multi- parent domain deployments, translation of
the authentication ID into the authorization ID (a process called
canonification) for both the web client and IMAP itself, as well as group
ACLs for IMAP based on roles or (simple) group membership.
For this purpose, Kolab is configured to use a service account, usually
uid=kolab-service,ou=Special Users in the primary domain’s root dn.
This service account is intended to have read access throughout all directory
entries, across all directory trees, as it is used to read lists of domain name
spaces locally hosted, and valid recipient and sender addresses in those domain
During setup, this account is configured to circumvent size, search,
lookthrough and other administrative limitations configured on normal
accounts, that protect your LDAP server’s performance.
The Kolab daemon kolabd is responsible for the synchronization of changes in
LDAP that are to be relected on the IMAP mail boxes and folders and access
It uses either searches or replication mechanisms available in the LDAP server,
depending on the LDAP server’s capabilities.
For each of the mutations in LDAP, the daemon takes the appropriate actions
against IMAP, such as;
Creating mailboxes for new users, shared folders and resources,
Renaming mailboxes for entries that have changed, when appropriate,
Deleting mailboxes for entries that have been removed,
as well as communicates back any further changes to LDAP should they be needed
– for example, the enforcement of policies such as the recipient policy.
The Kolab SASL Authentication Daemon kolab-saslauthd is responsible for
verifying the user credentials supplied to the IMAP server and the MSA,
in turn using the following key steps:
The authentication realm as provided in the (user-supplied) login username,
or the primary domain name space (the default realm),
The LDAP domain object that corresponds to the authentication realm,
The associated DIT root dn for the domain,
The user entry corresponding with the provided (user-supplied) login
An attempt to bind with the user entry DN found is made, using the
(user-supplied) login password.
Steps 2 and 4 are LDAP searches, that depending on the size of the deployment
may take longer than would be considered good performance.
Administration Guide topic for LDAP deployments with single trees growing
over 1.000 entries.
The Difference Between Accounts and Users
It is important to note that there is a difference between a user and an
account – of the type that a cow is an animal, but an animal is not a cow.
There is only one type of user, and that is a human being physically present in
this time and space.
While these users tend to have accounts (user accounts), other types of
accounts include service accounts, administration accounts and system accounts.
A service account included with a default Kolab Groupware setup is
kolab-service . This account enables services such as for example
Postfix, to search LDAP for entries (recipients hosted by the local Kolab
Groupware installation), without disclosing the contents of the entire LDAP tree
to everyone (anonymously).
An administration account that Kolab Groupware uses by default is
cyrus-admin. This account is made a Cyrus IMAP administrator (see the
admins setting in imapd.conf(5)), and is used by Kolab daemons to
maintain the mailboxes and other IMAP related policies.
On the other hand, your Linux system likely holds accounts such as root and
nobody. These would typically be considered system accounts. To make
sure Kolab Groupware daemons and applications do not have unrestricted access to
your entire system (or your data, for that matter), additional system accounts
are created on your system.
Parent, Alias and Child Domain Namespaces
All email environments make use of at least one domain name space.
Without it, only recipient addresses that are local could be exchanged messages
with, but not the rest of the Internet. A local user
doe must be qualified
to the rest of the Internet as being user
doe in a domain name space (such
example.org) – this is what makes an email address
An organization – anything ranging from just you to your family or a
multi-national corporation – for which Kolab Groupware is being setup, will
have to choose a primary domain for the deployment. The domain name
space choosen will be used for the email addresses if its users.
An organization such as the Kolab Community might, for example, setup Kolab
for the primary domain
kolab.org. The Doe family though might setup Kolab
with a primary domain of
Because domain name spaces typically only have one owner, it is recommended to
use the domain components that make up the domain to also make up the LDAP root
dn. The Kolab Community would therefore result in
dc=example,dc=org, and the
Doe family would use
dc=doe,dc=nl. This is also the default during the Kolab
There are two types of additional domains one might add to a Kolab Groupware
Like mentioned before, these are domains with a separate, isolated LDAP
directory trees. Adding a parent domain other than the primary domain
establishes a true multi-domain deployment.
A default Kolab Groupware deployment is not set up to handle multiple
parent domains out-of-the-box.
alias domains / child domains
Alias domains are additional domains to use with existing parent domains.
Kolab Groupware sets you up with 4 domain name spaces by default:
As the primary domain name space for the entire deployment, you
supply a domain name space of your choosing during setup.
This domain name space defaults to the domain name space your system FQDN
For a system FQDN of
kolab.example.org for example, the default domain
name space for email would be
Your systems’ FQDN, in order to make sure fully qualified local email is
indeed delivered locally.
With the previous example in mind, this would be a domain name space of
kolab.example.org. Local POSIX users, including the root superuser,
tend to receive email to addresses such as
The primary domain is also known as a so happens to also be called a
parent domain name space.
The parent domain name space (of
example.org) is how we would like
to refer to the domain (“the organization”) as a whole, but additional domains
may be available to its users, such as
example.net domain name space in this case is called an
alias domain name space or child domain name space (depending on
the nature of your setup).
It is important to note that in Kolab Groupware, each organization receives its
own root dn, meaning its own, separate LDAP directory tree. This allows
Kolab Groupware to use multiple LDAP servers, and allows organizations to use
features such as the Global Address Book without a compromise to security and
privacy. As such, each parent domain name space for each organization
directly corresponds to a DIT root dn.
For mail sent to recipients in either domain name space (
example.net), the same root dn (of
dc=example,dc=org) will need to be
searched in order to determine whether the intended recipient is in fact a valid
recipient, and what mailbox to use for delivery.
Users, distribution groups, resources and shared folders may be configured using
either of the domain name spaces as the resident domain for their primary
recipient address, for example
For additional information on LDAP, and your Kolab deployment, please see:
Integration with 389 Directory Server
389 Directory Server is by far the preferred Kolab Groupware LDAP server, not in
the least because it supports;
Multi-master replication with up to 4 masters ,
Effective Rights controls support ,
Persistent Search controls support,
Dynamic configuration of databases, indexes, replicas and replication
Dynamic configuration and execution of tasks, such as consumer initialization
Further scaling could be achieved by putting read-only replicas in front of the
LDAP write masters. Services such as kolab-saslauthd could make
use of these LDAP read-only replicas, as well as MTA and MUA applications.
389 Directory Server and Multi-Domain
389 Directory Server supports the real-time addition and configuration of new
root dn databases.
Mapping a Domain Name Space to a Directory Tree Root DN
A domain name space, which can be a parent or alias domain name space,
corresponds with a directory tree that contains the users, groups, resources,
roles and shared folders for that domain.
A directory information tree’s root dn can be established almost entirely
arbitrarily, and as such a domain name space of
example.org may actually
(need to) correspond to a root dn of
Kolab Groupware therefore uses the LDAP object classes
inetDomain. With these object classes, the following attributes are
associatedDomain, used as the container for domain name spaces,
inetDomainBaseDn, used as the container for the associated directory
information tree root dn.
Applications must therefore query the configured domain_base_dn for
objects (filtered by value of the configured domain_name_attribute) and
look for the configured domain_result_attribute on objects found.
Should the result attribute not be included with the LDAP object, as is the case
for a default Kolab Groupware installation, then the standard root dn can be
Since alias domain name spaces may be specified to a parent domain name space,
applications must make sure that the first value of the
domain_name_attribute attribute is used to establish the parent domain
Using the parent domain name space, as follows:
Explode the parent domain name space into its components as they are
divided by dot (.) characters.
For a parent domain name space of
example.org, this should give you
a list with a component
example, and a component
Implode the components using
,dc= as the delimiter.
For an exploded domain name space of
example.org, this should turn
the list resulting from the previous step ([
Prepend the string
Virtual List View (VLV)
Virtual List View control is an LDAP feature that allows a user to query the
database virtually unprohibited by size, administrative or lookthrough
In 389 Directory Server, the configuration for VLV is stored as part of the
LDBM database configuration in
This makes the configuration for VLV available to discovery.
The use of Virtual List View controls requires the use of Server-side
Server-side Sorting (SSS)
Server-side Sorting control is an LDAP feature that allows a user to have
the server sort the results of a query.
Default Attribute Use
Kolab object types are generally based off existing LDAP object classes
and LDAP attributes.
A Default Kolab User
A Kolab user is an LDAP entry with the following object classes:
and commonly at least the following attributes:
Additional attributes include:
kolabInvitationPolicy (from Kolab LDAP schema extensions)
kolabDelegate (from Kolab LDAP schema extensions)
kolabAllowSMTPSender (from Kolab LDAP schema extensions)
kolabAllowSMTPRecipient (from Kolab LDAP schema extensions)
cn: John Doe
displayName: Doe, John
A Static Kolab Distribution Group
A static distribution group is a group with one or more recipient
addresses, for which inbound message traffic is distributed among the
individual members of the group.
Members need to be added to and removed from the distribution group
individually, contrary to a
A Dynamic Kolab Distribution Group.
Object classes for a static distribution group:
Optional additional attributes:
# static, Groups, example.org
A Dynamic Kolab Distribution Group
A dynamic distribution group is a group with one or more recipient
addresses, that resolves to a set of individual members dynamically,
through executing another search in LDAP.
This means, for example, a dynamic group does not need to be updated to
include “everyone in department $x”, if the fact somebody is in
department $x can be determined using an LDAP attribute value or OU
Object classes for a dynamic distribution group:
Optional additional attributes:
# dynamic, Groups, example.org
A Kolab Resource
dn: cn=Mercedes SLK,ou=Resources,dc=example,dc=org
cn: Mercedes SLK
kolabTargetFolder: shared/Resources/Mercedes SLK@example.org
Primary Email Address (
The primary email address may be subject to a recipient policy,
which applies common rules to existing user information, to compose
the primary email address.
This recipient policy can be executed in one of three ways, see
Secondary Email Address(es) (
External Email Address(es) (
Integration with OpenLDAP