Deploying OpenLDAP: Interview with the Author
The Importance of OpenLDAP
OpenLDAP is the directory server of choice if you want a completely free and open source solution to the directory server problem. Tom Jackiewicz is the author of Deploying OpenLDAP, a title that aims to dissolve many of the myths and cover the mechnanics of using OpenLDAP in your organization. I talked to him about his book, his job (managing OpenLDAP servers) and what he does when he isn't working on an LDAP problem.
Could you summarize the main benefits of LDAP as a directory solution?
There are many solutions to every problem. Some solutions are obviously better than others and they are widely used for that reason. LDAP was just one solution for a directory implementation. Some people insist that Sony's BetaMax was a better solution than VHS--unfortunately for them, it just didn't catch on. The main benefit of using LDAP as a directory solution is the same reason people use VHS now. There might be something better out there but people haven't heard of it, therefore it gets no support and defeats the idea of having a centralized directory solution in place. Bigger and better things out there might exist but if they stand alone and don't play well with others, they just don't fit into the overall goals of your environment.
If you deploy any of the LDAP implementations that exist today, you instantly have applications that can tie into your directory with ease. Because of this reason, what used to be a large scale integration project becomes something that can actually be accomplished. I'm way into standards. I guess LDAP was simple enough for everyone to implement and just caught on. If LDAP existed in the same form it does today but another directory solution was more accepted, maybe I'd be making arguments against using LDAP.
But LDAP won--and here's one of the reasons why. Engineers, Programmers, System Administrators, and all the people behind the scenes have problems that they need to solve. Email systems went from single boxes to large infrastructures. Clusters of hosts became the norm. System infrastructures became more complicated and sharing data from many sources was now necessary. Cron jobs synchronizing files wasn't a permanent solution. LDAP enabled everyone to share this information and was the Tylenol to their headache. Obviously this wasn't the sole goal of LDAP, but you need to understand that that directories need data to be useful. The original source of the data that ended up in LDAP was often controlled by these people.
LDAP was designed to crack an exceedingly large nut within organizations with large directories. How does LDAP fit into the small to medium enterprise (SME)?
When I walk into companies that want to deploy LDAP, they usually want it for two reasons. A small company is often short sighted and wants to use LDAP as a phone book. That's it. They just want a web server with an LDAP back end that can be used to pop up extensions. I try to push them in the right direction and say that they should take some time to design a system that can be integrated with other applications. They usually bite.
Others want LDAP for single sign on. That's just a big buzzword with multiple meanings. They look at LDAP and SSO as the same thing and think it will be a magical solution to everything.
I try to convince people to deploy it for some small application, make it known that LDAP now exists in their company, and watch all their departments jump over each other to try to get access to it. There's so much out there that integrates with LDAP at all levels.
How does OpenLDAP operate and integrate within a mixed-platform environment, say with Unix, Mac OS X (which uses OpenLDAP), and Windows?
If done correctly, there won't be a problem. LDAP is LDAP. In the beginning, when control was limited and there was no corporate interest, everything worked well together. It was a given that code written for one LDAP implementation would work against another implementation on a different platform. Rules were simple, well defined, and actually followed--by the programmers on both sides of the equation.
I remember many years ago a friend called me up with an LDAP question. It was on a platform I hadn't worked on running an implementation I didn't even know existed at the time. I told him that I didn't think I could help him with his problem. He pushed. I figured it would only take a few minutes to look at his server and satisfy him that I wasn't the right one to fix his issue. The funny this is, the same bug I ran into in my environment existed in his. Even implementation bugs were shared across the community!
Today things are a bit different. Sun's implementation of LDAP, for example, has class of service, a really nice feature for the automatically populating data based on a template. The products they release that tie into their implementation rely on this feature. Microsoft has their own "improvements" with Active Directory. None of these things are documented standards. It makes it very difficult to integrate systems when every new implementation of LDAP has something new optimizations that tie you to that particular implementation.
You cover in the book the use of LDAP as a storage mechanism for system level data structures, such as passwords, hosts and even the standard mounts kept in fstab. What are the main benefits of using LDAP for this information?
You can store DNS data in LDAP. You don't necessarily have to do it (or want to do it). LDAP is very flexible. I don't see any particular advantage in using LDAP for many of these things today because these types of configurations are usually localized. However, the ability to store these things in LDAP opens you up to a whole world of possibilities for the future. SUN has a vision of a workstation that was completely stateless. With NIS, NFS, and now LDAP, these things are a possibility. Storing configurations outside of a local disk is where the industry is heading. LDAP helps make this possible.
I think the reason that there are methods of integration and standard schema provided for these things is that people see the need for a standard. If something is possible, people are going to do it. They might as well all do it in the same way so that these things won't cause headaches in the future.
Some day, all these things will be stored in a centralized system. It might as well be LDAP. And the facilities for doing this in a good way might as well be provided. LDAP is serving as a crystal ball here.
The LDAP data structure seems incredibly complex.. For example, when deploying an LDAP directory I have to specify the organization and searchbase, as well as the server (and possibly port number), even though the server I am talking probably only knows about one organization anyway. I can understand the need within a worldwide, enterprise class organization, but this seems like overkill for even a large, single location company. Do you think LDAP is over-complex considering the comparatively simple information that is often asked to store?
I disagree--to an extent. Yes, it is complex, but you don't need to know much to deploy it right away. This is a both a good thing and a curse. You can install LDAP with a few defaults and not really have much of an idea of what you're typing in. The search base, Base DN, port, schema, etc, can easily be answered by a novice. The problem is that the novice doesn't really know what the overall impact of his answers will be once his system is deployed. People can quickly find out the answers to "what is", but you rarely hear about the impact of these decisions. What if your directory information tree is too flat? What is your schema isn't well defined? These things often don't matter to the novice administrator but once LDAP becomes a more critical part of the organization, they quickly realize that they made some mistakes. The decisions that are made early stick with you forever and often become obstacles for your future integration projects.
Oracle, X.500, and all the other larger "solutions" to your company's problems come with some level of training and documentation. Every decision made during the deployment of these systems comes with a library of best practices. You know the potential problems right away because someone else has made these mistakes.
With LDAP, you often find out you made a critical mistake in the architecture when it is too late. That's the curse of simplicity.
LDAP--and OpenLDAP is no different--has considerable memory and disk space demands, even for relatively modest sized databases. Does this make it more difficult to deploy OpenLDAP within an existing server structure where many servers will already be working at capacity?
I like to split things into either physical or logical systems. If you're going to be deploying LDAP on the same host as mail, make sure you've got another interface on there named "ldap" so that people won't be connecting to your LDAP environment with the same hostname as your mail environment. A new box is great but if that isn't an option, a virtual interface always is.
In the beginning I wouldn't worry too much. The resources for a test LDAP system aren't really that high. Find a box that isn't used, throw LDAP on there, and see what it can do for you. The memory and disk demands come with utilization and data. A small installation without much data won't take up all your disk space or memory. With disk, memory and processing power being so cheap, I don't think the hurdles of yesteryear exist today.
I frequently find that beyond the command line and the extensive API that what LDAP (and OpenLDAP) is lacking are any extensive administration tools. Instead I end up building my own interfaces which complicate the deployment. Do you have any recommendations for LDAP tools? 8.Do you advocate the use of LDAP as a simple, albeit enterprise wide, address book? 9.You currently manage a large LDAP deployment for a Fortune 100 company. Could you tell us a little bit about the work involved in managing such a large database in this environment?
The big obstacles are in making sure the data is usable and up to date. I'm pretty sure LDAP isn't the authoritative source of all information in your company. It needs to get data from somewhere else--like HR, security, etc. I think the issue of catastrophic success is the main issue. There's a lot of time that needs to be invested here. If I spend too much time deploying something and no one uses it, it was a waste. If I don't spend enough time deploying something and getting the data working just right and everyone uses it, they see it as a failure and go back to their old methods.
Systems that utilize LDAP for security require that data be kept synchronized with the host system 24/7. There's not much room for error. If account data is 4 days out of date, there's going to be a problem. This is the main this that I need to deal with.
There's also the issue of people wanting to integrate with the main LDAP system and throw tons of garbage into it. I like to know if a person is still an employee. I don't want to know if someone like the background Blue for Application 18 on a random web server. Finding the balance here is often difficult.
Oh, and waking up at 3am because 1 of 100 LDAP servers is down and trying to convince the person who woke you up that it doesn't matter because we're redundant! But that's another story.
Working with such complicated data must be quite tiring. What do you do to relax?
Relax? I like to LDAP enable my kitchen appliances. I'm kidding but a few years ago that would have been true. I realized that doing the same thing for relaxation that you do during the day at the office just doesn't work too well. I don't want to get burned out so I read a lot of old detective novels. I try to find ones based on San Francisco so I can actually venture out to the areas where the story takes place. I always get a kick out of that.
You can order a copy of the book on Amazon.com
Tom Jackiewicz Bio
Tom Jackiewicz is currently responsible for global LDAP and e-mail architecture at a Fortune 100 company. Over the past 12 years, he has worked on the e-mail and LDAP capabilities of the Palm VII, helped architect many large-scale ISPs servicing millions of active e-mail users, and audited security for a number of Fortune 500 companies.
Jackiewicz has held management, engineering, and consulting positions at Applied Materials, Motorola, and Winstar GoodNet. Jackiewicz has also published articles on network security and monitoring, IT infrastructure, Solaris, Linux, DNS, LDAP, and LDAP security. He lives in San Francisco's Mission neighborhood, where he relies on public transportation plus a bicycle to transport himself to the office--fashionably late. His website is at www.sun4c.net.
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.