Showing posts with label LDAP. Show all posts
Showing posts with label LDAP. Show all posts

Sunday, January 2, 2011

LDAP authentication for Samba

As part of my OpenLDAP under Ubuntu Linux project, this post documents configuring Samba to use LDAP - as a storage back-end, as well as for authentication and authorization. (Samba is a free software re-implemenation of the SMB networking protocol, and is useful for providing network file shares that are recognized by Microsoft Windows.) As with my previous posts, this post was written against Ubuntu Linux's latest release, 10.10 ("Maverick Meerkat").

This post is focused on integrating SMBD (Samba's SMB/CIFS server) with LDAP, not with Samba or SMB itself. A few resources for Samba include:

Additionally, there are already a few references specific to combining Samba and LDAP, which proved useful when I first started working on this:

  • "Samba & LDAP" (wiki.samba.org)
  • The Linux Samba-OpenLDAP Howto (Jérôme Tournier & Olivier Lemaire, 2007-07-12, gna.org)
    • This is titled as revision 1.10. I also found references to a revision 1.21, but it actually appears older. There is no "print date", but I've only found it as a PDF on mirrors with a created metadata date of 2006-06-26.

As documented by Samba, Samba supports a few different account / password backends - including Ubuntu's default tdbsam (a "trivial database"), and for the purposes of this post, ldapsam.

First, we need to extend the LDAP schema to include Samba's object classes and their dependencies. Following my notes in OpenLDAP under Ubuntu Linux, the LDAP configuration, by default, including the schema, is stored in LDAP itself (a.k.a. "cn=config"). Unfortunately, documentation and examples using cn=config are still quite rare. This is complicated by the fact that schema additions or changes, just as with data, are now handled through LDIF files. Previously, schema files were available in ".schema" files, which used a custom format. When using cn=config, LDIF files need to be used. At least in Ubuntu, OpenLDAP comes with both versions (.schema and .ldif) for many of the "core" schemas, including "core", "cosine", "inetorgperson", "misc", "nis", and "openldap". However, this list doesn't include the "samba" schema, or other schemas that may be necessary in the future - so they need to be converted.

As discussed in Debian bug # 190162, finding even the samba.schema source file is a bit difficult. The easiest (but somewhat inefficient) way is to install the samba-doc package, then uncompress "/usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz". (Copy the file to a workspace directory, then run "gunzip samba.schema.gz".)

The best process I found for converting individual schema files to LDIF format is as follows (similar to the steps documented in OpenLDAP Server in the Ubuntu Server Guide):

  1. In a new "workspace" directory, create a "schemaConvert.conf" file. Add "include" lines for each schema to be converted, including any dependencies:
    include /etc/ldap/schema/core.schema
    include /etc/ldap/schema/cosine.schema
    include /etc/ldap/schema/nis.schema
    include /etc/ldap/schema/inetorgperson.schema
    
    include samba.schema
    
  2. Use slaptest (part of OpenLDAP), which includes functionality to convert to "config directory" (cn=config) format:
    $ mkdir config && slaptest -f schemaConvert.conf -F config
    configuration file testing succeeded
    
  3. Find the generated .ldif files in 'config/cn=config/cn=schema'.
  4. Copy the necessary file(s) to the root of the workspace directory for convenience and reference:
    cp diff 'config/cn=config/cn=schema/cn={4}samba.ldif' samba.ldif samba.ldif
    
  5. For each needed file, some edits are necessary:
    1. On the 1st line (beginning with "dn:"), remove the index surrounded by curly braces, and append ",cn=schema,cn=config" to the end of the line.
    2. On the 3rd line (beginning with "cn: "), remove the index surrounded by curly braces.
    3. At the end of the file, remove the line beginning with "structrualObjectClass", and any following lines - there should be 7 total.
    Here is a diff showing the necessary edits:
    $ diff 'config/cn=config/cn=schema/cn={4}samba.ldif' samba.ldif
    1c1
    < dn: cn={4}samba
    ---
    > dn: cn=samba,cn=schema,cn=config
    3c3
    < cn: {4}samba
    ---
    > cn: samba
    186,192d185
    < structuralObjectClass: olcSchemaConfig
    < entryUUID: a0d0349c-a737-102f-97c0-cf017cbccf86
    < creatorsName: cn=config
    < createTimestamp: 20101229013514Z
    < entryCSN: 20101229013514.341084Z#000000#000#000000
    < modifiersName: cn=config
    < modifyTimestamp: 20101229013514Z
    

Add the converted and modified samba.ldif using ldapadd, or your favorite LDAP editor e.g. phpLDAPadmin. (This assumes that the "core", "cosine", "inetorgperson", and "nis" schemas were already included in the default OpenLDAP configuration.)

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f samba.ldif

Add some appropriate security controls. This is what my "olcAccess" looked like on my "olcDatabase={1}hdb,cn=config" after the initial setup of OpenLDAP:

{0}to dn.subtree="ou=people,dc=example,dc=com" attrs=userPassword,shadowLastChange by group.exact="cn=ldap.admins,ou=groups,dc=example,dc=com" write by anonymous auth by self write by * none
{1}to attrs=userPassword,shadowLastChange by group.exact="cn=ldap.admins,ou=groups,dc=example,dc=com" write by anonymous auth by * none
{2}to * by group.exact="cn=ldap.admins,ou=groups,dc=example,dc=com" write by users read

I recommend making the following additions and updates, partially inspired by my previous password permissions configuration example:

{0}to * by group.exact="cn=ldap.admins,ou=groups,dc=example,dc=com" write by * break
{1}to dn.one="dc=example,dc=com" filter=(objectClass=sambaDomain) by group.exact="cn=samba.admins,ou=groups,dc=example,dc=com" write by * break
{2}to attrs=@sambaSamAccount,userPassword by group.exact="cn=samba.admins,ou=groups,dc=example,dc=com" write by * break
{3}to dn.subtree="ou=people,dc=example,dc=com" attrs=userPassword by self write by * break
{4}to attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange by self read by anonymous auth by * none
{5}to * by users read

The "ldap.admins" and "samba.admins" groups need to be created using the "groupOfNames" objectClass. Add a "samba.proxy" user (use the "applicationProcess" and "simpleSecurityObject" objectClasses), and make it a member of the "samba.admins" group, as well as "ldap.admins" temporarily. (Unfortunately, the above {1} access rule only allows for modification of the sambaDomain, not its creation. For only a one-time use, I haven't yet found a proper access rule that allows for its restricted creation.)

Modify "/etc/samba/smb.conf" to use the "ldapsam" backend. Find the existing "passdb backend = tdbsam", comment it out, then add the following lines:

passdb backend = ldapsam:ldap:///
ldap ssl = Off
ldap suffix = dc=example,dc=com
ldap admin dn = cn=samba.proxy,ou=serviceAccounts,dc=example,dc=com
ldap passwd sync = only
#ldap debug level = 1

For any serious usage, or any usage with real user accounts, "ldap ssl" needs to be properly configured to protect user credentials between the SMBD and LDAP servers.

The above "ldap passwd sync = only", per the ldapsam documentation, means:

Only update the LDAP password and let the LDAP server worry about the other fields. This option is only available on some LDAP servers and only when the LDAP server supports LDAP_EXOP_X_MODIFY_PASSWD.

OpenLDAP supports this, but the SambaNTPasword and SambaLMPassword fields will only be updated with an OpenLDAP overlay such as smbk5pwd. Unfortunately, this overlay is not currently installed with Ubuntu's distribution - see Ubuntu bug # 82853 for details. A few additional notes if building this overlay from source yourself:

  1. By default, this overlay is configured to support both Kerberos and Samba, both at compile-time and run-time. The dependencies for Kerberos are complex and numerous, at least under Ubuntu. If you don't have a need for Kerberos, I'd recommend compiling without Kerberos support. This can be done by running make with a DEFS argument of only "-DDO_SAMBA" from the smbk5pwd source directory. Unfortunately, this currently does not exclude the Kerberos includes or libraries dependencies from the make file. To remedy this, I also set "HEIMDAL_INC" and "HEIMDAL_LIB" to empty strings.
    • If dependencies are met at compile-time, and not at run-time - even if not enabled, slapd will fail to load with "lt_dlopenext failed: (smbk5pwd) file not found" visible in "/var/log/syslog". This is a bit misleading as it isn't "/usr/lib/ldap/smbk5pwd.so" that is missing, but one of its dynamically linked libraries, as viewable with ldd.
  2. While unrelated to Samba, part of the shadowAccount" objectClass is a "shadowLastChange" attribute. While it is apparently seldom or no longer used, if it exists, and if smbk5pwd needs to be compiled anyway, I thought it would be beneficial to have smbk5pwd also reset this attribute along with any password changes. I submitted this request to OpenLDAP, along with a completed patch, a ITS 6550. While this seemed to receive some support from Michael Michael Ströder (one of the developers), it was abruptly closed by Howard Chu. In case anyone else is looking for a similar solution, and in case the patch becomes unavailable from the OpenLDAP tracker for some reason, it is included below:
    Index: contrib/slapd-modules/smbk5pwd/Makefile
    ===================================================================
    RCS file: /repo/OpenLDAP/pkg/ldap/contrib/slapd-modules/smbk5pwd/Makefile,v
    retrieving revision 1.7
    diff -u -r1.7 Makefile
    --- contrib/slapd-modules/smbk5pwd/Makefile 13 Apr 2010 20:17:37 -0000 1.7
    +++ contrib/slapd-modules/smbk5pwd/Makefile 14 May 2010 00:50:46 -0000
    @@ -16,8 +16,8 @@
     OPT=-g -O2
     CC=gcc
     
    -# Omit DO_KRB5 or DO_SAMBA if you don't want to support it.
    -DEFS=-DDO_KRB5 -DDO_SAMBA
    +# Omit DO_KRB5, DO_SAMBA, or DO_SHADOW if you don't want to support it.
    +DEFS=-DDO_KRB5 -DDO_SAMBA -DDO_SHADOW
     
     HEIMDAL_INC=-I/usr/heimdal/include
     SSL_INC=
    Index: contrib/slapd-modules/smbk5pwd/README
    ===================================================================
    RCS file: /repo/OpenLDAP/pkg/ldap/contrib/slapd-modules/smbk5pwd/README,v
    retrieving revision 1.6
    diff -u -r1.6 README
    --- contrib/slapd-modules/smbk5pwd/README 13 Apr 2010 20:17:37 -0000 1.6
    +++ contrib/slapd-modules/smbk5pwd/README 14 May 2010 00:50:46 -0000
    @@ -1,6 +1,6 @@
     This directory contains a slapd overlay, smbk5pwd, that extends the
    -PasswordModify Extended Operation to update Kerberos keys and Samba
    -password hashes for an LDAP user.
    +PasswordModify Extended Operation to update Kerberos keys, Samba
    +password hashes, and the shadowLastChange attribute for an LDAP user.
     
     The Kerberos support is written for Heimdal using its hdb-ldap backend.
     If a PasswordModify is performed on an entry that has the krb5KDCEntry
    @@ -17,6 +17,10 @@
     objectclass, then the sambaLMPassword, sambaNTPassword, and sambaPwdLastSet
     attributes will be updated accordingly.
     
    +The Shadow support updates the shadowLastChange attribute to the current
    +date if a PasswordModify is performed on an entry that has the
    +shadowAccount objectclass.
    +
     To use the overlay, add:
     
      include <path to>/krb5-kdc.schema
    @@ -40,8 +44,8 @@
      smbk5pwd-enable  <module>
     
     can be used to enable only the desired one(s); legal values for <module>
    -are "krb5" and "samba", if they are respectively enabled by defining
    -DO_KRB5 and DO_SAMBA.
    +are "krb5", "samba", and "shadow", if they are respectively enabled by defining
    +DO_KRB5, DO_SAMBA, and DO_SHADOW.
     
     The samba module also supports the
     
    @@ -60,15 +64,16 @@
      olcOverlay: {0}smbk5pwd
      olcSmbK5PwdEnable: krb5
      olcSmbK5PwdEnable: samba
    + olcSmbK5PwdEnable: shadow
      olcSmbK5PwdMustChange: 2592000
     
    -which enables both krb5 and samba modules with a password expiry time
    -of 30 days.
    +which enables all the krb5, samba, and shadow modules with a password
    +expiry time of 30 days.
     
    -The provided Makefile builds both Kerberos and Samba support by default.
    -You must edit the Makefile to insure that the correct include and library
    -paths are used. You can change the DEFS macro if you only want one or the
    -other of Kerberos or Samba support.
    +The provided Makefile builds all of Kerberos, Samba, and Shadow support by
    +default. You must edit the Makefile to insure that the correct include and
    +library paths are used. You can change the DEFS macro if you only want partial
    +support.
     
     This overlay is only set up to be built as a dynamically loaded module.
     On most platforms, in order for the module to be usable, all of the 
    Index: contrib/slapd-modules/smbk5pwd/smbk5pwd.c
    ===================================================================
    RCS file: /repo/OpenLDAP/pkg/ldap/contrib/slapd-modules/smbk5pwd/smbk5pwd.c,v
    retrieving revision 1.34
    diff -u -r1.34 smbk5pwd.c
    --- contrib/slapd-modules/smbk5pwd/smbk5pwd.c 13 Apr 2010 20:17:37 -0000 1.34
    +++ contrib/slapd-modules/smbk5pwd/smbk5pwd.c 14 May 2010 00:50:47 -0000
    @@ -17,6 +17,7 @@
     /* ACKNOWLEDGEMENTS:
      * Support for table-driven configuration added by Pierangelo Masarati.
      * Support for sambaPwdMustChange and sambaPwdCanChange added by Marco D'Ettorre.
    + * Support for shadowLastChange added by Mark A. Ziesemer <www.ziesemer.com>.
      */
     
     #include <portable.h>
    @@ -81,14 +82,21 @@
     static ObjectClass *oc_sambaSamAccount;
     #endif
     
    +#ifdef DO_SAMBA
    +static AttributeDescription *ad_shadowLastChange;
    +static ObjectClass *oc_shadowAccount;
    +#endif
    +
     /* Per-instance configuration information */
     typedef struct smbk5pwd_t {
      unsigned mode;
     #define SMBK5PWD_F_KRB5  (0x1U)
     #define SMBK5PWD_F_SAMBA (0x2U)
    +#define SMBK5PWD_F_SHADOW (0x4U)
     
     #define SMBK5PWD_DO_KRB5(pi) ((pi)->mode & SMBK5PWD_F_KRB5)
     #define SMBK5PWD_DO_SAMBA(pi) ((pi)->mode & SMBK5PWD_F_SAMBA)
    +#define SMBK5PWD_DO_SHADOW(pi) ((pi)->mode & SMBK5PWD_F_SHADOW)
     
     #ifdef DO_KRB5
      /* nothing yet */
    @@ -100,6 +108,10 @@
      /* How many seconds after allowing a password change? */
      time_t  smb_can_change;
     #endif
    +
    +#ifdef DO_SHADOW
    + /* nothing yet */
    +#endif
     } smbk5pwd_t;
     
     static const unsigned SMBK5PWD_F_ALL =
    @@ -110,6 +122,9 @@
     #ifdef DO_SAMBA
      | SMBK5PWD_F_SAMBA
     #endif
    +#ifdef DO_SHADOW
    + | SMBK5PWD_F_SHADOW
    +#endif
     ;
     
     static int smbk5pwd_modules_init( smbk5pwd_t *pi );
    @@ -653,6 +668,34 @@
       }
      }
     #endif /* DO_SAMBA */
    +
    +#ifdef DO_SHADOW
    + /* Shadow stuff */
    + if ( SMBK5PWD_DO_SHADOW( pi ) && is_entry_objectclass(e, oc_shadowAccount, 0 ) ) {
    +  struct berval *keys;
    +  
    +  ml = ch_malloc(sizeof(Modifications));
    +  ml->sml_next = qpw->rs_mods;
    +  qpw->rs_mods = ml;
    +
    +  keys = ch_malloc( 2 * sizeof(struct berval) );
    +  keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) );
    +  keys[0].bv_len = snprintf(keys[0].bv_val,
    +   LDAP_PVT_INTTYPE_CHARS(long),
    +   "%ld", slap_get_time() / 60 / 60 / 24 );
    +  BER_BVZERO( &keys[1] );
    +  
    +  ml->sml_desc = ad_shadowLastChange;
    +  ml->sml_op = LDAP_MOD_REPLACE;
    +#ifdef SLAP_MOD_INTERNAL
    +  ml->sml_flags = SLAP_MOD_INTERNAL;
    +#endif
    +  ml->sml_numvals = 1;
    +  ml->sml_values = keys;
    +  ml->sml_nvalues = NULL;
    + }
    +#endif /* DO_SHADOW */
    +
      be_entry_release_r( op, e );
      qpw->rs_new.bv_val[qpw->rs_new.bv_len] = term;
     
    @@ -715,6 +758,7 @@
     static slap_verbmasks smbk5pwd_modules[] = {
      { BER_BVC( "krb5" ),  SMBK5PWD_F_KRB5 },
      { BER_BVC( "samba" ),  SMBK5PWD_F_SAMBA },
    + { BER_BVC( "shadow" ),  SMBK5PWD_F_SHADOW },
      { BER_BVNULL,   -1 }
     };
     
    @@ -860,6 +904,16 @@
       }
     #endif /* ! DO_SAMBA */
     
    +#ifndef DO_SHADOW
    +  if ( SMBK5PWD_DO_SHADOW( pi ) ) {
    +   Debug( LDAP_DEBUG_ANY, "%s: smbk5pwd: "
    +    "<%s> module \"%s\" only allowed when compiled with -DDO_SHADOW.\n",
    +    c->log, c->argv[ 0 ], c->argv[ rc ] );
    +   pi->mode = mode;
    +   return 1;
    +  }
    +#endif /* ! DO_SHADOW */
    +
       {
        BackendDB db = *c->be;
     
    @@ -882,66 +936,78 @@
      return rc;
     }
     
    +typedef struct smbk5pwd_verify_schema_t {
    + const char  *name;
    + AttributeDescription **adp;
    +} smbk5pwd_verify_schema_t;
    +
     static int
    -smbk5pwd_modules_init( smbk5pwd_t *pi )
    +smbk5pwd_modules_verify_schema(const char *ocName, ObjectClass **oc, smbk5pwd_verify_schema_t *ad)
     {
    - static struct {
    -  const char  *name;
    -  AttributeDescription **adp;
    + int i, rc;
    + 
    + *oc = oc_find( ocName );
    + if ( !*oc ) {
    +  Debug( LDAP_DEBUG_ANY, "smbk5pwd: "
    +   "unable to find \"%s\" objectClass.\n",
    +   ocName, 0, 0 );
    +  return -1;
      }
    + 
    + for ( i = 0; ad[ i ].name != NULL; i++ ) {
    +  const char *text;
    +
    +  *(ad[ i ].adp) = NULL;
    +
    +  rc = slap_str2ad( ad[ i ].name, ad[ i ].adp, &text );
    +  if ( rc != LDAP_SUCCESS ) {
    +   Debug( LDAP_DEBUG_ANY, "smbk5pwd: "
    +    "unable to find \"%s\" attributeType: %s (%d).\n",
    +    ad[ i ].name, text, rc );
    +   *oc = NULL;
    +   return rc;
    +  }
    + }
    +}
    +
    +static int
    +smbk5pwd_modules_init( smbk5pwd_t *pi )
    +{
    +
     #ifdef DO_KRB5
    - krb5_ad[] = {
    + smbk5pwd_verify_schema_t krb5_ad[] = {
       { "krb5Key",   &ad_krb5Key },
       { "krb5KeyVersionNumber", &ad_krb5KeyVersionNumber },
       { "krb5PrincipalName",  &ad_krb5PrincipalName },
       { "krb5ValidEnd",  &ad_krb5ValidEnd },
       { NULL }
    - },
    + };
     #endif /* DO_KRB5 */
     #ifdef DO_SAMBA
    - samba_ad[] = {
    + smbk5pwd_verify_schema_t samba_ad[] = {
       { "sambaLMPassword",  &ad_sambaLMPassword },
       { "sambaNTPassword",  &ad_sambaNTPassword },
       { "sambaPwdLastSet",  &ad_sambaPwdLastSet },
       { "sambaPwdMustChange",  &ad_sambaPwdMustChange },
       { "sambaPwdCanChange",  &ad_sambaPwdCanChange },
       { NULL }
    - },
    + };
     #endif /* DO_SAMBA */
    - dummy_ad;
    -
    - /* this is to silence the unused var warning */
    - dummy_ad.name = NULL;
    +#ifdef DO_SHADOW
    + smbk5pwd_verify_schema_t shadow_ad[] = {
    +  { "shadowLastChange",  &ad_shadowLastChange },
    +  { NULL }
    + };
    +#endif /* DO_SHADOW */
     
     #ifdef DO_KRB5
      if ( SMBK5PWD_DO_KRB5( pi ) && oc_krb5KDCEntry == NULL ) {
       krb5_error_code ret;
       extern HDB  *_kadm5_s_get_db(void *);
     
    -  int  i, rc;
    -
    -  /* Make sure all of our necessary schema items are loaded */
    -  oc_krb5KDCEntry = oc_find( "krb5KDCEntry" );
    -  if ( !oc_krb5KDCEntry ) {
    -   Debug( LDAP_DEBUG_ANY, "smbk5pwd: "
    -    "unable to find \"krb5KDCEntry\" objectClass.\n",
    -    0, 0, 0 );
    -   return -1;
    -  }
    -
    -  for ( i = 0; krb5_ad[ i ].name != NULL; i++ ) {
    -   const char *text;
    -
    -   *(krb5_ad[ i ].adp) = NULL;
    -
    -   rc = slap_str2ad( krb5_ad[ i ].name, krb5_ad[ i ].adp, &text );
    -   if ( rc != LDAP_SUCCESS ) {
    -    Debug( LDAP_DEBUG_ANY, "smbk5pwd: "
    -     "unable to find \"%s\" attributeType: %s (%d).\n",
    -     krb5_ad[ i ].name, text, rc );
    -    oc_krb5KDCEntry = NULL;
    -    return rc;
    -   }
    +  int rc = smbk5pwd_modules_verify_schema("krb5KDCEntry", &oc_krb5KDCEntry, krb5_ad);
    +  if ( rc != LDAP_SUCCES ) {
    +   return rc;
       }
     
       /* Initialize Kerberos context */
    @@ -980,32 +1046,21 @@
     
     #ifdef DO_SAMBA
      if ( SMBK5PWD_DO_SAMBA( pi ) && oc_sambaSamAccount == NULL ) {
    -  int  i, rc;
    -
    -  oc_sambaSamAccount = oc_find( "sambaSamAccount" );
    -  if ( !oc_sambaSamAccount ) {
    -   Debug( LDAP_DEBUG_ANY, "smbk5pwd: "
    -    "unable to find \"sambaSamAccount\" objectClass.\n",
    -    0, 0, 0 );
    -   return -1;
    +  int rc = smbk5pwd_modules_verify_schema("sambaSamAccount", &oc_sambaSamAccount, samba_ad);
    +  if ( rc != LDAP_SUCCESS ) {
    +   return rc;
       }
    + }
    +#endif /* DO_SAMBA */
     
    -  for ( i = 0; samba_ad[ i ].name != NULL; i++ ) {
    -   const char *text;
    -
    -   *(samba_ad[ i ].adp) = NULL;
    -
    -   rc = slap_str2ad( samba_ad[ i ].name, samba_ad[ i ].adp, &text );
    -   if ( rc != LDAP_SUCCESS ) {
    -    Debug( LDAP_DEBUG_ANY, "smbk5pwd: "
    -     "unable to find \"%s\" attributeType: %s (%d).\n",
    -     samba_ad[ i ].name, text, rc );
    -    oc_sambaSamAccount = NULL;
    -    return rc;
    -   }
    +#ifdef DO_SHADOW
    + if ( SMBK5PWD_DO_SHADOW( pi ) && oc_shadowAccount == NULL ) {
    +  int rc = smbk5pwd_modules_verify_schema("shadowAccount", &oc_shadowAccount, shadow_ad);
    +  if ( rc != LDAP_SUCCESS ) {
    +   return rc;
       }
      }
    -#endif /* DO_SAMBA */
    +#endif /* DO_SHADOW */
     
      return 0;
     }
    Index: contrib/slapd-modules/README
    ===================================================================
    RCS file: /repo/OpenLDAP/pkg/ldap/contrib/slapd-modules/README,v
    retrieving revision 1.6
    diff -u -r1.6 README
    --- contrib/slapd-modules/README 13 Apr 2010 20:17:33 -0000 1.6
    +++ contrib/slapd-modules/README 14 May 2010 00:50:46 -0000
    @@ -49,8 +49,8 @@
      Proxy Authorization compatibility with obsolete internet-draft.
     
     smbk5pwd (overlay)
    - Make the PasswordModify Extended Operation update Kerberos
    - keys and Samba password hashes as well as userPassword.
    + Make the PasswordModify Extended Operation update Kerberos keys,
    + Samba password hashes, and shadowLastChange, as well as userPassword.
     
     trace (overlay)
      Trace overlay invocation.
    
    To compile with the "shadow" patch, and without Kerberos, I used the following command:
    make DEFS="-DDO_SAMBA -DDO_SHADOW" HEIMDAL_INC="" HEIMDAL_LIB=""
    

To provide Samba with the password for the admin DN, use the smbpasswd tool:

$ sudo smbpasswd -W
Setting stored password for "cn=samba.proxy,ou=serviceAccounts,dc=example,dc=com" in secrets.tdb
New SMB password:
Retype new SMB password:

Now, enable SMB for the first user. This will also create a new "sambaDomain" child under the configured suffix:

$ sudo smbpasswd -a mark
New SMB password:
Retype new SMB password:
Added user mark.

Once complete, remove the "samba.proxy" user from the "ldap.admins" group, as the elevated permissions are no longer necessary. Users and the Samba domain can continue to be modified with the remaining permissions.

Finally, for some additional and advised security, add something along the following to "/etc/samba/samba.conf":

security = user
valid users = @samba.users

Per the Samba documentation:

"security = user" is always a good idea. This will require a Unix account in this server for every user accessing the server.

Finally, "valid users" points to a valid Unix group name. This can be anything that is resolved locally, and visible through "getent groups". This group may be declared locally to the same server running Samba, or a posixGroup declared in LDAP, as covered previously in Linux client authentication with LDAP, PAM, and NSS.

Wednesday, December 29, 2010

Linux client authentication with LDAP, PAM, and NSS

As part of my OpenLDAP under Ubuntu Linux project, this post documents configuring Linux client authentication and authorization through LDAP, using Pluggable Authentication Modules (PAM) and Name Service Switch (NSS). As with my previous posts, this post was written against Ubuntu Linux's latest release, 10.10 ("Maverick Meerkat").

As Linux uses numeric IDs for users and groups (in separate domains), I highly recommend creating a numbering strategy to keep things organized. Per existing Debian policy:

  • 9 - 99: Reserved for local system / package accounts, and should be consistent across systems. (For example, 0 is "root".)
  • 100 - 999: Typically for dynamically allocated system accounts.
  • 1,000 - 59,999: Dynamically allocated user accounts.
    • (For the first user created on an Ubuntu system, the user ID and primary group ID are probably both 1,000.)
  • 65,000 - 65,533: Reserved for global allocation by the Debian project.
  • 65,534: The "nobody" user and "nogroup" group.

Before any attempts are considered to organize the available user IDs into blocks, according to the above list, this would leave only 59,000 valid IDs for actual users. This shouldn't be a problem for many organizations, but what if a larger organization needed all of their employees on a large network in the same domain? (There are quite a few companies with over 250,000 employees.) Apparently, the 16-bit limit is only a recommendation, with a current maximum limit of 32 bits. However, 32-bit systems may treat this as signed, allowing for a safe total of 31 bits, or just over 2 billion accounts. So I'm not going to worry about this any further for now, knowing that IDs 65,536 - 2,147,483,648 should be available for future use if necessary.

For now, I'm breaking down the above 1,000+ range as follows:

  • 1,000 - 1,999: Local accounts, not in LDAP.
  • 2,000 - 2,999: Administrative groups, in LDAP.
  • 3,000 - 3,999: Service accounts (users and groups), in LDAP.
  • 4,000 - 4,999: Reserved for future use.
  • 5,000 - 59,999: Actual users.

At a minimum, this offers one significant benefit. As LDAP is a network service, the unfortunate reality is that it will go down on occasion. If all the accounts were in LDAP, there would be no way to access the systems while LDAP is unavailable. Linux can be configured to look for accounts both locally, as well as in LDAP, which will be detailed below. There should be at least one account created locally in the 1,000 - 1,999 range for emergency use independent of LDAP.

Before making any configuration changes, review what is returned by the "getent passwd" and "getent group" commands. Nothing should be visible from LDAP yet, only locally-defined users and groups.

For simplicity, I'd like to install only the NSS support (provided by libnss-ldap) to start with, then review the outputs of getent before continuing with PAM. However, libnss-ldap includes libpam-ldap (for PAM) in its dependency hierarchy, so, I guess we'll just take everything together in one batch:

sudo apt-get install libpam-ldap libnss-ldap 

During configuration of ldap-auth-config, answer the following prompts:

  • LDAP server Uniform Resource Identifier: ldapi:/// (Default)
    • This assumes that the LDAP server is running on the same machine. Any valid LDAP URL can be used here.
    • For any serious usage, or any usage with real user accounts hosted on a seperate LDAP server, this needs to be properly configured to use ldaps:// (SSL/TLS) to protect user credentials between the client and the LDAP server.
    • See below for a current issue with using ldapi:///.
  • Distinguished name of the search base: dc=example,dc=com (Default uses "dc=net")
  • LDAP version to use: 3 (Default)
  • Make local root Database admin: No (Default is Yes)
  • Does the LDAP database require login? Yes (Default is No)
  • Unprivileged database user: cn=ldap.proxy,ou=serviceAccounts,dc=example,dc=com (Default is "cn=proxyuser,dc=example,dc=net")
  • Password for database login account:
  • Local crypt to use when changing passwords: exop (Default is md5)

This added /etc/ldap.conf, which did not exist prior to this configuration. (The closest base reference I can find is /usr/share/doc/libnss-ldap/examples/ldap.conf.gz). To re-run the prompted configuration (if necessary), run "dpkg-reconfigure ldap-auth-config".

Now NSS needs to be configured. Edit /etc/nsswitch.conf to use "files ldap" for the "passwd", "group", and "shadow" databases instead of the existing "compat." This can be done automatically by running "sudo auth-client-config -t nss -p lac_ldap". Re-run the getent commands, and combined results from both the local accounts as well as LDAP should now be visible.

It appears that simply by installing one of the above packages (probably either libpam-ldap or ldap-auth-config), PAM was also already configured with default LDAP extensions. Logins can be attempted by using "su <username>". Attempting to login as a user that does not exist either locally or in LDAP should return a "Unknown id: " error message. Otherwise, a "Password: " prompt should be displayed, and using a password that matches an account configured in LDAP should successfully change to that user. (Alternatively, use "sudo login" for a more comprehensive login and test.)

To see what was configured in PAM for LDAP, here is a diff comparing "/etc/pam.d" before and after this configuration, basically showing the additions using "pam_ldap.so":

diff -ur before/common-account after/common-account
--- before/common-account       2010-12-29 17:14:02.264282406 -0600
+++ after/common-account        2010-12-29 17:14:36.554657351 -0600
@@ -14,7 +14,8 @@
 #

 # here are the per-package modules (the "Primary" block)
-account        [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so
+account        [success=2 new_authtok_reqd=done default=ignore]        pam_unix.so
+account        [success=1 default=ignore]      pam_ldap.so
 # here's the fallback if no module succeeds
 account        requisite                       pam_deny.so
 # prime the stack with a positive return value if there isn't one already;
diff -ur before/common-auth after/common-auth
--- before/common-auth  2010-12-29 17:14:02.264282406 -0600
+++ after/common-auth   2010-12-29 17:14:36.554657351 -0600
@@ -14,7 +14,8 @@
 # pam-auth-update(8) for details.

 # here are the per-package modules (the "Primary" block)
-auth   [success=1 default=ignore]      pam_unix.so nullok_secure
+auth   [success=2 default=ignore]      pam_unix.so nullok_secure
+auth   [success=1 default=ignore]      pam_ldap.so use_first_pass
 # here's the fallback if no module succeeds
 auth   requisite                       pam_deny.so
 # prime the stack with a positive return value if there isn't one already;
diff -ur before/common-password after/common-password
--- before/common-password      2010-12-29 17:14:02.264282406 -0600
+++ after/common-password       2010-12-29 17:14:36.554657351 -0600
@@ -22,7 +22,8 @@
 # pam-auth-update(8) for details.

 # here are the per-package modules (the "Primary" block)
-password       [success=1 default=ignore]      pam_unix.so obscure sha512
+password       [success=2 default=ignore]      pam_unix.so obscure sha512
+password       [success=1 user_unknown=ignore default=die]     pam_ldap.so use_authtok try_first_pass
 # here's the fallback if no module succeeds
 password       requisite                       pam_deny.so
 # prime the stack with a positive return value if there isn't one already;
diff -ur before/common-session after/common-session
--- before/common-session       2010-12-29 17:14:02.264282406 -0600
+++ after/common-session        2010-12-29 17:14:36.554657351 -0600
@@ -22,5 +22,6 @@
 session        required                        pam_permit.so
 # and here are more per-package modules (the "Additional" block)
 session        required        pam_unix.so
+session        optional                        pam_ldap.so
 session        optional                        pam_ck_connector.so nox11
 # end of pam-auth-update config
diff -ur before/common-session-noninteractive after/common-session-noninteractive
--- before/common-session-noninteractive        2010-12-29 17:14:02.264282406 -0600
+++ after/common-session-noninteractive 2010-12-29 17:14:36.554657351 -0600
@@ -22,4 +22,5 @@
 session        required                        pam_permit.so
 # and here are more per-package modules (the "Additional" block)
 session        required        pam_unix.so
+session        optional                        pam_ldap.so
 # end of pam-auth-update config

Here are some additional (manual) modifications, in addition to the above, and described below:

diff -ur after//common-account custom//common-account
--- after//common-account       2010-12-29 17:14:36.554657351 -0600
+++ custom//common-account      2010-12-29 17:17:22.626472292 -0600
@@ -14,8 +14,13 @@
 #

 # here are the per-package modules (the "Primary" block)
-account        [success=2 new_authtok_reqd=done default=ignore]        pam_unix.so
-account        [success=1 default=ignore]      pam_ldap.so
+#account       [success=2 new_authtok_reqd=done default=ignore]        pam_unix.so
+#account       [success=1 default=ignore]      pam_ldap.so
+
+account [success=1 default=ignore] pam_succeed_if.so uid < 2000 quiet
+account [success=2 user_unknown=ignore default=bad]     pam_ldap.so
+account [success=1 new_authtok_reqd=done default=ignore]  pam_unix.so
+
 # here's the fallback if no module succeeds
 account        requisite                       pam_deny.so
 # prime the stack with a positive return value if there isn't one already;
diff -ur after//common-password custom//common-password
--- after//common-password      2010-12-29 17:14:36.554657351 -0600
+++ custom//common-password     2010-12-29 17:17:22.626472292 -0600
@@ -22,8 +22,13 @@
 # pam-auth-update(8) for details.

 # here are the per-package modules (the "Primary" block)
-password       [success=2 default=ignore]      pam_unix.so obscure sha512
-password       [success=1 user_unknown=ignore default=die]     pam_ldap.so use_authtok try_first_pass
+#password      [success=2 default=ignore]      pam_unix.so obscure sha512
+#password      [success=1 user_unknown=ignore default=die]     pam_ldap.so use_authtok try_first_pass
+
+password [success=1 default=ignore] pam_succeed_if.so uid < 2000 quiet
+password [success=2 user_unknown=ignore default=die] pam_ldap.so try_first_pass
+password [success=1 default=ignore] pam_unix.so obscure sha512
+
 # here's the fallback if no module succeeds
 password       requisite                       pam_deny.so
 # prime the stack with a positive return value if there isn't one already;
diff -ur after//common-session custom//common-session
--- after//common-session       2010-12-29 17:14:36.554657351 -0600
+++ custom//common-session      2010-12-29 17:17:22.626472292 -0600
@@ -22,6 +22,7 @@
 session        required                        pam_permit.so
 # and here are more per-package modules (the "Additional" block)
 session        required        pam_unix.so
+session required       pam_mkhomedir.so
 session        optional                        pam_ldap.so
 session        optional                        pam_ck_connector.so nox11
 # end of pam-auth-update config

As mentioned above, and partially inspired by http://wiki.debian.org/LDAP/PAM, the edits in common-account and common-password configure LDAP to not be used for accounts with a UID below 2,000. However, the above approach seems a little cleaner, as pam_succeed_if is used first as the conditional, and then channels the request to either pam_ldap or pam_unix as appropriate, without having to ignore "user_known" return statuses from LDAP for local users. I've tested this and can confirms that it also successfully allows local logins if the LDAP server is unavailable. (I haven't tested the other configuration, but it looks like if LDAP can't return "user_unknown", it will default to a "bad" result, causing local logins to also fail.) The final edit in common-sesson simply adds pam_mkhomedir.so to create home directories at login as necessary.

Two other references that I found helpful were "LDAPClientAuthentication" in the Ubuntu Community Documentation, and Brian White's "LDAP Authentication" LinuxWiki.

Now that everything should be mostly working, there are a few further enhancements and fixes that can be made:

First, it may not be desirable for everyone in LDAP to have access to every LDAP-enabled client machine. /etc/ldap.conf provides several options for limiting which accounts can be used from the current machine. Options include "pam_filter", "pam_check_host_attr", "pam_groupdn", "pam_min_uid", and "pam_max_uid". I find "pam_groupdn" to be the most effective and useful, especially after setting "pam_member_attribute" to "memberUid" to allow reusing posixGroup's.

Next (as mentioned above), is an issue with using ldapi:///. This is really only applicable (possible) when running the LDAP server on the same machine as a client. Basically, "connection_read(): no connection!" warnings are logged when using ldapi:///, which are resolved simply by switching over to ldap:///. This actually appears to be an issue with the libldap client library provided by OpenLDAP itself (2.4.21), and not the slapd daemon. This was reported in full detail as OpenLDAP ITS # 6548. Even after being confirmed on the same ticket with a follow-up by Gerald Turner, the ticket was promptly closed without proper justification, as far as I can understand. This is now open as Ubuntu bug # 594840, where it is marked as confirmed and affecting at least 7 people as of this writing.

Finally, Ubuntu bug # 297408 may prove beneficial for some setups. From Edward Murrell's original bug description:

Binary package hint: libpam-modules

The pam_group module allows assigning groups based on group membership. This is handy, if for example you want to automagically enable various rights on a specific server dependent on a users membership in a given netgroup. The following line in /etc/security/group.conf makes a user part of the admin group on the machine if they are part of the net group developers.

*;*;@developers;Al0000-2400;admin

Unfortunately, this only works for NIS net groups. This isn't much help if your network groups are held in LDAP, which are recognized as normal NSS groups.

Patch is attached which fixes this. NSS groups are recognized by '%'. Ie;

*;*;%someldapgroup;Al0000-2400;admin

Reportedly, this functionality has been included in PAM 1.1.2. Thanks to Edward for his involvement in providing a solution for this! (As of this writing, Ubuntu Maverick is still using version 1.1.1.)

Tuesday, December 28, 2010

LDAP authentication for Apache HTTP Server

As part of my OpenLDAP under Ubuntu Linux project, this post documents configuring the Apache HTTPD Server to use LDAP for authentication and authorization. The Apache HTTPD Server will simply be referred to as "Apache" for the remainder of this post. As with my previous post on phpLDAPadmin, this post was written against Apache 2.2.16, and Ubuntu Linux's latest release, 10.10 ("Maverick Meerkat").

Before configuring Apache to accept credentials, ensure that sensitive pages and the prompts for credentials will only be accepted on SSL/TLS-protected sites, otherwise users' credentials will be passed over the network in clear-text where they may easily be compromised. (It doesn't make much sense to use SSL/TLS encryption between Apache and the LDAP server, if the communication between the web browser and the web server isn't protected.) Documentation for using SSL/TLS encryption for the Apache web server is readily available elsewhere (e.g. the "HTTPS Configuration" section under "HTTPD" in the Ubuntu Server Guide), and is beyond the scope of this post.

At least under Ubuntu Maverick, Apache is installed with the mod_authnz_ldap module, but it is not enabled by default. To enable, use "sudo a2enmod authnz_ldap", or manually create the symbolic links in "/etc/apache2/mods-enabled". (a2enmod is a Debian-specific script shared with Ubuntu.)

Next, add a <Location> directive into the Apache configuration that contains configuration directives as documented in mod_authnz_ldap. Assuming that only one LDAP directory will be used for the Apache instance, I just place most of the configuration under a root Location, like this:

<Location "/">
    AuthBasicProvider ldap
    AuthType Basic
    AuthName "example.com"
    AuthzLDAPAuthoritative off
    AuthLDAPURL "ldaps://ldap.example.com/dc=example,dc=com?uid?sub"
    AuthLDAPBindDN "cn=ldap.proxy,ou=serviceAccounts,dc=example,dc=com"
    AuthLDAPBindPassword "secret123"
</Location>

I need the bind distinguished name (DN) and password, as I have OpenLDAP configured to not allow anonymous binds, which is what Apache 2.2 defaults to if these are not specified. I don't particularly like the need for the proxy account, however, for security and maintenance reasons. I would think that ideally, Apache could just use the username and password of the authenticating user to perform the bind. If the user's bind fails, then access should be denied anyway. However, this would require Apache to know how to convert a username (e.g. "mark") into a DN (e.g. "cn=mark,ou=people,dc=example,dc=com") that is acceptable for the bind. As configured above, Apache currently determines this with a query performed using the specified bind credentials, searching for an LDAP entry where the uid (user identifier) attribute matches the user's entered username. Interestingly, it appears that "binding as the user" will be available in Apache 2.3 (currently in alpha), as seen in the 2.3 documents for AuthLDAPInitialBindAsUser and AuthLDAPInitialBindPattern. However, while sometimes beneficial, this method of translating the username is limited to string matching and substitution only (using regular expressions) as LDAP access is not yet available, so continuing to use a configured bind DN and password will still be more flexible for several scenarios.

Securing the LDAP queries with SSL/TLS is necessary to protect the credentials being passed over the network, as accomplished with the "ldaps://" AuthLDAPURL above. For testing or troubleshooting during initial setup, it can be temporarily replaced with simply "ldap://" to use unencrypted connections. Alternatively, if the LDAP server is operating on the same host as Apache, "ldapi:///" can be used (with the hostname ommitted) to use *NIX sockets, bypassing the IP layer entirely. Interestingly, while I can't find any documentation to support this (only Apache Bug # 44302 which reports that it wasn't working at least as of Apache 2.2.8 on 2008-01-27), "ldapi:///" is working for me as of this writing.

For SSL communications to be successful, the LDAP server's SSL certificate must be trusted by the calling server. This is currently accomplished by providing one or more trusted cerver certificates, and setting LDAPTrustedGlobalCert in the Apache configuration. If multiple certificates must be supported, they can simply be concatenated into a single file when using the Base64 / PEM (CA_BASE64) certificate format. Currently, this must be configured globally per Apache instance, not per directory or location. Alternatively, this can be set globally per server through the TLS_CACERT option in /etc/ldap/ldap.conf. Setting "TLS_REQCERT never" should also work, but this is not recommended for security reasons, nor does it appear to work currently.

Now, just add require directives as appropriate. Available options for LDAP include ldap-user, ldap-group, ldap-dn, ldap-attribute, and ldap-filter. ldap-user should be avoided for reasons of maintainability and security best practices. One of these directives may be placed at the same root <Location> block as above, or in child locations. (Per the Apache Configuration Sections documentation, <Directory> directives should be used over <Location> directives for access control of filesystem-based resources, as improper configurations may otherwise easily result in circumventions.) Either Location or Directory directives will inherit the above-configured Auth* directives from a parent.

For example, to protect phpLDAPadmin as previously configured:

  <Location "/phpldapadmin">
    Options +ExecCGI
    AddHandler fcgid-script .php
    FCGIWrapper /usr/lib/cgi-bin/php5 .php

    require ldap-group cn=ldap-admins,ou=groups,dc=example,dc=com
  </Location>

Finally, reload the Apache configuration ("sudo /etc/init.d/apache2 reload"), and test away!

Monday, December 27, 2010

LDAP web administration with phpLDAPadmin

As part of my OpenLDAP under Ubuntu Linux project, I wanted to find a good web administration tool for the directory. The best option I found was phpLDAPadmin (Wikipedia), a.k.a. PLA.

I meant to complete several other LDAP-related posts since I started this project in April, but other priorities took precedence. However, a side benefit is that my previous configurations have now been successfully repeated and tested under Ubuntu Linux's latest release, 10.10 ("Maverick Meerkat").

Apache Configuration

As phpLDAPadmin is a web application, it depends on a web server that can serve PHPs. My choice is the Apache HTTPD Server (Wikipedia) version 2.2, which will simply be referred to as "Apache" for the remainder of this post.

phpLDAPadmin is available in the Ubuntu package repositories. However, the default configuration (as packaged for Ubuntu) could use some improvement, so I'd recommend against installing it from the repository. I already have an Apache instance running for some other uses, which uses Apache's default worker MPM. However, Ubuntu's packaged version depends on libapache2-mod-php5, which depends on apache2-mpm-prefork, which reconfigures Apache to use the prefork MPM. The differences between these Multi-Processing Modules is documented by Apache in Apache Performance Tuning, and a few other references that I stumbled upon:

Now granted, my uses of Apache and/or LDAP aren't currently anywhere near demanding enough for a significant difference in performance between the MPMs. However, this is a good exercise, and I can be confident that this setup will be able to scale with fewer issues in the future.

My existing Apache installation consisted of the "apache2" Ubuntu (meta)package. To support PLA, the "php5-cgi" and "php5-ldap" packages also need to be installed. (Do not install the base "php5" package, as this also has the same dependencies listed above, and will reconfigure Apache to use the prefork MPM.)

The primary reason for libapache2-mod-php5 depending on the prefork MPM is due to thread-safety issues. As such, a suitable way is necessary to run PHP under Apache in a thread-safe fashion. Standard CGI would be one option, but is terribly inefficient. FastCGI is an option that provides for isolation between PHP (and/or other modules and languages) and Apache, while avoiding the inefficiencies of CGI. Support for FastCGI in Apache was originally available through mod_fastcgi, but is discouraged due to various stability and license compatibility issues. mod_fcgid is the preferred alternative, provides binary compatibility, is reportedly faster, and is available as the libapache2-mod-fcgid package in Ubuntu.

To summarize the above paragraph, also install libapache2-mod-fcgid. The module should be automatically enabled. If not, use "sudo a2enmod fcgid", or manually create the symbolic links in "/etc/apache2/mods-enabled". (a2enmod is a Debian-specific script shared with Ubuntu.)

Download the latest "phpldapadmin-php5" package from http://sourceforge.net/projects/phpldapadmin/files/phpldapadmin-php5/. As of this post, I am using version 1.2.0.5. I extracted the download into "/var/www/phpldapadmin" (the default DocumentRoot). Then add a <Location> directive into the Apache configuration, utilizing fcgid:

  <Location "/phpldapadmin">
    Options +ExecCGI
    AddHandler fcgid-script .php
    FCGIWrapper /usr/lib/cgi-bin/php5 .php
  </Location>

As phpLDAPadmin deals with credentials (including passwords for both administrative login, as well as user accounts), proper measures should be taken to secure this site. It should only be accessible over SSL/TLS (HTTPS). I've also configured Apache to require authorization to access PLA at all - including its login page (detailed later).

phpLDAPadmin Configuration

phpLDAPadmin provides an example configuration in config/config.php.example. Copy it to config/config.php, then customize it from there. If you are running the LDAP server (e.g. OpenLDAP) on the same host, no changes should be required, but setting the server "friendly" name is probably desired at a minimum. Details are available at Installation, Config, Config.php, and LDAP server definitions in the PLA Wiki.

At this point, phpLDAPadmin should be mostly usable. However, as of version 1.2.0.5 of PLA, there are a few quirks that I found and addressed:

  1. One unloadable DN causes others to not expand in the tree, due to a buggy early return from the draw function in lib/HTMLTree.php that skips over draw_javascript() from being called, and ajax_tree.js and layersmenu-browser_detection.js not being loaded into the browser. I reported this in bug # 2997938, and also provided a patch (attached to the bug report). As of 2010-12-27, there has been no acknowledgement or other activity taken by the PLA developers on this bug, so anyone also affected will need to manually apply the patch.

  2. When using phpLDAPadmin over HTTPS (as recommended above), all page resources are properly loaded over HTTPS except the SourceForge logo in the page footer. This causes security warnings in the browser due to "partial encryption". I reported this in bug # 2997703, along with a work-around of using the "remoteurls" option that is mentioned but otherwise undocumented at http://phpldapadmin.sourceforge.net/wiki/index.php/Config.php, as well as a code fix to properly use proper relative URLs. As of 2010-11-06, a fix has been committed for the next (but not yet available) PLA release.
  3. With every attempt to edit an entry, there is a nuisance "Select a template to edit the entry" page, that prompts for a template to use (either "Default", "Generic: Address Book Entry", or "Generic: Posix Group"). This prompt is repeated for repeat edits, with no visible option to save a default template. After reading this forum post on gentoo.org, and extending upon some of the suggestions offered for other issues in the PLA FAQ, I renamed each of the 2 .xml files under "templates/modification" to add a non-.xml suffix, essentially disabling the modification templates. (Simply renaming or removing the directory seemed like it should be a better option, but causes other errors.)
  4. Similar to the above, and more closely covered by the FAQ, even after removing the "modification" templates, there are still "Automatically removed objectClass from template" warnings displayed when first editing an entry in a PLA session. Renaming "mozillaOrgPerson.xml", "courierMailAccount.xml", and "courierMailAlias.xml" under the "templates/creation" folder seems to have removed all of these warnings, at least for my configured LDAP schema. (I'm not sure why the "creation" templates are even being referenced during modification.)

Alternatives

I had looked through a few alternatives before choosing phpLDAPadmin. At least while limiting the search to free and open-source solutions, I really didn't find anything that I think can compare to PLA. However, one cool, but non-web-based alternative I did find is shelldap, which allows for browsing and manipulating an LDAP directory using familiar shell commands like cat, cd, cp, ls, touch, mkdir, move, and vi.

Sunday, June 6, 2010

OpenLDAP Password Permissions Configuration Example

Following my post on OpenLDAP under Ubuntu Linux Lucid Lynx 10.04, I'd like to address a question submitted as a comment submitted by "raerek":

I plan to set up things like this:
-Group A: members can change the password of anyone, except the password of other Group A members.
-Group B: members can change their own passwords, and the passwords of Group C members.
-Group C: members can only change their own password.

Can you outline how to write the "olcAccess: to" lines - If I do not have to, I would not like to set up three OU-s - I'd rather have everyone in the ou=people.

While I cannot guarantee a response to every question, this one caught my interest - especially due to some of the well-advised reasons I'm guessing are behind the stated requirements.

The "Group A" requirement in particular looked rather complicated when I first looked at this, as the "... anyone, except ..." would normally be addressed with compound conditionals - and OpenLDAP doesn't provide for this - at least not as many would expect. As with many technical issues, the best approach here seems to be in simplifying the functional requirements:

  1. Anyone can change their own password.
    • Is specified by both the original "Group A" and "Group B" requirements, and completely satisfies the original "Group C" requirement.
    • "Anyone" should not necessarily apply to "service" or "machine" accounts, unless such an account is specifically known or required to change its own password.
  2. "Group A" members cannot change the passwords of other "Group A" members.
  3. "Group A" members can change the passwords of everyone else (besides other "Group A" members, as listed above in #2).
  4. "Group B" members can change the passwords of "Group C" members.
  5. Unless otherwise specified above, deny any other access to passwords, except for accounts to read their own password (probably not always even necessary) and for anonymous (an account before authenticated) to authenticate against.

Here is my entire proposed solution, with notes to follow. First, an LDIF export of a setup to demonstrate the example:

dn: dc=example,dc=com
dc: Example
description: LDAP Example 
o: Example Organization
objectclass: top
objectclass: dcObject
objectclass: organization

dn: ou=groups,dc=example,dc=com
objectclass: organizationalUnit
ou: groups

dn: cn=groupA,ou=groups,dc=example,dc=com
cn: groupA
description: members can change the password of anyone, except the password 
 of other Group A members.
member: cn=groupOfNamesPlaceHolder,ou=groups,dc=example,dc=com
member: cn=groupA_user1,ou=people,dc=example,dc=com
member: cn=groupA_user2,ou=people,dc=example,dc=com
objectclass: groupOfNames

dn: cn=groupB,ou=groups,dc=example,dc=com
cn: groupB
description: members can change their own passwords, and the passwords of Gr
 oup C members.
member: cn=groupOfNamesPlaceHolder,ou=groups,dc=example,dc=com
member: cn=groupB_user1,ou=people,dc=example,dc=com
member: cn=groupB_user2,ou=people,dc=example,dc=com
objectclass: groupOfNames

dn: cn=groupC,ou=groups,dc=example,dc=com
cn: groupC
description: members can only change their own password.
member: cn=groupOfNamesPlaceHolder,ou=groups,dc=example,dc=com
member: cn=groupC_user1,ou=people,dc=example,dc=com
member: cn=groupC_user2,ou=people,dc=example,dc=com
objectclass: groupOfNames

dn: cn=groupOfNamesPlaceHolder,ou=groups,dc=example,dc=com
cn: groupOfNamesPlaceHolder
objectclass: applicationProcess

dn: ou=people,dc=example,dc=com
objectclass: organizationalUnit
ou: people

dn: cn=groupA_user1,ou=people,dc=example,dc=com
cn: groupA_user1
objectclass: inetOrgPerson
objectclass: simpleSecurityObject
sn: Test
userpassword: secret

dn: cn=groupA_user2,ou=people,dc=example,dc=com
cn: groupA_user2
objectclass: inetOrgPerson
objectclass: simpleSecurityObject
sn: Test
userpassword: secret

dn: cn=groupB_user1,ou=people,dc=example,dc=com
cn: groupB_user1
objectclass: inetOrgPerson
objectclass: simpleSecurityObject
sn: Test
userpassword: secret

dn: cn=groupB_user2,ou=people,dc=example,dc=com
cn: groupB_user2
objectclass: inetOrgPerson
objectclass: simpleSecurityObject
sn: Test
userpassword: secret

dn: cn=groupC_user1,ou=people,dc=example,dc=com
cn: groupC_user1
objectclass: inetOrgPerson
objectclass: simpleSecurityObject
sn: Test
userpassword: secret

dn: cn=groupC_user2,ou=people,dc=example,dc=com
cn: groupC_user2
objectclass: inetOrgPerson
objectclass: simpleSecurityObject
sn: Test
userpassword: secret

Note that the userpassword's are in clear text for the purposes of this example. They should normally be stored using a cryptographic hash such as salted SHA (SSHA) for proper security.

Next are the olcAccess rules:

# Req. #1 - Any user in the people OU can change their own password.
olcaccess: to dn.subtree="ou=people,dc=example,dc=com"
  attrs=userPassword
  by self write
  by * break
# Req. #2 - "Group A" members cannot change the passwords of other "Group A" members.
olcaccess: to filter=(memberof=cn=groupA,ou=groups,dc=example,dc=com)
  attrs=userPassword
  by group.exact="cn=groupA,ou=groups,dc=example,dc=com" none
  by * break
# Req. #3 - "Group A" members can change the passwords of everyone else.
olcaccess: to attrs=userPassword
  by group.exact="cn=groupA,ou=groups,dc=example,dc=com" write
  by * break
# Req. #4 - "Group B" members can change the passwords of "Group C" members.
olcaccess: to filter=(memberof=cn=groupC,ou=groups,dc=example,dc=com)
  attrs=userPassword
  by group.exact="cn=groupB,ou=groups,dc=example,dc=com" write
  by * break
# Req. #5 - Unless otherwise specified above, deny any other access to passwords,
#   except for accounts to read their own password (probably not always even necessary)
#   and for anonymous (an account before authenticated) to authenticate against.
olcaccess: to attrs=userPassword
  by self read
  by anonymous auth
  by * none

First, note that this requires use of the "memberof" overlay, as detailed in section "12.8. Reverse Group Membership Maintenance" in the OpenLDAP Administrator's Guide. Without it, the "memberof" attributes will not exist, and the required filters will not work. Also note that as provided by the current version of the overlay, the "memberof" attributes are stored rather than simply calculated when requested (probably for performance reasons), and are only updated when the entry is involved in a modification of group membership. As such, if the overlay is added to a database with existing populated groups, the groups will likely have to be re-populated for the "memberof" attribute to reflect the current and expected results. In testing, any update to the "member" attribute on a group - even only the addition or removal of one member - will cause the overlay to update the "memberof" attribute on all other members in the group. Also related to performance, make sure that "memberof" is indexed after enabling the overlay.

Next, note that most rules are terminated by a "by * break" clause. This allows following rules to be considered, without first terminating with the "by * none" clause that is implicitly added at the end of every rule, as detailed in section "8.2.4. Access Control Evaluation" in the OpenLDAP Administrator's Guide.

No work is complete without a good test script. This is also a good reference for how to change account passwords using ldapmodify. Here is the test source as a bash shell script:

#!/bin/bash

# Mark A. Ziesemer, http://www.ziesemer.com
# 2010-06-06

_cpw(){
  # "Change PassWord"
  local bindUser=$1
  local bindPW=$2
  local changeUser=$3
  local newPW=$4
  declare -i expected=$5 # optional, defaults to 0

  declare -i result=0
  echo "% _cpw $*"
  echo "
    dn: $changeUser
    changetype: modify
    replace: userpassword
    userpassword: $newPW" | ldapmodify -D "$bindUser" -xw "$bindPW" || result=$?
  if [ $result -ne $expected ]; then
    echo -e "\t* Test FAILED, exit code: $result"
    if [ $result -gt 0 ]; then return $result; fi
    return 1
  fi
  echo -e "\t* Test passed, exit code: $result"
  return 0
}

_testTitle(){
  echo -e "\n*** $1\n"
}

_defSuffix="dc=example,dc=com"
_peopleOU="ou=people,${_defSuffix}"
_groupA_user1="cn=groupA_user1,${_peopleOU}"
_groupA_user2="cn=groupA_user2,${_peopleOU}"
_groupB_user1="cn=groupB_user1,${_peopleOU}"
_groupB_user2="cn=groupB_user2,${_peopleOU}"
_groupC_user1="cn=groupC_user1,${_peopleOU}"
_groupC_user2="cn=groupC_user2,${_peopleOU}"

_testTitle "Testing requirement #1: Anyone can change their own password."
_cpw "${_groupA_user1}" "secret" "${_groupA_user1}" "secret1"
_cpw "${_groupA_user1}" "secret1" "${_groupA_user1}" "secret"
_cpw "${_groupB_user1}" "secret" "${_groupB_user1}" "secret1"
_cpw "${_groupB_user1}" "secret1" "${_groupB_user1}" "secret"
_cpw "${_groupC_user1}" "secret" "${_groupC_user1}" "secret1"
_cpw "${_groupC_user1}" "secret1" "${_groupC_user1}" "secret"

_testTitle "Testing requirement #2: \"Group A\" members cannot change the passwords of other \"Group A\" members."
_cpw "${_groupA_user1}" "secret" "${_groupA_user2}" "secret1" 50

_testTitle "Testing requirement #3: \"Group A\" members can change the passwords of everyone else."
_cpw "${_groupA_user1}" "secret" "${_groupB_user1}" "secret1"
_cpw "${_groupA_user1}" "secret" "${_groupB_user1}" "secret"
_cpw "${_groupA_user1}" "secret" "${_groupC_user1}" "secret1"
_cpw "${_groupA_user1}" "secret" "${_groupC_user1}" "secret"

_testTitle "Testing requirement #4: \"Group B\" members can change the passwords of \"Group C\" members."
_cpw "${_groupB_user1}" "secret" "${_groupC_user1}" "secret1"
_cpw "${_groupB_user1}" "secret" "${_groupC_user1}" "secret"
_cpw "${_groupB_user1}" "secret" "${_groupB_user2}" "secret1" 50

_testTitle "Testing requirement #5: Deny other access."
_cpw "${_groupC_user1}" "secret" "${_groupA_user1}" "secret1" 50
_cpw "${_groupC_user1}" "secret" "${_groupB_user1}" "secret1" 50
_cpw "${_groupC_user1}" "secret" "${_groupC_user2}" "secret1" 50

With the associated output from a successful run:

*** Testing requirement #1: Anyone can change their own password.

% _cpw cn=groupA_user1,ou=people,dc=example,dc=com secret cn=groupA_user1,ou=people,dc=example,dc=com secret1
modifying entry "cn=groupA_user1,ou=people,dc=example,dc=com"

        * Test passed, exit code: 0
% _cpw cn=groupA_user1,ou=people,dc=example,dc=com secret1 cn=groupA_user1,ou=people,dc=example,dc=com secret
modifying entry "cn=groupA_user1,ou=people,dc=example,dc=com"

        * Test passed, exit code: 0
% _cpw cn=groupB_user1,ou=people,dc=example,dc=com secret cn=groupB_user1,ou=people,dc=example,dc=com secret1
modifying entry "cn=groupB_user1,ou=people,dc=example,dc=com"

        * Test passed, exit code: 0
% _cpw cn=groupB_user1,ou=people,dc=example,dc=com secret1 cn=groupB_user1,ou=people,dc=example,dc=com secret
modifying entry "cn=groupB_user1,ou=people,dc=example,dc=com"

        * Test passed, exit code: 0
% _cpw cn=groupC_user1,ou=people,dc=example,dc=com secret cn=groupC_user1,ou=people,dc=example,dc=com secret1
modifying entry "cn=groupC_user1,ou=people,dc=example,dc=com"

        * Test passed, exit code: 0
% _cpw cn=groupC_user1,ou=people,dc=example,dc=com secret1 cn=groupC_user1,ou=people,dc=example,dc=com secret
modifying entry "cn=groupC_user1,ou=people,dc=example,dc=com"

        * Test passed, exit code: 0

*** Testing requirement #2: "Group A" members cannot change the passwords of other "Group A" members.

% _cpw cn=groupA_user1,ou=people,dc=example,dc=com secret cn=groupA_user2,ou=people,dc=example,dc=com secret1 50
modifying entry "cn=groupA_user2,ou=people,dc=example,dc=com"
ldap_modify: Insufficient access (50)

        * Test passed, exit code: 50

*** Testing requirement #3: "Group A" members can change the passwords of everyone else.

% _cpw cn=groupA_user1,ou=people,dc=example,dc=com secret cn=groupB_user1,ou=people,dc=example,dc=com secret1
modifying entry "cn=groupB_user1,ou=people,dc=example,dc=com"

        * Test passed, exit code: 0
% _cpw cn=groupA_user1,ou=people,dc=example,dc=com secret cn=groupB_user1,ou=people,dc=example,dc=com secret
modifying entry "cn=groupB_user1,ou=people,dc=example,dc=com"

        * Test passed, exit code: 0
% _cpw cn=groupA_user1,ou=people,dc=example,dc=com secret cn=groupC_user1,ou=people,dc=example,dc=com secret1
modifying entry "cn=groupC_user1,ou=people,dc=example,dc=com"

        * Test passed, exit code: 0
% _cpw cn=groupA_user1,ou=people,dc=example,dc=com secret cn=groupC_user1,ou=people,dc=example,dc=com secret
modifying entry "cn=groupC_user1,ou=people,dc=example,dc=com"

        * Test passed, exit code: 0

*** Testing requirement #4: "Group B" members can change the passwords of "Group C" members.

% _cpw cn=groupB_user1,ou=people,dc=example,dc=com secret cn=groupC_user1,ou=people,dc=example,dc=com secret1
modifying entry "cn=groupC_user1,ou=people,dc=example,dc=com"

        * Test passed, exit code: 0
% _cpw cn=groupB_user1,ou=people,dc=example,dc=com secret cn=groupC_user1,ou=people,dc=example,dc=com secret
modifying entry "cn=groupC_user1,ou=people,dc=example,dc=com"

        * Test passed, exit code: 0
% _cpw cn=groupB_user1,ou=people,dc=example,dc=com secret cn=groupB_user2,ou=people,dc=example,dc=com secret1 50
modifying entry "cn=groupB_user2,ou=people,dc=example,dc=com"
ldap_modify: Insufficient access (50)

        * Test passed, exit code: 50

*** Testing requirement #5: Deny other access.

% _cpw cn=groupC_user1,ou=people,dc=example,dc=com secret cn=groupA_user1,ou=people,dc=example,dc=com secret1 50
modifying entry "cn=groupA_user1,ou=people,dc=example,dc=com"
ldap_modify: Insufficient access (50)

        * Test passed, exit code: 50
% _cpw cn=groupC_user1,ou=people,dc=example,dc=com secret cn=groupB_user1,ou=people,dc=example,dc=com secret1 50
modifying entry "cn=groupB_user1,ou=people,dc=example,dc=com"
ldap_modify: Insufficient access (50)

        * Test passed, exit code: 50
% _cpw cn=groupC_user1,ou=people,dc=example,dc=com secret cn=groupC_user2,ou=people,dc=example,dc=com secret1 50
modifying entry "cn=groupC_user2,ou=people,dc=example,dc=com"
ldap_modify: Insufficient access (50)

        * Test passed, exit code: 50

Additional references:

Sunday, May 9, 2010

OpenLDAP under Ubuntu Linux Lucid Lynx 10.04

Introduction

Somewhat as a follow-up to my Ubuntu Linux router upgrade project over a year and a half ago, I've worked on extending my home setup to include a complete LDAP solution.

My router upgrade project was completed under the latest version of Ubuntu Linux at the time, 8.04 ("Hardy Heron"), which also happened to be a Long Term Support (LTS) release. That guide has held up very well over the last 2 years and the following 4 Ubuntu releases, and is still my working reference as I choose to rebuild with each new release every 6 months. This includes the latest release, Ubuntu Linux 10.04, "Lucid Lynx". Lucid also happens to be the next LTS release, and is the version I am basing this guide on.

This guide will include setup of an LDAP server, as well as setting up client authentication and administration tools.

LDAP stands for "Lighweight Directory Access Protocol". In the simplest setup, it is a database of usernames, passwords, and other information, and is commonly used for shared authentication and authorization. It can be extended with any set of additional fields, allowing for extra uses.

For my purposes within a home network, LDAP is probably a bit of an overkill. However, with an increasing number of computers and virtual machines, it will make user maintenance easier once complete. I even plan on using it with RADIUS and WPA 2 Enterprise for keeping better control around wireless access. Additionally, this will be a good learning experience, as well as hopefully a good working reference for others needing a similar setup.

OpenLDAP

OpenLDAP (Wikipedia) is a free and open source LDAP server. It is highly configurable and very performant. As detailed at http://www.openldap.org/pub/hyc/LDAPcon2007.pdf:

OpenLDAP is the premier implementation of LDAP client and server software, providing full support of LDAPv3 and most popular standard and draft (work in progress) LDAP extensions. It has evolved over the years from its origins in the University of Michigan's reference implementation of LDAPv2 as a vehicle for experimentation into a mature, commercial grade package capable of supporting the most demanding environments. The current release has been proven to scale to hundreds of millions of objects in data volumes in excess of a terabyte, with performance in excess of 22,000 queries per second at sub-millisecond latencies. Reliability in production deployments has been flawless, with hardware failure being the principal cause of unscheduled downtime.

Also refer to "An OpenLDAP Update" (Marty Heyman, 2007-09-13, onlamp.com) for additional details. This was as of 2007, and these results should easily be multiplied through replicated nodes. (See "What is a directory service?" and "Replication" in the Administrator's Guide, and the "Directories vs. Relational Database Management Systems" FAQ entry.) OpenLDAP is also the only LDAP server provided in Ubuntu that is also maintained / supported by the Ubuntu developers.

The only alternatives I even considered were:

  • The 389 Directory Server (Wikipedia). Part of Red Hat's Fedora project, and identical to the Red Hat Directory Server. Like OpenLDAP, the 389 Directory Server is also based off of the University of Michigan project, and later, Netscape Directory Server. Unfortunately, the 389 Directory Server looks rather exclusive to Fedora and Red Hat Enterprise Linux (RHEL), with no binary packages readily available for other systems. There is some outdated documentation for Ubuntu, that only applied to older versions of both the directory server (1.1 vs. 1.2) and Ubuntu (9.10 vs. 10.04). Even following the notes, installation under a 9.10 VM no longer works as documented. Compiling from source would probably be the most successful attempt for current versions, but just the number of dependencies involved doesn't make this a very appealing option.
  • Apache Directory Server (Wikipedia). I had no specific issues against, but also no current compelling reasons to consider Apache Directory Server over OpenLDAP.

OpenLDAP installation under Ubuntu

Unfortunately, as of Ubuntu Linux 9.10 (Karmic Koala), there is no longer any automated, prompted configuration when installing the Ubuntu-packaged OpenLDAP server, slapd. The issues are visible in Ubuntu Bug # 463684, https://help.ubuntu.com/community/OpenLDAPServer, http://ubuntuforums.org/showthread.php?t=1313472, and http://ubuntuforums.org/showthread.php?t=1295934. Fortunately, most of these issues appear to have been corrected in the latest server guide for 10.04 (Lucid Lynx) at http://doc.ubuntu.com/ubuntu/serverguide/C/openldap-server.html.

My installation is based off of the latest server guide (the last link above), with a few noted changes (highlighted) for the backend*.ldif file:

# Load dynamic backend modules
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulepath: /usr/lib/ldap
olcModuleLoad: back_hdb
olcModuleLoad: back_monitor

# Database settings
dn: olcDatabase=hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcSuffix: dc=example,dc=com
olcDbDirectory: /var/lib/ldap
olcRootDN: cn=admin,dc=example,dc=com
olcRootPW: secret
olcDbConfig: set_cachesize 0 2097152 0
olcDbConfig: set_lk_max_objects 1500
olcDbConfig: set_lk_max_locks 1500
olcDbConfig: set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: uid eq
olcDbIndex: cn eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: memberUid eq
olcDbIndex: uniqueMember eq
olcLastMod: TRUE
olcMonitoring: TRUE
olcDbCheckpoint: 512 30
olcAccess: to dn.subtree="ou=people,dc=example,dc=com" attrs=userPassword,shadowLastChange by dn="cn=admin,dc=example,dc=com" write by anonymous auth by self write by * none
olcAccess: to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=example,dc=com" write by anonymous auth by * none
# Below line should already exist by default in frontend.
#olcAccess: to dn.base="" by * read
# Below line modified from "*" to "users" to prevent anonymous access.
olcAccess: to * by dn="cn=admin,dc=example,dc=com" write by users read

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootDN
olcRootDN: cn=admin,dc=example,dc=com
-

dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: to dn.subtree="cn=Monitor" by dn="cn=admin,dc=example,dc=com" read
-

# http://www.openldap.org/doc/admin24/monitoringslapd.html
dn: olcDatabase=monitor,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {2}monitor

My updates include enabling monitoring, addition of commonly used indicies, and some security changes. The security changes are somewhat commented above, and include disabling anonyous access by default, removing a redudant entry that already exists in the default-created /etc/ldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif file, and only allowing "people" (vs. system accounts, etc.) to change their own passwords. Though fixed later in the server guide under "Setting up ACL", the initial permissions on the userPassword and shadowLastChange attributes are treated differently in the server guide. The above gives them the same permissions, and matching those under "Setting up ACL" later in the server guide - from the start.

Starting with OpenLDAP 2.3, the LDAP configuration, by default, including the schema, is stored in LDAP itself (a.k.a. "cn=config"). This allows for dynamic configuration at runtime, and typically without restarting the service. At least in Ubuntu's default configuration, access to this configuation, stored in cn=config, is only available to the root user on the operating system. My updated configuration (above) also allows access to the same configured root user (olcRootDN) as specified in the backend database. Since no seperate olcRootPW is provided, the same password from the backend database is also used. Interestingly, I found that if only a olcRootPW is provided for the configuration database without a olcRootDN, a currently-undocumented default olcRootDN of "cn=admin" is used. I filed an issue report addressing this oversight in the documentation at http://www.openldap.org/its/index.cgi?findid=6546. An additional reference I found helpful around the update to "cn=config" is http://www.zytrax.com/books/ldap/ch6/slapd-config.html.

These settings and changes may not and probably will not be perfect for everyone, but at least this should point out some things to be aware of. Please modify as appropriate to fit your needs.

Security

Be sure to configure TLS (transport layer security). This appears to be covered quite well in the Ubuntu server guide, and I don't plan to provide any additional details around TLS for LDAP here.

Backup Plan

A backup plan is not currently covered in the Ubuntu server guide, so be sure to at least review the Maintenance section of the OpenLDAP Administrator's Guide. However, even the OpenLDAP guide doesn't even mention the possibility of hot database backups, but does conclude the backup section with "MORE on actual Berkeley DB backups later covering db_recover etc.".

A hot database backup doesn't require any downtime, while offering good protection with minimal space overhead. Unlike the other documented approach using slapcat, a hot database backup also guarantees consistency by capturing an exact point in time, regardless of how long the backup takes.

Here I am assuming that you are using a Berkeley Database for the backend, either bdb or hdb. Details of these backends are available under "Berkeley DB Backends" in the OpenLDAP Administrator's Guide. Since most of the database is stored within this database, we can defer to the database's backup documentation. For the Berkeley Database, this is documented quite well at http://download.oracle.com/docs/cd/E17076_02/html/bdb-sql/admin.html.

The best available option for backing up, at least for a hot backup, seems to be the db_hotbackup command line utility referenced in the Berkeley DB documentation. At least in Ubuntu, this script is not installed by default, but is available in the db4.x-util package. Unfortunately, the OpenLDAP implementation provided by the Ubuntu package is still linked against version 4.7 of the Berkeley DB instead of the version 4.8 that was standardized on by almost every other package depending upon Berkeley DB in the Lucid release, so the db4.7-util package is probably the one you need to install. I filed a bug report addressing this version issue in Ubuntu Bug # 572489.

Once the utility package is installed, a hot backup can simply be executed as:

sudo db4.7_hotbackup -c -h /var/lib/ldap/ -b <backupDir>/db

Also backup the /etc/ldap/slapd.d/ directory, which contains the server configuration, including the LDAP schema and configuration of the backend database: (On my systems, I already backup all of /etc/.)

sudo cp -R /etc/ldap/slapd.d <backupDir>/slapd.d

Schedule this to happen regularly and automatically through cron or another job scheduler, and ensure a copy is written to tape or another equivalent media and kept off-site, following typical best practices.

To be continued...

I'll be following up with a number of posts. To be included: