Reading this chapter is not an absolute requirement for deployment of LDAP, but if
you become familiar with some of the architectural nuances, you can better understand broader deployment strategies. Each naming service has its own unique characteristics which may dictate how you deploy them. Although the focus of this BluePrint is LDAP, it is helpful to understand the feature set of legacy Solaris naming services to see how this new technology compares.

This is a sample chapter from Solaris and LDAP Naming Services: Deploying LDAP in the Enterprise.

This chapter is from the book

The Solaris operating environment provides a sophisticated infrastructure
that supports a variety of naming services. The architecture on which it is
based is extensible and able to accommodate new naming services without the need
for a rewrite of important operating system utilities that access naming
services. The Solaris 8 LDAP naming service plugs into this architecture and is
thus accessible to system utilities that formerly had only NIS, NIS+, and DNS
available.

Evolution of Solaris Naming Services

The UNIX operating system was developed to operate in a timesharing
environment where users access the server via physically attached ASCII
terminals. Users typically accessed only one server, so information about user
accounts, group memberships, and so on, only needed to be maintained on that
server. Storing that information in a text file worked quite well.

The Berkeley version of UNIX introduced the notion of distributed computing
built on top of the TCP/IP protocol. Computers running the UNIX operating system
could now easily communicate with one another. However, for things to work
smoothly, information about users and other systems in the network needed to be
maintained on each server. Storing this data in text files meant that any time
something changed, the text files on every server needed to be updated.

In 1985, Sun Microsystems produced NIS (Network Information Service), one of
the first UNIX-based distributed naming service as a replacement for storing
information in text files. The text files would be converted to binary maps that
would only be stored on selected computers, called NIS servers, in the network.
The other computers in the network would contact the NIS servers when they
needed access to the information.

However, some text files still needed to be maintained for two reasons: 1)
some data was required during the booting process before access to the network
was established and 2) there had to be a way to log in if the computer was
disconnected from the network. Moreover, some mechanism was required so that the
operating system utilities could search both text files and NIS, since NIS could
not completely replace the text files.

The introduction of NIS presented a new system administration model, by which
information was administered from a central repository and not all
administrators were granted permission to update it. Since some users still
wanted to be able to manage local accounts and system information, they needed
some way to do this without administering of NIS maps.