Share This Article
The following article is associated with a JumpCloud webinar on the role of a directory in modern IT environments featuring entrepreneurs Stephen O’Grady, Principal Analyst & Co-founder of RedMonk, and Tim Howes, Computer Scientist & Co-creator of LDAP. Watch the full webinar recording here.
For those of you who don’t know Tim Howes, he has been on the frontlines of the tech industry since he co-created the Lightweight Directory Access Protocol (LDAP) in 1993. His work as a computer scientist and serial entrepreneur has helped shape modern IT, from LDAP to the SaaS and IaaS models we see today in many organizations. He has co-founded multiple successful startups, including enterprise software company Opsware, web browser company Rockmelt, and education management company Know Yourself. He currently serves as an angel investor and sits on JumpCloud’s Technical Advisory Board.
What made you start the LDAP project?
This goes back to the prehistory of directory, even before 1999. Some time in the early nineties at the University of Michigan, a couple of other people and I were given the task of moving us off of the campus mainframe system. One of the things we needed to replace, along with email and other things, was a directory system. I was essentially handed an open source version of X.500, which was the OSI directory standard at the time, and told to implement it for the campus.
It was a bit of an impossible task because the machines most people had on their desktops, which were small PCs and Macs, were not really equipped to run the OSI stack. So my team and I developed a precursor to LDAP called DIXIE, which was just a very lightweight front end to the heavier-weight X.500, and people seemed to like that. I was approached by some people in the Internet Engineering Task Force who said, “Hey, why don’t you come work with us to make a standardized version,” which became LDAP.
How did the creation of DIXIE impact the overall adoption of LDAP?
I would say there were two transition points. One was trying to get X.500 out there, then along came DIXIE, and then later LDAP, which really spurred the adoption of X.500 in a small way. Then when it became clear that the internet was going to win the day, not OSI protocols, we more or less divorced LDAP from X.500 and just said, “Let’s keep the information model, but there’s no reason you can’t have something else behind LDAP whether it’s Active Directory or your own database.” And we of course made the whole thing open source, so that really accelerated adoption since step one to getting LDAP was no longer to get X.500. Step one was just untar it, compile it, and you’re ready to go.
We also saw a lot of commercial adoption at that point with companies who were trying to figure out, “How do we play in the standards game and how do we maybe front end our proprietary directory with something?” They could pick up the software and more easily adapt it to what they were doing, which is exactly what a lot of folks did.
Do you feel like the role of LDAP or DIXIE, or what you originally created, has changed? Why has it changed in that direction, or is it exactly the same?
Well the jobs to be done are the same, right? You still need to authenticate, you still need to verify, you still need to do authentication, but the context has changed so much over the years. Even from the initial days of LDAP to when Active Directory really came on the scene, to when internet applications became the driving factor and you had companies focused solely on that piece of it, like Okta.
So the context is different because instead of a bunch of desktop applications, you’ve got web applications. You have the cloud coming into play, you’ve got local and remote devices. So the scale is different, but the problems are the same and it’s interesting to see what people deal with today. It’s the same problems we had back in the day, it’s just at a different scale. There are so many more vendors now and it’s an even thicker acronym soup.
Why did you decide to open source LDAP? You could have just made it another proprietary software, right?
Yeah, but as another piece of proprietary software, we wouldn’t have had anything going for us above say Banyan, the big directory at the time, or NDS, the Novell Directory System, the two big proprietary standards when we started. The whole idea behind LDAP was to be open and to create a way for these different directories to talk to one another, and for all the applications out there to talk to different directories via a standard protocol.
I think at the time, Netscape was coming up and they had really shone a bright light on the cost of vendor lock-in and lack of standards, so open standards from HTTP to SMTP and LDAP became one of those things that they promoted. It was at the same time that the IETF was doing a lot of work on the internet in general and the internet was really starting to take off.
You brought up a very interesting point about the importance of the resources talking to each other. Why do you think that is important?
You don’t want things to be too centralized and as much as you can, you want communication to occur between the parties involved, as opposed to through some centralized broker. Now the directory kind of has a centralized role in all of that, because that’s where you store authentication, it’s where you do authorization and things, and you’ll need something like that for those functions, which are difficult to federate out. But I think, you look at people bringing their own devices to work and IT has kind of lost control of what people use to do their work on. So in that context, it’s really important for those devices to come and be able to operate as independently as possible while still fitting into the larger corporate context.
What advice do you have for IT admins who have just started building their operations?
Experience is a great teacher and it’s funny to see this same thing play out in a different way. Like back in the day, there were people who said, “I’m just going to go all in on Microsoft, I’m going to go Active Directory and that’s it.” Then today I think we have people making a similar decision around whether it’s Google or Amazon or something else.
First of all, I’d say it’s not possible to go with a single vendor today. If you think it is, you’re making a mistake and you’re going to have to deal with it someday, whether it’s a wholesale change from one vendor to another, or “Oh, I just want to integrate this one app that’s a little bit different. It’s quirky. It can’t integrate with Google or whomever.” It seems like it’s going to be easy to handle those one-offs, or maybe you don’t even think about them, but that’s what kills you. Pretty soon your whole environment becomes nothing but a series of one-offs and then you’re wishing you had taken a more standards-based approach.
So my advice is to think about it from the beginning. It doesn’t make things any harder, in fact, some things are made a lot easier if you can think about standardization from the beginning. If you can think about, well, what if I end up having to change vendors? What if I need to integrate applications or devices or other things that don’t fit in with whatever worldview I started with? Because it will happen.
Really good sysadmins are the ones who can look a little bit further ahead and say, ‘My job should not just be putting out the same fire over and over again, my job should be designing fire suppression tools that then can be used in an automated fashion.’
Tim Howes
A problem many IT admins have right now is they are inundated with a lot of tickets and requests, so it is very hard for them to step back and think about standardization. Do you have any advice about how they can balance that workload?
To me, that’s the same question. They say the best sysadmins are the laziest ones. What that means is they’re the ones who, when they do something twice or three times or 10 times, they say to themselves, “I don’t want to do this again. I’m going to develop a tool, I’m going to automate it and then I just have to press the button or better yet, even automate the response to it.” So that’s what I mean when I say the best sysadmins are the lazy ones, they’re the ones who developed the tools so they don’t have to do duplicate work in the future.
I think it takes time to develop those tools, just like it takes time to design your directory and the whole environmental context around that directory, but it pays dividends down the road. It’s the same kind of mindset where you have to think about, do I really want to do one-off integrations down the road, or do I want to design something upfront so I don’t have to do that?
Really good sysadmins are the ones who can look a little bit further ahead and say, “My job should not just be putting out the same fire over and over again, my job should be designing fire suppression tools that then can be used in an automated fashion.” And this is exactly analogous to that, in the context of directory.
What do you think the future of LDAP is? Do you see it getting adopted more widely, or do you think it’s going to be merged with another protocol?
Predicting the future is never a good business to be in, but I would say adoption of LDAP will probably grow as use of directory grows. It’ll continue to have a role, I would imagine. I think once something gets out there as much as LDAP or other protocols, it’s hard to yank it out, no matter how much you might say, “Boy, I would have designed that differently if I had known.” Which I do sometimes, you know, if I’d known where the world was going. I think it’s probably still got some life left in it. I think the fundamentals of the information model are pretty strong. I think things like LDAPS are good evolutionary paths for it. I’d like to see more adoption of that.
To see the full interview, watch the recording of JumpCloud’s recent webinar: Redefining the Directory for Remote and Cloud-First IT Teams.
Dive Deeper Into LDAP
If you’d like to hear more from Tim Howes, check out our previous interview series:
Part 1: Origins of LDAP and Cloud-Based Directory
Part 2: Securing Decentralized IT
Part 3: Microsoft, LDAP, and the Directory
Part 4: Future Trends in Identity and Access Management (IAM)
If you’d like to learn even more about LDAP, here are some additional resources to explore:
