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

[VolciMaster]

I don't know if any of these directly answer your question, but there is a whole raft of available LDAP books from places like B&N: for example here.

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

[Anonymous Coward]

> Just how many LDAP deployments of millions of users have you seen?
Here, here!

Re:Can somebody answer this

[Penis_Envy]

How would a flatter DIT alter replication significantly? At the very least, it would be easier to manage with fewer replication agreements. Would you be referring to catching up to the changes? That problem would exist no matter what, given a certain number of entries or number of changes.

I'd be interested in hearing your experience, as I've been on deployments with hundreds of thousands of users under an OU. Most directory structures are going for a flatter design (per resource type), using attributes to define location.

At the ISPs that I've dealt with, they have many hundreds of thousands of users under ou=people. There's simply no logical way of breaking it up beyond what mail store the users are on. Anything beyond that would be adding unnecessary complexity. What Directory products have you dealth with that have subdivided OUs so? If anything, you would like a shallower Directory, rather than a deeper one.

Re:Can somebody answer this

[Anonymous Coward]

What? Where? Talk sense, man!

Re:Can somebody answer this

[Anonymous Coward]

I have about 75K records hanging from my ou=People, because I have plain students, but sometimes they become professors, and there's staff that signs up as students, so I just have a flat space and attributes for category, department and so on. I also maintain a few small group objects for specific purposes.

In fact i'm staff, proffesor and student myself, in different departments, so when learning about LDAP I saw all the silly deep geographical/functional tree examples and always thought:
"from which branch should I hang myself then?"

I have come to hate LDAP though, mostly because keeping it up to date is a pain, it's slow to the point that sometimes I have to keep the updating proccess running 24/7 just to keep up with the changes.

I guess I'm doing something wrong somewhere, but don't think i'll do better than going from slow as hell to just plain slow.

Re:Can somebody answer this

[ian13550]

Obviously you are talking about replication agreements that can only be defined at distinctive branch points in your DIT (ie, OUs). The more rebust Directories can do replication on an attribute level (Novell eDir comes to mind but there are others).

Bottom line: It's very 1995 to create your DIT based upon location or department. I've worked with more than 1 Fortune 10 company that had several million entries in a Directory with only a handful of branches in their DIT. Think about having to move users in your directory every time they change departments or your company re-orgs..It is a HORRIBLE way to design a DIT.

Re:Can somebody answer this

[Anonymous Coward]

OUs work great for healthcare.

corporate office -> many hospitals -> many clinics & doctors offices / users on local network

Its useful depth :)

A shallow OU for us would be a nightmare

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.

Re:Can somebody answer this

[netsrek]

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.

Give the man a cigar!
screw this dividing everything up in branches... attributes are the way to do this.

Re:Can somebody answer this

[chrome]

you must be. I'm running a similar directory for about 90,000 mail accounts and the lookups are blindingly fast. Updating also.

One master, two replicas.

Use fast machines with lots of ram, hold everything in memory. Run a recent version of OpenLDAP.

Re:Can somebody answer this

[Anonymous Coward]

25 Million objects - 1 tree flat. Believe me not by choice - it was a SW requirement. One which I have repeatedly mentioned to the developer.

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.

Re:Chapter title based review

[Anonymous Coward]

No kidding. Might as well be a two chapter book:

Chapter 1: What is LDAP
Chapter 2: Installing, Running, And Admining LDAP.

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.

Re:Access Control

[tzanger]

My biggest question is in schema design. I mean there are hundreds of schemas out there yet it seems next to impossible to put them together intelligently to get an object that would allow something along the lines of

• name, nickname,position, etc.
• contact info (address,phone,email)[home/biz/alternate]
• samba/u nix/whatever identities
• GPG public/private keys, x.509 certificate information, etc.
• connection information (secretaries, wife, children, pets)
• anniversaries (birthday,marriage,etc.)
• photo
• biometric ID
• some access to a free-form series of notes on the person

The last one could be done with some kind of GUID you could link outside of the LDAP server but the rest seem to be impossible to bring together in an organized fashion. I mean this kind of thing must have been done ages ago but the schemas seem to be lost. I'd love to get an LDAP server set up to keep this information in one place but I always get lost in the schema design.

Re:Access Control

[aaronl]

Then make your own schema. It's really easy to do, you just have to watch on the numbering. Take a look at a schema file in OpenLDAP, for example, and you'll see what I mean. It's very straight-forward, and they're fairly self-documenting.

If you poke around you can find schema's for apps out here, like Netscape. There are keywords to mark compatible types too.

Re:Access Control

[tzanger]

You missed my point, almost entirely.

