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?"

Comments

Check out Microsoft's tools

[fawadhalim]

I know I'll get flamed like hell for writing this, but I suggest that you check out Microsoft's LDAP tools. I'm not sure about their interoperability with slapd etc, but they play along amazingly with Microsoft LDAP server.

Also, check out gq , which is a pretty nice GTK+ based LDAP client. It's still very barebone, but it's better than the commandline tools for a lot of tasks.

Re:Check out Microsoft's tools

[Craig Davison]

In Windows, LDAP browser is a good tool. It even shows you 'hidden' password attributes that get obfuscated by the Microsoft tools.

AFAIK, it supports LDAPv2, LDAPv3 and Active Directory. It supports most all SASL mechanisms, even NTLM when necessary.

I know what you mean.

[Rick_Clark]

I had to roll most of my own admin scripts. There is a great java based browser/editor though.

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

It is the best thing out there as far as I can tell.

Rick

Isn't Active Directory an LDAP implementation?

[Bistronaut]

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.

Slap me with a strongly worded post if I am incorrect, but isn't Active Directory an LDAP implementation?

Re:Isn't Active Directory an LDAP implementation?

[isomeme]

Slap me with a strongly worded post if I am incorrect, but isn't Active Directory an LDAP implementation?

Yes, it is -- among other things. Remember that LDAP is just an interface spec; it says nothing about underlying representation. Just as XML may be used to report the contents of a database or the results from a calculation or any other data source, LDAP provides a generic front-end on any vaguely tree-like directory services provider. Thereore, Microsoft ADSI offers an LDAP interface along with several proprietary interfaces for use in querying and modifying the underlying directory store.

To their credit, the Microsoft ADSI LDAP implementation is remarkably standards-compliant. I developed an app which authenticated users against OpenLDAP, and extended it to support ADSI as well with minimal effort (mostly involving generalization of assumptions about directory layout, rather than interface changes per se).

Re:Isn't Active Directory an LDAP implementation?

[thehunger]

Here are some major real-world problems with AD:

• It's Windows-only. It does nothing for Windows NT, 9x, Linux, Solaris workstations.
• When you install it, it disables all disk caching on the server to prevent corruption, affecting overall server performance by 50%
• It requires changes to your DNS infrastructure and can crash existing DNS servers
• Groups aren't scalable, supporting max 5000 users
• You cannot grant rights at the OU level
• You can't rename domains or merge trees
• There's no remote management. No web based management.
• For AD repairs, you have to be physically present at the server, reboot it into a special repair mode, log in with the non-AD credentials you used when you installed the server (if you remember them!), try to repair, and then reboot and bring the server up in normal mode. If the problem still isn't fixed, you must repeat the process. Talk about downtime!
• AD doesn't have true inheritance, which means that granting a Password Admin type user rights to reset every user's password can take forever.
• Similarly, granting rights to a file system also takes forever because OU's cannot be granted rights to files and directories
• AD is -very- resource intensive. Simple operations can take hours, and the database grows almost exponentially. Granting rights to a user to administer e-mail addresses for 5000 users will grow the database by 13 megs!

my preferred LDAP browser

[Doktor Memory]

Unfortunatly, the best LDAP browser/editor I've found so far is neither web- nor console-based, but is a Windows program. LDAPBrowser 2.0, from the nice folks at Softerra, has been invaluable in helping me figure out how to make a bunch of openldap-based client programs talk to an MS Active Directory LDAP server. It's free-as-in-beer, and they have a number of other cool ldap toys available as well.

You would think that wrapping a gtk+ interface around ldapsearch would be a straightforward and no-brainer proposition, but you would apparently be wrong.

Re:my preferred LDAP browser

[downwa]

