«

»

Sep 29

OpenLdap: History’s greatest monster

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.

 


			
						
						
		

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>