I didn't say I couldn't create my own schema. I said that something as obvious as what I described should already exist somewhere, and I was hoping someone reading knew where it was. I didn't want to reinvent the wheel with something inferior. I mean I can't be the only person on the planet who is looking for even 70% of what I listed. I'm sure it's been done before and likely includes things I didn't even think of.

That's the bigger problem with LDAP I think -- once your schema's designed it's a bear to change to something else. Possible yes, but pretty... certainly not. :-)

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

[Anonymous Coward]

It's obvious you haven't read the book. All the information in the book points to LDAP not being used as a database and helping to structure info. You're a Linux weenie and your web site sucks.

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

[Anonymous Coward]

This is because LDAP isn't used widely outside enterprise markets.

It's not going to be usefull for a web/file/print server unless they are part of a wider sceme.

It's for managing large amounts of desktop users (as in Microsoft's LDAP service (aka Active Directory)), and user information, which isn't something you see very often with Linux deployments.. yet.

Re:Disgustingly Bad Book

[bananasfalklands]

Whenever I put someting in production I prefer that is remains 'independant' from a single host

So should disaster happen I can
1. fix 'broken' thing
2. restore backup
3. change hostname
4. Problem ?

Ldap (like imap) is ideal for this
The sooner a good book on ldap appears the better for Linux.

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.

Re:Disgustingly Bad Book

[Just Some Guy]

Openldap still appears to be a 'priesthood' occult.

I kind of have to disagree. I set it up to replace NIS and serve as a shared addressbook on my little home LAN. I wouldn't say it was easy, but I don't consider myself a once-in-a-lifetime genius and I was able to get it up and running with only the documentation I could find online.

I'm sure a professional LDAP admin would laugh at my setup, but it serves my purposes and is easy enough to maintain. A steep initial learning curve? Sure. Unlearnable by a reasonably bright admin with a desire to figure it out? Nah. I don't think it was any worse than Apache or Sendmail.

Re:Disgustingly Bad Book

[mrroach]

I am working on a tool to make ldap (along with kerberos, sasl, samba etc.) easy to deploy for actual humans :-). At the moment it targets Debian/Ubuntu, but support for additional distros is coming soon. If anyone is interested in making ldap/kerberos ultra-simple to deploy, i.e. easier than AD, check it out: EDSRealmAssistant

-Mark

Re:Disgustingly Bad Book

[cortana]

Care to recommend something else? There are about a hojillion books of this nature, and I am afflicted with the subtle tyranny of choice. :)

Re:Disgustingly Bad Book

[cortana]

Erm, whoops. I replied to the wrong commont or something. Which I've now closed the tab for. Argh. Much gnashing of teeth.

Re:Disgustingly Bad Book

[tjackiewicz]

I'm not sure where the whole "LDAP IS NOT A DATABASE" comment comes from. It is made very clear that it's not. There are many examples showing that today, many vendors use it as a database.. and it is made clear that it is wrong.

Re:Disgustingly Bad Book

[chrome]

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

Yup, have to agree here. I do believe OpenLDAP is getting this soon though. I think its in the latest betas.

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.

I'm sorry I can't give you anything better than colloquial evidence, but I do run a 700,000 email a day system and every mail coming in is one to three LDAP lookups. The CPU load on my load balanced OpenLDAP servers is never more than 0.01 load average. The machines are 2.8Ghz 2GB memory IBM 306's. I think performance has less to do with what directory product you use, rather how fast your hardware is. Considering that licenses for a commercial directory server probably equals an extra server, I'd rather have that extra server ;) It would be really nice for someone to do benchmarks though.

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

I'm always caught between two opposing viewpoints when I think about the "benefits" of vendor support. If its a company like Oracle or Sun, then I think there is validity to what you say. But, for smaller products, or smaller vendors, "vendor support" can be a two edged sword. I've been left wishing I could send an email to a public mailing list to ask what the hell was going wrong with a proprietary system and knowing it was impossible. With products like OpenLDAP, you generally post, and one of the developers answer. How does that compare with Oracle? You usually have to climb through 15 levels of beuracracy before you can talk to an actual developer!

Re:Disgustingly Bad Book

[Penis_Envy]

Yup, have to agree here. I do believe OpenLDAP is getting this soon though. I think its in the latest betas.

Well, it's going to be a moot point as soon as redhat releases the Netscape Directory server source that they bought. They've had a few patches over the years, but nothing that made it into a release.

