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.
Get on the Lightweight Directory Access Protocol, LDAP. The sooner you get started with LDAP, the sooner you'll find that the MAD versus NDS battle will eventually become irrelevant.
Technically speaking, LDAP is a TCP/IP-based protocol, which is why a vendor 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 mostly what you do with an LDAP server.
It is also designed to allow data to be easily distributed. Although conceivably you could load up one 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 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 further, you need to be able to define new data fields and types.
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 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.
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. Reach him at nicholas_petreley@infoworld. com