Deploying OpenLDAP

Dustin Puryear writes "I work extensively with LDAP as a consultant, and so I'm always reading the latest and greatest books and articles on the subject. It's just part of the business. So I was excited to see "Deploying OpenLDAP," by Tom Jackiewics and published by Apress, on Amazon's electronic bookshelf. After reviewing the Table of Contents I quickly ordered the book. This looked good. After all, Jackiewicz had some great chapter titles such as 'Implementing Deployment, Operations, and Administration Strategies.' That just sounds smart. Before giving you my feelings on the book, let me first say that I'm already well experienced with LDAP. This is especially true with OpenLDAP. With a title like "Deploying OpenLDAP" I was expecting a book that tackled not just low-level tactical issues such as installing OpenLDAP binaries, but strategic ones as well, e.g., how to design access control. So if you have never used OpenLDAP then your experience with the book may differ." Read on for the rest of Puryear's review.

Deploying OpenLDAP
author	Tom Jackiewicz
pages	344
publisher	Apress
rating	5
reviewer	Dustin Puryear
ISBN	1590594134
summary	HOWTO for installing and using OpenLDAP.

The book begins with a quick note that the target audience is those wishing to install and configure OpenLDAP, and not those that wish to delve into the intricacies of LDAP architecture. Unfortunately, Jackiewics delivers on this promise. While I didn't expect the book to provide me with a guide on enterprise-level LDAP deployment, I had hoped to see more focus placed on design, but that wasn't forthcoming.

The first chapter, "Accessing Your Environment," is a moderately good review of how to identify key elements of your company that are appropriate for inclusion in a directory service. In addition, Jackiewics makes a clear case that an LDAP directory is not a relational database -- so don't try to replace Oracle with OpenLDAP. A very good point.

Chapter 2, "Understanding Data Definitions," provides background information on how schemas are defined. Basically, a schema is just the types of object classes and attributes that your directory supports. Jackiewics actually does a good job covering customized schemas, which is a troublesome area for new OpenLDAP administrators.

It was in Chapter 3, "Implementing Deployment, Operations, and Administration Strategies," that I was hoping to get some real nuggets of information. Alas, that wasn't forthcoming. The chapter should be renamed to "Where to put your OpenLDAP server on the network, and what to name the server." There are some areas of this chapter that really disappointed me. The most culpable: Jackiewics spends almost four pages explaining how to come up with a good hostname for your server, and then a brief page on understanding OpenLDAP's log file, and that brief page mostly contains example output. This chapter is also a good example of a bad book layout -- why are we reading about hostname conventions in the same chapter that discusses debug output?

Chapter 4, "Installing OpenLDAP," is a decent HOWTO for installing OpenLDAP. It also provides several manpages in case you accidentally deleted the 'man' command on your own system.

Chapter 5, "Implementing OpenLDAP," is kind of the "catch all" chapter. Jackiewics discusses how to decide on hardware, but his examples aren't very clear. One of the real gems of the book is his discussion on SASL and OpenLDAP. In addition, there is a reasonable discussion of replication between OpenLDAP servers. Alas, there is almost no troubleshooting on replication, and replication does hiccup at times. (Indeed, this book contains essentially no help in troubleshooting any problems.) Another sore point: Jackiewics only provides a single paragraph on access control (i.e., OpenLDAP ACLs). That topic alone deserves its own chapter.

Because Jackiewics had specifically stated that this book's scope was quite narrow I would typically be more lenient. However, Chapter 6, "Scripting and Programming LDAP," consumes sixty pages that are immediately outside the book's scope. I would prefer to see this chapter removed entirely, and the sixty pages devoted to a chapter on troubleshooting OpenLDAP and deciphering slapd's debug log file, and perhaps another chapter on designing a scalable replication infrastructure using OpenLDAP. Unfortunately, what we get is essentially sixty pages of manpages and documentation labeled as "Scripting and Programming LDAP."

Jackiewics closes the book with Chapter 7, "Integrating at the System Level," and Chapter 8, "Integrating OpenLDAP with Applications, User Systems, and Client Tools."

