OpenLDAP TechTip:
Introduction to OpenLDAP Overlays

Matthew Backes, Symas Corporation, October 15th 2004

Abstract

Modern enterprise directory servers must provide reliable, rapid access to increasingly complex data. OpenLDAP's overlay technology provides an easy-to-deploy yet powerful tool for customizing directory behavior for your organization. The core directory server infrastructure remains uniform and standards-compliant across installations, which results in more reliable software and strongly promotes standards compliance and interoperability. Development of new features can move at the speed needed by modern enterprise customers because the overlay API provides a clean, stable interface to directory server internal functionality.

The Modular Approach

The hierarchical database model implemented by directory servers lends itself to division of resources by delegating responsiblity. This led to the early appearance of replaceable database back-ends. Each of the modern database types offer different functionality:

back-bdb and back-hdb - Reliable, fast, hierarchical, journaled data storage
back-ldap - Simple LDAP proxying
back-meta - Complex proxying and remapping of directory content
back-monitor - Statistical reports of directory performance
back-shell, back-perl - Rapid prototyping for more complex meta-directory services

When combined by using subordinate database clauses within one directory or directory referrals across multiple directories, these back-ends provide the basic tools for assembling complex organizational directory layouts.

A typical organization's directory server infrastructure would use back-hdb for storage of local directory data and back-ldap to provide local LDAP clients a unified view of the organization-wide directory information tree. (DIT)

Overlays

Overlays continue this approach of using convenient interlocking pieces to assemble a larger system by layering features on top of the functionality within existing back-ends:

slapo-ppolicy - Password policy enforcement allows easy implementation of organization-specific security requirements using the IETF Password Policy proposal. This includes password expiration, automatic lock-out for excessive failures, length requirements, and automated hashing of passwords.
slapo-refint - Referential integrity ensures object references remain valid after rename (modrdn) and delete operations.
slapo-unique - Attribute-value uniqueness provides a reliable method for ensuring that identity-values such as mail addresses and employee numbers remain unique within a database.
slapo-dyngroup - Dynamic groups are already supported within the standard OpenLDAP access-control model, but this overlay extends the compare operation so that LDAP clients can easily detect dynamic group membership.
slapo-constraint - Constraint checking of attribute-values provides a convenient method for enforcing local policy for directory content when the existing standard schema syntax rules are too lenient. Both character sets and full regular expressions are supported.
slapo-pcache - Proxy Caching improves remote directory performance through back-ldap or back-meta by implementing a configurable caching mechanism.
slapo-translucent - Translucency allows for local customization of read-only databases, similar to a BSD UNIX style union mount of file-systems. The remote database provides most of the content while the local database fills in added details created by local modification attempts. This has uses including local policy changes, securely contained integration with untrusted applications, and resource-friendly test and development directories.
smbk5pwd - Provides automated Samba 3 and Kerberos 5 password hash generation. This ensures that this application-specific authentication data remains in-sync and present on the correct attributes.

The Power of Stacking

The overlays improve the capabilities of the existing database back-ends by providing easy methods for local policy control. Just as they layer functionaly over databases, they can stack on top of each other. This is the typical method for applying all necessary customizations for an organization's directory server.

There are several common examples which demonstrate how overlays fit together:

An enterprise directory server providing the authentication store CIFS shares (Samba) and a KDC (Kerberos); back-hdb provides the reliable database while slapo-ppolicy and smbk5pwd ensure secure password polices and keep the application password hashes current without the need for external password change or synchronization software.
A branch office or satellite campus directory server can use slapo-pcache to create a high-performance replica of the master directory without changing overall organizational replication policies or wasting resources on unused branches of the directory. This can be done without sacrificing the data content protection provided by password policy rules, referential integrity, attribute-value uniqueness, and attibute-value constraints.
A departmental directory server can use slapo-translucent to override arbitrary pieces of the organization's directory without standing up an independent directory and falling behind organization-wide changes.
A departmental directory server can use slapo-ppolicy to implement more secure password policies than the parent organization, which is useful in large organizations with independent departments with varying security needs.

An Example

###### A simple slapd.conf

### schemas

include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema

# slapo-ppolicy has extra schema requirements
include /usr/local/etc/openldap/schema/ppolicy.schema

pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args

### set up dynamic modules

modulepath /usr/local/lib/openldap

# load several database backends
moduleload back_monitor.la
moduleload back_hdb.la
moduleload back_ldap.la

# load several overlays
moduleload ppolicy.la
moduleload refint.la
moduleload unique.la

### minimalist acls

# root DSE
access to dn="" by * read

# monitor backend for statistical reporting
access to dn="cn=Monitor" by * read

# other backends
access to attrs=userPassword
    by self write
    by * auth
access to *
    by * read

### backend configuration

database monitor

database hdb
# do not forget to edit DB_CONFIG
cachesize 10000
suffix "dc=symas,dc=com"

# should be removed later, ideally
rootdn "cm=Manager,dc=symas,dc=com"
rootpw Secret

# indexing
index default eq

# basic use
index objectClass,uid,dc,o,ou

# references
index member,owner,seeAlso

# mail
index mail

# names
index cn,sn,givenName,displayName eq,sub

### overlays for that last hdb...

# password policy
overlay ppolicy
ppolicy_default "cn=default,ou=Policies,dc=symas,dc=com"

# referential integrity
overlay refint
refint_attributes member,owner,seeAlso

# uniqueness
overlay unique
unique_base "ou=People,dc=symas,dc=com"
unique_attributes uid,employeeNumber

### end