[Date Prev][Date Next]
Re: Got it working
One question: saslpasswd -c u:<uid>
Is the u: part needed? If I set a password like saslpasswd tarjei or through
cyrus-imapd then the 'u:' part is not included, right? Is it possible to set up
OL so I do not need to use the u: part.
Also, to use OL w/ sasl, do I have to use saslpasswd for changing my
userPassword or can this be done f.x. through an ldif file?
Has anyone managed to use sasl together with pam-ldap and changed passwords
through the normal passwd command?
> 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
> - Added a user, making sure the record contained a uid field*. For
> 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
> 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
> (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,
> * (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