Slashdot Mirror
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?"
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
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.
News for Nerds. Stuff that Matters? Like hell.
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.
Hands in my pocket
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.
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
/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..
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
Use it wisely
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.
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
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.
The Crystal Wind is the Storm, and the Storm is Data, and the Data is Life
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
-- Two men say they're Jesus. One of them must be wrong. - Dire Straits
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)
--
Failure is a human trait. Luckily, I'm not human
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...
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.
- jon
Ganymede, a GPL'ed metadirectory for UNIX