For a gtk+ GUI LDAP brwoser, gq (http://biot.com/gq/) would probably be what you want.

For a command-line add/modify/delete utility, here's one I created:

http://pushan.integritysi.com/down/ldapuser

Windos tools

[alen]

I'm in the process of helping deploy active directory. MS Windows comes with some LDAP tools that aren't too bad. I'm still in the learning stage so I can't frame a good opinion, but first impressions are OK. But like everything Windows if you want to get into the guts of the OS you'll have to dig around for the info. MS prefers you use their MMC based admin tools which don't give you much control.

IBM LDAP Client

[dgenr8]

Go looking for the IBM SecureWay Directory Management Tool (DMT). It's a Java LDAP client that lets you edit the directory manually.

Active Directory

[flanker]

M$ is betting quite a bit on LDAP with AD, touting it as the number one reason for enterprises to move off of NT to 2000 server platforms. Unfortunately upgrading is such a complicated operation very few larger organizations are moving to it as fast as M$ would like. They have integrated all sorts of things into the standard directory service and it can be very confusing trying to figure out exactly what it is.

FWIW, Novell's NDS has been the only enterprise-class directory service since the mid-90's and AD is a play into this arena.

Of course, this is all moot since this is Slashdot and of course you aren't interested in technology from the Dark Empire (tm).

Re:Active Directory

[a9db0]

I've used NDS extensively in a couple of organizations and found it to be reasonably flexible and as reliable as a dead cat. NDS handles thousands of users, replicates across hundreds of servers, and has given me no grief. It's solid. It's reliable. It just doesn't have the mind-share it deserves.

Not a big industry player?

[Wolfger]

Daimler Chrysler is using Novell/LDAP. Sounds like big industry to me...

Re:Not a big industry player?

[CounterZer0]

Guess what powers Yahoo? Novell eDirectory (LDAP). Novell doesn't do much marketing, and they admittedly haven't been 'gaining' much market share, but they have some die hard fans, and some of those fans are BIG business. It's because LDAP makes a network so much easier to run. eDirectory provides a convient way to manage EVERYTHING on your network. And it supports multiple platforms!

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.

My Favorite tools

[Daeslin]

Of course, the standard commandline classics (ldapsearch, ldapmodify, etc.) that come with any of the major vendors stuff (Netscape's SDK, Novell's eDirectory).

Also, I REALLY like the java LDAP Browser for GUI use (available from http://www.iit.edu/~gawojar/ldap)

As far as account creation tools, there's some nice trends among the big user provisioning corporate grade systems (i.e. Access360) to manage accounts in LDAP.

I'd stay away from Active Directory since it doesn't follow all of the standards. eDirectory's only big annoyance is that it's LDAP is actually a mapping on top of their old stuff, so sometimes that adds complexity. But for a long time they had the only multi-mastered replication setup. iPlanent now has that and MS/AD kinda does (but they have crappy granularity on their objects in case of collisions).

libnss-ldap

[coyote-san]

Have you looked at libnss-ldap? Install that, set up your /etc/nsswitch.conf file to refer to ldap in addition to your other resources, and all well-behaved programs (re: that use the NSS routines in glibc instead of attempting to modify /etc/whatever directly) should update the LDAP records.

Anything but OpenLDAP

[Pegasus]

I dont know about commercial LDAP offers, but openldap led me to the conclusion to NOT use ldap anywhere. I still have it installed in three locations and am actively working in porting it to mysql or unix flatfiles, because it's so unreliable. nss library from padl.com for some reason doesnt always closes its connections, so you hit 1024 file descriptors limit within a week or so. yes, you can compile with -DFD_SETSIZE, but this only gives you more time until restart is needed. Second, replication never worked reliably, so trying to avoid fd problem with more replicas only casued more pain and sleepless nights rebuilding and reindexing databases (125k user entries, it takes 7 hours on 4way xeon). And if only the slapd itself would work! It stops responding every now and then, for no reason. OK, i can catch these with a trivial script ... but recently, i got more and more examples where connection is accepted, but result never comes ... so ldapsearch just sits there without answer, huh. I've also seen examples where some slapd threads would occupy one or more cpu in the box, slowing things down noticeably.

So, whatever you do, AVOID OpenLDAP.

Re:Anything but OpenLDAP

[whynot]

Some advice for rebuilding your LDAP-DB: Rebuild your directory on a RAMDISK, speeds things up by factor 5 for us. We are rebuilding our db on a daily basis. It has about 300k entrys and is 500MB in size and takes less than 60min to rebuild.

OpenLDAP dies a lot over here too. Replication works quite well for us, the only "problem" ist that slurd opens lots of processes for every replication target - our main ldap-machine is running about 750 processes at all times.

Don't even dare to try any 2.XX version of openldap - they have a lot of features you probably don't need and are even more buggy.

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.

Re:Anything but OpenLDAP

[smutt]

My organization chose OpenLDAP after doing extensive testing with IPlanet and DC Directory. We measure the size of our deployments in the 10's of thousands of users. I'm talking big honking SUN boxes with fiber channel, Gig-E and SAN's. I've found OpenLDAP(configured properly) stable and easily scalable. It's not the easiest thing in the world to setup, but at least it behaves deterministically and scales.

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.

What about "Directory Administrator"?

[DocSnyder]

Directory Administrator is a GUI (GTK+) frontend for user administration within a LDAP directory. It still requires some knowledge about a LDAP hierarchy, but it helps a lot.

My advice is to create two user hierarchies: one for administrative non-human accounts (e. g. root, mail, www) and one for real users. Same thing for groups. This way you can manage your real-user accounts with some kind of GUI frontend and even re-use the objects in an addressbook like Evolution Contacts without risking a security hole.

This has been a huge problem for us as well

[Casshan]

I am with a admin group trying to integrate a couple hundred UNIX and Windows machines into a single login using an Active Directory server, which provides us with Kerberos authentication, and an LDAP directory. (This was mandated to us "from above") The kerberos authentication of course was easy, however there is hardly ANY information about actually using LDAP in a production environment.. we are trying to use the active directory LDAP server to provide the POSIX gecos and home directory information for the UNIX clients... however the default Active Directory schema does not include RFC2307

Probably the most frustrating part is if you go on google and look for help, you see people mentioning that this works, but never any specifics. I assume you are just using pam_ldap to grab a password crypt from an LDAP server (which is a secure as giving everyone read permissions on your shadow file).

I think the best solution is to use an LDAP server to host all the user information that is normally in /etc/passwd. This is possible in Linux and Solaris using the nss_ldap module which lets you add an "ldap" entry to your network switch file, and use ldap instead of /etc/passwd. It seems the best solution is Kerberos for authentication and LDAP for everything else, which Active Directory can provide, in a mixed-OS environment even.. but has anyone been able to successfully run nss_ldap against an AD LDAP server? (without using services for UNIX or other kludges) LDAP seems to be an integration nirvanna.. but without proper documentation I am afraid it will never see broader use..

Re:This has been a huge problem for us as well

[sheldon]

Hmm, it's pretty easy to add fields to the Active Directory schema. There's also AD editing tools that will let you modify them at low level.

Failing that AD/LDAP is pretty easy to script using ADSI interfaces.

I've never done what you are looking at, but it doesn't seem like it should be that difficult.

Re:This has been a huge problem for us as well

[dillon_rinker]

I've never done what you are looking at, but it doesn't seem like it should be that difficult.

You have a very promising career in technical management.

Re:This has been a huge problem for us as well

[sheldon]

Haha. No I'm saying that the LDAP default install in AD lacking certain fields doesn't appear to be a challenge because they can be easily added.

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.

I'm a river of knowledge to my people

[foofboy]

Use it wisely

Re:Uhh.... what's LDAP?

[Jahf]

LDAP == Lightweight Directory Access Protocol (I think, that's from memory).

LDAP was originally intended to be a more flexible and less resource intensive implementation of Directories (phone books are a good example but not the only one) a'la the older X.500 protocol.

LDAP has been embraced by alot of companies like Microsoft and Sun (my employer) as a core server technology to form the "glue" between distributed services.

One of the most common uses is to maintain remote password authentication databases. Similar in concept to RADIUS or NIS, but in a more standard implementation without all of the overhead.

For instance, Sun is moving it's internal network to LDAP authentication (originally it was unconnected, later they used NIS, both older systems are still in use at Sun right now). It allows an employee to use the same password for many different resources on the internal network while having a single place to update that password.

Re:Directories are dead in the water

[AndyDeck]

I've got to disagree with your assesment that Novell is not a key industry player. Novell's eDirectory is the premier directory solution in a market that includes Active Directory, iPlanet, OpenLDAP, and others. Microsoft's attempt to cover for their weak directory solution do not in any way detract from the importance of a good directory.

And to answer the original question, eDirectory is the new name for Novell's NDS, a mature yet still evolving directory service that is fully LDAPv3 compliant. As it has been available for so long, there are MANY third-party tools and utilities available to manage it (such as Bindview or JRBUtils) in addition to Novell's own tools and utilities. Novell's eDirectory management utilities include import/export tools built in to ConsoleOne (an admittedly heavyweight Java-based management console) as well as BulkLoad, a command-line LDAP utility that uses LDIF files for command input. These utilities permit import/export of userids in LDIF format, as well as the migration of data between LDAP servers.

eDirectory is fully cross-platform, currently running on Netware, NT, 2000, Linux, Solaris, and Tru64 UNIX. It's been demonstrated at tradeshows with databases of up to one BILLION user accounts. Features of the latest version, 8.6, include persistent searches, dynamic groups, and live backup. The next release is expected to include UDDI, SOAP, and DSML 2.0 support.

Novell is practically giving eDirectory away at a list price of $2/user or less. They are actually giving it away for VARs and developers that wish to bundle eDirectory as the dedicated directory for their applications.

Oh, and if you wish to stay with open source options, look on Freshmeat.net for OpenLDAP - it includes a set of client utilities that should fit at least some of your requirements. Freshmeat should also have other LDAP clients, including browsers.

linux/unix LDAP user tools

[Paul Jakma]

checkout:


directory_administrator which is a GNOME LDAP user admin tool (slick enough for use by a frontline helpdesk).

there are other LDAP GUI's, KDE has one. search freshmeat.

gq a general purpose LDAP GUI tool. quite slick, comes with RH7.x.

Also, note that with RH7, the 'passwd' tool uses pam and will hence automatically work with LDAP authentication. (presuming your LDAP server is configured correctly for write access).

finally, you'll probaby want to develop your own scripts with template LDIF's for things like useradd, or find someone who's already done so. (i noticed there's a post on this thread providing a link to exactly that.) Note that for scripting, PADL's migration scripts are very informative. These are included with the OpenLDAP distribution.

You're not looking hard enough

[Anonymous Coward]

If you can't find LDAP tools, you havn't been looking hard enough. Here (http://www.dbaseiv.net/code/cpu.phtml) is a tool for doing unix style user management with an LDAP directory. Here (http://www-unix-mcs.anl.gov/~gawor/ldap/index.htm l) is a fully functional, really awesome ldap browser that I have used extensively. These are just a tiny sample of all the software for directly working with an LDAP directory. Check the OpenLDAP and IETF lists for more tools, OpenLDAP comes with quite a few as well.
If you have paid careful attention, you will notice that LDAP support has crept into hundreds and hundreds (of not thousands) of applications over the last year. The API's for doing LDAP programming yourself are also extremely well developed imho. You have options for C, PERL, C++, Python and a slew of other programming languages. Search Freshmeat or Sourceforge for LDAP and see what you come up with, I think you'll be surprised.
I don't think LDAP is dead, I think it's one of those protocols like TCP that just sneaks up on you with it's usefulness :)

LDAP is quite useful where I am

[hysterik]

I am employed by a major aerospace company, and have been using LDAP for several years for web based authentication. This has permitted us the option of "piggy-backing" any other web servers into this authentication scheme. The tools I have used have all been written by myself in Perl, using the Net::LDAP module. I believe there is at least one other module available to use, either available from CPAN. I believe Graham Barr is the author of this module. Using this approach, you should be able to build your own custom webpages for selective browsing of LDAP shares, and management.

If you're seeking some bonafide support options, you might confer with openldap.org, or better yet iPlanet's Directory Server. The latter would cost some money, but it is an option.

Novell's been "going out of business" for years...

[itwerx]

TSIA.
The fact is there's a niche between small business (Microsoft products) and Fortune 100 (*Nix) where Novell's products reside quite comfortably.
And eDirectory is a full-featured LDAP implementation in its own right. Not to mention the free version for Linux! (Registration required).

Hey, whad'ya know, I see that /. is filtering out the quotes in the link.

Here it is again in plain text for your cut'n'pasting pleasure:
https://download.novell.com/ICSLogin/?"http://do wn load.novell.com/download.jsp?cat=NDS&pid=646&targe t=sdExpLic.jsp"

The ultimate tool.

[Anonymous Coward]

Use Console One. It lets you manage your LDAP directory and a whole lot more. Imagine managing users, resources, printers, servers, EVEN files, all from a single Java based tool.

That's right you can do all this and a whole lot more, using Novell Netware. Even if you don't use Netware, eDirectory (included in Netware or sold separately) allows a lot of these functions from within the Java based Console One. It runs on almost any platform, available today. It even has additional modules that allow things like single signon and more. That's right, all the advantages of .NET without the bugs and security risks. And, the best part, is it has been shipping for quite a while now, unlike certain other vaporware products.

Even if it isn't free, for enterprise use, it is down right cheap!

LDAP Admin Help

[medcalf]

I've been working with LDAP for the past four years as a manager, consultant, administrator, project manager and architect in various situations and for various companies and clients. My experience has been with Netscape/iPlanet, OpenLDAP and Active Directory. I've worked on very small and very large projects. LDAP has the potential to bring amazing efficiency gains to an enterprise or Internet-based organization (ISP or ASP), but it also is fairly immature.

Let me rephrase that: the protocol is mature and useful, and the servers by and large are mature and useful, but the support tools stink, as a general rule. Since it sounds like you are mostly concerned with user administration, I will stick to just that, and let other people mention tools they've found useful.

If you are using Solaris, AIX or Macintosh, using LDAP for accounts is pretty trivial, since the OS supports it directly - you'll need to have the POSIX user schema loaded, and point the OS's naming service to LDAP instead of its local database. Win2K/XP kind of force you to use Active Directory, so you are also taken care of there. In all of these cases, accounts other than the system superuser will be in LDAP, and so therefore synchronization is not a problem.

useradd, userdel, usermod and passwd are all replaced by ldapmodify, or you can use the tools included with some servers (the iPlanet console being a good example of how to do this right). Right now, there doesn't seem to be any substitute for thoroughly learning ldapsearch and ldapmodify, Perl and Net::LDAP. You can use ldapsearch and ldapmodify for quick actions (adding, modifying or deleting a single user, or changing a password) and Perl and Net::LDAP for more complex operations (or for putting together a CGI for common functions like changing a user's password).

I find I end up writing built-to-purpose Perl tools just about everywhere I go. In some cases, this is because of differences in admin policy at different sites, or differences in schema. In others, the issue is more contractual (whomever is paying me gets ownership of the code I write, so I have to rewrite from a clean sheet at the next site).

The good news is, it is fairly quick and painless to write replacements for useradd, usermod, userdel and passwd which can be run from the command line or as a CGI, and you only have to write them once for your site, if you write them well in the first place.

-jeff

Just saw this on a mailing list:

[Teancom]

Weird, as this came in just yesterday on kde-pim:

Carillon Information Security Inc. would like to announce the release of
KDirAdm version 0.1

K DIRectory ADMinistrator is a tool for use by Directory Administrators to
manage their LDAP based directory. Using the K Desktop Environment (KDE) and
OpenLDAP toolsets, this application currently has all of the basic
functionality required to browse, add, and delete directory entries. As this
is an initial BETA release, the capability to modify existing entries, as
well as the ability to handle binary directory objects is currently missing.
This is planned for the next release, along with improved password entry
handling and possibly LDAP over SSL support.

KDirAdm is open source software released under the GNU Public License. As
such we encourage anyone to help us in the development of this software.
Specific jobs that need doing at the moment are improving the documentation,
the artwork, and of course, any LDAP wizards that want to help out will be
greatly appreciated.

The homepage for KDirAdm is at:

http://www.carillonis.com/kdiradm

where both source and Debian packages may be obtained.

Comments, suggestions, wishlist items and patches may be sent to
ppatterson@carillonis.com

So, it's "pre-beta" but has that ever stopped a true free software geek before? ;-)

LDAP, Tools, Servers et al

[JABOFH]

I've finished the process of migrating a fairly large ISP/Telco (1.5M users) to LDAP a couple of months ago. I've been at it for over a year, and
from my own experience I can tell you that:

1 - The best available tools are definitely the command-line that come with most servers.

2 - OpenLDAP sucks big time in large scale environments. It's replication is anything but reliable

3 - GQ is a very, very nice browser for LDAP. But I wouldn't use it for administration.

4 - You can assemble a whole range of ISP services (mail, ftp, http, whatever) based on an LDAP tree. Even if you can't find a _insert favorite daemon here_ supporting LDAP, you can always use...

5 - PAM/NSS LDAP. It just rocks. If you configure it properly, anything using PAM/NSS will use/update your tree accordingly. This includes unix tools like "passwd", "useradd", or "finger", or services like QPopper and OpenSSH.

6 - The best way to automate some processes is to create our own tools. Net::LDAP is very easy to use, and does anything you can think of (in terms of LDAP ops)

A few tools

[Ludoo]

maybe there are some duplicates with the above posts
Object Identifiers

• • [OIDs Registry]

Schema Browsers

• • [Softerra LDAP Browser]
  • [Java LDAP browser/editor]

Language Libraries

• • [LDAP client API for Python]

Exchange Schema

• • [Directory Schema Contents]

LDAP tools? Open Source tools are here!

[jlittle]

As the host of open-it.org, are entire focus is solving this problem. Many people are actively working on integration with ActiveDirectory, and other tie ins, and people loosely associated with Open-IT are working in various projects that help resolve this (Samba-TNG supports ldap backends).

As for management, we now host Directory Administrator,a great GTK front end to user management, I have also created a simply useradd program for creating users in ldap (its called addluser).

We are currently working on a new release of Directory Administrator with a new backend which will allow CLI, GUI, and Web clients to be built on it. Further, if you love WebObjects, Apple just released 5.1, which has a JNDI adaptor, allowing quick Web Apps to be built against LDAP directory servers using Java.

Is the documentation not up to snuff at Open-IT, then help out! We have some basic howtos, and I package pam_ldap, nss_ldap, openldap, and other great things to get you going.

Back to work...

Ganymede, an LDAP manager / alternative

[jonabbey]

Well, I'll post a pointer to Ganymede, which is not specifically for LDAP, but which could probably be useful in a lot of environments.

Ganymede is at once simpler than LDAP, in that it doesn't support the kind of hierarchical objects that LDAP and x.500 support, and in that it doesn't actually speak LDAP, and more complex, in that it has a sophisticated transactions model and can handle complex concurrent operations while maintaining namespace and referential integrity.

Ganymede is useful if you want to have a smallish (less than 50,000 users, say) 'flat' directory, but for which you want to allow detailed permisison delegation and fine-grained concurrency. If you have a very large NIS domain and you want to allow scores of users and admins to be changing their passwords and account information concurrently, Ganymede will work wonders for you.

We actually use Ganymede for just about everything here, up to and including our DNS, although we don't have our DNS support code 'productized' yet. We do master our LDAP directory from Ganymede data, in order to support applications which can use an LDAP server for an address book (such as Outlook and Netscape Messenger). If you were to combine Ganymede with something like Thomas Reith's ldapdiff utility, you could combine Ganymede's sophisticated administration services with LDAP for distribution.

OT: Troll?!

[uradu]

What the heck's wafting through the ether around here? Moderations are getting ludicrous. While you might not value this guy's opinion, he hardly linked to goatsex or anything. Some other posts in this thread also got modded Offtopic and Flamebait while being perfectly servicable posts.

-

*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:Life beyond LDAP

[mabatche]

We are actually using a product from Novell called DirXML to do exactly this. We are syncing RACF/Notes/NDS/(soon NT Domains) and peoplesoft with our "meta directory" (It's actually just NDS but we call it a meta directory). We are pretty early on in the project, but so far things are looking good.

Fun with LDAP

[uberchang]

Softerra's LDAP Administrator is pretty good, and they have a freeware version called LDAP Browser. The LDAP Browser/Editor is nice also.

If you are using LDAP as your addressbook, ldap-abook is a nice interface to add/delete/modify entries. Most email clients are LDAP-aware these days and it's convenient to be able to share an address book between my personal and work email accounts.

I've had to roll my own to do system accounts, however. Make ldapmodify your new best friend, or write an interface of your own - there is a lot of support for Perl or PHP LDAP functions out there. Server-side, I've used OpenLDAP and iPlanet's Directory Server, and I prefer iPlanet. iPlanet has a free non-commercial license option, is significantly faster than OpenLDAP, and has hooks to synchronize with an NT or Active Directory domain so you could do all the user administration in Windows and they would propagate over to your LDAP server.

Other fun things you can do with LDAP are:

Handle Unix authentication through pam_ldap
Hook into NIS with the NIS/LDAP gateway
Authenticate through apache with mod_auth_ldap or auth_ldap or Netegrity
Centralize your smtp routing data in LDAP for sendmail

Good luck.

Webmin's LDAP plugin...

[Spoing]

Webmin, my favorite tool, has an LDAP module. It looks basic, so I don't know if it would be appropriate.

Links: Webmin & Freshmeat page for LDAP module (LDAP module site is in French but easy to grok);

1. http://www.webmin.com/webmin

2. http://freshmeat.net/projects/ldap_module

The Secret OpenLDAP Speed Boost

[KagatoLNX]

Actually, it takes some tweaking.

There is a poorly documented (gee, surprise surprise) option to add indexes (at least for the ldbm backend). Try putting

index cn,gn,sn,uid,objectclass,o,ou pres,eq,sub

in your database definition in SlapD. Note that you will need to rebuild the DB after that. I suggest exporting it to ldif (via 'ldbmcat -n > file.ldif' with slapd offline), delete the db, then reimport (via 'ldif2ldbm -i file.ldif') and restart slapd. You will notice a *SERIOUS* speed increase during search and a *SERIOUS* speed loss during the initial import. Unless you're doing tonnes of updates, you shouldn't have any speed issues with updating it, though.

Re:From a purely simplistic view, LDAP is pointles

[DeathBunny]

LDAP and SQL are considerably different beasts for different purposes. What you propose is basically to say that screwdrivers make decent pry bars, so why ever buy a pry bar?

Here is some information comparing LDAP and SQL from the OpenLDAP FAQ:
http://www.openldap.org/faq/data/cache/378.html

And here is some from an old usenet post. It's specifically talking about why Netscape's LDAP server uses it's own database instead of a RDBMS, but it has lots of good information about how directory services and RDBMS's differ and why one does not make a good substitute for the other.
http://groups.google.com/groups?q=ldap+compariso n+ sql&selm=36AD06E4.F7362E47%40netscape.com&rnum=9

GQ is also worth a look

[Nailer]

Its `a graphical browser for LDAP directories and schemas. Using GQ, an administrator can search through a directory and modify objects stored
in that directory'

It comes as Red Hat's standard LDAP admin tool. Get it here. Its not as good be, but neither is directory administrator the last time I looked.

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?!