X.500: The Directory Service That Time Forgot

Transcript

[00:00:00.23]
Ned: But maybe that's just my imagination.

[00:00:04.21]
Chris: Once again, Running Away With You. It's a reference for our over-80 crowd.

[00:00:14.12]
Ned: Over-80? Wow.

[00:00:16.22]
Chris: Dude, that song came out in the '60s.

[00:00:19.00]
Ned: I mean, that's a valid point.

[00:00:20.25]
Chris: Do the math. Actually, don't do the math.

[00:00:23.20]
Ned: I'd really rather not. Hello, Alleged Human, and welcome to the Chaos Lever podcast. My name is Ned, and I'm definitely not a robot. I'm a real human person who would have an object class in LDAP matching the person type. With me is Chris, who is also allegedly a person type. Hey, Chris.

[00:00:54.16]
Chris: I'm pretty clearly a person type. The actual type, however, has been a subject of controversy and questioning. A lot of answers, not positive.

[00:01:06.21]
Ned: You should stop sending out surveys to all the people you've met. You know what those interactions were like.

[00:01:15.16]
Chris: You mean that's not how you follow up a first date?

[00:01:19.06]
Ned: It is an odd way to go about things, though I appreciate your efficiency. You have a Google form and you stick with it.

[00:01:26.20]
Chris: Look, these 78 questions are all important.

[00:01:30.17]
Ned: All your thoughts on pickles, dill or sweet. That's important stuff, man. If she gets it wrong, she's out.

[00:01:41.13]
Chris: Pronounce the word A-Z-U-R-E. There is one correct way to do it.

[00:01:47.23]
Ned: That is almost certainly not true. I say that having spoken to so many different Microsoft employees that pronounced it different. I've heard Azure is Azure?

[00:02:00.01]
Chris: That's not because they're right, they do it to vex me.

[00:02:07.05]
Ned: I've never seen an official pronunciation guide for Azure.

[00:02:13.28]
Chris: The correct answer is clearly Azuare. And I don't understand why everyone keeps getting it wrong.

[00:02:23.13]
Ned: Well, if that's wrong, I don't want to be right. Let's talk about some tech We're in the garbage, shall we?

[00:02:31.04]
Chris: Okay.

[00:02:34.01]
Ned: Where in the world is Carmen San Diego?

[00:02:37.25]
Chris: We're sued, and that wasn't right.

[00:02:40.23]
Ned: Ironically, she's not in San Diego. I don't know if that was ever the correct answer for the game. Last week, we spent the episode regaling you, dear listener, with our various adventures in the world of disaster recovery. You should go listen to it. I mean, not right now, but later, after you listen to this. During that episode, Chris and I got into a discussion about what it takes to bring up Active Directory in a disaster, and I was thrown back to my early days of managing AD and learning about things like EDC's, BDCs, domains, forests, and the importance of FISMO. Those are all real things.

[00:03:22.16]
Chris: Don't feed FISMO after midnight.

[00:03:27.17]
Ned: I mean, it's a very good point, but that is how you promote a backup domain controller to a primary?

[00:03:36.12]
Chris: I have no response to that.

[00:03:37.29]
Ned: You're not even sure if I'm kidding or not. It has to be midnight, full moon, the planets aligned, Well, last night would have been perfect, apparently.

[00:03:46.23]
Chris: Look, man, I only skimmed the instructions. That's a lot of pages.

[00:03:52.12]
Ned: There were two pages, which I guess for some people, that's a lot. There was actually a time before the land of Active Directory when the need for a directory of users and computers was first identified, and an international organization built a standard and model for such a directory, and they called it X. R-500, an awkward and confusing name that itself requires some explanation. Let's do that. In this episode, which I am officially calling now as Part One of multiple parts, We'll talk about the OG Directory Service, who came up with it, and how it was implemented. In future episodes, we'll get into Netscape, Novel Network, and this tiny company you maybe have heard of called Microsoft, I don't know. I don't know if they made it out of the '90s.

[00:04:49.27]
Chris: They don't even have a GUI. They'll never take off.

[00:04:53.19]
Ned: Like a shot at Novel right there. Ouch, because they really didn't. I'm sure someone somewhere, some government organization is still running Novel.

[00:05:05.10]
Chris: Oh, there's no doubt in my mind.

