[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: kpasswd



> -----Original Message-----
> From: Allan Streib [mailto:astreib@indiana.edu]

> On Thursday, October 16, 2003, at 05:57 PM, Howard Chu wrote:
>
> >> I gather from what I've read in the archives that I would
> need to run
> >> saslauthd on the ldap server (with the '-a kerberos5'
> option ??), and
> >> then set the appropriate userPassword attribute value to
> >> {SASL}principal ??  Is there more to it, or did I miss some docs
> >> elsewhere?
> >
> > That's all there is to it.
>
> I'm running into some difficulty -- started saslauthd as:
>     saslauthd -a kerberos5
>
> Edited my userPassword attribute to be:
>
>     userPassword: {SASL}astreib@IU.EDU
>
> I get an invalid credentials error trying to bind.  Also
> tried omitting
> the @IU.EDU and the same error.  My ldap logs show:

> Oct 17 11:06:56 slapd[30324]: SASL [conn=10] Error: unable to open
> Berkeley db /etc/sasldb2: No such file or directory
> Oct 17 11:06:56 slapd[30324]: SASL [conn=10] Failure: Invalid
> credentials

> I've never had a problem doing SASL binds without
> /etc/sasldb2 before,
> and in fact a SASL/GSSAPI bind still works fine.  Is that required to
> exist for {SASL} passwords, even though kerberos is what I want to be
> used?

Password {SCHEMES} in the userPassword attribute are only for use with LDAP
Simple Bind, not for SASL Binds. This whole thread has been about using
Kerberos passwords with Simple Binds, why it's a bad idea, and how to do it
if you're OK with doing something unwise.

If your clients are already using SASL Binds, then you can safely ignore
every email in this thread.

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