Hewlett Packard
19420 Homestead Road, MS 43LF
Cupertino, CA 95014
Phone: (408) 447-0482
E-mail: morteza@cup.hp.com
Introduction
Computers and operating systems have come a long way since the days Thompson and Ritchie worked on early versions of UNIX on a PDP-7 in Bell Laboratories. Back then a typical computer center had a few large computers shared by a small number of users. Today almost all corporations have very large networks consisting of many different operating systems and applications, and support thousands of users. To make the problem worse, most of these operating systems and applications have their own account information and their own method of managing their data. Managing these users/accounts on such a large scale is a very time consuming and therefore expensive task
Over the last decade, many unix vendors have adopted various tools and applications to manage this growth. The most widely used solution to this problem was developed by Sun Microsystems. Although it was originally called Yellow Pages, it was later renamed to Network Information Service or NIS. NIS along with its newest sibling NIS+ provide network wide management of many unix configuration files (i.e. /etc/passwd, /etc/group, /etc/services,...). Although, NIS+ is a very capable directory, it has its share of shortcomings in the enterprise market. Most notably, NIS+ was designed as a solution for the problem of managing unix network configuration, and was never intended to be a generic network directory. NIS+ suffers from lack of interoperability and therefore it is missing the much needed flexibility in the hybrid environments.
Over the past few years, Light Weight Directory
Access Protocol (LDAP) has been getting a lot of attention from almost
all vendors and is quickly becoming the defacto standard in accessing network
directories. Using LDAP as a repository for unix account information has
many benefits including ease of management, the ability to share information
between many operating systems and applications, and also the possibility
of achieving common authentication to name a few.
Lightweight Directory Access Protocol
LDAP is an Internet standard produced by the Internet Engineering Task Force (IETF). The original LDAP RFC was written by W. Yeong, T. Howes, and S. Kille in University of Michigan. The protocol was designed to provide access to the Directory while reducing the resource requirements of the Directory Access Protocol (DAP). The key feature of LDAP was that the protocol ran directly over TCP or other transports without requiring the overhead of session/presentation layer overhead. The following RFCs provide detail information about LDAPv3 protocol, and other LDAP related standards:
Integration of HP-UX accounts and LDAP
To allow HP-UX and applications to access the network information stored in a LDAP directory, they must become aware of the new data repository and have code to retrieve the information they need. This would be a very tedious task to say the least if one had to modify all applications and libraries that need access to this data. Fortunately, as of HP-UX 11.0, the C library includes an architecture that allows new information repositories to be added to the system without requiring to modify the applications needing access to the data. This is known as the Name Service Switch or NSS, which was originally developed by Sun Microsystems for Solaris 2. the Name Service Switch allows all applications to be able to retrieve network information, via use of 'getXXbyYY()' function calls from various sources depending on the configuration of the NSS (i.e. content of '/etc/nsswitch.conf' file). The simplest case of this is when the switch is configured to retrieve all the network information from their respective configuration files. For example account information is read from '/etc/passwd' and group information from '/etc/group', and so on.
For accessing information via LDAP, a new backend for NSS is written that allows NSS to access an LDAP server for retrieving information that is requested by a given application or operating system process. By storing information such as user and group entries into the LDAP directory, the management of this data is greatly simplified due to the fact that now we only have one instance of this information for access by many applications or operating systems. For example, if a user's name is changed, the system administrator no longer needs to change that information in many different places and the change is simply done by updating the directory entry for the user in one place.
Additionally, the backend is designed in a way that the search and access to the data in the directory is almost entirely configurable which allows this implementation to be compatible with almost any existing directory schema that defines similar data. This flexibility in addition to providing a very powerful tool in integrating HP-UX account information into existing LDAP directories, also provides the basis needed for common authentication. This level of flexibility is achieved through extensive use of the most flexible feature of LDAP protocol, the search filters. By allowing network designers and system administrators to modify search filters, information can be retrieved from many different areas which means that data sharing can be maximized.
For example if a system administrator setup
the directory so that the password attribute is shared between various
applications requiring authentication, then account synchronization and
common authentication is automatically achieved. For example in case
of Netscape directory services, if HP-UX account information is shared
with Netscape's inetOrgPerson information, common authentication
is achieved between Directory Servers users and HP-UX users. And
more interestingly, by setting up NT Directory Synchronization services
on the server, HP-UX account and NT accounts now are synchronized and common
authentication is available between all three environments.
To demonstrate the use of Name Service Switch and configurable attributes, lets look at an example. Let's assume a given application needs to find the passwd entry for a given uid. The application simply calls 'getpwuid(uid)' which in turn goes through the name service switch to find out where to get this information. Assuming that '/etc/nsswitch.conf' was configured to use the LDAP backend for password entries, the LDAP backend functions are then called to authenticate to the directory, perform a search to find the entry with the given uid, if sufficient permissions exist retrieve all related attributes, and finally store the information into a passwd structure and pass it up to the calling program. Now the interesting part in this transaction is the translation of the attributes to the passwd entry. For example the gecos field can be configured to pass the attribute called gecos as defined by RFC 2307, or return attribute phoneNumber as part of an organizationalPerson schema defined in RFC 2256. This flexibility is extremely valuable and allows system administrators to deploy HP-UX accounts into LDAP directories where other not-so-flexible applications or operating systems exist and force the directory to be structured in a way that their data may not coexist with other applications.
This flexibility is the most significant
part of this integration and what makes this implementation different from
other similar efforts that are in progress. This integration work,
was architected from beginning by focusing on using the directory as a
common repository of information for all applications, operating systems,
and resources, rather than viewing it as a private data store for Unix
account information. This means that this integration is designed
in such way that many pieces of common information in the directory can
be shared between various applications, and can be applied to existing
directories.
Schema Definitions
The definition of the schema plays a very
important role in the design of any LDAP enabled application, since the
schema defines how the data is stored in the directory. In case of
the HP-UX integration, with the use of search filters and attribute assignments
this are has essentially become configurable by the end user and therefore
at least in theory should work with any schema implementations. However,
as default, the schemas defined by RFC
2307 are used to store, and retrieve the information from the directory.
This RFC defines a set of schemas that allow LDAP to be used as a backend
to store information in the same manner as NIS.
Single Sign On
Single sign on is the next step in this chain of evolution. Once applications and operating systems start to use an LDAP directory as a repository for their network and authentication information, the next natural move for them is to authenticate into the directory directly. Doing so will free up the applications from the task of authentication and managing user credentials, and allows them to concentrate more on the essence of their application. Once the authentication is actually done into the directory for all applications and operating system, then single sign on can be achieved if the host operating system provides re-bind services to the directory server. Doing so will allow applications to authenticate to the directory without requiring the user to re-enter his/her password or credentials. Additionally, looking even further down the road, since operating system and applications store their data into the LDAP directory, there is no need for the applications to authenticate at all since the user in the operating system has already authenticated into the directory and has access to the data required by the application.
This, however, would require different
applications to be aware of LDAP and specifically change their authentication
methods, but it is very likely that once various applications become aware
of the advantages of the directory services and start to use them, they
will also take the next step (or steps) as well. This project takes
the first step and provides the building blocks as a step toward Single
Sign On.
Conclusion
This paper provides a very high level view of how integration of HP-UX account and group information into an LDAP directory can be done, in addition to providing some insight into benefits one might get from doing so. However, due to very young age of LDAP protocol and related standards, this is a moving target and is evolving at a very fast pace. And this is yet another reason for designing the integration project with utmost flexibility in mind. Currently there are many different groups of people working on solving the same problem, and although due to lack of standards in the area, our solution might be different from others, but given the flexibility of our design, coexistence between these systems should be achievable via simple re-configuration of the our client.