the Support Group inc Sponsor Message

August 2001

LDAP? What’s That?

Explore a new HP 3000 feature, and see how a little LDAP’ll do ya

Links to learn more about LDAP

By Curtis Larsen

When you think of LDAP, what do you think of? You’ve probably heard about it — something to do with directories, right? — but you’re not quite sure. You’ve heard some industry buzz about it here and there, read a paper or two, but perhaps you still don’t quite know what it can do for you, or how it could work with an HP e3000 system. Hopefully this article will de-mystify it a bit for you, and spark some ways you could use it in your own organization.

MPE currently has limited support for LDAP, but the support is growing. Aside from the OpenLDAP source ported by Lars Appel, HP offers an LDAP “C” Software Development Kit for writing HP e3000 code to access directories, er, directly.

LDAP stands for “Lightweight Directory Access Protocol.” In a nutshell, it allows you to create directories of information similar to what you would see in a telephone book. Any information you want to store for later quick retrieval: names, telephone numbers, conference room capacities, addresses, directions — even picture or sound files. Using directories such as these is an incredible time-saver (can’t you think of company applications for one already?), but LDAP can do so much more. The directories you create are wholly up to you, so the sky’s the limit.

At this point you might be saying “Great, but why not use a database for this stuff?” That’s an excellent question, and in truth, there is some overlap in what you might want stored in a database versus being stored in a directory. The first and foremost difference between them is that a directory is designed for high-speed reading (and searching) — not writing. The idea is that, generally speaking, a directory doesn’t change much, but quickly reading its information is a must. Understand that this doesn’t mean that directory writes are at all bad — they’re just not structurally designed to be as fast as reads are.

Databases also require more in the way of overhead: high-powered servers and disks, (usually) high-priced Database Management Systems — which one will be best for you? — and highly-skilled, highly-paid DBAs to keep it all happy. (Our DBA said I had to mention that part.)

LDAP directories are generally simpler and faster to set up and manage. LDAP is (also) a common client-server access standard across many different systems. You don’t have to deal with the outrageous slings of one DBMS, or the delightful syntax variations in SQL or ODBC implementations. LDAP directories can even be replicated. Copies of directories, or just sections of larger directories, can be stored on different servers and updated (or cross-updated) periodically. This can be done for security (“mirrored directories” — one here, one elsewhere), performance (all queries against local entries on a local server), or both.

Let’s dig more into what LDAP directories can do. I won’t get into any real technical details about syntax, history, specifications, etc. Better explanations of these things have already been written by folks far more knowledgeable than I am. You’ll find some links at the end of this article that you can use to understand more.

Practical LDAP ideas

For most, adding all the different network and systems logons can be a tedious task. Add to that the different options on each system (like VESoft security on e3000s) and you have a necessary, but time-consuming chore. With an LDAP directory maintained by your Human Resources folks, regular batch jobs can query that directory and perform the add/change/delete maintenance automatically. The jobs can even update the directory with the new logon information.

Wouldn’t it be nice to have different batch jobs send various e-mail (or faxes, or pages, or…) to different folks about something? Using that same HR LDAP directory, any job can look up someone’s current contact info and send them that message, page, fax, etc. Your Admins, Ops, and Help Desk folks are now on to bigger things, and no more need for maintaining separate KSAM or Image tables on the HP system.

Here’s a bit of a mind-bender: How about “personalized printing”? Same as the last example, but what if an LDAP directory stored the list of printers your new hire will (generally) use as well? Now all your systems — e3000 included -— can direct printed output based upon a person — not a destination. If they change locations, just change the directory entry. We can get even more esoteric and say “logical entity” instead of “person.” Suddenly, you have the ability to address output to groups of people (“Accounting’s printer,” fax or e-mail addresses), other computer systems, etc. Get a little wilder and you can even have the LDAP directory describe the format for the addresses used. (Batch job to LDAP server: “I have this color print file on legal paper for ‘Bob’ — where should I send it?”) Really, it’s just a small step past device classes.

Interesting stuff, eh? All of these things are possible this very instant. Yes, they do require some preparation and support work (but then every new technology does). Let’s try another idea:

You say you want system-wide variables? How about enterprise-wide variables? Using LDAP, practically any type of system can share information with any other system. You would want those variables to be fairly static (that “reads are better” thing), but certainly a central repository for something like cross-system daily scheduling information (dates don’t change much) or summary totals could be a handy thing. “Variable” states can be retained as long as needed, too.