[00:05:07.18]
Ned: Even though I think support ended in 2001. Well, The idea of a directory isn't exactly novel or new. Sometimes you need to look up some information about a person, a place, or a thing. It's not uncommon to use a directory of some sort to accomplish that goal. Office buildings have directories. Phonebooks are essentially directories. Kids, so phonebooks are these things that you used to get. Do I need to explain this? I'm not sure. We can even go back to the beginning of the second millennium to find the Doomsday Book, which was essentially a directory of landowners in England and was used by William the Conqueror to figure out who owned what and how much they owed him in taxes. As At its core, a directory is simply an organized list of entries about entities, real or imagined, and some attributes about those entries. The Domesday Book, or Doomsday Book, I've heard it both ways, had entities like parcels of land or livestock with attributes like the size and value of the land or the type, count, and value of the livestock. Really came back to money a lot.

[00:06:28.26]
Chris: These cows are worth 0. 1 cent.

[00:06:32.29]
Ned: Which could buy you a small castle in those days.

[00:06:38.11]
Chris: Inflation and all. Yeah, but only a small castle.

[00:06:39.22]
Ned: Yeah, I mean, it's just half a cent, a hay penny even. A building directory that lists businesses along with their location in the building and possibly their phone number or their purpose. As the size and complexity of computer systems grew, the need for various directories appeared. The most obvious is the file system directory, which details each file and its location in the file system. We tend to use the terms folder and directory interchangeably, but Really, the folder is a container for files, and the directory is a catalog of where those files are stored. In some file systems, folders are just an illusion. An artificial construct laid on top of the file system by the directory. It's trippy, I know. Have you ever really looked at your hands?

[00:07:39.05]
Chris: I consider them objects.

[00:07:41.07]
Ned: You consider folder objects?

[00:07:44.29]
Chris: No, my hands.

[00:07:46.01]
Ned: Okay, all right. A little scared there for a second. What else needs directories? Users, for one. Even on the earliest multi-user systems, there had to be some directory that housed user entities and included attributes like their password, group membership, and a home directory location. Once we started networking systems together, there arose a need to have a unified directory that spanned multiple systems questions. So the ITU-T, or more accurately, the CCI TT, came along and established the X. 500 recommendation. And all was well. The end. Roll credits. There's no other questions, right?

[00:08:33.11]
Chris: Why would there be?

[00:08:36.11]
Ned: Okay, so maybe there are a few lingering questions. For starters, what the hell is the ITU-T? And why is it more accurate to say the CCI TT. What the ever-loving fuck is the X. 500? Worry not. Answers will come in due time. And if you pay your dues. We're starting a Patreon? No, we're I did that once. It was a bad idea. If there's one thing that was sorely lacking in my early technical education, it was any background in technology history or where all these cool technology thingamajigs came from. I started my college career studying computer engineering in 1996. Humblebrag? No. No, probably not. The engineering program had approximately zero interest in telling me anything about emerging computer computing stuff like, I don't know, the Internet, telecommunications, directory service, operating systems, etc. It made sure I knew a shit ton of calculus, physics, and formal logic, but not so much with like, TCP/IP. I didn't even know that existed at the time.

[00:09:50.15]
Chris: Well, I mean, it really only barely existed.

[00:09:53.18]
Ned: In '96? No.

[00:09:57.10]
Chris: Well, let me see. No, I guess you're right. It would be more like '86. And then IP was like '90.

[00:10:07.12]
Ned: It had been around for a while. Maybe it hadn't become the juggernaut. I mean, token ring was still a thing, but still. My point is, everything that I was learning was preparing me to be able to design circuit boards and do materials engineering, and none of it had anything to do with actual computers, which is That's part of why I dropped out, part, and got an associate's degree in computing technology, which at least focused on computer hardware, modern operating systems, Windows NT 3. 5. That was modern. Shut up. And getting my A plus certification. It's also how I managed to snag my first job in the world technology on a help desk in the blissful year of 2002. What was I doing for that six-year stretch? Believe me when I say that, number one, we do not have that time. Number two, there are at least three novels just waiting to be written about it. Number three, there was a non-zero amount of raves that I attended, and at least one guy who went by the name of Gargoyle.

[00:11:19.17]
Chris: What?

[00:11:20.27]
Ned: Anyway, technology is pretty cool. But if you develop technology in a vacuum and everyone If someone else does the same, then none of your shit works together. This has been a constant source of irritation for centuries, and only more so with the industrial revolution. There is definitely an XKCD comic about this, probably several. So standards bodies were developed to get everyone to agree to do things in the same general way, or at least in a way that things could work together. Think about the establishment of the meter or the metric system as a whole. Fun fact, France also tried to implement a metric calendar, and that went less well. Turns out people like seven days in a week for a reason, and you can't really alter what a year is unless you can change the orbit of the Earth. God knows that Napoleon tried.

[00:12:21.19]
Chris: They also tried to do a metric clock. How that would even work, I will leave as an exercise to the reader.

