Why Use an LDAP-Based Naming Service?

A naming service stores information in a central place, which enables
users, machines, and applications to communicate across the network. This
information can include, for example, machine (host) names and addresses,
user names, passwords, access permissions, group membership, and printers.
Without a central naming service, each machine would have to maintain its
own copy of this information. Naming service information can be stored in
files, maps, or database tables. If you centralize all data, administration
becomes easier.

The Solaris OS supports the following naming services:

DNS, the Domain Name System

/etc files, the original UNIX naming system

NIS, the Network Information Service

NIS+, the Network Information Service Plus

LDAP, the Lightweight Directory Access Protocol

However, Oracle's strategic direction is to move to LDAP-based naming
services.

The LDAP naming service has the following advantages over other naming
services:

Enables you to consolidate information by replacing application-specific
databases, which reduces the number of distinct databases to be managed

Allows data to be shared by different naming services

Provides a central repository for data

Allows for more frequent data synchronization between master
servers and replicas

Is multi-platform and multi-vendor compatible

The LDAP naming service has the following restrictions:

Clients prior to Solaris 8 are not supported.

Setting up and managing an LDAP naming service is more complex
and requires careful planning.

An NIS client and a Native LDAP client cannot coexist on the
same client machine.

The Solaris OS supports LDAP naming in conjunction with Oracle Directory Server,
as well as other LDAP directory servers. Although using Oracle Directory Server
is recommended, it is not required.

Migrating From NIS to LDAP

Moving from NIS to LDAP is a two-step process that involves data
migration and client migration. The Solaris OS provides the NIS-to-LDAP transition
service (N2L service), which accomplishes both steps.

The N2L service replaces existing NIS daemons on the NIS master server
with NIS-to-LDAP transition daemons. The N2L service also creates an NIS-to-LDAP
mapping file on that server. The mapping file specifies the mapping between
NIS map entries and equivalent Directory Information Tree (DIT) entries in
LDAP. An NIS master server that has gone through this transition is referred
to as an N2L server.

The NIS slave servers continue to function in the usual manner. The
slave servers periodically update their data from the N2L server as if the
N2L server were a regular NIS master. A script, inityp2l,
assists with the initial setup of these configuration files. When the N2L
server has been established, you can maintain N2L by directly editing the
configuration files.

The N2L service supports the following:

Import of NIS maps into the LDAP DIT

Client access to DIT information with the speed and extensibility
of NIS

Migrating From NIS+ to LDAP

Although you can keep NIS+ data synchronized with LDAP, such synchronization
has previously required an external agent. However, the NIS+ daemon now enables
you to use an LDAP server as a data repository for NIS+ data. This feature
enables NIS+ and LDAP clients to share the same naming service information.
The transition from using NIS+ as the main naming service to using LDAP for
the same role is therefore easier.