Understanding Solaris 9 Operating Environment Directory Services
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Network Information System (NIS) and its enhanced version, NIS+, have been around for over ten years. NIS is in wide use today and has served its purpose well. Due to the many advances that have taken place in standards-based directory technology in recent years, Sun Microsystems, Inc. has tried to leverage these advances with the introduction of the next generation of Solaris_ Operating Environment (Solaris OE) naming services.
The Solaris 8 OE provided a back-end to the Name Service Switch (NSS) that allowed Solaris OE clients to obtain naming information from a Lightweight Directory Access Protocol (LDAP) enabled directory service. This implementation is commonly referred to as the Solaris OE LDAP Client. The Solaris 9 OE improves this implementation in several areas, including the following:
Ease of setup and configuration
Flexible directory configuration options
Enhanced security model
Because improved security features are the most important area of improvement, this implementation is commonly referred to as the Secured LDAP Client. This article examines the differences between the LDAP Client and the Secured LDAP Client, and explains how they can be supported on the same directory server. In addition, the article details troubleshooting tips for common implementation problems.
This article contains the following sections:
"NIS and NIS+ Overview" on page 2
"LDAP as a Naming Service" on page 3
"Solaris 8 OE LDAP Implementation" on page 5
"Solaris 9 OE Secured LDAP Client and Server Configuration" on page 9
NIS and NIS+ Overview
The premise behind any naming service is simple, provide a mechanism to translate one representation of data into another representation of data. The benefits of doing this are twofold. Easy to remember names can be assigned to numeric data, and changes can be made to one format without changing the other. For example, a script or application might reference the host name of a computer rather than its Internet Protocol (IP) address, allowing the computer to be moved to a new subnet and be assigned a new IP address without requiring you to modify the script or application.
Although the objective of a naming service might be simple, you must consider several complex issues. You should address the following questions and consider how NIS and NIS+ addresses them.
Where and how is data centrally stored?
NIS addresses this issue by storing data in a binary format (that could be created from text files), then placing it on a server. The structure of the data is a simple key-value pair. To retrieve data, clients specify a key, such as a host name, then receive the associated value, such as an IP address. NIS+ improves data storage by supporting tables that can be accessed as rows and columns.
How can clients easily access data?
NIS and NIS+ clients access naming service data through the transport independent remote procedure call (TI-RPC), which is commonly called the Sun RPC. These calls are defined in the Open Network Computing (ONC) specification for NIS and ONC+ for NIS+, implying that client platforms that want to access NIS or NIS+ have libraries that support these specifications ported to them.
How can you eliminate single points of failure?
Single points of failure are eliminated by supporting multiple NIS/NIS+ servers that can supply the same data to clients. Data is synchronized by replication between servers. NIS replicates complete maps, or databases, while NIS+ replicates just the updates. Only one NIS or NIS+ server can function as a master at any time. That is, only one server can accept updates.
How can you prevent unauthorized access?
For simplicity, NIS was designed to allow anonymous access from clients. Because of this, NIS servers typically accept connections from any client, as long as it belongs to the NIS domain of the server. You can modify this behavior by specifying a list of IP addresses of clients that are permitted access, and then restricting access to only those clients. However, with IP spoofing, this mechanism can easily be circumvented. NIS+ implements additional security by providing the option to assign network passwords to NIS+ clients and requiring the password to be sent along with requests.
Can you protect sensitive data from snooping?
NIS and NIS+ both send data, except for passwords, over the network in clear text. This makes the data susceptible to snooping. At the time NIS and NIS+ were developed, most naming service data was considered public and the overhead of encryption made deploying it restrictive.
Does the naming service scale to an enterprise-wide level?
The NIS and NIS+ naming services scale horizontally by adding more servers as needed. Although NIS clients can access NIS servers that reside on remote subnets, a common configuration is to have at least one server per subnet, which reduces network traffic through routers.
Can it interoperate with other naming services?
Because NIS is based on the ONC specification, it interoperates with other vendor implementations that adhere to the specification. That is, you can mix and match master and slave servers from different vendors and support NIS clients that run on different operating environments.
The Solaris 9 OE provides synchronization between NIS+ and LDAP with the introduction of an enhanced rpc.nisd process.