[00:12:28.10]
Ned: There I've seen pictures of what the metric clock looked like. It's madness. Listen, some things are just meant to be broken into non-decimal amounts, and that's fine. Twelve is a perfectly good number for so many reasons. Do we really want to get into that? Because we can. I have strong opinions about twelve.

[00:12:51.23]
Chris: How do you want this series to be?

[00:12:54.19]
Ned: Well, if it's going to be anything like your cryptography series- Hey, carry on. Fair enough. When the Telegraph was created in the 1800s, a standards body called the International Telegraph Union was formed in 1865 as part of an agreement for European states to adopt standards regarding telegraphic equipment, operating instructions, and tariffs. Really does seem to come back to money, doesn't it? The ITU later merged with the International Radiograph radio telegraph union in 1932 to form the International Telecommunications Union, which meant they didn't have to change their logo. It intended to encompass communications technology beyond just the radio and the telegraph, especially since this telephone thing had started happening, and that seemed like it was going to be important. The ITU became part of the United Nations in 1949, and as far as I can tell, it is the oldest such French standards body at the UN. The ITU is broken up into three sectors that handle radio communication, general standardization, and development. The standardization sector used to be called, and I'm going to apologize to our French listeners right now, and probably again later, Comité Consultif International, Telephonique et Téléraphique, or the CCI I-T-T. There it is.

[00:14:33.02]
Ned: And then it was- You just retroactively failed French. I'm glad I never took it. Then it was renamed the ITU-T in 1993. Oh, yeah. All this stuff was led by France, who really love standards almost as much as they love cheese and surrender. Cool. Don't blame me, blame the sentence. Cool. Now we know what the ITU-T What about this XDIVE. 500 naming convention? The ITU-T doesn't call what they create standards. They call them recommendations. Isn't that nice? It's so polite. Because the French love categories, they establish 25 different categories within the ITU-T using the letters of the alphabet, A through Z, except for W, because fuck W. It knows what it did. You do, too. Seriously, though, I look this. I have no idea why W is skipped. The French have the letter W. That's not a question. I don't know. Listener, if you know why W is the only one that wasn't included, send us a message through our feedback form and please let me know because I got nothing. Anyhow, the X category is reserved for data networks, open system communications and security. Each recommendation is given a number, and X. 500 happened to be the number they chose for the general topic of directory services.

[00:16:18.13]
Ned: Other 500-level recommendations also outlined directory-adjacent topics and specifics for implementation. You've actually probably come across several of these ITU-T recommendations, whether or not you realized it. H. 264 for video encoding, that's one of their recommendations. X. 25 for packet switching. X. 400 for email, which if you are an exchange administrator or had to work with any of the other email programs, you might have seen that come up. T. 38 for faxes, though I suspect that one might just be me. V. 28 for RS-232 serial communications. For people of a certain age, they might have seen V. 92 on their 56 kilobit modems. That was the standard or recommendation, whatever. T. 8 is for the JPEG standard. Yep, they're the ones behind the standard for JPEGs. Seems random, but they're behind a lot of things. They're like the Illuminati, but less cool. If you happen to come across something that is a letter, dot, a number, it is pretty likely that is an ITU-T recommendation. The ITU are not the only standards body out there, and loyal listeners will surely be familiar with the Internet Engineering Task Force, Task Force or the IETF, or the Institute of Electrical and Electronic Engineers, the IEEE.

[00:18:00.01]
Ned: You probably also won't be shocked to learn that there's been a significant amount of overlap between these groups, and that hasn't always been resolved amicably. The ITU in particular has wained in importance in the last decade or so, but that is probably a story for another time. There's also some stuff about what happened in 2012 in the entrance of some less than savory characters into the ITU who tried to, I guess, do a mini Who?

[00:18:31.20]
Chris: Belgium? Were they Belgium?

[00:18:35.16]
Ned: No, I wish. I had Turkey was involved and China. They were trying to steer things in a very specific direction. Iran, I think, was also involved in the process. Like I said, we don't have time, but that would make its own interesting episode, probably. Now on to the X. 500 recommendation. Okay. I read through the X. 500 documents, which are long and boring, and so I'm going to summarize. You're welcome. The X. 500 recommendation was drafted and ratified in 1988. We're talking about the true infancy of so many adjacent technologies. Tcp/ip was yet to become the standard for networking communications. I mean, it was getting there, but it was not the standard. Dns was a whopping three years old at this point. Bgp It could even be invented until the following year in 1989. That whole OSI seven-layer model thing had only recently been adopted as X. 200 in 1983. Yes, the OSI model is also from the ITU. It's also an episode in and of itself. We'll put that one to the side as well on top of the stack of the other three episodes that I've already mentioned. The point is that so much of the Internet that we take for granted now was still just starting to take shape.

