There were flatfiles. This was fine for small installations with a small number of hosts; the files could be easily copied from one host to another without many problems. However as UNIX networks grew, there was a need to make a network-centric nameservice, that could be managed from a single point, changes being pushed out from that point to the hosts on the net in an automated manner, keeping as little data as possible on the clients themselves (usually just enough to boot and get on the network). To fill this need Sun Microsystems created NIS (Network Information Service). NIS was built on top of RPC and filled this role well but several shortcomings became apparent. NIS was insecure in its nature; it used arbitrary ports, did no data encryption, and had no access-control mechanism. It had several operational shortcomings also; it was a flat (non scalable) namespace, it was a single-key database (providing only basic searching abilities), all changes had to be made by the superuser on the domain master, and it did not provide directory services for non nameservice applications. Various workarounds were implemented over the years to attempt to address these problems. Sun went as far as to create a replacement called NIS+, however this system proved complicated to administer and did not gain the widespread acceptance of the UNIX community that NIS had.
In 1995 the University of Michigan began addressing the problem of accessing OSI X.500 data over IP. OSI DAP (Directory Access Protocol) was a complicated and high-overhead beast, requiring a high degree of system resources. UofM created LDAP (Lightweight Directory Access Protocol) as an answer to this problem. However LDAP proved to be the right tool for many problems outside the X.500 system. It was found that stand-alone ldap daemons (those not relying on an X.500 backend, commonly reffered to as slapd) could be used for a wide variety of directory based applications. The first visible use of these servers was by the many email address directories (such as bigfoot and 411). The popular netscape navigator client had an LDAP interface to provide search capability. Netscape communications adopted LDAP as its directory service, using LDAP to store configuration data for most of its server offerings. LDAP has since gained momentum and is in use in a wide variety of applications and systems.
LDAP Addresses many of the shortcomings of NIS. It uses a well-known defined port for communications, giving administrators the ability to traffic filter around it; Implmentations provide data encryption via SSL/TLS; Clients have the option to authenticate to the server, while the server uses Access Control Lists to grant appropriate rights to the client, including the ability for clients to update records based on those rights; LDAP provides a powerfull searching mechanism allowing searches on any field; LDAP has a heirarchal namespace, providing the ability to scale by branching data; and LDAP provides directory services for a wide range of applications beond nameservice such as network address books and public key repositories.