I'm sorry I can't give you anything better than colloquial evidence, but I do run a 700,000 email a day system and every mail coming in is one to three LDAP lookups. The CPU load on my load balanced OpenLDAP servers is never more than 0.01 load average. The machines are 2.8Ghz 2GB memory IBM 306's. I think performance has less to do with what directory product you use, rather how fast your hardware is. Considering that licenses for a commercial directory server probably equals an extra server, I'd rather have that extra server ;) It would be really nice for someone to do benchmarks though.

I would say that system load does not necessarily equate performance. I agree it's lightweight, but it does not respond as quickly as the commercial products. Unfortunately, the only benchmarking document I could find is from 2001, which is rather outdated, and OpenLDAP has come a ways since then.

I would disagree that faster hardware == faster directory. To a point, that is true, but when you get into larger Directories and higher utilization of the Directory, the software has a huge impact. Granted, anything on a 486 with 16mb RAM is going to be slow.

For the record, (700,000 * 3) = 2.1m queries/day. It's a decent load, but it also depends on what kind of queries are being performed and how many entries there are, etc... Just listing how many queries isn't very telling of performance.

I'm always caught between two opposing viewpoints when I think about the "benefits" of vendor support. If its a company like Oracle or Sun, then I think there is validity to what you say. But, for smaller products, or smaller vendors, "vendor support" can be a two edged sword. I've been left wishing I could send an email to a public mailing list to ask what the hell was going wrong with a proprietary system and knowing it was impossible. With products like OpenLDAP, you generally post, and one of the developers answer. How does that compare with Oracle? You usually have to climb through 15 levels of beuracracy before you can talk to an actual developer!

Agreed. It's irritating digging through sun support at times, and binary patches are irritating as well. Yet another reason why I am waiting for RedHat to release their purchased Netscape DS. It's the best of both worlds. Can't wait!

Re:Disgustingly Bad Book

[chrome]

For the record, (700,000 * 3) = 2.1m queries/day. It's a decent load, but it also depends on what kind of queries are being performed and how many entries there are, etc... Just listing how many queries isn't very telling of performance.

You're right, of course. There are 94,000 entries in the directory. Entries are mostly a posixUser objectClass with a few extra attributes to support our mail system (based on qmail+ldap, but we don't use qmail anymore - we use exim).

The entries are small. Replication is fast. Queries are fast.

crude benchmarking with 'time' and ldapsearch shows me each query taking 0.011s to complete. Most of the has to be network overhead. The directory is small enough to sit in memory.

Those 90,000 entries are using 235MB of ram (i heavily index everything, probably too much to be honest) and lets say it scales linearly, I will hit the 2GB of memory limit at about 700-800,000 entries. At which point I start buying opterons? And start optimizing the directory, I guess.

If OpenLDAP is slow, I don't see any evidence of it yet. Maybe in time I will. I will probably look at the Netscape DS when its released.

My first experience with Netscape DS was when it was iPlanet a few years ago, and I was planning a migration of 2.5 million mail accounts into it. It didn't strike me as anything special, though I did like the user interface ;)

You can spot bad consultant from a good one

[Anonymous Coward]

when he enjoys touting obscur acronyms like LDAP 30 times without mentioning what it means even once.

Good things about this book

[Anonymous Coward]

It covers more recent RFC's that are typically not even mentioned in other references. It also covers both commercial and open source solutions to problems of scaling, standards, and interoperability. Also, this is a fast paced book and covers in just a few pages what other books fill with useless garbage and repetition.

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!

Re:Thanks for the Review. Any recomendations?

[bigsmoke]

Even after learning much of the inns and out through trial and error, this book has taught me a great deal I didn't know and desperately needed to know (often without me knowing how desperate).

You can spot trolling ACs...

[Anonymous Coward]

...when they can't even visit Google and click on any of the first few results, which immediately explain what LDAP is.

Re:You can spot trolling ACs...

[Anonymous Coward]

You can tell a shitty author when they write an article with no explanation of the key issue they are writing about.

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.

Re:You can spot trolling ACs...

[Anonymous Coward]

What's an "IT" acronym?

Re:You can spot trolling ACs...

[Anonymous Coward]

I hope you never write anything again, you fucking worthless turd.

Re:You can spot trolling ACs...

[Hecatonchires]

Goblins need *urk*?
got no uncles
green needy ugboots

Re:IN CASE IT GETS /.ed

[chronicon]

Uh, are you expecting Slashdot to get /.'d?

If we can't see the original post, we can't see your "mirror" either.

A very cruel joke on us indeed...

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!

Oops

[Anonymous Coward]

It also provides several manpages in case you accidentally deleted the 'man' command on your own system.

That'd be one hell of a 'woopsies!'

-Rick

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:ldapsh

[Anonymous Coward]