[00:20:06.17]
Ned: Larger scale rollouts of desktop PCs and the revolution of X86 commodity servers had yet to make their impact felt. But there was something in the air. People definitely saw the explosion of users, systems, and applications coming, and they wanted something that could effectively catalog those entities and respond to queries about them. That is the climate in which the X. 500 recommendation and model was developed. I found an interesting ebook online that I'll include in the show notes that describes the X. 500 model in more detail and has a chipper, upbeat tone to it, which I found odd but enjoyable. But they stressed in the ebook that there are several different perspectives you can use to view the X. 500 model But if you boil things down to the very basic level, the goal behind the model was to have a single directory that was organized in a hierarchical tree that could respond relatively quickly to reads and queries. Rights were certainly important, but the theory was that most users and clients would be reading information out of the system the vast majority of the time and seldom altering its contents. As an For example, you probably log in with your Active Directory account or some other user account several times a day.

[00:21:38.09]
Ned: But you only change the password maybe once every three months, depending on what your security team forces you to do, and the rest of the information in your user account almost never changes. The recommendation outlines a structure for the directory, and that's a capital D directory, if you couldn't hear it, but it It doesn't prescribe a specific database technology or an application to bring it to life. The structure of the directory starts at the root with an empty entity that has no parent, and then each entity below it has to have a parent entity going up back to that root. It feels familiar, right? If an entity has no children, then it's a leaf. Most entities will be leaves, with parent entities lending the directory a hierarchy for organization and administration. Each entity will have one or more attributes that describe characteristics of that entity, some of which are user-facing and some that are for operational concerns. For instance, your username and your password and maybe your telephone number or email address. Those are user-facing. Other people might want to read that information. Operational stuff might be last time logged in or last time password changed.

[00:23:03.22]
Ned: That's something for the system or administrators to look at and deal with. The entity itself has to be unique within its... The name of the entity has to be unique within the node of its hierarchy with the addition of the parents' names, forming a globally unique name. Now, that's a lot of technical jargon, so let's go with an example. Chris, let's say you're running a global organization with offices in US, UK, and India. Congratulations. Good job.

[00:23:38.28]
Chris: That sounds like a lot of time zones.

[00:23:41.04]
Ned: It does. It's going to be hard to put together. You probably want some information about these various offices, maybe what time zone they're in and who's there. The root of your directory would have three children, one for each country. You'd have US, UK, and maybe IN for India for the names. Each of your country entities would have children corresponding to things like states, provinces, or whatever the equivalent is in England. I don't know, Hamlets or some shit. Each of those entities would have offices by location. Maybe you have an office in Coventry in both the UK and the US. We're copy cats in that regard. The full entity name is called the Distinguished Name. For the UK Coventry Office, it would be C equals UK, T equals West Midlands, I looked it up, L equals Coventry. The US one would be C equals US, S equals Rhode Island, L equals Coventry. Both these entities would have the same relative distinguished name of Coventry, but each would have a unique distinguished name, which is usually shortened to DN. When you see something asking for your DN, it wants the distinguished name of your entity. The directory tree that holds all this information is called the Directory Information tree or the DIT.

[00:25:19.05]
Ned: The DIT is served up to clients by servers designated as Directory Service Agents or DSAs, and the clients are Directory Services Users or DSUs. Initialisms. The document that I read is rife with initialisms, and I'm not going to even try to include them all. Really, all we need to remember is really the DSAs and the DSUs. Everything else is not that important.

[00:25:46.14]
Chris: And the distinguished names.

[00:25:48.18]
Ned: Yeah, and the DNS. You need those. You do if you want to find something or refer to it. An interesting feature of the DSAs is the fact that no single DSA a directory needs to have a complete copy of that directory. Each DSA can be made responsible for a portion of the directory being its so-called... It's called the master of that portion of the directory. I know that we avoid that term nowadays, but this was 1988. That's what they called it. As a master of the portion of the directory tree, the DSA would be responsible for updating and disseminating indicating changes to that portion of the DIT. Going back to our example, we could have a DSA located in each country. The one in the US would probably handle all the entries for the C equals US portion of the tree. It also needs to know the DSA is responsible for other portions of the directory, so it can forward requests or even redirect requests to those DSAs. As an administrator, you can also locally cache cache read-only versions of other portions of the directory. If you had a lot of UK workers from Coventry visiting the US, you might add the C equals UK, T equals West Midlands, L equals Coventry portion of the directory to your USDSA.

