RE: ldapadd won't add entry via SASL/DIGEST-MD5

["Howard Chu" <hyc@symas.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Gary C. New

> I decided to open up the verboseness of ldapadd and
> believe I've discovered what the fundamental problem
> may be.  It seems that ldapadd is trying to
> authenticate against the server's FQDN as the realm,
> which is not associated with any of the users in the
> sasldb.  I tried specifying the authcid (-U) and
> authzid (-X) (i.e., root@localhost), but could never
> get ldapadd to supply the correct realm information.
> I am able to add ldap entries using simple
> authentication, but still no sasl.
>
> Any idea how I might be able to force ldapadd to use
> the user specific realm information (i.e., localhost)?

   ldapadd -U root -R localhost

Apparently the -R flag was omitted from the man pages but it is listed in the
"usage" information for all of the commandline tools.

It's unfortunate that this problem occurs. The SASL documentation specifies
that the default realm is the FQDN of the server, but the Cyrus code doesn't
actually implement this specification, while OpenLDAP does. The Cyrus code
takes whatever it gets from gethostname() which may or may not be fully
qualified, and usually isn't. The OpenLDAP code uses gethostbyname() to
retrieve the FQDN of the host, which is the correct/standard method of
retrieving FQDNs. So, the Cyrus tools (like saslpasswd) generate password
entries with incomplete realm specifiers by default, and these specifiers
don't work (by default) with any software that actually follows the SASL
docs. You can tell saslpasswd to use a specific realm with the "-u" option
when setting the password.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support