[KLUG Members] LDAP and passwords

Adam Williams members@kalamazoolinux.org
Sat, 30 Aug 2003 07:38:05 -0400


> Hey, Adam, I have a question. I'm setting up a test LDAP here at home,
> and I have a number of questions:
> 1. Aside from defining the 'TLSCert...' entries to point to my
>    self-signed x509 cert, and defining 'URI ldap:/// ldaps:///', how do
>    I turn on ldaps?

Nothing, that I recall.  Is the server listening on port 689?

> 2. Your presentation PDF mentions using sasldb. Is that somehow
>    necessary to using LDAP/SASL/Kerberos?

No, sasldb is used for CRAM-MD5, it is not used for Kerberos.

> 3. I have a number of future password needs. I'd like to support Unix
>    hash, SMTP AUTH (probably using HMDA (DIGEST MD5)) and Samba NT
>    passwords. How do I store these passwords? Is it safe to store the 
>    plaintext in userPassword,

Actually yes, and it is pretty common.  Simply define a rule making it
available on for "compare" but never "read".

>  or do I need to store each hash (Unix/NT)  separately? 

Nope, and the libraries handle the hash type automatically.  So, so long
as you use a support type (how would you use an unsupported type?
hmmm...) you should be OK.

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} 

> I see RFC 2307 says that LDAPv3 may do things
>    differently. Also, I note your presentation doesn't use the
>    '{crypt}X5/bLHDu7sJM73h21' format under the user examples.

Hm.  What slide uses something else?  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).