Integrating HP-UX Account Management and Authentication with LDAP

ManualsBrandsHP ManualsSoftwareHP-UX Identity Management Integration Software

[1]

Hewlett-Packard

May 04, 2000

Why Integrate LDAP with UNIX?

The acceptance of Lightweight Directory Access Protocol (LDAP) technology has progressed at a rapid pace. Many enterprises have already

deployed LDAP directories, primarily for messaging and security products. As more applications are directory enabled, important tasks such as

administration, authentication and authorization, are being consolidated and centralized. Integrating important operating systems into the

directory greatly enhances the value of this consolidation. Most UNIX vendors have some primitive directory enablement, but little real

integration with LDAP.

In June 2000, HP is releasing several new products on HP-UX 11.0 that will provide a full range of directory integration. Customers may choose

the level of integration that meets their needs, or may migrate their environments one level at a time:

YPLDAP is a protocol gateway that allows UNIX configuration data to be migrated to an LDAP directory, and accessed via existing client

software (NIS). Previously, this product was only available on HP-UX 10.20.

●

NSS_LDAP accesses configuration data via native LDAP.●

PAM_LDAP authenticates HP-UX users to an LDAP directory.●

LDAP Access Profiles provide the ability to customize NSS_LDAP and PAM_LDAP directory access to enable integration and data

sharing with other applications and platforms using LDAP.

●

Lightweight Directory Access Protocol

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. LDAP providers support the most

popular methods of authentication, including password based, Secure Socket Layer (SSL), and Kerberos. LDAP support of the Simple

Authentication and Security Layer (SASL) allows for additional authentication methods to be negotiated. The following RFCs provide detailed

information about LDAPv3 protocol, and other LDAP related standards:

Lightweight Directory Access Protocol v3 (RFC 2251)●

An Approach for Using LDAP as a Network Information Service (RFC 2307)●

A Summary of the X.500(96) User schema for use with LDAPv3 (RFC 2256)●

LDAPv3 Attribute Syntax Definitions (RFC 2252)●

UTF-8 String Representation of Distinguished Names (RFC 2253)●

The String Representation of LDAP Search Filters (RFC 2254)●

The LDAP URL Format (RFC 2255)●

Simple Authentication and Security Layer (RFC 2222)●

SSL 3.0 specification●

UNIX and Directories Today

Originally, UNIX account and configuration information was stored in a series of text files. As the need to share this information across systems

increased, the first widely accepted product named Yellow Pages, and later renamed to Network Information Service (NIS) was developed by

Sun Microsystems. NIS provides network wide management of many UNIX configuration files (e.g., /etc/passwd, /etc/group, /etc/services). An

NIS master server generates maps based on the configuration files and transfers copies to slave servers. On NIS client systems, operations

reading the configuration file are redirected to send a request across the network to retrieve the information from an NIS server.

While providing a high degree of backward compatibility with file based configuration, NIS has limitations in scale and security that prevent it from

being easily deployed in enterprise environments. NIS does not support delta based updates, causing entire maps to be transferred to all the

slave servers. These maps are transferred across the network unencrypted. The underlying database used by NIS servers can support a limited

number of entries, requiring administrators to break up the data by creating multiple NIS domains. Despite these shortcomings, NIS is widely

used today across a variety of UNIX platforms.

NIS+ was introduced as a successor to NIS to provide greater scalability and security. While succeeding to some extent, NIS+ has not achieved

the level of acceptance of NIS. UNIX administrators have reported that the level of complexity in administering NIS+ often outweighs the

benefits. With the arrival of more general purpose directories, the potential of a more powerful generic directory has supplanted the NIS model in

the imagination of the UNIX community. NIS+ suffers from lack of interoperability and therefore it is missing the much needed flexibility in hybrid

environments.

The acceptance of LDAP, and the deployment of LDAP directories in many enterprises has created a need for existing UNIX clients from a

variety of vendors to access data stored in an LDAP directory.

LDAP/HP-UX Integration

http://raptor.cup.hp.com/ldap/doc/WhitePapers/intpaper/uxint.html (1 of 6) [5/4/2000 1:33:48 PM]

Summary of content (6 pages)

PAGE 1
LDAP/HP-UX Integration Integrating HP-UX Account Management and Authentication with LDAP [1] Hewlett-Packard May 04, 2000 Why Integrate LDAP with UNIX? The acceptance of Lightweight Directory Access Protocol (LDAP) technology has progressed at a rapid pace. Many enterprises have already deployed LDAP directories, primarily for messaging and security products.
PAGE 2
LDAP/HP-UX Integration HP-UX NIS/LDAP Gateway (YPLDAP) The HP-UX NIS/LDAP Gateway product (YPLDAP) is a protocol gateway that translates requests and replies between NIS clients and LDAP servers. UNIX information such as user accounts, groups, and services are stored in an LDAP Directory in the format defined by the RFC 2307 schema. UNIX clients configured to use NIS will be able to interact with YPLDAP without modification. YPLDAP replaces the NIS slave server (Figure 1).
PAGE 3
LDAP/HP-UX Integration 4. If found, the front end returns a UNIX password record to getpwuid() which in turn passes the result back to the who command. 5. The who command now displays the user name from the password record. NSS_LDAP is a new back-end that searches an LDAP directory for name service information. The first release will support user, group and shadow password entries.
PAGE 4
LDAP/HP-UX Integration an LDAP directory (Figure 3): 1. The login program calls the C library function pam_authenticate(). 2. pam_authenticate() calls the authentication function for the PAM_UNIX module. 3. PAM_UNIX attempts to find and authenticate the user based on the entry returned by getpwnam(). Note that LDAP-UX has the capability to disable PAM_UNIX authentication for user entries found in the LDAP directory. 4.
PAGE 5
LDAP/HP-UX Integration LDAP directory in an entry called a profile. Each individual HP-UX system now only needs to configure an LDAP server and the name of the profile to be used. The HP-UX LDAP profile includes the following: ● Server name(s) and port(s). This is a set of server names and port ids where the actual search for data will be performed. If a server does not respond to a bind request, HP-UX will attempt to bind to the next server listed. ● Authentication level.
PAGE 6
LDAP/HP-UX Integration Figure 5. Controlling UNIX login with profiles. On the systems using general profile, either Jane or Joe may log in. On systems using finance profile, only Joe is accepted. Some directories contain rich access control list (ACL) functionality that can be used as well. Features such as limiting access to an entry, profile or subtree based on the caller's encryption level, IP address, or DNS domain, can be utilized in a variety of situations.