Wednesday, April 11, 2012

OpenLDAP Installation and Setup

  1. Never trust the IT person who waves their hand dismissively and tells you that installing/configuring anything is "easy"
  2. Even if you're a stone-cold Windows admin, there is a lot to be gained from learning to install/configure something in Linux (shell, not GUI)
I'll discuss both bullets in relation to OpenLDAP, with the understanding that this applies to just about all software/applications and protocols. I'm talking DNS, FTP, Joomla, whatever. 
So, the second point first (I'm contrary that way). I was a Windows Admin first and foremost for a good portion of my career. I cut my server teeth on Windows and naturally that means, in a corporate environment, that I did a fair amount of work in Active Directory. Active Directory is a directory service. It uses LDAP at its core. In creating and deploying a Windows domain, you use the features of LDAP. In order to control Exchange features for a user by utilizing the ADUC console, for example, you have to first add the Exchange schema to it. You come across these terms (schema, object, attribute) and you use the tools, but do you really understand what Active Directory is, or how it works under the hood? Or is it enough in most cases to simply know the high-level stuff, like site/topology replication, or even just how to add a new user/group/email account? I understood Active Directory, but I didn't understand LDAP. 

Well, I embarked on a journey at my current job to deploy OpenLDAP, the open-source implementation of LDAP, in our colo. I saw the benefits as two-fold:
  1. Efficiency. As we grow our hosting platform and add more servers, it becomes harder to remember to add the necessary users to the servers via /etc/shadow. Similarly, should we lose team members it's a pain to go through each of those servers and manually remove that person. Yeah, I could write a script that runs deluser on each server and removes their home directory, but there are easier ways to do this. 
  2. Security. I can implement password-aging and complexity policies. 
This brings me to my first point. Yes, in many cases there are applications that can simply be installed and are ready to go out of the box. Apache, for example, is one that is touted as something you can have installed and going in 15 minutes. MySQL is another. Good ol' apt-get install or yum install do the trick very nicely in many cases. Yep, if you intend to host these things on a machine in your house that only you and your family will access, this will be just fine. It's when you get into configuring these things for real world use that you start to realize that the folks telling you how easy it is to do are either typical show-boating admins who say that about everything; have done it so many times they've become cavalier about it; or haven't done it in so long that they've forgotten the complexities that can appear. I don't tend to often run into the admin who says, "You know, the initial installation can be easy but it's the finer-grained tuning that will be time-consuming and potentially confusing." 

I used a ton of resources to get under the OpenLDAP hood. In no particular order:

Absolutely, installing OpenLDAP was as easy as the instructions at Server World. I followed them on my test box and had an installation up and going in no time. The problem was, I didn't actually understand what it was I had done, and immediately ran into trouble when I wanted to do something not covered in this guide. I wanted to implement a password policy, which according to documentation meant using password-policy overlay. This wasn't mentioned anywhere in the guide. Even though the directions for creating a new user included attributes for a password, it didn't actually talk about them at all. The Ubuntu guide did the same thing but added additional information on how to extract information from the directory, along with more complex topics like replication, TLS, and ACLs. 

I don't know about you, but I'm not comfortable deploying something in a production environment if I don't actually understand what it does and how it works. In other words, if it breaks I want to have a headstart on understanding how to fix it. In the case of OpenLDAP, with the two sites I just discussed, I had a working implementation, but I didn't know how it was working. For example, I started looking into how to add password policies to my users. I wanted to learn more about this ppolicy overlay thing. I researched, I Googled. I got a good start on things. Zytrax told me to add the ppolicy schema. told me how to add a schema. 

Then I hit a wall. I stared open-mouthed at my screen as site after site told me how to edit slapd.conf to complete the setup. I didn't have a slapd.conf file. Why didn't I have a slapd.conf file? I finally found out that OpenLDAP had two ways of working. One was the old way, which used slapd.conf. The other was the new way, which used a dynamic backend in the form of the cn=config DIT. The what now? What's a DIT? What's cn=config? And how do I do this then using the new way?

Oh boy. Can you see the rabbit hole? 

Long story short (a little too late for that I guess), I never figured out how to add ppolicy using the dynamic backend, and I was not about to go backwards and convert it to using slapd.conf. I threw myself into trying to understand how OpenLDAP worked. I can't recommend Zytrax highly enough. Their site was informative and fun to read. and were also instrumental in helping me get to the bottom of my queries. Here's some of what I learned: 
  • No one (not even the OpenLDAP official site) talks about how to actually use the dynamic backend configuration as far as I can tell. Everything uses slapd.conf. 
  • cn=config is the root of the slapd directory information tree. It contains global configuration information including the installed schemas. There's also confusion around the setup of this naming context, which makes things additionally confusing.
    • Apparently on older versions of Ubuntu, running the ldap install actually prompted you to create an admin password for the cn=config naming context. Newer versions of the OS (10.04 LTS and above I believe) don't prompt you for one, essentially leaving it open for anonymous queries. 
    • Guides for setting up OpenLDAP that are not Ubuntu-specific walk you through creating an admin user for cn=config. You have to do this in order to use GUI tools like Apache Directory Studio. Say what you will about point and click, but once you've done yourself a favor and learned how OpenLDAP really works, ditch the command line and use the GUI. Much less error-prone. 
  • Passwords are stored in cleartext unless you specify a hashing mechanism. I used SSHA to copy the hashed values into my files. 
  • During the libnss-ldap setup for client machines, whether or not you use ldap:// or ldapi:// to identify your ldap server matters a lot. Using ldapi:// the uri field was uncommented out in ldap.conf, resulting in OpenLDAP not working. Commenting this back out and using the host directive worked, which only happens if you either do it manually or use ldap://. 
  • I'm not sure if this was due to the fact that I was following instructions for Ubuntu 11.04 on a 10.04 machine, but sudo pam-auth-update did nothing to my pam.d files. Manually editing them according to the Server World guide was the only thing that worked. 
  • Even though the password attributes were included in user account creation examples for most guides, no one explained them. At all. I grepped the schema files to figure out what objectClass they belonged to, and then went searching for details on that one (it's the shadowAccount objectClass if you're interested, btw). I finally found a nice, comprehensive guide here
I'm about at the end of this journey. I've added most of my colo servers to our OpenLDAP setup. I'll finish the last of them today. The process of learning OpenLDAP was humbling, and what was supposed to be a fairly easy implementation took much longer than I'd anticipated. In the end, I'm not sure that the time spent on it was worth the outcome, but I have to think that one day, when we're 50 servers instead of 13, this will have proven worthwhile. 

No comments:

Post a Comment