You don't need to call the Psychic Friends Network to know LDAP's future.
As we get closer to a release candidate for Windows 2000, expect the battle between Microsoft Active Directory (MAD) and Novell Directory Services (NDS) to heat up once again. But the conflict will be much ado about nothing.
I'll even save you the cost of a call to the Psychic Friends Network with a tip on the winner: bet on the Lightweight Directory Access Protocol, LDAP. In fact, the sooner you get started with LDAP, the sooner you'll find that the MAD vs NDS battle will eventually become irrelevant.
Technically speaking, LDAP is a TCP/IP-based protocol, which is why a company such as Novell can tack LDAP on top of its NDS. However, in practice (especially on Unix) an LDAP server is an extensible hierarchical database.
An LDAP server isn't a typical hierarchical database, though. LDAP is tuned to perform best when you are searching for data, because that is what you do with an LDAP server most of the time.
It is also designed to allow data to be easily distributed. Although conceivably you could load up a single server with a ton of data, the LDAP hierarchical data model lends itself to multiple user directories organised by logical business units.
Each business unit is likely to have one or more of its own servers that are considered the home servers to the users in that unit. If you adopt LDAP for your user directory for each business unit, you automatically have all the pieces you need to create a hierarchical distributed system.
It is fairly easy to use an LDAP directory to authenticate your Unix users, especially if you are using Linux or Solaris 2.6 or later. These flavours of Unix can make use of Pluggable Authentication Modules (PAMs).
PAM is a modular authentication approach that allows unlimited flexibility in the way your server authenticates users. You can configure PAM to authenticate users for just about any service, such as FTP, login, PPP access, and others. And you can use PAM to direct any one of those services to use encrypted shadow passwords, SQL database authentication, LDAP authentication, or any other PAM-enabled authentication resource you may have installed.
So if you have both LDAP and PAM, it is fairly simple to begin using LDAP as your network information system. But this is only the first step toward unifying all of your resources around a single directory. To go farther, you need to be able to define new data fields and types in LDAP.
That takes me to the best kept secret about LDAP: it is easily extensible. I discovered this when I experimented with Netscape's Roaming User feature. Netscape Communicator, Version 4.5 and later allows you to set up roaming profiles. When you set up Communicator to use roaming, you can add bookmarks, history lists, or e-mail addresses at one client machine and have those changes automatically synchronised to your other client machines.
One of the ways you can do this with Netscape is to have Communicator save all its data into an LDAP server database. The only problem is that LDAP doesn't normally understand things such as Netscape bookmarks or history lists. So you have to make LDAP aware of these data types by modifying the LDAP configuration files. Once you've done that, you define a few profile entries in your directory, configure Netscape Communicator, and go.
I recommend that you get your feet wet by setting up a single LDAP server. If you don't have Solaris, all it takes is a cheap PC, Linux, and openldap (www.openldap.org). The first thing I would do is to load it up with employee information and use it as a central directory for e-mail addresses.
When you're ready, set up the machine as an FTP server and use LDAP to authenticate users for FTP access. If you don't like the idea of FTP, pick something else. As you configure LDAP to handle more tasks, you'll see that LDAP is an ideal way to unify all your directory-enabled applications around a single directory. Eventually you'll be able to change user information in one place regardless of how many different server operating systems you have or what services they provide.
By the way, I know how Microsoft abbreviates its Microsoft Active Directory. I just did it my way to make them MAD.
Nicholas Petreley is editorial director of LinuxWorld (http://www.linuxworld.com). Reach him at firstname.lastname@example.org, and visit his forum at http://www.infoworld.com.