 of mine who works at One Secure, and he's got to talk to you about LDAP. Just to give you a background about me, some of you may know me as XS, you can call me Greg, whichever you want. I work with Pete at a security vendor of sorts in the Bay Area. I'm a security engineer over there, so I don't really work with LDAP every day. A little bit of my background with LDAP is when I was first brought on board, I was asked to implement a new mail and user system, and I was looking at a couple different options, either like a SQL back-end or a virtual user back-end, and I kept hearing things about LDAP, and I had never used it before. So I figured, let's see what I could use it for. And it turns out my favorite MTA, Qmail, has a patch for it called Qmail LDAP, which lets you use a LDAP back-end for user authentication, aliasing, et cetera. That's pretty much how I picked it up. Unfortunately, the project I was working on was kind of canceled, so I haven't had much other implementation work with LDAP aside from that, so that's about where my knowledge ends. But what I've done is I've tried to get as much research on LDAP as I can find in RFCs and associated fax and online documentation so that those of you who haven't heard of LDAP or X500 or any directory access protocol can walk away from this, at least knowing what it is, knowing what you could do with it, and hopefully wanting to go back and learn some more. I did have some pretty slides and such for you, but seeing as I can't get internet access, we're going to go with text and e-terms. So you'll have to look at my ASCII diagrams. So with that, feel free to ask me questions anytime. Just let me get through this spleel I wrote in a paper, and then you can just hammer me away. I have no intention of this being long-winded or taking all day or anything. So as soon as you feel like you don't have any more questions, just get the hell out of here. If you have any LDAP three questions, there's someone else in the room that can help you out a little more with that, but we'll get into that in a little while. LDAP, lightweight directory access protocol. It's an open standard alternative to X500 directory access protocol. X500 is a directory access protocol first approved as a standard in 1988, was maintained by ITU, International Telecommunications Union, which released an enhanced version in 93. X500 uses the OSI network stack instead of TCPIP, UDP, etc. Not many of us use it anymore. A directory, for those of you who don't know what directories are, the intent of the directory is based on the fact that human users must be able to look up assorted information about other people. Email addresses, mailing addresses, telephone numbers, fax numbers, birth dates, spoken languages, etc. And computers need to be able to look up addresses for various services. Passwords for users, user IDs, permissions, file system information, mount points, remote hosts, etc. And a lot of the time you think, why not use a centralized database for all this information? And the problem comes in with, because most centralized databases are big enough and comprehensive enough to cause slowdowns during peak query times. And because of their centralization, they're usually isolated on very inefficient, high-availability networks, or the simplest thing could just make them unavailable to any other networks. More on that, the administration of these databases is usually also centralized. Often, this means that there's a long turnaround time between when you want changes done and when changes are done, often called passing the book. There's another similar way of distributing this information, and it's DNS, Domain Name Service. DNS is maintained in a distributed fashion, like LDAP, where each DNS server provides name servers for a limited number of domains. And along with that, servers are often identified, backup servers are often identified for domains, so that in case of failure of a primary server, hosts won't lose name servers, simple enough. There's some problems with DNS though. DNS has very limited search capabilities, and the fact that it provides very few data types. Data types in A records, PTR records, C names, different types of records you can associate with actual names you're hosting. And adding new names involves widespread implementation changes. I can't just go out tomorrow and create a new record type and expect everyone else to be able to read it without everyone else changing what their name server does. Solution to this, LDAP provides decentralized maintenance, meaning that each site running LDAP is responsible for its part of the directory so that maintenance and updates can be done instantaneously and easy. I want to make a change to my local company's database. I don't have to go, you know, I don't have to call, I don't know, Washington to get them to change the database and then wait for the changes to sync all the way back to me. I make it locally. They see it over there. As easy as that. It has extremely powerful searching capabilities. Not exactly all regular expression style, but very similar. And you can construct just extremely complex queries to search LDAP databases. Or excuse me, not databases, directories is the correct term. The definition of how it stores data is actually stored inside of it. So if you want to make a change to how it stores data, say you want to add a new type of record, favorite topping on pizza, you don't have to go out and change the actual implementation. You just add it to your directory. And people remotely can't see it unless they add it to their directory. And it doesn't affect them, it doesn't affect you because they can't see it. It's just something you've added to your database. They can sync it up to theirs, you can sync it up to theirs, whichever. As it's standard based, it's very, very, very easy to build applications which use directory service. Email servers, automated resource locators, other special purpose tools. Regardless of where they are, what they're running on, or what they're running for an LDAP implementation. Also because it's standard based, there are few incompatibilities between different implementations. Once you start using it, you'll see that's a little wrong, but because it's based on a standard, they're supposed to be all the same, but one has an API that allows you to do this, a different one has an API that allows you to do that. So it gets confusing when you start running software for it. And it can be accessed by most information in one implementation. It can be accessed from another implementation without much headache most of the time. Problems with LDAP. Searches in LDAP can span more than one LDAP server, meaning that they're going to have to cross network boundaries. And a lot of implementations cache all this information that it goes out and requests from a remote server. And this usually slows down the response time in queries. It's not as true anymore with people getting larger and larger servers and more and more bandwidth, but that was one of the slowdowns and why you haven't seen LDAP deployed everywhere yet. Security configurations are another problem with LDAP. A lot of the security configurations allow a limited number of query returns when you query LDAP. You may seek, you know, something like everyone named Bob and you may get 100 results, but the security restrictions on the server may only restrict you to seeing 10 results. These are all stuff that can be tweaked, but it requires a lot of work on the user end if it's not set up correctly to begin with. Some examples of directory service, in case you still haven't caught on, phone companies 401 or directory service, excuse me, directory assistance is provided by all the baby bells or all the I-Lex and all the C-Lex. They keep an electronic list of all the, you know, everyone has a phone line, their names, their addresses, their phone number. You call up, give them the name, give them the address to give you the phone number. It's also available in the phone book. The problem with that is if you need the city they live in, excuse me, it's hard to sell in here, their name. Now if you return more than one name, say two names, there's really no other way to limit down who's who. It's a limit of an example of another directory service. In addition, the information they may have in there can be from two weeks old in the electronic version to up to a year old in the phone book. So not much they can do about a phone book that's sitting in your house other than sending you another phone book. Pretty inefficient. Another problem with that is if I want to look up the number of someone in Atlanta, for example, I have to call a directory service in Atlanta. I can't call my local directory service. So another limitation of this directory service, excuse me, directory systems. How directories are broken up? Entries are primarily constructed holding information in a directory. An entry would be an entry for a user, for example, or a person. Each entry contains information about an object. An object would be telephone number, favorite topping on pizza, spoken language, mailing address, email address. Those are examples of objects in LDAP. Each of these has a collection of attributes for them, or syntax for attributes for them. For example, telephone number can only contain numerics. Your surname can only contain alphanumeric characters. There's some other ones that, you know, photo data, time code, different types of syntax. You can stick on attributes, boring stuff. Security in LDAP. LDAP by default is extremely lax when it comes to security. It's not much more secure than any default installation of your favorite OS. Pick whatever it is. Excluding Windows, just never secure. Securing it requires much administrative intervention, so it's not something you could plug and play and hope no one owns it. Access control lists are built into LDAP. You just have to know how to use them and you have to use them. Each attribute or each object of a given entry, entry being a person, for example, can be permitted to detect, compare, read, modify permissions based on the reader's membership in various groups. For example, if someone wanted to look me up and get my phone number, my LDAP server can restrict them from seeing my phone number. They could see that I exist. They could compare my password against another password if I allowed them to do that. They could get my address, but I could restrict them from seeing my phone number. Or it could be the other way around. I could select them only see my phone number and see that I exist. That's what I mean when I say compare, read, and modify. Compare would be just compare two entries. Is Greg in the LDAP database? Yes, Greg's in the LDAP database, for example. You can also specify information given to the public so that anyone can read it the same way if I just want them to have my phone number. A pretty cool security feature of LDAP is when, if you're using it for user authentication, is the user password object, which stores user passwords before stuff. Syntaxfus allows you to store it in plaintext, Unix, Crept, MD5, SHA, and seeded MD5 or SHA, which is pretty cool considering. Say I'm running a FreeBSD machine and I want to authenticate my Linux users off of it and I'm running LDAP for authentication. I can use any of these schemes, SHA, MD5, Unix, Crept, and it doesn't matter what platform I'm using. It's all based in LDAP. So I can go from Sys5 to BSD without having to worry about going between MD5 and Crept. Some common uses of LDAP. Email servers. Not all MTAs, but as far as I know, most MTAs have either patches or come default with support for LDAP that allows the control of addressing, LACing, forwarding. Another example of this is QML LDAP. It uses LDAP to look up user information and then uses the return information to process messages. Say it's having to add 100 users to a mail server just to get them to receive mail. You stick them in the LDAP database and you're set. You don't have to add anyone to the machine. Kind of like virtual users with any other MTA, except you're doing yourself a favor by putting them in LDAP. The patch for QML that I was referring to earlier will also do authentication for, you know, if you want to pop in and get your mail or I'm at the end and get your mail. You can use the authentication scheme in LDAP on a variety of platforms, usually using LDAP as the transport, but there's also PAM LDAP modules. So if you, I don't know, Solaris comes with PAM support. If you wanted your Solaris machine to start authenticating off an LDAP server, you would just stick a PAM LDAP module on there and you're set or your Red Hat machine or, you know, whatever you have PAM can pile it on. Employee listing and automation is another use for it. Very similar to what Netscape uses. Netscape's, well, last time I read, Netscape's corporate network was based on LDAP. It was basically meant HR hires a person, they add them to the database and instantly they're on the contact list, on the phone list, in the mail server. You know, they have an account to dial up and do whatever, all just by adding one entry. So that's where the centralization comes in. But it's not limited by centralization. I'll get to that. LDAP can be used as an NIS replacement, which I'm very happy about. There's some plugin replacements which are written by the guys at Paddle.com, P-A-D-L.com. One of their products is called YP-LDAP-D. And what it basically does is, if you say you have an existing NIS server and you want to replace it with an LDAP server, but you have machines on the network that don't support LDAP, you can stick YP-LDAP-D on there to answer NIS queries from the LDAP database. That way you can start sticking access lists on there and use the LDAP database for other things on your network. Pretty easy to implement too. I've done it a couple of times. They make another software product. These are all free products, by the way. I don't recall what the name is. It's available from the same people. What it does is it acts as an object that you stick in since Solaris, it's user-lib security. It's a YP object that you stick in there that instead of going to an NIS server, it will just automatically go to an LDAP server, save you tons of trouble. And with an infrastructure like this, it's pretty easy to roll it out network-wide without anything hiccuping or anyone dying coming in the office with a gun and killing you or anything. And it allows for replication and authentication across your network. I'm going to throw out a few examples of some software and some products that use LDAP. Netscape's got a really nice LDAP server. It's called iPlanet Directory Server now. There's some... Most Cisco hardware nowadays supports LDAP. They network sell some stuff that supports LDAP. It's rolling out at a very fast rate. That was the paper I've written. I hope it's answered some of the questions you have. I also have some diagrams I'll show you. Maybe this will help you out if you don't understand yet. But if you guys have any questions, just start firing away. Hit me. Open LDAP. That's all I've used. I swear by it. It's free. Be careful with the documentation. You've got to look through their fact system. They have one of those automated fact systems. It gets a little confusing at times. But all in all, it's a pretty hardcore server. I've used it on a variety of platforms. Linux, FreeBSD, Solaris. So that's my favorite. They're at openldap.org. If you're spanning more than one directory server, I don't remember. Yeah, Lito. He wants to know how servers, if they're spanning a network, authenticate against each other. So it doesn't think it's just a user going out and trying to pull information. Lito knows a little bit more about LDAP3 than I do. Safe Pages. Is it based off UMichigan? Yes. That reminds me, another open one. University of Michigan. Let me give you the URL for that, because it's kind of convoluted. I'll pull that up for you. Any other questions? Go ahead. If I were rolling it out, I would have two separate machines simply to minimalize the confusion involved. You could. It's not going to hurt anything. It's just a matter of maintenance versus confusion. The YP or NIS LDAP implementations are pretty easy to set up. Once they're set up, it's all a matter of maintaining the LDAP server. What's up? I don't think so. Oh, excuse me, I spelled that wrong. Dislex, yes, that's it. Any other questions? Go, dude. You did out add the root dn first. When you're adding it the first time, or where it is in the slapdconfig. Okay. You have to add the root dn first. It's not documented, and it may not be something you always have to do, but I've always had to do that. You have to add the root dn. You do the same thing when you're adding a user. You just add the actual six. If your organization equals Defcon and your country equals US, you add that first. And then add users underneath that. You need to use that for the authentication. Catch me later. We'll take a look at it on here. For LDAP or prior to LDAP? The RFCs. Let me show you the RFCs here. There's a couple of them. These are the RFCs you want. Right there. A lot of the earlier ones in here are RFCs. The later ones are LDAP3 RFCs. But everything in between will help you organize it. You'll see how other people have done it. Another good example is if you look at some of the facts on these pages here and see how they've laid it out, it's a good indication on how to do it. It's pretty straightforward. When you add users, you add them as people. When you add computers, you add them as computers. It's pretty tough to use yourself when you do it. Except with the number of options you have, the number of objects you have. Think of anything you've used, Lito? That's probably a good start. There was one I was using for a while. Net LDAP. There's another one. It's a simple LDAP administration tool. It's SLAT. Check out Freshmeat also. There's quite a few front-ends. That's another problem, with some of the open or free LDAP servers. They don't come with a front-end, so you're going to have to do it all by hand unless you go out and either write a front-end or download a front-end. Yeah. That's the advantage of the commercial servers versus the free servers. You have a front-end to do everything in. I haven't implemented that before. It's SlurpD. It uses SlurpD. I'm not sure what port it runs on. But you run a replication server. Actually, not if you're replicating. If you're just running flat LDAP between servers, it's still LDAP. It just goes out as a user. That's what we were discussing before, how it authenticates. Yeah. It's X500, which was the predecessor to LDAP ran on the OSI network stack. LDAP runs on TCPIP. Let me see what port it is for you here. That's SSL LDAP. I don't recall which port it runs on. 3.9? There you go, 3.9. That's the LDAP 3 Master over there. Yeah. Well, you've got, okay. There's a couple of examples of LDAP ripoffs or similarities. Notes uses, I think, X400, X500 for the back-end. Active Directory from Microsoft. Similar to LDAP. NDS from Novell. Similar to LDAP. We're actually talking one day about using an Active Directory server for an LDAP back-end with the NIS module for Solaris. To use a 2000 machine to authenticate a Solaris machine. We never got around to that. Would have been kind of cool. Yeah. The UMichigan URL is right here. LDAP. ITD UMich. Open LDAP is based off of that. And there's a little more developers on the Open LDAP team. I would stand behind them more the Open LDAP team myself. That's exactly how it works. That's exactly how it works. Yeah. It's just on the server that you're querying it needs to have other servers to find. I need to know where to look for the other objects that you want to grab. It's not as bad anymore. If you're running huge, huge queries you're going to see slowdowns. But everyone's running their LDAP servers in like 4.50s and crap so you're not going to have a problem. Well, Courier IMAP which Inter7 is now maintaining supports LDAP for authentication. So I had all the users information stored in LDAP. Yeah. Someone back there had a question. Sleepycat is what they roll out with and suggest that you use. That's all I've ever used. Sleepycat DB Sleepycat Berkeley, excuse me. Netscape Corporate 401.com Security of it versus Active Directory or NDS. I don't even know yet. It was just an assumption. Security is passing clear text by default. So you'd want to use LDAP SSL and since you're authenticating it off an Active Directory server again, not that we know that it's possible or not. You don't have SSL support. It's all in transport. It's not that much different from using radius except that radius hashes everything before it sends it. So it'd be what's actually on your network that you need to worry about. As far as the machine the access list or what you want to set up to allow people on your network to either, you know, just compare passwords just get user names, user ideas. I haven't done that so I can't I can't really comment on what you can do with it. I'm sorry dude, I can't hear you. Oh, a lot of bugs in LDAP. Yeah, documentation. The first bug. Lack of any knowledge amongst network administrators about LDAP most of the bugs are just user created. Lack of knowledge or no one's ever used it before. That are confusion. When you set up for the first time you're going to be really frustrated just like anything else. The first time I set it up I'm like, what the fuck, just use SQL or something. But after a while I realized, okay, I see where this fits in. I haven't run into any major bugs. That's easy though, because you dump it to an LDAP pull out what you don't want and then dump it back in. I mean, you'd think. That's a way I found to fix the database a lot of times. Just dump it to an LDAP pull out what you want and then dump it back. Anyone else? Who's talking about corruption in databases? Yeah, I have problems when you're setting up a replication. Yeah. It just dumps see the format I have here on the command line. It just basically dumps the database back to that format out of the DB format. So you can go in there modify it or replicate it, back it up, show it to your friends, tattoo it on your back or something. Not very. Out of the box. Well, the problem you're going to run into is if it's on your DMZ and someone knows it's there they're going to be able to query it with certain user information. But if you have it on the DMZ specifically for a few machines on the DMZ you can have it post simply what it needs. You can have it post the portion of the directory that it needs. I don't know, say you have a list of all your clients through web servers in the LDAP server you can have the one on the DMZ hold only that and have it replicate or work with an internal LDAP server. Yeah. I haven't used TAC-AX before. I actually have to as soon as I get back I play with TAC-AX. LDAP vs. Radius I was bored a long time ago and I wrote a Q mail back in in Perl that used Radius for authentication and user information and it's pretty convoluted to use Radius to store real names forwarding addresses mailboxes pictures of people what languages they speak I think it should stick only to doing authentication with Radius. Authentication and pulling down network information not raws and not information. Authentication you have the benefit with Radius because more stuff supports it right now. Well there is some regions authentication accounting is one of the ones you mentioned and authorization you're going to win with LDAP every time. If you're running the NIS back in with LDAP you can have it do everything on your machine so you're going to have the benefit there and it can be distributed too Radius you can do the whole what is it called authentication with Radius but you're still limited to authentication you can't store as many objects in Radius so authentication you're probably going to win with Radius if that's all you want to do that answer your question convoluted enough you can flag me down later anyone else I bore you to death enough okay you can I'll have slides for you you can get them here I'm going to write down the URL or if you know me it's my email address always around always available if you see me here at cons just run up to me ask me a question whatever I'll either avoid the question or deny it that's been LDAP that's what I know that's what you know now hope you enjoyed it whatever whatever