Okay, let’s explain a little more about that last one. LDAP directories are made up of basically three things: containers, variables and values. Containers can hold either variables or other containers, and variables have values. (There’s a little more to it than this, but it will hold us for now.) Using those elements, the LDAP directory you create looks very much like the classic tree structure used in most file systems (like DOS, Unix, etc.) or even DNS.

An example of this might be a “root” container for your company, holding a container object named “USA,, holding one named “New York.” In “New York” is a “dept.” container named “Accounting,” and in that is one named “P. Strings.” That object type might be “person,” and it, in turn holds all sorts of contact information. You could just as easily have a container named “Jobs,” holding one named “Schedule X,” wherein we could find lots of information on Schedule X, like its completion time and status.

For the object-oriented among you, you can also think of a container as an object, and variables as properties of that object. This makes LDAP very workable with OOP. Perl likes it, Python likes it — shucks, even C++ thinks it has class.

This idea is a bit stretched, but: persistent, cross-platform objects/object classes. You can use an LDAP directory as a base class template library and retrieve certain directory sections into a program for later use. Use them as a library of other things as well. LDAP directories fit DOM fairly well, so you can use LDAP to store DTDs and other work with XML. (“Does anyone know where the DTD for getting EDI XML data from ‘Foobar, Inc.’ is?” “Yeah, It’s the LDAP directory under “DTDs, EDI, Foobar, or just do a search for ‘Foobar, Inc.’”.

Where LDAP’s in use

Finally, I should mention that major products and projects do use LDAP:

• Novell’s NDS uses it heavily, as does Microsoft Windows 2000.

• E-mail applications such as Microsoft Exchange Server and Novell Groupwise both permit LDAP access and searches of addresses, etc. Sendmail can/will use LDAP for authentication.

One big upcoming use of LDAP will be in the next major version of Samba. Using an LDAP directory, Samba will be able to authenticate connections to shares and services without requiring the allowed user to be an actual user ID. This is a very big deal, and finally means authentication to one source. (You can see some of these not-quite-used settings now in some of the latest Samba books.)

• Many Internet-access-enabled colleges, and businesses allow LDAP access.

• There are LDAP-to-web gateways, and Kerberos encryption availability (for authenticating your LDAP logon), etc.

I certainly hope you found this article useful, and that it gives you some thoughts about what you might want to do with an LDAP server or two accessed by your HP e3000. LDAP, like Samba and Apache before it, is yet another example of innovative technology working upon the rock-solid stability of the HP e3000 system. File and print server, web server, and now LDAP — who says the e3000 can’t share?

Find out more at LDAP links

An LDAP Roadmap & FAQ
To my mind, the main LDAP information site. If you go to but one site for information, this one is it. (It has so many links it’s practically a portal site.)
www.kingsmountain.com/ldapRoadmap.shtml

A System Administrator’s View of LDAP
The best all-around one-page explanation of why LDAP is A Good Thing. (Definitely worth the time to read!)
people.netscape.com/bjm/whyLDAP.html

LDAP Documentation
An excellent one-page links page to LDAP docs (Bookmark this page for easy access to doc links.)
www.umich.edu/~dirsvcs/ldap/doc/

The LDAP Zone
A nice LDAP Developer’s site. Mostly for techs, but all are welcome.
www.ldapzone.com

LDAP Central
A nice portal site — they want to be the best.
www.ldapcentral.com

OpenLDAP
THE LDAP software site. This is where you download the source code.
www.openldap.org

OpenLDAP for MPE/iX
Here’s the site for the MPE LDAP client. (Thanks to Lars Appel, we can try it on MPE)
www.editcorp.com/Personal/Lars_Appel/ldap/

HP LDAP C-SDK/iX (for MPE/iX 6.0 and later)
Here’s HP’s C SDK for writing your own LDAP client code
jazz.external.hp.com/src/ldap/index.html

LDAP Google Search
The link to everything else LDAP
www.google.com/search?q=LDAP

Curtis Larsen has been working with HP 3000s for over 10 years, and believes that, given enough time, any application can be written using the CI. He currently works for Covance Laboratories, in Madison, Wis. 

Copyright The 3000 NewsWire. All rights reserved.