[Bug 6629] userPassword Support not available, because it is not build with libssl-dev

[Benjamin Montgomery]

Public bug report changed:
https://launchpad.net/malone/bugs/6629

Comment:
Guido Trotter wrote:
> I haven't tried because I use normal binding, on an SSL or TSL encrypted
> connection, which is perfectly fine security wise, and even better than
a SASL
> bind, from my point of view, as it protects the whole connection and not
only
> the password.

I'm using ldaps with a GSSAPI SASL bind. The passwords are stored in
kerberos and SASL uses kerberos tickets to grant access.  This works
without problems.  I haven't tried the other SASL methods.  This is why
I was wondering what parts are broken, because SASL binds seem to work
correctly.  My LDAP server is configured to not allow access unless the
request is authenticated with an appropriate kerberos ticket.  I mostly
have it set up to provide a LDAP+Kerberos single sign on capability.

> You say the sasl works only with unencrypted passwords... are you sure
it's not
> *supposed* to behave that way? Thinking about it: if your password is
> transmitted over the wire then the LDAP server on the other end of the
> connection can use whichever hashing tecnique it has used to encrypt the
> password to verify its correctnes... On the other hand if the password
is used
> as a shared secret to provide some kind of challenge response
authentication how
> can the server actually do its work without *knowing* the secret himself
(rather
> than some one-way-encrypted version of it). It seems to be the same
tradeoff
> there is between PPP CHAP and PAP authentication.
>
> Anyway just to be sure it's not a gq issue: why don't you ask the user who
> complained to try binding to the same account with the command-line
ldapsearch
> and see if that works or not? If it doesn't it's probably not gq's fault!

The problem is not with binding.  We are looking at the userPassword
field in an LDAP record.  With the correct build-deps gq can handle
hashing passwords before they are sent to the server.  You can tell if
this feature is enabled if there is a drop-down menu next to the
userPassword text entry box that allows you to pick a hash.

I had to add libsasl2-dev and libssl-dev to the build-deps in order to
enable the userPassword hash functionality and the ability to do a SASL
bind.

I've asked the orginal bug reporter to do some testing on the
userPassword hash functions and update the ubuntu bug report if gq
performs the hashes correctly.

At a minimum I think it makes sense to add libssl-dev to the build-deps
and update the copyright file.  I can say that GSSAPI SASL binds work,
but I don't have the capability to check other types of SASL binds right
now.  It probably is best to leave that feature disabled.  Maybe we
could add to the README.Debian that SASL is untested and how to enable
it by building a local package?

Ben

-- 
Benjamin Montgomery
bmontgom at montynet.org