User:Kanarip/Draft:Kolab LDAP Schema Extensions

From Kolab Wiki

Jump to: navigation, search


This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

KEP : Kolab LDAP Schema Extensions

Status DRAFT
Type informational
Author Jeroen van Meeuwen
Revision ID 11540
Created 2011-04-15
Last Modified 2011-6-29
Latest Working Copy KEP-0000.txt
Tracker Ticket N/A


The Kolab Groupware solution is heavily based around LDAP functionality, and more specifically OpenLDAP. While OpenLDAP ships, alongside the software, a limited number of LDAP schemas, additional functionality has been provided through LDAP schema extensions specific to Kolab.

However, these LDAP Schema extensions duplicate large amounts of objectClass and attributeType functionality already provided by LDAP server software NOT OpenLDAP, including but not limited to;

  • Novell eDirectory
  • Red Hat Directory Server
  • Netscape Directory Server
  • Sun Directory Server
  • 389 Directory Server

and possibly including, to a lesser extent;

  • IBM Lotus Domino Directory Server
  • Microsoft Active Directory
  • Open Directory Server

Since LDAP directories are built to last, and loading additional schemas creating duplicate functionality for multiple objects is often not considered the most sustainable way to deploy a new environment such as a Kolab Groupware environment, it makes sense to redefine the LDAP Schema extensions Kolab Groupware requires.

Release Format(s)

The implementation and acceptance of this KEP will cause the Kolab LDAP schema extensions to be released in the following formats:

  • LDIF Compatible,
  • RFC 2252: Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions [1]

Kolab Objects

Kolab objects referred to in this document are defined in KEP #7: Definitions of Kolab Objects.

Registered OID Prefix

The registered OID prefix is

Naming Convention

The naming convention is to prefix all objectClasses and attributeTypes with 'kolab'.

Exceptions to this rule may apply, such as the alias attribute defined in the OpenLDAP schema extensions.

Kolab User Accounts

Distinguishing types of account objects in LDAP is a prerequisite to successful Kolab deployment. In the simplest case, no account that is in a certain tree branch is not also a Kolab User. To illustrate, the following example;

   `- ou=Groups
   `- ou=Accounts
      `- ou=Users
         `- uid=jdoe
      `- ou=Services
         `- uid=apache

Given the following conditions, no additional schema extensions would be required;

  1. No external user accounts exist in the LDAP tree,
  2. All user accounts reside under ou=Users,ou=Accounts,dc=example,dc=org (or, in other words, all users reside under a specific organizational unit, and no objects other then users reside under that organizational unit),
  3. All user accounts are also Kolab users.

However, some Kolab Groupware functionality is implemented using LDAP Schema extensions, that we are not willing to lose.

As such, we require schema extensions that allow these attributes to be defined for Kolab users.

For large deployments, with all possible account types and possibly a few more, imagine the following illustrative example directory tree exists;

   `- ou=Groups
   `- ou=Accounts
      `- ou=Users
         `- uid=jdoe           # Kolab user
         `- uid=jsixpack       # Microsoft Exchange user
         `- uid=mimum          # Not a groupware user
      `- ou=Services
         `- uid=apache

The Kolab user requires a set of objectClasses, attributeTypes and/or attribute values -anything that can build a unique triplet of base dn, search scope and search filter- that can clearly distinguish this user from other users for the purposes of authentication and authorization, as well as to allow the Kolab Daemon to pick up only the true positives.

Without any schema extensions applied to the user object, the attribute that describes the mail server could be used, but this doesn't scale very well (the search for all Kolab users would need to include a filter for all mail servers).

It therefore makes sense to extend the LDAP Schema, though the extension only requires providing minimal additional functionality. This objectClass could be;

objectClasses: (
  NAME 'kolabInetOrgPerson'
  DESC 'Kolab Internet Organizational Person'

This also allows us to add some attributes providing additional Kolab Groupware features:


Delegation of one's Kolab account means to say, that user A allows user B to 'send on behalf of'. A popular form of delegation is also to not give out access to the INBOX of user A, but instead copy user B on messages of a particular type (such as invitations and confirmations).

The following configuration needs to be stored in LDAP, because the original user, the target user and the Kolab Groupware system services need to be aware of the configuration:

The user whom is the delegate
The policy to use in delegating



Invitation Handling Policies


Delegate Policy
This may be mutually exclusive with Delegate Policies or may need to preceed Delegate Policies

Sender Access Policy


Allow the senders listed / matched to send to this recipient.

Recipient Access Policy


Allow the sender to send to the recipient listed / matched.

Take into account SASL username vs. envelope sender, the authorization thereof, and the targetted recipient policy


  1. RFC 2252: Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions


This document is placed in the public domain.

Personal tools