Got it working

[manig <manig@steltor.com>]

Thanks for all of your help. I'm going to post the exact steps I took to
get this working; since this will be stored in the archive someone may
find this useful :)

What I did to get SASL (DIGEST-MD5 Mech) working with OpenLDAP 2.0.x
====================================================================

- I familiarized myself with RFC 2829 "Authentication Methods for
LDAP"and RFC 2831 "Using Digest Authentication as a SASL Mechanism".
- Compile and install Cyrus SASL 1.5.x (not version 2).
- Compile and install OpenLDAP 2.0.x, making sure that Cyrus SASL is
detected during the configure process.
- Set up OpenLDAP as the "OpenLDAP Quick Start Guide" instructs. (Some
things in the quick start guide did not work for me "out of the box",
just scanning the mailing list archives and RTFM'ing I quickly found
solutions)
- Added a user, making sure the record contained a uid field*. For
example:

dn: cn=Shigeru Miyamoto,dc=steltor,dc=com 
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: shigeru
cn: Shigeru Miyamoto 
sn: Miyamoto

- Added a password for the user using saslpasswd(8), with the following
command:

saslpasswd -c "u:shigeru"

- Things should be working properly now. Test things out:

/usr/local/bin/ldapsearch -I -D "uid=shigeru" "cn=*"
SASL/DIGEST-MD5 authentication started
SASL Interaction
Default: root
Please enter your authentication name: u:shigeru
Please enter your authorization name: u:shigeru
Please enter your password: 
SASL username: u:shigeru
SASL realm: c-644.in.steltor.com
SASL SSF: 128
SASL installing layers
version: 2

#
# filter: cn=*
# requesting: ALL
#

# search result
search: 5
result: 32 No such object

# numResponses: 1

Note that I entered u:shigeru as both the authentication and
authorization names. This causes whichever OpenLDAP client (in this case
ldapsearch) to not specify an authzid in the DIGEST-MD5 authentication
process (which is good). If I leave authorization name blank, it will
specify authzid="", which is less desirable. I don't know if this should
be considered a bug.

That's all it took! And note that my slapd.conf is completely vanilla
(i.e. no "access" lines with regexps or anything like that), except for
having included a couple schemas for inetOrgPerson to be a recognized
objectClass.

(As you might have guessed, my understanding of OpenLDAP and LDAP in
general is very shallow. I have less than a week's worth of experience
with SASL and/or LDAP, so please forgive me if the above guide seems
amateurish :))

Thanks again,
-Mani

* (SOAPBOX) OpenLDAP 2.0.x does not support using dnAuthzid as specified
in RFC 2829, despite the statement "All servers which support the
storage of authentication credentials, such as passwords or
certificates, in the directory MUST support the dnAuthzId choice." I
supposed this version of OpenLDAP does NOT store authentication
credentials, but it should at least have been clearly documented that it
does not support authzid = "dn:<dn>" (/SOAPBOX)


"Kurt D. Zeilenga" wrote:
> 
> At 11:45 PM 2002-02-14, Howard Chu wrote:
> >Using "u:dn:cn=foo,..." is not legal. The docs say you must use either a
> >"u:" prefix or a "dn:" prefix, you cannot use both at once. And as I noted
> >in my previous message, the released code only allows a "u:" prefix. This
> >can be
> >considered a bug,
> 
> It's not a bug.  2.0 doesn't support SASL Proxy Authorization.
> Since the user is not attempting a proxy authorization, the
> authzid should be not-present/empty.
> 
> 2.1 will support SASL Proxy Authorization.  However, unless
> the user is attempting proxy authorization, the user should
> not specify an authzid.
> 
> Kurt

-- 
/* Mani Ghasemlou, Software Developer
 * Steltor Inc., 2000 Peel Street, 4th floor, Montreal.
 * TELEPHONE: (514) 733-8500 EXT 4217 FAX: (514) 733-8878
 */