...ldapsh, which lets you [...] use vi to edit records.

You say that like it's a good thing...

Re:ldapsh

[oneiros27]

It might let you call other editors to modify the records -- I've never tried. But it's still better than trying to create the correct LDIF so that you can pass it to ldapmodify, no matter how much you might dislike an editor.

Re:ldapsh

[sloanster]

Too bad there is no support for linux - other than the totally obsolete 2.2 kernel. We haven't deployed any linux 2.2 systems in this millennium.

Re:Thank you!

[jedidiah]

nis++

On a related note...

[mrtrumbe]

I noticed from the review that this book covers OpenLDAP and SASL integration. Was there any info in the book on integration with Kerberos + SASL? I realize this is probably outside the scope of the book.

Also, given that this isn't a great book, are there any recommendations for guides on implementing SASL + OpenLDAP out there? Again, I am specifically looking for OpenLDAP + SASL + Kerberos. And pushing even further, any good guides to using Mac OS X as a Kerberos / OpenLDAP client. (Yes, I know OS X Server does a lot of the work for you, but I'm cheap and want to set it up on my own.)

Taft

Re:On a related note...

[Anonymous Coward]

Stanford has information on OpenLDAP, SASL/GSSAPI and Kerberos at:

http://www.stanford.edu/services/directory/openlda p/configuration

Re:On a related note...

[Anonymous Coward]

Well, OSX has a directory services plugin called LDAPv3. It has preset mappings for Open Directory (which is really OpenLDAP with Apples client management/policy schemas loaded into it), Active Directory (for direct LDAP access), RFC2307, and custom. In custom, you can manually map all LDAP records on the client to suit your needs. You could map all the attributes manually, but if you are setting it up yourself, you should at least start with 2307. It defines a set of attributes that are commonly needed across most *NIX systems such as "uid", "gid", "NFSHomeDirectory", "loginshell", etc...

As for the server side, you are correct. Mac OS X server integrates OpenLDAP, MIT KDC, and SASL (password server) together and slaps a pretty decent UI on them. The advantage of this is not only that you get the Apple UI, but that Apple tests all three software projects and makes sure the versions jive well with eachother, and then releases the relevant security patches for them. For a lot of people, this is worth more than the money they would save integrating, updating, and fixing the software on their own.

The tools themselves provide a "unified" view of the three services. For example, when you create a user in their "Workgroup Manager" tool, it creates and manages the user record in LDAP, the principal in the KDC, and also the password in the SASL password service. This solves a lot of syncronization headaches as you don't have to write scripts and such to keep these three components in sync.

Re:Uh just me?

[eno2001]

Time to turn in that "geek" card? Huh? ;P LDAP is only the most happeningest approach to directories this side of the dead tree yellow pages! ;P

Laugh, it's funny!

OpenLDAP Schemas?

[eno2001]

I'e been through the configuration and installation from source of OpenLDAP several times. It's pretty straightforward. Where I run into trouble is the schemas. It's incredibly hard to find EASY-TO-UNDERSTAND docs on schemas. I've glanced at the RFCs, but they are too atomic for my needs. The two main things that I think any beginner needs to know with LDAP are:

1. What are the existing default Classes and attributes in OpenLDAP?
2. How do you add your own custom classes and attributes?

My most recent experience was last week when I installed OpenLDAP on my workstation to try and test some things. I got as far as putting in a single username within my DC tree, but I hadn't a clue what other attributes that Class had. I guessed at trying to do:

mail:
e-mail:
inet:
internet:

None of those worked. (My main experience with LDAP is Sun's implementation in the iPlanet products where they use 'mail' as an attribute of the Person class.)

It's also been my experience that many of these books get outdated quickly, so I really don't bother reading or buying books anymore. I mostly rely on online documentation which tends to be better overall. However, there does seem to be a dearth of LDAP documentation. What to do?

Re:OpenLDAP Schemas?

[Anonymous Coward]

To get information on what schema elements (objectclasses and attributes) with syntactic rules and dependencies, you can either login to your server running slapd and start reading *.schema, or you can use some gui-tool like Luma or GQ. Both these and possibly other tools have schemabrowser.

Proprietory implementations like Oracle Internet Directory and Sun Java Directory Server among others have their own java gui to browse and edit schema elements as they store this information inside the ldap dabase and not in flat files like OpenLDAP.

As for writing your own schemas, specifically for use with OpenLDAP, I suggest looking at
http://www.openldap.org/doc/admin22/schema.htm l#Ex tending%20Schema
and http://cvs.sourceforge.net/viewcvs.py/gnomis/norEd u/norEduPerson.schema?rev=1.3
and see how they make use of ObjectIdentifier for increased readability of OID numbers in attributes and objectclasses.

Re:OpenLDAP Schemas?

[afindlay]

You are right about the lack of good material on schema design. I surveyed the web a few months ago and found very little (and some of what I did find was trying to treat LDAP as a relational database!).

As a result, I ended up presenting a paper on LDAP Schema Design at the UKUUG Winter Conference. The paper covers issues of tree design and also entry design, and explains why the examples used in X.500 and early LDAP documents are not indicators of good practice. The full paper is available from my own website in both HTML and PDF formats.

In answer to your question about existing classes and attributes, I suggest getting either GQ or jXplorer - both include schema browsers which can help you to understand the relationships between the various elements. GQ may be in your favourite Linux distro. jXplorer is Java-based and I have run it happily on both Linux and Windows. In both cases you need a running LDAPv3 server as the schema that they display is the "live" one.

Andrew Findlay, Skills 1st Ltd

Re:OpenLDAP Schemas?

[eno2001]

Excellent info! Thank you VERY much! :)

