Well, not really, but I bet I got your attention.

Having just gone through two days of pain involved in getting OpenLDAP to work in place of /etc/passwd, I have such a set of troubleshooting tips unlike anything I’ve experienced before.   I am going to write these down as quickly as I can, before the horrifying experience is mercifully driven from my mind.

Note that this was using RHEL 6.0 and yum

• Recent (as in 2012, perhaps 2011) versions of OpenLdap use a different config structure than the older version.  Dramatically different.   Many of the examples I found on the ‘net are based on the old model, and can be very, very confusing.
• Lots of examples discuss creating your own database of stuff.  But you dont have to do that!  There’s already a database ready and waiting for you in: /etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif
  • Update that DB, instead of creating your own bdb, which is what most of the examples do.
• I had several problems getting syslog to properly capture the OpenLdap logging events.   I had to add an olcLogFile= directive to actually get things to log.
• This was pretty clear, but just for the sake of thoroughness, I had to add a ‘top level’ user who could do most management functions.  This was very helpful with creating users, setting passwords, etc.  I created:
  • olcRootDN: cn=Manager,dc=example,dc=com
  • olcRootPW: {SSHA}Cw888Xm4M77777Zb8Zhut7LLgwHfb3y8b

• • in the bdb database (described above).
    • use slappasswd to generate the {SSHA} password from clear text.
• The examples of rules to set up ACLs so that users can access their own data, and change their own password were woefully unclear.   I kept getting this error in the logs: “RESULT tag=103 err=50 text=” .  That’s because the ACLs weren’t set up right.
• To set up the ACLs so your users can access their own data, and change their own password (but no one else can even see it), here were the magical lines I had to include in: /etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif
  • olcAccess: {0}to attrs=userPassword by self write by anonymous auth by dn.base=”cn=Manager,dc=example,dc=com” write by * none
  • olcAccess: {1}to * by self write by dn.base=”cn=Manager,dc=example,dc=com” write by users read by * none
• I had to install all of the following packages to successfully get ssh to connect to OpenLdap
  • pam_ldap
  • openssh-server
  • openssh-clients
  • openssh-ldap
  • openssh
  • openldap-clients
  • openldap-servers
  • openldap
  • nss-tools
  • nss-sysinit
  • nss
  • nss-util
  • nspr
• I had to modify the following config files:

  • /etc/openldap/ldap.conf

  • /etc/openldap/slapd.d/cn=config.ldif

  • (the aformentioned bdb database, which is where the various users are stored.  more about that later)
  • /etc/pam_ldap.conf
  • /etc/nsswitch.conf
  • /etc/nslcd.conf
  • /etc/sysconfig/authconfig
  • /etc/sysconfig/ldap
  • /etc/ssh/sshd_config
• I used authconfig to enable ldap in PAM.  Wait, that sounds really dirty.
• I had to copy /usr/share/openldap-servers/DB_CONFIG.example into /var/lib/ldap/DB_CONFIG to get the database to stop complaining about not having a configuration
• I had to define the People and Group organizational units, and use them consistently.
• Learn how to use ldapadd to add data to the database.  Clunky, but easier than adding it by hand.

Here’s what I used to create my People and Group organizational units:

dn: dc=example,dc=com

objectclass: dcObject

objectclass: organization

o: example.com

dc: example

dn: ou=People,dc=example,dc=com

objectClass: organizationalUnit

objectClass: top

ou: People

dn: ou=Groups,dc=example,dc=com

objectClass: organizationalUnit

objectClass: top

ou: Groups

After that, I could add users to both the People and Group domains:

Adding a user to People:

dn: uid=jbsw,ou=People,dc=example,dc=com

objectClass: top

objectClass: account

objectClass: posixAccount

objectClass: shadowAccount

cn: John SW

uid: jbsw

uidNumber: 1001

gidNumber: 1001

homeDirectory: /home/jbsw

loginShell: /bin/bash

userPassword: {crypt}x

shadowLastChange: 0

shadowMax: 0

shadowWarning: 0

I took that data, wrote it to a file called user_jbsw.ldif, and then imported it using ldapadd:

ldapadd -x -D "cn=Manager,dc=example,dc=com" -f /etc/openldap/user_jbsw.ldif -W

and to group:

dn: cn=jbsw,ou=Groups,dc=example,dc=com

objectClass: top

objectClass: posixGroup

cn: jbsw

userPassword: {crypt}x

gidNumber: 3001

I wrote that data to a file called group_jbsw.ldif

ldapadd -x -D "cn=Manager,dc=example,dc=com" -f /etc/openldap/group_jbsw.ldif -W

And last but not least, (for that user) I used ldappasswd to change that password to something that ldap and ssh would accept:

ldappasswd -s blarneystone -D "cn=Manager,dc=example,dc=com"  -W -x uid=bsw,ou=People,dc=example,dc=com

Then what happened?

I had everything set up properly – I had pam_ldap.conf pointing to the LDAP server, the LDAP server was running, sshd was configured to use PAM, but I still couldn’t log in.  It kept complaining about unauthorized access (error 49).   Eventually, I realized that I hadn’t installed the nss package(s), which created yet another way to describe how to talk to ldap.

And then all was well?

Well, no, after I figured that out, and got the password working, it demanded a new password.  I tried to enter it, but it wouldn’t accept it, saying I didn’t have the rights to modify the user object in LDAP.  That was when I figured out the ACL issue (already described above).

And then you were done?

Well, no, in the process of monkeying around with /etc/pam.d/system-auth, I inadvertantly set up the ‘change password’ functionaity so it asked for and verified the new password twice.   But that was just a matter of editing.

Anything else?

• modifications to  /etc/ssh/sshd_config require a restart of the sshd daemon
• modifications to /etc/nslcd.conf require a restart of the nslcd daemon
• modifications to openldap config require a restart of slapd
  • I also deleted all the data in /var/lib/ldap/ each time I modified /etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif
• modifications to PAM were instantaneous.

Hope all my pain helps someone, somewhere.