This article examines the differences between the Solaris 8 Operating Environment (Solaris OE) Lightweight Directory Access Protocol (LDAP) Client and the Solaris 9 OE Secured LDAP Client, and explains how to support them on the same directory server. In addition, this article details troubleshooting tips for common implementation problems.

Like this article? We recommend

The Network Information System (NIS) and its enhanced version, NIS+, have
been around for over ten years. NIS is in wide use today and has served its
purpose well. Due to the many advances that have taken place in standards-based
directory technology in recent years, Sun Microsystems, Inc. has tried to
leverage these advances with the introduction of the next generation of Solaris_
Operating Environment (Solaris OE) naming services.

The Solaris 8 OE provided a back-end to the Name Service Switch (NSS) that
allowed Solaris OE clients to obtain naming information from a Lightweight
Directory Access Protocol (LDAP) enabled directory service. This implementation
is commonly referred to as the Solaris OE LDAP Client. The Solaris 9 OE improves
this implementation in several areas, including the following:

Ease of setup and configuration

Flexible directory configuration options

Enhanced security model

Because improved security features are the most important area of
improvement, this implementation is commonly referred to as the Secured LDAP
Client. This article examines the differences between the LDAP Client and the
Secured LDAP Client, and explains how they can be supported on the same
directory server. In addition, the article details troubleshooting tips for
common implementation problems.

This article contains the following sections:

"NIS and NIS+ Overview" on page 2

"LDAP as a Naming Service" on page 3

"Solaris 8 OE LDAP Implementation" on page 5

"Solaris 9 OE Secured LDAP Client and Server Configuration" on
page 9

NIS and NIS+ Overview

The premise behind any naming service is simple, provide a mechanism to
translate one representation of data into another representation of data. The
benefits of doing this are twofold. Easy to remember names can be assigned to
numeric data, and changes can be made to one format without changing the other.
For example, a script or application might reference the host name of a computer
rather than its Internet Protocol (IP) address, allowing the computer to be
moved to a new subnet and be assigned a new IP address without requiring you to
modify the script or application.

Although the objective of a naming service might be simple, you must consider
several complex issues. You should address the following questions and consider
how NIS and NIS+ addresses them.

Where and how is data centrally stored?

NIS addresses this issue by storing data in a binary format (that could be
created from text files), then placing it on a server. The structure of the data
is a simple key-value pair. To retrieve data, clients specify a key, such
as a host name, then receive the associated value, such as an IP address. NIS+
improves data storage by supporting tables that can be accessed as rows and
columns.

How can clients easily access data?

NIS and NIS+ clients access naming service data through the transport
independent remote procedure call (TI-RPC), which is commonly called the Sun
RPC. These calls are defined in the Open Network Computing (ONC) specification
for NIS and ONC+ for NIS+, implying that client platforms that want to access
NIS or NIS+ have libraries that support these specifications ported to them.

How can you eliminate single points of failure?

Single points of failure are eliminated by supporting multiple NIS/NIS+
servers that can supply the same data to clients. Data is synchronized by
replication between servers. NIS replicates complete maps, or databases, while
NIS+ replicates just the updates. Only one NIS or NIS+ server can function as a
master at any time. That is, only one server can accept updates.

How can you prevent unauthorized access?

For simplicity, NIS was designed to allow anonymous access from clients.
Because of this, NIS servers typically accept connections from any client, as
long as it belongs to the NIS domain of the server. You can modify this behavior
by specifying a list of IP addresses of clients that are permitted access, and
then restricting access to only those clients. However, with IP spoofing, this
mechanism can easily be circumvented. NIS+ implements additional security by
providing the option to assign network passwords to NIS+ clients and requiring
the password to be sent along with requests.

Can you protect sensitive data from snooping?

NIS and NIS+ both send data, except for passwords, over the network in clear
text. This makes the data susceptible to snooping. At the time NIS and NIS+ were
developed, most naming service data was considered public and the overhead of
encryption made deploying it restrictive.

Does the naming service scale to an enterprise-wide level?

The NIS and NIS+ naming services scale horizontally by adding more servers as
needed. Although NIS clients can access NIS servers that reside on remote
subnets, a common configuration is to have at least one server per subnet, which
reduces network traffic through routers.

Can it interoperate with other naming services?

Because NIS is based on the ONC specification, it interoperates with other
vendor implementations that adhere to the specification. That is, you can mix
and match master and slave servers from different vendors and support NIS
clients that run on different operating environments.

The Solaris 9 OE provides synchronization between NIS+ and LDAP with the
introduction of an enhanced rpc.nisd process.