O'Reilly book

[bananasfalklands]

By Carter - Its a bit thin - ideal if your member of the ldap priesthood. OK for syntax.

Re:O'Reilly book

[MyDixieWrecked]

The O'Reilly book actually helped me out a lot. My only complaint with it was its lack of ACL info (it would have been nice if it had an ACL cookbook, like) and lack of alternate configureation techniques (like if I wasn't going to set it up based on location).

It got me to the point of setting up slapd and getting my directory populated with the migration tools, and the Gentoo LDAP Authentication How-to got my server up and running on my Gentoo box.

It also has some great examples of PERL's LDAP libraries and functions.

IBM Commercial Products and a good Book for free

[browncs]

Domino is not the thing to get from IBM for LDAP. It drags along a ton of non-LDAP stuff.

From IBM, you should go for the Tivoli Directory Server.

It is a full function DB2-based directory server. Best of all, you can download it FOR FREE.

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

I'm a Man Page Reprint Hater (MPRH)

[Anonymous Coward]

It also provides several manpages in case you accidentally deleted the 'man' command on your own system.

I hate that! Or the book just has the same info as a reference doc on a webpage with some names changed.

I partly blame that on the need for books to double as anchors in case you're out at sea. They need to cover everything and its brother, and since no one can write that much they end up lifting online docs. Why are there 700+ computer books out there? If it is so complex, make two books out of it. I would rather pay more money for something that is concise and presents a new perspective.

I used to look at books as an expense, ie "this book is $50!!!" Now I look at them as time savers. If I can get one thing out of a book that saves me a couple hours of poking around online then my $50 was well spent.

Re:I'm a Man Page Reprint Hater (MPRH)

[otis wildflower]

That's why I stick with O'Reilly almost exclusively.

Re:I'm a Man Page Reprint Hater (MPRH)

[Anonymous Coward]

This publisher in general should not be written off. They've put out some really great books. I've personally had the opportunity to read Holub on Patterns, Practical Subversion, and Test-Driven Development: A J2EE Example, all of which were worth -while. -- John Flinchbaugh

Re:IBM Commercial Products and a good Book for fre

[bananasfalklands]

BTW link returns a 404 ?the /.ers strike again?

Do i need to login? - it's the reason I hate all IBM websites.

I'd love to do it myself in openldap - after all its only text files put through a parser to a bdb

Re:IBM Commercial Products and a good Book for fre

[dwarfking]

Be careful with this however. Because it is DB2 backed, modifying the expected object schema is a bit of a pain. Netscape's LDAP and OpenLDAP are better in this regard.

If you have no need to change the schema and are comfortable with DB2 admin issues, go ahead and look at this. It really didn't work well where I used to be (as a replacement for the old Netscape LDAP) and was being removed.

No crucification necessary

[cbreaker]

There's two primary differences between AD design and conventional LDAP directory designs.

While AD is extensible and you can use it in nearly any instance where you could use a "standard" LDAP directory, it's designed for a corporate network. The basic structure, client access, and replication topology of AD is meant to serve this end. It's less flexible, but it works really well.

AD was created in 2000, where broadband and otherwise high speed connections were quickly becoming commonplace between company offices. Because of this, AD pretty much replicates the entire database to any of the other DC's in the domain. There's not much in the way of partitioning. While this would be a nightmare in the days of 56K lines being the strongest, or dial-up, now a days it's not all that bad. And you end up with a fully functional database in each location, if you need one. In this way, it's much easier to organize AD into logical groups instead of geographical groups.

At my company, AD is designed first by IT policy-user type/Security policy, then by geographic region.

