JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)     Oracle Solaris 11 Express 11/10
search filter icon
search icon

Document Information


Part I About Naming and Directory Services

1.  Naming and Directory Services (Overview)

2.  The Name Service Switch (Overview)

Part II DNS Setup and Administration

3.  DNS Setup and Administration (Reference)

Part III NIS Setup and Administration

4.  Network Information Service (NIS) (Overview)

5.  Setting Up and Configuring NIS Service

6.  Administering NIS (Tasks)

7.  NIS Troubleshooting

Part IV LDAP Naming Services Setup and Administration

8.  Introduction to LDAP Naming Services (Overview/Reference)

9.  LDAP Basic Components and Concepts (Overview)

10.  Planning Requirements for LDAP Naming Services (Tasks)

11.  Setting Up Sun Java System Directory Server With LDAP Clients (Tasks)

12.  Setting Up LDAP Clients (Tasks)

13.  LDAP Troubleshooting (Reference)

14.  LDAP General Reference (Reference)

15.  Transitioning From NIS to LDAP (Overview/Tasks)

NIS-to-LDAP Service Overview

NIS-to-LDAP Tools and the Service Management Facility

NIS-to-LDAP Audience Assumptions

When Not to Use the NIS-to-LDAP Service

Effects of the NIS-to-LDAP Service on Users

NIS-to-LDAP Transition Terminology

NIS-to-LDAP Commands, Files, and Maps

Supported Standard Mappings

Transitioning From NIS to LDAP (Task Map)

Prerequisites for the NIS-to-LDAP Transition

Setting Up the NIS-to-LDAP Service

How to Set Up the N2L Service With Standard Mappings

How to Set Up the N2L Service With Custom or Nonstandard Mappings

Examples of Custom Maps

Example 1-Moving Host Entries

Example 2-Implementing a Custom Map

NIS-to-LDAP Best Practices With Sun Java System Directory Server

Creating Virtual List View Indexes With Sun Java System Directory Server

VLVs for Standard Maps

VLVs for Custom and Nonstandard Maps

Avoiding Server Timeouts With Sun Java System Directory Server

Avoiding Buffer Overruns With Sun Java System Directory Server

NIS-to-LDAP Restrictions

NIS-to-LDAP Troubleshooting

Common LDAP Error Messages

NIS-to-LDAP Issues

Debugging the NISLDAPmapping File

N2L Server Timeout Issue

N2L Lock File Issue

N2L Deadlock Issue

Reverting to NIS

How to Revert to Maps Based on Old Source Files

How to Revert to Maps Based on Current DIT Contents

Part V Active Directory Naming Service

16.  Setting Up Oracle Solaris Active Directory Clients



NIS-to-LDAP Service Overview

