OpenLDAP TechTip: Introduction to OpenLDAP Overlays

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

Overlays are a powerful customization tool that allow organizations and smaller units to fine-tune the directory behavior for their specific needs. Keeping this power encapsulated within overlays ensures that OpenLDAP remains both strictly adherent to the Internet standards and very useful for implementing ad-hoc local policies.

Home About Pricing Updates Downloads Key Relationships Contact

Copyright © 2001 - 2012, Symas Corporation.All rights reserved. The content on this page has been approved by Jordan H. Heyman, the Dog in "seven guys and a dog." No rabbits were harmed in the production of this Web site.