On the other hand, LDAP itself has been around for quite some time and many conventional practices involve partitioning off the database into replicas only necessary for each site. While this makes good sense for the most part, it also complicates things. Most LDAP admins would never imagine replicating the entire directory out to each site, and maybe I wouldn't either - but with Active Directory it works because it assumes faster links, and it's right, in the year 2005.

If I were to design a corporate directory with OpenLDAP, I'd probably model some of the design after a typical corporate AD setup.

Re:No crucification necessary

[B'Trey]

Just to refine what you said a bit for any lurkers who may not be familiar with AD, AD is segmented by domains. All domains in a forest share a common schema, but not a common LDAP database. (There's a second database, called the Global Catalog, that IS common to and replicated across all domains.) If you do have an area that is connected by a low-speed connection, you can minimize replication traffic by giving it its own domain. Additionally, you can establish site links and designate bridgehead servers between sites. Within a site, all domain controllers replicate with each other, but all replication between sites is done via the bridgehead server. You can configure when the bridgeheads replicate. For example, you might restrict replication to night hours when the LAN sees less use and has more free bandwidth.

So there is justice to what you say - AD is a bit of a bandwidth hog compared to other versions of LDAP. But there are tools and configuration options that will allow you to manage and control replication traffic.

Re:No crucification necessary

[rikkards]

With AD in 2003 it gets a bit better where if a site does not justify having a whole new domain (i.e small amount of users or computers and slow link) by and putting a GC is not possible, by enabling Universal Caching will speed up logons.

Designating a specific server to be the bridgehead should only be done manually (opposed to the KCC designating it's own) if there appears to be some impact on one of the DCs during replication.
If you specify the bridgehead and it goes down, replication to the opposite site will cease until another server is designated.

Also you don't really specify when the bridgeheads replicate, you specify when replication can occur across the Site Links. Sorry just nitpicking but otherwise what you say is correct.

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

[bigman921]

AD is winning because of the MS domination on the desktop. It has nothing to do with LDAP in general. In order to have a well managed windows based network you need AD. It's really just that simple. Yes, there's an auhtenticaiton plugin system in windows that novell implements....but that's gotten novell next to nowhere. Every network out there that has windows machines runs AD. What's interesting is that AD is now moving out of the NOS space and into e-biz/enterprise space. People are using AD to manager partners & customers as well as employees.

Re:Microsoft Won

[Anonymous Coward]

Since when has RedHat had a propriatary "Directory Service" ?, they ship OpenLDAP.

They recently aquired Netscape and its Directory Service but that was only very recently and have yet to even release it as a "product". If RedHat plan to ship this with RedHat Enterprise Linux, it will be GPLed.

Re:Microsoft Won

[LordMyren]

the enterprise linux solution is really a complicated directory service, its just not powered by LDAP.

just look at the intersection between Active Directory and RedHat Enterprise Linux (RHEL). they both provide many user and machine management directory services. sure, EL provides more system rollout stuff as well, but there is a directory service in there, even if its not called so.

i really hope redhat does something Good (v. evil) with their Netscape DS purchase. couple months ago we had a RHEL talk on campus, and they mentioned how excited they were about it. I still havent seen or heard anything.

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

[lukehatpadl]

As others have explained, the prevelance of Windows desktops is one reason why Active Directory is being widely deployed. One alternative that runs on Linux is PADL's XAD.

Re:Microsoft Won

[Anonymous Coward]

OK, I've had enough belly acheing.....

I've worked with DS implementations since Novell put out the first version of NDS (NetWare 4.0). I've watched other vendors try their hand at it, from IBM to Oracle to Microsoft. So far, from the commercial point of view, Novell has the ONLY stable thing going.

From a programming point of view, face it, LDAP/DS is not simple. Microsoft's nonchalant attitude towards a usable and consistant interface is downright criminal. OSS solutions, including the venerable OpenLDAP, stink in the documentation area.

ALL books on the subject stink because there is a huge gap between the logical LDAP-managed network designers, the network (read LAN/WAN/Router dudes) administrators, LDAP programmers (backend developers, like those for OpenLDAP), and everyone else. So far as I can see, every book on the subject is more like the old "scratch that itch" OSS project. It fits the needs of the writer, which is a generally good thing. What we need, though, is a good central place for input from the community with WIKI/forum/collection formats to develop a good community base that we can all add our part into.

For Example:
1. Schema needs for Unix (AIX, Solaris, BSD(s), etc.), Linix, Posix requirements, Windows/Samba usage, integration... with detailed scripts to extend the schema foreach platform that the community develops...
2. Scripts to bring a standard distribution's OpenLDAP (or other) into alignment with general standards... This should eventually represent multiple distros/versions, as users commit...
3. Raw and/or canned install/compile/etc. instructions, with version defferences covered...
4. Integration sections for Samba, Pam, etc... Detailed, and simple... with scripts, by golly, donated by US!
5. Security sections: SASL+Kerberos+biometrics+whateverIfeelliketoday, etc...
6. Management practices to ensure stability, extendability, and scale... With scripts to automate management tasks, setup replication, test connections, etc...
7. tools, again donated by US, to wrap these scripts, build interfaces, or entire "products" that simplify management, installation, migration, and all...
8. More stuff, yadayadayada...

LDAP is here to stay. It is the only sane way to manage a large enterprise (Streettalk was pretty good....maybe I can.... oh never mind...). This is an important project and I'd like to work on it!

I don't (currently) have space or bandwidth available. If someone does, let me know and we can get something better going!

My login is cookied on another computer (have no idea what it is) so here is my email! (So there! I'm not an anonymous coward!)

$W%R$F$e%l%t%s$@%$h$o%$t%ma$i$l$do%t$$c$o%m

Get rid of the $ and % and figure it out.

Now, we've ranted enough. Let's get to work.

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).

Re:Microsoft Won

[Christopher Cashell]

In a recent interview, one of the higher-ups at Red Hat said they were currently cleaning up the Netscape Directory Server source code in order to make it usable and buildable (he said that it currently required a very complex and involved build environment, and was being simplified).

He said that he expected it to be released within the next few months.

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.

recomended book for LDAP

[Penis_Envy]

obligatory link to a book on amazon:

Understanding and Deploying LDAP Directory services:
http://www.amazon.com/exec/obidos/tg/de tail/-/0672 323168/qid=1110838872/sr=8-1/ref=sr_8_xs_ap_i1_xgl 14/002-0439029-3995207?v=glance&s=books&n=507846

A good book.

Re:recomended book for LDAP

[Penis_Envy]

Fixed link:

For the record, this is a general LDAP book, not specific to OpenLDAP.

http://www.amazon.com/exec/obidos/tg/detail/-/0672 323168/qid=1110838872/sr=8-1/ref=sr_8_xs_ap_i1_xgl 14/002-0439029-3995207?v=glance&s=books&n=507846

Re:recomended book for LDAP

[Anonymous Coward]

Shouldn't that be:
dn=book=002-0439029-3995207?v\=glance&s\=book s&n\= 507846,ref=ref\=sr_8_xs_ap_i1_xgl 14,sr=sr\=8-1,gid=1110838872,uid=0672323168,arbitr arydelimiter=-,levelofdetail=detail,subfolder=tg,f older=obidos,method=exec,service=www,dc=amazon,dc= com
title: Understanding and Deploying LDAP

Re:IBM Commercial Products and a good Book for fre

[browncs]

Sorry posted before I was finished.

You can download and use it for free. Only if you want support do you have to pay. It's also included with other IBM middleware such as WebSphere.

On the linked page there's also a link to an IBM redbook that has a few initial chapters on LDAP. Again this is free for the download.

Re:IBM Commercial Products and a good Book for fre

[browncs]

MY BAD. I somehow messed up the URL.

HERE IT IS.

Alternatives

[maverick97008]

One thing I really like on negative reviews is a recommendation of an alternative.

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.

Re:Another excellent free book

[Anonymous Coward]

I JUST FINISHED A CONTRACT PROGRAMMING TOOLS AGAINST MAD. IT STINKS!!! Yes I'm yelling. You have to triple-check everything you program by using multiple interface, including that awful IDispatch mess. The interface is inconsistant, dishing up some of the data for some objects but not for others (of the same object type). Sometimes one entry point will get the information you need, but not always.

Just ask MS where the ACTUALLY store the terminal services entries for the user account... They don't extent the schema, they extend a dll (through the dreaded, cumbersome, and downright stupid IDispatch interface) to make it look like it's in the schema. It's not.

Also, ask them why "Well known NT 4.0 objects" have problems in active directory. Getting group members, for instance, via LDAP or the LDAP-ADSI interface (MS's recommended and preferred interface for AD) is deceptively easy. If, however, your AD was upgraded from NT 4.0, "Domain Admins" MAY truncate the member list returned WITHOUT ANY ERROR! If you're auditing such groups as "Domain Admins" you may not see everyone in the group. The only workable interface to get ALL group members consistantly (sort of) is the WinNT-ADSI interface, which means that for some attributes, you have to instantiate one object type (LDAP-ADSI), and another (WinNT-ADSI) for group interaction. This makes for cumbersome and bug-prone code. ...and..... you had better have several layers of error checking going on!

THIS OBNOXIOUS BEHAVIOR IS CONSISTANT ACCROSS WIN2K AND WIN2K3 AD IMPLEMENTATIONS!

Don't put your Unix boxes under this "LDAP+Kerberose" monster! It IS broke and unreliable. They may have a nice document thingy going on for "Unix under LDAP" or whatever. Use it at your own risk, but don't trust it!

That, my friends, is an in-the-trenches, I-had-to-find-microsoft's-bugs-for-them, programming experience. All you Microsofties out there, don't even try and tell me I don't know what I am talking about. I've been in these programming trenches since before Novell waswell known. I could tell you of IBM's "ancient" attrocities too.... Nothing that MS has put out is original. It is bought, squashed,or arm-wrestled from competition... then made virtually useless. Linux, and the assundry OSS projects that run so well on it are FAR more stable, better documented, and, if you can believe it, easier to program for. I will not shed a single tear when MS finally bites the big one.

LDAP organisation

[ta bu shi da yu]

Not necessarily. Though it's common to do this, you can organise LDAP differently. Another way a lot of companies do things is via company departments and divisions. It really all depends on what is most flexible for your company.

I guess that many books on LDAP just assume that you are part of a multinational company and use this as an example.

Decent OSS LDAP browser?

[runderwo]

Does anyone know of a decent/usable OSS LDAP browser that includes schema/template editing? I'm using a closed source Java LDAP browser which barely works, but haven't found anything else even comparable yet.

Re:Decent OSS LDAP browser?

[ta bu shi da yu]

Have you tried GQ?

Re:Decent OSS LDAP browser?

[Anonymous Coward]

Tried http://www-unix.mcs.anl.gov/~gawor/ldap/ ?

Re:Decent OSS LDAP browser?

[martin]

JXplorer is nice....

http://pegacat.com/jxplorer/

Re:Decent OSS LDAP browser?

[Anonymous Coward]

Luma (luma.sf.net) comes to mind, as well as Directory Administrator and numerous webbased tools.

Gq is an oldie but goldie... but it has its quirks and hasn't been maintained properly the last couple of years. Apart from non-java,non-web applications only directory administrator and Luma seems to have a vital life.

Re:Decent OSS LDAP browser?

[wido]

A schema creator is currently in the works for Luma (http://luma.sf.net/). Depending on how much time I can spend on this, it will be ready in about two weeks. Basicly you will be able to create a pool of attributes and objectClasses and choose from them to export to a schema file. It will have multiple backends for different LDAP server, with OpenLDAP being currently the main focus. But others will follow in time.

Re:Decent OSS LDAP browser?

[runderwo]

Yeah, that's the Java one I was referring to in the original post. Thanks anyway.

LDAP Programming, Management, and Integration

[amsr]

Sorry to hear about this book. However:

LDAP Programming, Management, and Integration by Clayton Donley

is an excellent book on the basics of how LDAP works and how to set up LDAP services.

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?

Flat branches here

[alistair]

I have managed a large corporate LDAP implementation which has around 120,000 people in a flat branch of the tree. I have tested this to a million and have seen real world implementation with similar numbers.

Branches of trees should be used for your replication design and security model, they were very important as search bases in X500 but much less so in a typical LDAP directory.

Consider a organisation which has people in multiple countries. It is just as efficient to run a search from the base of people and searching on country name then to set the base as countryname and search for all people (assuming countryname is indexed)

However, moving objects in LDAP is painful and complex. So with a flat tree you would simple rename the countryname attribute, in the deep tree model you would effectively have to delete and recreate the entry to move it (some servers are better than others, but all do this with less than optimal efficiency)

You can still restrict your applications access to one country, either by using a filter in the ACL or using an LDAP proxy (SUN now give one away with their very useful Directory Server)

As for replication, on some servers you can do filtered or fractional replication which can improve the effeciaency of this process by allowing only certain parts through, ofthen this is more efficient than being forced to use a replication structure by your tree (which is very hard to change once your service is established).

The sad thing from a replication point of view in that when SUN brought out DS 5+ we lost the client request and timed replication, this certainly had its uses when you wanted to push updates out at specific times. As Red Hat have the code now I hope this is one feature they retain in their offering.

Better book coming...

[Phatmanotoo]

There's a book by Terpstra (of Samba's fame) coming this summer:

OpenLDAP by Example by John H. Terpstra and Benjamin Coles (0131488732)

If the quality is similar to any other of his Samba books, then this will become one of the best LDAP books.