Chapter 7 discusses how to replace "old technology," such as NIS and Sendmail alias files, with LDAP. Not a bad chapter, although Jackiewics continues to delve too far into man-page material. Chapter 8 provides examples of using LDAP in Apache, Pine, Samba, and various other types of clients.

Overall, I would say that I left this book with little new information. People that are just now installing OpenLDAP may find the book beneficial, but I really didn't see any material that stood out. My personal belief is that this "Deploying OpenLDAP" needs to provide far more troubleshooting and example deployment scenarios and less regurgitation of manpages and HOWTOs.

---

You can purchase Deploying OpenLDAP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Can somebody answer this

[Anonymous Coward]

Whenever I've looked into LDAP, all the tutorials seem to revolve around organising things into geographical locations. This just seems backward to me, and I can't believe for a second that this is how you are meant to use LDAP. Is this really the case, and if not, can anybody suggest some good learning material that doesn't set things up this way?

Access Control

[Anonymous Coward]

strategic ones as well, e.g., how to design access control.

Are there any books on this? I have no problem setting up OpenLDAP (the docs are pretty clear) but am not in a position to use it in anger because I don't have the benefit of learning from other peoples high level mistakes. Access Control is the biggest question mark for me.

Thanks for the Review. Any recomendations?

[Confessed Geek]

Thanks for the frank review!

Sounds like the book could be replaced with a few google searches.

Do you have any recomendations for a Good dead tree on OpenLDAP? I'm getting ready to do a small installation and would be very interested in intermediate reference work/howto/security and trouble shooting book

Sounds like a new book is in order.

[JLavezzo]

Judging by the reviewer's comments it sounds like he's in a position to make a better book! And judging by the comments on this article, sounds like it's needed.

Go for it!

Re:Thanks for the Review. Any recomendations?

[werdnab]

I've been maintaing a OLDAP installation for the past two years. I say maintaining because after I installed it, I haven't done any new development. You're in for a real trip. There isn't any Good lit on LDAP. It's mostly trial and error, and if you're lucky enough to figure out your error, you'll have more trial to fix it. One doesn't have to wonder why LDAP isn't more ubiquitous.

It could be replaced by ohh... a card cataloge.

Re:Can somebody answer this

[FreeLinux]

Most of the large deployments (at least in the millions of users) I have seen do this. Once you have the suffix named, then it is often best to just leave it relatively flat below that (e.g., all users below "ou=People,dc=example,dc=com") and use attributes within the entries to provide logical arrangements of users.

Just how many LDAP deployments of millions of users have you seen? That were flat no less?

I've seen hundreds of implementations. Most of the ones I've seen had thousands or hundreds of thousands of objects in them and one had over a million objects. I have not seen any implementation, with more than a couple of hundred objects, that was flat.

The thought of a flat tree with millions of objects sounds like a replication nightmare!

Re:On a related note...

[Anonymous Coward]

Well, OSX has a directory services plugin called LDAPv3. It has preset mappings for Open Directory (which is really OpenLDAP with Apples client management/policy schemas loaded into it), Active Directory (for direct LDAP access), RFC2307, and custom. In custom, you can manually map all LDAP records on the client to suit your needs. You could map all the attributes manually, but if you are setting it up yourself, you should at least start with 2307. It defines a set of attributes that are commonly needed across most *NIX systems such as "uid", "gid", "NFSHomeDirectory", "loginshell", etc...

As for the server side, you are correct. Mac OS X server integrates OpenLDAP, MIT KDC, and SASL (password server) together and slaps a pretty decent UI on them. The advantage of this is not only that you get the Apple UI, but that Apple tests all three software projects and makes sure the versions jive well with eachother, and then releases the relevant security patches for them. For a lot of people, this is worth more than the money they would save integrating, updating, and fixing the software on their own.

The tools themselves provide a "unified" view of the three services. For example, when you create a user in their "Workgroup Manager" tool, it creates and manages the user record in LDAP, the principal in the KDC, and also the password in the SASL password service. This solves a lot of syncronization headaches as you don't have to write scripts and such to keep these three components in sync.

examples of when I should use OpenLDAP?

[Squeezer]

I have a vague understanding of what OpenLDAP is. I have a network with 150 users using central samba server as a primary domain controller. what benefits would I have with openldap that I don't have now?