The NIS–to–LDAP transition service (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 slave servers do not have an NISLDAPmapping file, so they continue to function in the usual manner. The slave servers periodically update their data from the N2L server as if it were a regular NIS master.

The behavior of the N2L service is controlled by the ypserv and NISLDAPmapping configuration files. A script, inityp2l, assists with the initial setup of these configuration files. Once the N2L server has been established, you can maintain N2L by directly editing the configuration files.

The N2L service supports the following:

In any naming system, only one source of information can be the authoritative source. In traditional NIS, NIS sources are the authoritative information. When using the N2L service, the source of authoritative data is the LDAP directory. The directory is managed by using directory management tools, as described in Chapter 9, LDAP Basic Components and Concepts (Overview).

NIS sources are retained for emergency backup or backout only. After using the N2L service, you can gradually phase out NIS clients. Eventually, all NIS clients can be replaced by Solaris LDAP naming services clients.

Additional overview information is provided in the following subsections:

NIS-to-LDAP Tools and the Service Management Facility

The NIS and LDAP services are managed by the Service Management Facility. Administrative actions on these services, such as enabling, disabling, or restarting, can be performed by using the svcadm command. You can query the status of services by using the svcs command. For more information about using SMF with LDAP and NIS, see LDAP and the Service Management Facility and NIS and the Service Management Facility. For an overview of SMF, refer to Chapter 11, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.

NIS-to-LDAP Audience Assumptions

You need to be familiar with NIS and LDAP concepts, terminology, and IDs to perform the procedures in this chapter. For more information about the NIS and LDAP naming services, see the following sections of this book.

When Not to Use the NIS-to-LDAP Service

Do not use the N2L service in these situations:

Effects of the NIS-to-LDAP Service on Users

Simply installing the files that are related to the N2L service does not change the NIS server's default behavior. At installation, the administrator will see some changes to NIS man pages and the addition of N2L helper scripts, inityp2l and ypmap2src, on the servers. But as long as inityp2l is not run or the N2L configuration files are not created manually on the NIS server, the NIS components continue to start in traditional NIS mode and function as usual.

After inityp2l is run, users see some changes in server and client behavior. Following is a list of NIS and LDAP user types and a description of what each type of user should notice after the N2L service is deployed.

User Type
Effect of N2L Service
NIS master server administrators
The NIS master server is converted to an N2L server. The NISLDAPmapping and ypserv configuration files are installed on the N2L server. After the N2L server is established, you can use LDAP commands to administer your naming information.
NIS slave server administrators
After the N2L transition, an NIS slave server continues to run NIS in the usual manner. The N2L server pushes updated NIS maps to the slave server when yppush is called by ypmake. See the ypmake(1M) man page.
NIS clients
NIS read operations are no different than traditional NIS. When a Solaris LDAP naming services client changes information in the DIT, the information is copied into the NIS maps. The copy operation is complete after a configurable timeout expires. Such behavior is similar to the behavior of a normal NIS client when the client is connected to an NIS slave server.

If an N2L server cannot bind to the LDAP server for a read, the N2L server returns the information from its own cached copy. Alternatively, the N2L server can return an internal server error. You can configure the N2L server to respond either way. See the ypserv(1M) man page for more details.

All users
When an NIS client makes a password change request, the change is immediately visible on the N2L master server and to native LDAP clients.

If you attempt to change a password on the NIS client, and the LDAP server is unavailable, then the change is refused and the N2L server returns an internal server error. This behavior prevents incorrect information from being written into the cache.

NIS-to-LDAP Transition Terminology

The following terms are related to the implementation of the N2L service.

Table 15-1 Terminology Related to the N2L Transition

N2L configuration files
The /var/yp/NISLDAPmapping and /var/yp/ypserv files that the ypserv daemon uses to start the master server in N2L mode. See the NISLDAPmapping(4) and ypserv(4) man pages for details.
In the context of the N2L service, the term map is used in two ways:
  • To refer to a database file in which NIS stores a specific type of information

  • To describe the process of mapping NIS information to or from the LDAP DIT

The process of converting NIS entries to or from LDAP DIT entries.
mapping file
The NISLDAPmapping file that establishes how to map entries between NIS and LDAP files.
standard maps
Commonly used NIS maps that are supported by the N2L service without requiring manual modification to the mapping file. A list of supported standard maps is provided in Supported Standard Mappings.
nonstandard maps
Standard NIS maps that are customized to use mappings between NIS and the LDAP DIT other than the mappings identified in RFC 2307 or its successor.
custom map
Any map that is not a standard map and therefore requires manual modifications to the mapping file when transitioning from NIS to LDAP.
LDAP client
Any traditional LDAP client that reads and writes to any LDAP server. A traditional LDAP client is a system that reads and writes to any LDAP server. A Solaris LDAP naming services client handles a customized subset of naming information.
LDAP naming services client
A Solaris LDAP client that handles a customized subset of naming information.
N2L server
An NIS master server that has been reconfigured as an N2L server by using the N2L service. Reconfiguration includes replacing NIS daemons and adding new configuration files.

NIS-to-LDAP Commands, Files, and Maps

There are two utilities, two configuration files, and a mapping that are associated with the N2L transition.

Table 15-2 Descriptions of N2L Commands, Files, and Maps

A utility that assists with the creation of the NISLDAPmapping and ypserv configuration files. This utility is not a general-purpose tool for the management of these files. An advanced user can maintain the N2L configuration files or create custom mappings by using a text editor to examine and customize the inityp2l output. See the inityp2l(1M) man page.
A utility that converts standard NIS maps to approximations of the equivalent NIS source files. The primary use for ypmap2src is to convert from an N2L transition server to traditional NIS. See the ypmap2src(1M) man page.
A configuration file that specifies the mapping between NIS map entries and equivalent Directory Information Tree (DIT) entries in LDAP. See the NISLDAPmapping(4) man page.
A file that specifies configuration information for the NIS–to–LDAP transition daemons. See the ypserv(4) man page.
A mapping used by yppasswdd to read and write password aging information to the DIT when the NIS-to-LDAP transition is implemented.

Supported Standard Mappings

By default, the N2L service supports mappings between the following list of maps and RFC 2307, or its successors', LDAP entries. These standard maps do not require manual modification to the mapping file. Any maps on your system that are not in the following list are considered custom maps and require manual modification.

The N2L service also supports automatic mapping of the auto.* maps. However, since most auto.* file names and contents are specific to each network configuration, those files are not specified in this list. The exceptions to this are the auto.home and auto.master maps, which are supported as standard maps.

ethers.byaddr ethers.byname
group.bygid group.byname group.adjunct.byname
hosts.byaddr hosts.byname
ipnodes.byaddr ipnodes.byname
mail.byaddr mail.aliases
netgroup netgroup.byprojid netgroup.byuser netgroup.byhost
networks.byaddr networks.byname
passwd.byname passwd.byuid passwd.adjunct.byname
project.byname project.byprojectid
protocols.byname protocols.bynumber
services.byname services.byservicename

During the NIS-to-LDAP transition, the yppasswdd daemon uses the N2L-specific map, ageing.byname, to read and write password aging information to the DIT. If you are not using password aging, then the ageing.byname mapping is ignored.