Go to main content

Working With Oracle® Solaris 11.3 Directory and Naming Services: LDAP

Exit Print View

Updated: September 2018
 
 

About the NIS-to-LDAP Service

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 the NIS 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 known 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. The inityp2l script assists the server with the initial setup of these configuration files. Once the N2L server has been established, you can edit the configuration file to maintain the N2L service.

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

In the context of the N2L service, the term "map" is used in the following 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

In any naming system, only one source of information can be the authoritative source. In traditional NIS, NIS sources are the authoritative information. When you use the N2L service, the source of authoritative data is the LDAP directory. The directory is managed by using directory management tools. For more information about directory management tools, see Introduction to the LDAP Naming Service.

NIS sources are retained for emergency backup or backout only. After you use the N2L service, you must phase out NIS clients. Eventually, all NIS clients should be replaced by LDAP naming service clients.

The Service Management Facility (SMF) manages the NIS and LDAP services. You can perform administrative actions on these services, such as enabling, disabling, or restarting, 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 in Working With Oracle Solaris 11.3 Directory and Naming Services: DNS and NIS. For information about SMF, refer to Managing System Services in Oracle Solaris 11.3. Also refer to the svcadm(1M) and svcs(1) man pages for more details.

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 service, see the following sections:

Additional overview information is provided in the following sections:

When Not to Use the NIS-to-LDAP Service

The intent of the N2L service is to serve as a transition tool from using NIS to using LDAP. Do not use the N2L service in the following situations:

  • In an environment where you do not plan to share data between NIS and LDAP naming service clients

    In such an environment, an N2L server would serve as an excessively complex NIS master server.

  • In an environment where NIS maps are managed by tools that modify the NIS source files (other than yppasswd)

    Regeneration of NIS sources from DIT maps is an imprecise task that requires manual checking of the resulting maps. Once the N2L service is used, regeneration of NIS sources is provided only for backout or reverting to NIS.

  • In an environment with no NIS clients

    In such an environment, use LDAP naming service clients and their corresponding tools.

Effect of Installing the NIS-to-LDAP Service

Installing the files that are related to the N2L service does not change the NIS server's default behavior. While installing the N2L service, you may see some changes to the NIS man pages and the addition of N2L helper scripts, inityp2l and ypmap2src, on the servers. However, 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. The following table lists the 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. For more information, see the ypmake(1M) man page.
NIS clients
NIS read operations are similar to traditional NIS. When an LDAP naming service client changes information in the DIT, the information is copied into the NIS maps. The copy operation is complete after a configurable timeout expires. This 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. For more information, see the ypserv(1M) man page.
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 Commands, Files, and Maps

This section describes the utilities, configuration files, and mapping associated with the N2L transition.

The N2L transition uses the following utilities:

  • /usr/lib/netsvc/yp/inityp2l Assists with the creation of the NISLDAPmapping and ypserv configuration files but not the management of these files. If you are familiar with the technologies, you can maintain the N2L configuration files or create custom mappings by using a text editor to examine and customize the inityp2l output. For more information, see the inityp2l(1M) man page.

  • /usr/lib/netsvc/yp/ypmap2src Converts standard NIS maps to approximations of the equivalent NIS source files. You can use the ypmap2src utility to convert from an N2L transition server to traditional NIS. For more information, see the ypmap2src(1M) man page.

The N2L service uses the following files to transition from NIS to LDAP:

  • /var/yp/NISLDAPmapping Specifies the mapping between NIS map entries and equivalent DIT entries in LDAP. See the NISLDAPmapping(4) man page.

  • /var/yp/ypserv Specifies configuration information for the NIS-to-LDAP transition daemons. For more information, see the ypserv(4) man page.

When the NIS-to-LDAP transition is implemented, the yppasswdd command uses the ageing.byname mapping to read and write password aging information to the DIT.

Supported Standard Mappings

By default, the N2L service supports mappings between its standard maps and LDAP entries based on RFC 2307, RFC 2307bis, and later standards. Standard maps do not require manual modification of the mapping file. Any maps on your system that are not standard N2L service maps are considered custom maps and require manual modification.

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

The N2L service supports the following standard maps:

audit_user
auth_attr
auto.home
auto.master
bootparams
ethers.byaddr ethers.byname
exec_attr
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
netid.byname
netmasks.byaddr
networks.byaddr networks.byname
passwd.byname passwd.byuid passwd.adjunct.byname
prof_attr
project.byname project.byprojectid
protocols.byname protocols.bynumber
publickey.byname
rpc.bynumber
services.byname services.byservicename
timezone.byname
user_attr

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