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.

Comments

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?

Re:Can somebody answer this

[FreeLinux]

Geographic division of the LDAP tree is very common and works best for most situations but it is not a requirement. Depending on your environment you may prefer to divide the tree by department(political) or by function, or any other way you can think of. What usually makes the decision for you is your business process and network operation/replication.

There are many books available that cover this topic. From this review, I would skip this particular book.

Re:Can somebody answer this

[Anonymous Coward]

This is really a carryover from the now largely-obsolete X.500 days. In most cases, a geographical based setup (or in fact, breaking up the DIT at all) is not the best practice. RFC 2247 recommends using domain components based on your DNS domain (so if your domain is example.com, then you could use dc=example,dc=com). 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.

Note, however, that some directory servers do not perform well or scale very well to larger systems, and therefore they often recommend that you break up the DIT so you can spread it across multiple systems in order to handle the necessary load. If you're in a situation where this might be necessary, then perhaps it's a better idea to look at a directory that can scale.

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:Can somebody answer this

[B'Trey]

I'll probably get crucified for this, but the Microsoft Press books on Active Directory actually get this right. It's specificially focused on Active Directory, of course, but there's a lot of it that is applicable to any form of LDAP. MS recommends that you configure your sites (essentially, units of replication) based upon geography and you configure your LDAP based upon the IT organization. Factors to take into account include administration responsibilities and security concerns. Sometimes, this coincides with geography. If you have local admins at each location, it might make sense to put users and computers at each location in a seperate OU. You can then delegate full admin control of the OU to the admins at that location. On the other hand, in a different structure it might make sense to divide your OUs up by departments, with, for example, everybody in Sales in one OU, regardless of which location they work.

Re:Can somebody answer this

[rihock]

Flat actually works better for replication. I've done designs that have 2mm, 8mm and 10mm users. When you get to that level, flat is best, and small numbers of attributes is highly recommended. On the 2mm, the tree was c=US, dc=company,dc=net. Below that was ou=people, ou=companies, ou=divisons. Under ou=people were all 2mm users. They had 22 attributes attached. The replication was from one master to 2 rep hubs to 8 consumers. It served as the basis for a portal. Worked like a charm.

Yes, this was on real LDAP- SUN and Netscape.

The 10 million was for a very large ISP (as was the 8 million). They had similiar setups-- ou=isp, ou=people, ou=companies, ou=administrators. Again, worked great.

One mistake people make in LDAP is to make it look like an organization chart-- big mistake. Use your attributes to create context and you'll be fine. Just keep your entry small.

Again, not a replication nightmare at all, its actually the opposite that's true-- the more complex the tree, the harder replication is to complete and index properly.

Chapter title based review

[Timesprout]

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

What a surprise. I would have expected each of these substantial areas to have their own individual chapters on strategy.

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.

Disgustingly Bad Book

[njcajun]

I love the publisher, but I HATE this book. This book covers nothing new, and covers what has been covered ad nauseum poorly, and in such a way as to do a disservice to the reader. The book makes assertions that are completely incorrect, misleading, false, and many other very negative words. For just one highly simplistic example: Tom, LDAP is NOT a database. Gerald Carter's "LDAP System Administration" is a better intro to OpenLDAP, though not a great primer on higher-level LDAP concepts. For that, you need "Understanding and Deploying LDAP Directories": the bible of LDAP. Novell keeps lots of good docs on LDAP lying around, and if you need more on OpenLDAP, there are also some docs on my website. I REPEAT: STAY AWAY FROM THIS "book".

Re:Disgustingly Bad Book

[bananasfalklands]

Are there any decent books on ldap ? (amazon say no decent books either)

My problems with ldap:
1. Why do you have to buy a 'commercial' product (no not MS - but say IBM (domino),Novell (nds))
2. or Enterprise Linux?

Please do not get me wrong
1. Writing ldif files is easy
2. Ldap (i assume is easy) but only if you have done it before

Openldap still appears to be a 'priesthood' occult.

Re:Disgustingly Bad Book

[Penis_Envy]

Reasons for problem #1:

1a.) Multi-master replication. Something very handy to have when you're looking at high-availability environments.