[00:27:18.07]
Ned: When there's an update to that portion of the directory, the DSA in the UK will notify the USDSA to copy the updates over to its cached instance. The X. 500 specifies that every entity should have an object class that draws from a separate part of the DIT that defines the directory schema. We have all of our entities in one portion of the DIT. Then there's this separate section that just defines what object classes and types are allowed. The X. 520 and the X. 521 recommendations outline some of the object classes and the attribute types, but it's extensible. If there's an object class that you want to introduce to your system, you're welcome to do that. They just wanted to have some general recommendations for things you probably want. Stuff like country an organization unit, a person, a username, a user password was one, and there was a few more. For example, they define a person as an object that has to have the attributes common name and surname and may include attributes like description, telephone number, and user password. There's also a concept of subclasses. There's an organizational person subclass, which adds on some additional attributes like the organization unit name and the title.

[00:28:50.05]
Ned: There is a ton more in the...

[00:28:52.02]
Chris: What about a disorganized person?

[00:28:55.10]
Ned: Would that be a subclass of a subclass? Or would it be its own thing? I'm not sure.

[00:29:01.14]
Chris: Whatever it is, I'm sure it would be miscategorized.

[00:29:05.00]
Ned: Fair enough. There's a ton more in the specification, and I'll include links to the X500, the X520, and the X521, if you really want to read through them. But the last thing I want to mention is how you were meant to communicate with a DSA. X500 established two directory protocols. The Directory Access Protocol for interaction between a DSU and a DSA, and the Directory System Protocol for DSA to DSA communications, so that replication and forwarding of requests. These protocols weren't meant to ride on the TCP transport. Because remember, this was really early days, they were meant to be their own transport level protocols. That didn't last for long because LDAP was about to arrive on the scene. Seriously, Honestly, though. The first few early implementations of X. 500 were heavyweight and cumbersome to implement. You had to write your own transport stack. What's to do that? There were two major pilot programs, one in the US called the White Pages Pilot Project, and one in the UK called Paradise, I think. Sources vary. Both implementations were plagued by slow reads, incomplete data, and low adoption rates. But the directory idea had merit. It just needed better implementations to run and query the directory.

[00:30:38.00]
Ned: There were several projects that worked to craft a better DSU because that seemed to be the real sticking point. The client software that was written just sucked, and it was written by engineers who had never experienced a real person. It was totally unusable by anyone who wasn't deeply steeped in the particulars the X500 recommendation. Some other people were like, Hey, maybe we make this a little bit easier. Two projects in particular were the Directory Assistance Service or a DASED, D-A-S-E-D, that was developed by Colin Robbins and the Dixie from Tim Howes at the University of Michigan. Both projects chose to use TCP for the transport protocol instead of DAP. Eventually, Usually, the two projects merged together to become the Lightweight Directory Access Protocol or LDAP. That's why it's lightweight, because it's better than DAP. In case you ever wondered. The first release of LDAP came in 1992, and it was basically an immediate success. The team released it as an open standard and published RFC 1487 in 1993. By 1996, when I was just entering During college, it had been endorsed as the leading standard by a consortium of 40 software vendors. In 1997, LDAP V3 was approved as a proposed internet standard.

[00:32:13.12]
Ned: That's where I think we need to end things for this round. You might be interested in know why Tim Howes and his colleagues were hired by Netscape, or how our modern browser certificate scheme ties into X. 500, or why Microsoft added LDAP to their product line. All of that and more will be explored in part, Others. I was going to say part two, but I'm going to be honest, it's probably going to extend beyond that. There's a lot of stuff here. What's nice is a lot of the people involved are still alive, and I was hoping we could snag one of them to maybe come on and talk about their role in some portion of this.

[00:32:59.05]
Chris: That could be fun, and they could criticize all the things you got wrong. Who doesn't enjoy that?

[00:33:05.16]
Ned: I love it. Everybody enjoys that. Hey, thanks for listening or something. I guess you found it worthwhile enough if you made it all the way to the end. So congratulations to you, friend. You accomplished something today. Now you can go sit on the couch, fire up an old copy of an X500 database, and query it with LDAP. You've earned it. You can find more about the show by visiting our LinkedIn page, Just search Chaos Lever or go to our website, chaoslever. Com, where you'll find show notes, blog posts, and general Tom foolery. We'll be back next week to see what fresh hell is upon us. Ta-ta for now.

[00:33:45.03]
Chris: I actually got a well, actually, private message.

[00:33:55.28]
Ned: No. I've got one of our shows?

[00:33:58.02]
Chris: In the encryption episode version, volume, I don't know, 109, I said the Zimmerman telegram happened in World War II, and actually, it happened in World War I. That's my bad.