[Date Prev][Date Next]
Re: /etc/ldap.secret : hack one client and own the whole directory?
"pam_krb5 + nss_ldap + openldap + openssl + sasl"
could be a good solution ... I set it up partially (nss_ldap still missing) using
for a large part the tuorial of Turbo Fredriksson at http://www.bayour.com/LDAPv3-HOWTO.html
I use Active Directory as Kerberos 5 but please do not comment on that :-)
----- Original Message -----
From: "barbapapa" <email@example.com>
Sent: Friday, July 18, 2003 8:09 PM
Subject: /etc/ldap.secret : hack one client and own the whole directory?
> 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
> 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
> 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
> 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?
> the url of the tutorial mentioned above is:
> 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.