I have working LDAP + SSH solution, but I would like to ask, why do I have to have the ldap root password stored in libnss_ldap.secret and pam_ldap.secret? It seems to be unsecure, someone can hack one ldap client machine a has the password to whole ldap?

How can I avoid this, is the ldap admin pass really needed for authenticating the users?

Thank you, Martin


As sysadmin1138 says, you do need read access to the LDAP database. You can achive this by adding a special ldap user with read access to every attributes (except userPassword).

dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: <some sha1 hash> 

And then in the access control file (assuming OpenLDAP here):

access to *
        by dn.regex="cn=admin,dc=example,dc=com" read
        by * read

You could also give read access to anonymous users (only restricting userPassword). Then you want need a special admin user you can just drop libnss_ldap.secret and pam_ldap.secret. This works equally well, and the uid and gecos fields of your user database is rearly all that secret anyway. This is what I usually do. You might want to set size limits and restrict access to the mail attribute to authenticated users:

sizelimit 100
timelimit 60

access to attrs=userPassword
        by anonymous auth
        by * none

access to attrs=mail
    by self read
    by users read
    by * none

access to *
        by * read

Hope that helps!


IIRC, the user and password that has to be stored there is the one that can read all of the appropriate LDAP attributes. It just so happens that LDAP-root can read them all. If time is taken to create a user in the LDAP structure that has the ability to read the correct attributes, but not write them, it will allow a less privileged account to be stored in those files. I believe this is best-practice anyway.

  • +1 putting the root password in the pam_ladp.secret file is like giving all your users the root password to login to their workstations; it gets things working, but it's not a good idea in the least. – Chris S Sep 22 '10 at 16:09
  • So do I have to create some another user with read privileges and store this user/pass on client machines ? – John Sep 22 '10 at 16:15
  • 1
    @mejmo In the AD directory, you do need to create a new user with the ability to read the right attributes. You then store THAT user on the client machines. – sysadmin1138 Sep 22 '10 at 18:44

The only way to avoid this is using kerberos with ldap. Do not use ldap for authentication, but kerberos.

If you have a redhat based linux, you can try freeipa. Their version 2 is nearly done and it shows a lot of promise (I have tested it in a lab and it is really easy to set up, maintain and expand). As soon as version 2 is out as production I intend to use it everywhere I can ;-)

If you do not use a red hat based linux, then a world of pain is in front of you to get this working. It is possible, but not for the faint of heart. I have found that these howtos regarding this stuff work quite well: rj systems howtos, skip the non kerberos/ldap stuff. Ubuntu has a community document (those two words do not inspire a lot of confidence to me) to set up this stuff: ubuntu openldap/kerberos.

Thankfully with freeipa, if you do not have any windows servers, we will have a decent AD equivalent for linux/unix.

  • Is the LDAP authentication transfered in clear text ? Because I dumped some packets right now, and there is authenciation simple : <some string of chars and digits> . So this is clear text in fact ? – John Sep 24 '10 at 13:57
  • And what installation is worse pain in the ass? OpenLDAP + SSL or OpenLDAP + Kerberos. – John Sep 24 '10 at 14:02
  • you could start sniffing with dsniff monkey.org/~dugsong/dsniff to see if you actually get the credentials. If you use tls/ssl, it will not work – natxo asenjo Sep 24 '10 at 14:04
  • 1
    it depends on how much you know about kerberos. If you already have openldap for authentication and account info, adding ssl should be easier than going the kerberos route. However, once you set the kerberos realm, you have truly single sign on to your kerberized environment. You can login your kerberos realm and from there login the rest of your servers without having to enter your password again. – natxo asenjo Sep 24 '10 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.