Using the LDAP to NIS+ Gateway
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This article contains information derived from a Sun BluePrints book titled, LDAP in the Solaris Operating Environment – Deploying Secure Directory Services, by Michael Haines and Tom Bialaski. This book is scheduled for publication in the Fall of 2003.
There are two approaches that you can take when transitioning from NIS+ to LDAP-based services. One approach is to replace your naming service clients with the Secured LDAP Client. The second approach is to keep your current NIS+ clients, and deploy a transition tool to gain access to LDAP naming service data.
The first approach is covered in the upcoming book in Chapter 4 "Deploying Solaris OE LDAP Naming Services". The second approach, using the NIS+ to LDAP Gateway, is discussed in the following sections of this article:
"What is a Gateway?" on page 2
"Using the Gateway as a Transition Tool" on page 4
"Configuring the Sun ONE Directory Server Software as a Configuration Server for rpc.nisd" on page 20
"How NIS+ Data is Mapped to LDAP" on page 22
"NIS+ to LDAP Migration Example" on page 33
"Testing and Troubleshooting the NIS+ Gateway" on page 37
This article is intended for IT architects and administrators who have some experience with NIS+, and who are interested in deploying LDAP using the Sun ONE Directory Server 5.2 software.
What is a Gateway?
A gateway is a service that provides a mapping of one type of data to another. In respect to naming services, a gateway is used to map NIS+ data to LDAP data. The NIS+ gateway maintains a copy of NIS+ data, most of which is stored in a LDAP directory. The copy of the data is updated whenever the corresponding LDAP entries are updated. It can also be updated using the native naming service tools.
To function transparently to clients, a modified version of the native server rpc.nisd, is used to service the clients. The modified server references a mapping file to determine how to store the native naming service data in LDAP and how to retrieve it so it can be presented to the client. The modified server is also responsible for maintaining cache consistency.
The advantage of the new gateway over the previous NIS Extensions implementation is that the service is decoupled from any particular LDAP server. The NIS Extensions were implemented partly as a directory plug-in that only worked with a specific directory server version (Netscape Directory Server 4.1x). The process that provided the native naming service (dsypservd) had to run on the same system as the directory server.
The new gateway technology uses a Solaris OE process that is a standalone process from the directory server process. This allows the gateway to run on a different server than the directory server, although you can run them on the same server if you want to. The only dependency is the operating environment. FIGURE 0-1 shows what a gateway deployment might look like.
)
FIGURE 0-1
Gateway Deployment
In FIGURE 0-1, Client 1 is a native NIS+ client that communicates to Server A which is running the gateway software. In this case, only cached data is maintained on the server. When data updates occur, the cache is refreshed from the directory server that resides on Server B. The native NIS+ client called Client 2 communicates directly to a server where the directory server resides. The third client, Client 3, is running native LDAP and is accessing the same information as the other clients.
NIS+ Gateway Components
FIGURE 0-1 shows how the gateway is implemented. The software for this service is contained in the following packages:
SUNWnisr
SUNWnisu
These packages also contain the software for native NIS and NIS+. They are loaded as part of the core installation, so should be available. However, to run the NIS+ Gateway software, a directory server must exist somewhere on the network. In theory, any LDAP v3-compliant directory server should work, but only the bundled Sun ONE directory Server software is discussed here. This is because several additional configuration steps are required to configure other directory servers, and those steps are beyond the scope of this article.
There are only three visible components of the NIS+ Gateway software:
/usr/sbin/rpc.nisd
/etc/default/rpc.nisd
/var/nis/NIS+LDAPmapping
The same rpc.nisd process is used whether you are running the gateway or running native NIS+ without the gateway. The rpc.nisd process determines the configuration by the presence of the /var/nis/NIS+LDAPmapping file. If a file with that exact name does not exist, the rpc.nisd process will not use the directory server as a back-end store.
The /etc/default/rpc.nisd file contains information about what directory server to use and where to search for information it contains. There are many parameters that can be configured in this file, as described in a following section.
The NIS+LDAPmapping file describes how the NIS+ data is mapped to LDAP attributes and object classes. The mapping file is quite complex, but in most deployments, only a slight modification is required. For reference, all the relevant parameters are described.