LDAP Tools - Where are they?

fixe asks: "I have spent the last few months up to my eyeballs in LDAP. While I am still hopeful of what LDAP can bring to the table I am admittedly disappointed in the tools, support and documentation surrounding the standard. I have been successful at creating and populating an LDAP directory and even authenticating against it, however I cannot find decent replacements for useradd, userdel, usermod, passwd, etc. Nor have I found any decent LDAP editors or browsers (preferably console or web-based). I am hoping that the Slashdot crowd might be able to shed some light on the subject. Are there any LDAP veterans out there who can reccommend any tools? What is the best way to maintain system account synchronization with an LDAP directory? Or perhaps, is there a more attractive alternative to LDAP?"

Re:Directories are dead in the water

[DeathBunny]

>Yes, there are people using LDAP, there are even people using X.500 - but more or less these >technologies have not altered IT thinking in the dramatic way they were positioned. Arguably the >XML-based approach of web services is more timely -

XML is a file format (or metaformat), not a directory service like LDAP. The two technologies are orthogonal.

>its hard to make an argument of listing >another protocol on an isolated port to provide a >solitary service

<sarcasm> Yeah that's a great idea! Let's run everything over port 80! </sarcasm>

>There also doesn't appear to be much corporate interest - Microsoft has moved its mindshare >strategies to web services, leaving the only big backer of LDAP being Novell - not really a key >industry player at this point.

Hello?? Active Directory is LDAP based. Admittedly it's LDAP with the usual "embrace and extend" twists like proprietary Kerberos extensions and slightly non-standard schemas, but LDAP none the less.

Re:Java based browser/editor

[PacketMaster]

Yeah, I use this to adminitrate my Linux network that uses pam_ldap to authenticate users corporate-wide. It's a terrific tool.

Re:ever hear of Freshmeat?

[Anonymous Coward]

Well that's fantastic. Except you failed to mention even ONE of all the tools you had "NO PROBLEM" finding. Why did you even bother posting you piece of shit?

Re:Anything but OpenLDAP

[sheldon]

Ahh, and so goes the struggle of Open Source.

It all works fine on someone's home machine, because it's never under any load. Try to put it into a moderate production environment, though, and it all falls down go boom.

I used to hear similar comments about open source NIS implementations 3-4 years back.

So you either start load testing it yourself, understand why it's broken and fix it. Or go with a commercial product that has already been through this process.

*sigh*

[kikta]

First, yes I know that this is probably a troll. However, on the off chance that it isn't, I have these questions for the AC.

1) If the public protocol is leaky, why not develop their own, totally different & competing protocol?

2) If they did care about the public domain issues and improvement, why not submit their improvements to the standards body to have their "improvements" included?

3) Failing or separate from this, why not license out their "improvements" to other software vendors? They would still make money, right?

I think the truth is that while it is possible that MS may have made a few small improvements (doubtful, but possible), their real goal is to ensnare new customers and to dig existing ones even deeper. If you still disagree, I would appreciate hearing any lucid arguments.

Re:Why use LDAP?

[dublin]

I think NIS is the best open source solution for Linux. NIS+ server code for Linux doesn't exist yet, but the client code does...

NIS+ is a truly elegant architecture, in many ways, what AD should have been. It's far superior to AD, LDAP, or any other X.500-derived directory - that ISO/OSI brain damage is just too deep to let X.500's ilk be easily used in the real world.

Unfortuantely, Sun really botched its attempt to get NIS+ accepted, for several very good reasons:
1) Although the directory itself was incredibly impressive, and worked very well, there were NO administrative tools usable by mere mortals. I was a "Network Ambassador" at Sun at the time NIS+ was attempting to make inroads, and I can tell you that even amongst that elite group, not 1 in 50 was capable of setting up and properly administering NIS+ in a configuration suitable for enterprise use. Some things were just impossible, like recovering from a lost root key: You just had to rebuild everything from scratch. Secure, but hardly practical. This inordiante complexity may well be why there's still no Linux NIS+ server (besides the fact that one would be pointless now...)

2) There was no good migration plan from NIS to NIS+, and no way to keep the two in sync: it was pretty much an all-or-nothing scenario, at least for the Unix boxes. Not surprisingly, lacking Microsoft's arm-twisting ability, all but a handful of Sun's customers chose to pass NIS+ by, no matter how good it was.

3) Sun tried hard, but didn't make adopting NIS+ sweet enough for IBM and HP, who at one time had "committed" to putting NIS+ into their Unix OSes. Unfortunately, the combination of NIS+ being perceived as "Sun's" and its underwhelming adoption even solid Sun accounts (due to reason #1 above) led to its not being considered a serious contender.

4) If you really know what you're doing, it's possible to build a hierarchical multi-domain name/directory service using NIS, although I only know of one company (a Fortune 20 former employer) that's ever actually put this in production enterprise-wide. All the capabilities are there, it's just that very few people bother to figure out how NIS really works. We eventually wound up replacing regular NIS with a security-enhanced superset NIS (and appropriately modified utilities) of our own design, where all appropriate changes at a higher level filtered down to the lower domains, and each domain only had to administer its own portion of the namespace.

Sad, but I'd say NIS+ is pretty much completely irrelevant now.

Microsoft and AD have won this battle so far, but it may once again be the unlikely knight Samba that will save the day and turn the tide. We'll see.

P.S.: Side note to comment 1 above: This is just one in a long line of times Sun has developed extremely impressive core architectures and failed in the marketplace. (NIS+, SunNet Manager, Jini, Jiro, and even Java itself, to some degree...) The fallacious assumption is that the elegant core is all that's required, and that dealing with pesky details like administration, management, or writing apps that take advantage of the elegant plumbing can be left as an excercise for the customer, not something worthy of Sun's time and attention. When will they learn?!

Re:Anything but OpenLDAP

[sheldon]

"Basically, you're assuming that all open source projects are little home things that, in order to make them "real", need to be adopted by commercial interests and "fixed". That's just silly."

No I'm saying that any time you post a query about most open source projects not working for you because of load issues, the response is "It works fine on my little home network."

Listen, load and stress testing an application takes a fair amount of resources. It takes money to buy the test hardware and execute tests and such. This isn't something most people can do on their little home networks, so it takes corporate investment to make it happen.

How many people do you know who have a dozen servers and 200 desktops sitting in a room just waiting around for someone to setup and run some tests?

Companies like Compaq, IBM, Microsoft, and so forth have these resources. If Compaq and IBM view OpenLDAP(or whatever) to be critical, perhaps they will make their testing labs available to the open source developers.

Otherwise you are relying upon testing in production, which is not the way to win friends.