## Managing Enterprise Wide HP-UX accounts using LDAP 1

### Morteza Ansari

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:

- Lightweight Directory Access Protocol v3 (RFC 2251)
- LDAPv3 Attribute Syntax Definitions (RFC 2252)
- UTF-8 String Representation of Distinguished Names (RFC 2253)
- The String String Representation of LDAP Search Filters (RFC 2254)
- The LDAP URL Format (RFC 2255)
- A Summary of the X.500(96) User schema for use with LDAPv3 (RFC 2256)
- An Approach for Using LDAP as a Network Information Service (RFC 2307)
- Simple Authentication and Security Layer (RFC 2222)
- IMAP/POP AUTHorize Extension for Simple Challenge/Response (CRAM-MD5) (RFC 2095)
- Most recent Draft SSL 3.0 specification (this is only a draft)

Hewlett Packard recently announced that a Lite version of Netscape Mission Control Directory will be shipped with every copy of HP-UX at no cost to customers. This Lite directory has all the features defined in LDAPv3 protocol (with the exception of LDAP referrals), and is an excellent starting point in setting up a LDAP directory in HP-UX environments. This light version of Netscape Directory Services, bundled with HP-UX, has all the functionality needed by most ISVs developing directory enabled applications and will allow network designers to start deploying LDAP directories with minimal effort and cost.

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.

1 Due to the HPWorld's publishing deadlines, this paper had to be submitted before the designs of the LDAP/HP-UX integration project were final, and therefore the content of this paper is subject to change. A final version of this paper will be available at HPWorld during the presentation, or from the author.