RE: LDAP Auth and users changing their passwords

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Terrence Martin

> Ok but is this at all secure? To me this is looking a lot
> like putting a
> root password in a file and crossing my fingers no one will read it.

True.

> Don't credentials placed in the /etc/ldap.conf file that are used to
> bind to the directory essentially open up the directory for arbitrary
> writing/reading by anyone with root on the client?

They open up the directory to whatever operations you permit those
credentials to perform. Generally, you would assign very specific read-only
privileges to such an identity.

> While this
> might be
> suitable on tightly controlled client I would like to have
> lab machines
> and even systems that have shared root access to use the ldap
> server for
> authentication. There has to be another way that does not
> place so much
> trust in clients.

I prefer having pam_ldap perform a SASL bind on behalf of the user. This
places zero trust on the clients, as well as minimal administrative overhead.
Unfortunately this imposes some password synchronization issues if you're
also using nss_ldap. (Systems that use NSS to retrieve and evaluate a user's
password pretty much expect it to be in Unix crypt(3) format. SASL requires a
plaintext password.) Clearly some improvement needs to be made in
streamlining all of this.

> The Oreilly ldap book has an example of an ACL that will
> allow users to
> change the userPassword attribute only if they authenticate.
>
> access to *
>     by * read
>
> access to attrs=userPassword
>     by self write
>     by * auth
>
> Unfortunately the book is kinda vague on how exactly the user
> is getting
> authenticated to the directory and how the bind is occuring.

Also unfortunately, the book is wrong. The ACLs are processed in the order
they're listed, so the "access to * by * read" directive overshadows the
subsequent directive. This example would be more secure if the order of the
two clauses was reversed.

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