1b.) Speed. OpenLDAP can be tuned quite nicely, but doesn't match the performance of the commercial app's. If someone has anything contrary to this, I'd love to hear it.

1c.) Supportability. Having a vendor to yell at when it all falls down in pieces is rather handy.

I am waiting with baited breath for Redhat's release of the Netscape Directory server 6 code. That would solve these three problems. For smaller or simpler applications, openldap does wonderfully. It's not until you hit the higher end that you start "needing" the commercial app's.

I'm not sure what you meant by "or Enterprise Linux"... Are you referring to the frequent requirement of the commercial apps that you be using the enterprise distributions? If that's what you're referring to, it's probably because those distributions are rather stable targets for support, having a much slower development and release cycle.

Re:Disgustingly Bad Book

[tjackiewicz]

There are various improvements that could be made to this book and I appreciate some of the comments that are being made. As a whole, I think that I did a good job with the theory buy could do better in expanding some of the sections and removing areas percieved as filler. In the programming section, which was put together with significant help from Lane Davis, who was responsible for the C section, we could expand into some realistic do's and don'ts and more commentary on the code itself. On reshashing man pages, various parameters were explained and then used in subsequent sections. Additional commentary was given to explain their meaning. But I see how it doesn't give the best first impression in that's what someone flipped to first. Regardless, it's nice when reading them in the restroom away from a terminal ;) They didn't take up a significant portion of any of the sections. For any errors, I think the point got across and I still think there the bulk of the book is a useful guide.

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

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:Thanks for the Review. Any recomendations?

[chronicon]

Samba-3 By Example has some useful information on implementing LDAP. Available in dead tree and .pdf format.

Also, The Samba/LDAP How-To using Samba v. 3 by David Trask may be helpful to you as well.

Finally, while I have not reviewed this one it sounds like what you are searching for: LDAP System Administration from O'Reilly.

Happy authenticating!

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:You can spot trolling ACs...

[nightcrawler77]

So I am to assume you would spell out common IT acronyms like Transmission Control Protocol/Internet Protocol? Or Hypertext Transfer Protocol?

I hope you never write an article about a piece of GNU software. Better start expanding that one now.

ldapsh

[oneiros27]

I'd highly recommend that anyone who has to administer LDAP (that's Lightweight Directory Access Protocol, for those who don't use it. [aka NetInfo Services for the mac, or Active Directory for windows]), especially if it's on systems that have tight ACIs for admin rights to look into ldapsh, which lets you walk the tree using cd, and use vi to edit records.

Re:ldapsh

[TheGuapo]

Or for a graphical interface, try the ldapbrowser. http://www-unix.mcs.anl.gov/~gawor/ldap/

Re:Thank you!

[jedidiah]

nis++

Missed opportunity

[iksrazal_br]

Too bad about the book, I'm in the market. I've used OpenLDAP for the last 1 1/2 years as a programmer and administrator. I struggled alot and google only helped so far. What I would like to see is an OpenLDAP book that:

1) Has a good explanation of how to implement InetOrgPerson, including userCertificate;binary and digital certificates.

2) Explains ACL's in depth, particular to OpenLDAP.

3) Cover some of the schemas, such as java.schema for storing serialized java objects like Strings and HashMaps. I never did get a Java X509CertStore to work.

4) Tuning and performance.

5) How to migrate a DB with a basic USER table to OpenLDAP, and the advantages/disadvantages for doing so.

6) Explain SSL and kerbosos authentication.

I'd buy a book that explained half of that.

iksrazal

Microsoft Won

[LordMyren]

I really think the absolute VOID of good practical LDAP books is why microsoft is winning.

If ldap had any documentation for how it would be used, there would be stunning amazing products to pound the living tar out of Active Directory. Unfortunately for free software and whatever author-should-be that never decided to get rich, no one has stepped up to the plate.

There is no more pressing need. Period. At all. Directory services are absolutely vital to absolutely everyone.

I've been pissed off over this for years. I got the whole LDAP+Kerberos+PAM+every service known to man thing working but could not for the life of me figure out how to build an ldap infrastructure to manage it. Albiet I was so tired of the whole project by the time I got there I didnt have much patience (and all too many other projects).

