[KLUG Members] LDAP and passwords

[Adam Williams]

> > Nothing, that I recall.  Is the server listening on port 689?
> Hmm... no, and it's not complaining about it at all, aside from not
> being able to open an AF_INET6 port, which is normal. I even started it

What version of OpenLDAP?

> from the command line with '-d 3', and it didn't give any errors about
> not reading the cert/key pair, or not being able to bind to port ldaps.
> My /etc/services gives 389 (working) and 636 (not) as the ldap and ldaps
> ports, respectively.

That is correct (389 & 636)

> > No, sasldb is used for CRAM-MD5, it is not used for Kerberos.
> Now, you see, that is very confusing! 

Yep!  I'm no SASL expert.

> Are you speaking of CRAM-MD5 *and* DIGEST-MD5, or just the former? 

Erm.  Not entirely sure.

> Is there no way to store the information in /etc/sasldb2 in LDAP?

If you do a "ldapsearch -H ldap:///127.0.0.1 -p389 -x -s base -LLL
supportedSASLMechanisms" what do you see?

I have used SASL to achieve GSSAPI,  I have no first hand experience
with CRAM/DIGEST beyond mere diddlin'.

There is a document however that states "CRAM-MD5, DIGEST-MD5
The user presents a digest of his password instead of plaintext. These
mechanisms require storage of the secrets in the SASL database. See the
SASL documentation for details."
http://www.ameritech.net/users/mhwood/ldap-sec-setup.html

However!!! The "10.2.3. DIGEST-MD5" section of
http://www.ayni.com/openldap/doc/admin/sasl.html states: "To use secrets
stored in the LDAP directory, place plaintext passwords in the
userPassword attribute. It will be necessary to add an option to
slapd.conf to make sure that passwords changed through LDAP are stored
in plaintext:
       password-hash   {CLEARTEXT}
Passwords stored in this way can be managed either with ldappasswd or by
simply modifying the userPassword attribute."

Welcome to the wonderful world of LDAP!  Where something is believed by
everyone to be true until those developers with eyes like buring coals
and breast plates of shiney bronze come down from their cubicles and
whack us all upside the head (in the Open Source world, this chain of
events being equivalent to actually releasing some half-way decent
documentation).

> See, I want to allow SMTP AUTH connections from outside the LAN, for
> home users using imaps. Unless I choose to expose Kerberos logins to the
> outside world, or have Exim bind to another port with SSL using PLAIN
> passwords, I need another solution.

Gotcha.

> > But you *DO* need all of userPassword, ntPassword, and lmPassword.  You
> > can't eliminate ntPassword or lmPassword regardless of the hash type -
> > the whole M$ architecure depends on them (actually I'm not sure anything
> > uses lmPassword anymore, but ntPassword is required).  Samba 3.x.x will
> > manage all these values for you,  having three crypts seems scary but
> > really is quite painless.  Just channel all password changes via Samba.
> > ldap passwd sync = { yes | no | only} 
> o how do I get those hashes in there in the first place from an extant
> Samba setup with a new, mostly empty LDAP db?

The "userPassword" attribute is not required.  You can create the
accounts without a userPassword crypt.  Samba authentication will still
work.  Subsequent changing of the password will populate it.

Or you could just crack the lmpassword hash,  I'm told that is pretty
trivial given the correct tool.  But I haven't done that.

> > Hm.  What slide uses something else?
> 10 and 29. Your later slides show it correctly.

I'll take a look at those.

> > The above format is correct, "{crypt type}crypt value".  Note the
> > exception of the special type "{KERBEROS}principle" which passes
> > password authentication off to the KDC (which is transparent to the
> > end application - this allows it to work for non-Kerbized
> > applications).
> Using GSSAPI, right?

Yes.  The only SASL mechanism I've used to any real degree (other than
PLAIN + saslauthd + pam)