NIS to LDAP Gateway

The NIS to LDAP Gateway, or NIS to LDAP transition service (N2L service) software, is in the BETA test phase. This software might not be shipping at the time this book is published. Because this software offers a helpful tool for companies migrating from NIS to LDAP, an overview of the service is provided for high-level awareness of this emerging technology.

Note

As with any software that is not officially released, the exact features, implementation techniques, or even the product as a whole is subject to change without notice. Use the following information for general familiarity .

The NIS to LDAP transition service is a service that replaces an NIS master. Instead of maintaining name service data in DBM files, an LDAP directory is used as a backend store. In many respects, N2L services is similar to the NIS+ Gateway discussed in Chapter 6 "Management Tools and Toolkits." The obvious difference is that native NIS clients are supported instead of native NIS+ clients .

The Directory Information Tree (DIT) that N2L services uses is the same DIT that Secured LDAP Clients use. Therefore, you can set up a single DIT that supports NIS clients accessing the directory through N2L services and clients that access the directory directly through LDAP operations.

The intention of N2L services is not to simply replace NIS. Instead, it is meant to be used as a tool to migrate from NIS to LDAP-based name services. By using N2L transition services, you can begin to deploy LDAP without having to modify client software. This is an important consideration especially if clients are running a version of the operating system earlier than Solaris 8 OE, because these versions do not have a Secured LDAP Client.

Comparison with NIS Extensions

Companion software to the Netscape Directory Server 4.1x, (NsDS 4.1x) software was introduced, called NIS Extension to Netscape Directory Server 4.1x. This software is tightly coupled to NsDS4.1x, and is not available for the Sun ONE Directory Server 5.x software versions. One reason for this is the Extension's reliance on a directory plug-in that was written to an API that changed in newer versions of the Sun ONE Directory Server software.

The purpose of the plug-in is to detect operations performed on the directory that affected name service data. If an entry was added, deleted, or modified the plug-in notifies the dsypserv process running on the same server where the change occurred. The dsypserv process then regenerates the affected NIS DBM files. The problems with the plug-in implementation are:

• There are no standards for directory plug-in APIs, so they are subject to change.

• The plug-in expected the dsypserv to be running on the same server which limited scalability.

• The directory server had to run as root so it could create the NIS DBM files.

The NIS Extensions support bi-directional synchronization. This means you can update the NIS DBM files with NIS tools like makedbm or update the directory data through LDAP operations. While this provides flexibility, inconsistencies can develop if both methods are used concurrently. For this reason, it is recommended that one method be chosen , and only that method used. To implement NIS to LDAP synchronization, modifications to the NIS Makefile are required.

To perform the synchronization from NIS DBM files to LDAP data, a program called dsimport needs to be run. The dsimport program relies on a mapping file to determine how changes should be mapped to LDAP data. The dsimport program also must query the directory to see if an updated entry exists, and if it does, identify which attributes are affected. The mapping file format is very complex and not well documented. While it is possible to create a mapping for custom maps, it is very difficult.

The NIS Extensions are based on a schema that is different than what a Solaris OE LDAP naming client uses. This means that, with this technology, you cannot support both Solaris OE LDAP name clients and NIS clients using the same DIT.