/etc/ldap.secret : hack one client and own the whole directory?

[barbapapa <barbapapa@myrealbox.com>]

hi all,
i have to install a centralized password server for lots of client
machines and
had my first look at openldap. However, there's a point in the tutorial
i read
(link and excerpt pasted below) that makes me shiver: it basically says
that i
have to have a /etc/ldap.secret file on every client machine, containing
the
full text password of the user listed as rootbinddn in /etc/ldap.conf.

that tutorial admits the consequences this has on the security of the
repository:
any user gaining read access to /etc/ldap.conf can
a) access to ALL password md5sums of the whole directory (of all users)
  and since most users use weak passwords, john the ripper does the rest.
b) modify all passwords if i set it up to allow users to change their
password with
  the passwd command in the first place

Since it would be all too easy to gain read access to the client's local
/etc/ldap.secret ( just take the hdd out and hook it to a computer of
your own ),
i suppose there must be a more secure way to configure a password server
with
openldap, but how? from what i see, any solution with a local
/etc/ldap.secret on
the client machines is insecure.

I've understood that many people use openldap together with kerberos. Is
this the
solution to avoid the problem mentioned above? If so, is there an easy
tutorial for
setting up a combined krb/openldap (linux)? if not, what is the kerberos
good for
in combination with openldap?

regards,
  barbapapa

references:
the url of the tutorial mentioned above is:
  http://www.mandrakesecure.net/en/docs/ldap-auth.php
and here's an excerpt of the part where it explains the problem:
--------------------------------------------------------------

You now have to make a serious decision. The fact that /ldap.secret/ is
a cleartext password in order to read the userPassword is not ideal.
However, providing read-only access to userPassword minimizes the impact
(somewhat). This means that anyone who has access to read the
/ldap.secret/ file will be able to obtain every user's userPassword
attribute. Since the file should only be accessible to root, this is no
different than root having access to //etc/shadow/; the end result is
the same: either way, a person who has root access has access to the
user's encrypted passwords.

The drawback to having the proxy user only have read access is that the
*passwd* tool will not work as it should. User's will be unable to use
passwd to change their own passwords. If the proxy user has *write*
access, then the passwd tool will work (provided PAM is correctly
configured, which we will see in a moment). So if you choose to give the
proxy user write access, you simple need to change the "read" to "write"
in /slapd.access.conf/. The problem with this is that while a person
with root access on a client machine (note that they do not have to have
root access on the LDAP server, it is sufficient that they have root
access on their own client machine), and is able to view /ldap.secret/
will likewise be able to change any user's password. You may not want
this! For this reason, our example ACL for the proxy user has read
access and not write access.

--------------------------------------------------------------