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

Re: kpasswd

I would also add.. A comment was made about performance. The latest
version of saslauthd (v2) supports a caching layer that makes a HUGH
difference in speed. We allow credentials to be cached for 1 hour which
means only 1 TGT request gets generated each hour then saslauthd caches
the results. If you support lots of simple binds via saslauthd
(protected by SSL of course) or Cyrus IMAP connections via SSL like we
do it makes a BIG difference. 

FWIW. The same discussion about protecting simple binds / none native
GSSAPI/SASL binds occurs frequently on the sasl and kerberos lists, but
"in the real world" we do what we can to make the enduser's life easy --
i'd love to see the day when everything understood good crypto/auth -
but we still have to deal with crap software...  ;-)

Allan Streib wrote:
> On Friday, October 17, 2003, at 03:35 PM, Howard Chu wrote:
> > 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.
> Yes, this is about allowing simple binds.  I encourage clients to use
> GSSAPI SASL binds if they can, but I have also needed to support simple
> binds.  I'm trying to make this {SASL} password thing work, since the
> {KERBEROS} scheme is being dropped.
> Allan