Basically RedHat and Novell exist based on making people pay for their proprietary directory services. I realize cutting them out could be concieved of as a bad thing, but I'm sure they can adapt. On the other hand, Microsoft will finally have gained a sincere challenger.

Myren

Re:Microsoft Won

[LordMyren]

This is so back-asswards its almost funny.
First off, and FYI, AD is LDAP+Kerberos. "It has nothing to do with LDAP in general"

MS domination of the desktop is because of services like Active Directory, not the other way around. Windows would be nowhere if evolution ended at shared folders. You yourself state "In order to have a well managed windows based network you need AD," which is exactly my point. To have a well managed network you need directory services. No directory services, no prayer, no desktop domination.

Which brings me back to my point; its a joke to think of people trying to promote Linux to buisness or consumers when there's no directory services and no docs for how design them should you be dumb enough to try building them yourself. There's docs for how to build them (as in, ./configure, make, make install + some conf file help), but no good books for some of the most important subjects in the world: how to architect a solution with these tools. I've found nothing good which takes you from there "here's LDAP" stage to the building scalable enterpise ldap solutions stage.

Myren

Re:Microsoft Won

[ookaze]

I strongly disagree with you on some points.
I've done a study for the company I work for now, to help make a choice between directory services (Free Software/Open Source, Novell OES, Microsoft AD). I have also implemented the OpenLDAP/Kerberos/PAM/... platform in the past.
I saw the problems. You are right with the fact that nowadays, there is still a lack of administrative tools. That is the only lack, though a big one.
Vendors like Red Hat are taking care of that right now, they will have a solution soon, and Novell already has one.

With the rest I disagree. Saying that AD is LDAP+Kerberos is misleading at best. Yes it is based on these, but these it is not. It is not even LDAPv3 compliant, try switching the directory for a LDAPv3 compliant one (actually you can't). Their Kerberos implementation is not standard either, you can not mix.
I would say that without MS domination of the desktop, AD would not even have been possible. I say that because of the administration tools. With an Open solution, if you have only Linux desktops, you have 80 % of your admin tools centralized (perhaps even 90 %), but when you start putting Windows desktops, the admin tools plummet to 40 %, and you need a LOT of development to bring the level of centralized admin tools to 100 %. You need tools to manage rights delegation, centralised filesystem rights tuning for users, centralised printers administration, ...
And when you provide directory services, you MUST be able to cope with every client. The sole exception is Microsoft. Microsoft AD virtually only support Windows desktops, and they can get away with it, because of their monopoly. Because if you try to admin Linux desktops with AD, you are toast, AD is far worse than anything else on this.

As for the docs on enterprise scale ldap solution, I agree there is no dedicated book to build one, but that is because of the Windows desktops monopoly. Knowing that, you think Samba, and look in the Samba books (on their site), you will find such deployments help, with hints (but not solutions) on how to administer such a deployment. See the problem ? Samba is essential because of the Windows desktops.

To end this post, not every company need directory services, it is very specialized and need professional admins to build, and maintain the solution. I've not even started on meta directory services (but I do not know what MMS can do, so I will not be objective).

In reality

[hellfire_23]

In reality this book is meant to be for LDAP beginners and Tom does make that clear. I believe the book was actually originally written as a college text which further strengthens the point is geared for a beginner. Having a actual paperback book on man pages and scripting examples is probably one of the most lacking pieces of documentation around for LDAP. The only good docs I've found on Net::LDAP and even the php libraries are only the authors api docs. The truth is you need scripting examples to get good at managing LDAP.

Another excellent free book

[shancock]

MS has for free downloading their wonderful book on LDAP: Windows_Security_and_Directory_Services_for_UNIX.z ip
(a large pdf file inside the zip)
Search for the title on MS Downloads site. This is a very good book that covers the Unix side of LDAP as well as it does their AD implementation of LDAP.

This is one area that MS got right. They started with open standards and then enhanced it for their servers, while keeping full access to Unix servers. I have no problem with this. We want LDAP mostly so we can interoperate with window servers. Without this crucial piece we would not be able to get Linux servers in the door of most of our clients.

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?