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. Many organizations including HP are moving support away from NIS+ in favor of LDAP because they see LDAP as the long-term solution. The acceptance of LDAP and the deployment of LDAP directories in many enterprises have created a need for existing UNIX clients from a variety of vendors to access data stored in an LDAP directory.
LDAP directories can play many roles in an enterprise, one of them being a naming service for POSIX systems. Specifically, LDAP can provide a scalable replacement to an NIS-based architecture. Just as NIS became a de-facto standard, a schema defined by RFC 2307 provides a standard way to represent POSIX naming information (NIS databases) in an LDAP directory. Aside from scalability, LDAP directories (often with the help of a meta-directory) offer the promise to integrate many disparate applications such as HP-UX account information and a Human Resources database, thus consolidating data and administration. For example, a name change in an HR database could change the finger information in the HP-UX account. And LDAP directories appear to be the backbone for future security mechanisms, such as a public-key infrastructure. Many Web browsers can interface directly with an LDAP directory in order to obtain user credentials as well as the necessary public keys to allow symmetric and asymmetric cryptography to take place.
In this chapter, we establish a cookbook approach to setting up an LDAP directory containing the information that we would normally store in the text files we mentioned above, e.g., /etc/passwd, /etc/group, /etc/services, and so on. This is a basic introduction just to show you where to start. Beyond this introduction, we are looking at a much more detailed understanding of products such as Netscape Directory Services. That is a whole different certification and product track that some of us might want to investigate. Essentially, the object of this introduction is to demonstrate how to store user-related information in an LDAP directory. This information could be accessed by many different pieces of software ranging from the login process to email to Internet browsers. We start with an introduction to LDAP and then get straight into using the software.
Directories are repositories of names. Names can be anything from a username to a hostname to a domain name, and are essential for navigating loosely structured data like the Internet. In Chapter 17, we spoke about a directory we all know and love: the Domain Name System (DNS). DNS works great, but it requires users to know the domain name they want. Applications like email and network management can benefit from more natural directory entries that include, for instance, people's names, type of service, or geographic location. This is particularly true on the global Internet, where the address space is growing exponentially; but it's increasingly true on wide-area intranets as well. This is essentially the problem solved in the old days with products such as Yellow Pages, a.k.a. NIS. There have been attempts at supplying directories as an integral part of the operating system with products such as Novell's NDS. Being proprietary, NDS was never going to work in open arenas such as UNIX and the Internet. In open networking, these capabilities are provided for in an international standard called X.500. Adoption of X.500, which has been around since 1988, has been slow because of its complexity and the practical constraint that its client half, Directory Access Protocol (DAP), was too big and cumbersome to run on most machines of the day. What we needed was the capabilities of X.500 but without all its baggage. Then, a couple of guys from the University of Michigan had a look at X.500 and decided it was a good starting point; they just needed to make it more efficient and sleeker. LDAP was born. Lightweight Directory Access Protocol (LDAP) is an Internet standard produced by the Internet Engineering Task Force (IETF). W. Yeong, T. Howes, and S. Kille at the University of Michigan wrote the original LDAP RFC. An excellent introduction to LDAP was written by Tim Howes and Mark Smith and is available at http://www.isoc.org/HMP/PAPER/173/html/paper.html. 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. 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 the 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
LDAP, or should we say Lightweight DAP, is also known as X.500 Lite; the protocol enables corporate directory entries to be arranged in a hierarchical structure that reflects geographic and organizational boundaries. Using LDAP, companies can map their corporate directories to actual business processes, rather than to arbitrary codes. The acceptance of Lightweight Directory Access Protocol 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 directory enablement, but little real integration with LDAP. I am sure that this situation will change in the not-too-distant future.
In June 2000, HP entered the LDAP arena with a number of new products on HP-UX 11.0 that provide a full range of directory integration. We can choose the level of integration that meets our needs, or we may migrate our 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).
NSS_LDAP accesses configuration data via native LDAP (the name service switch file
/etc/nsswitch.conf).PAM_LDAP authenticates HP-UX users to an LDAP directory (the
/etc/pam.conffile to integrate with the login process).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.
LDAP directories are arranged like a UNIX filesystem (an inverted tree). Below the topmost root node, country information appears, followed by entries for companies, states, or national organizations. Next come entries for organizational units, such as branch offices and departments. Finally, we locate individuals, which in X.500 and LDAP includes people, shared resources such as printers, and documents. An LDAP directory server makes it possible for a corporate user to find the information resources they need anywhere within the enterprise network. The namespace looks very much like the namespace of DNS, but names are referenced in a different format. For example, we could have a top-level organization called maabof.com (our DNS domain name). We would reference this entry as o=maabof.com. Organization units are referenced below our organization. Some administrators have been known to store their UNIX-type information in an organizational unit called unix. We could reference this using the name ou=unix, o=maabof.com. Below that, we would have People ou=People, ou=unix, o=maabof.com. Eventually, we get to individual entries that have a common name cn=Alice referred to as the Relative Distinguished Name. Entries are named by one of their attributes, e.g., uid. Entries themselves are typed by using an attribute known as objectClass; for example, the objectClass for Alice could be objectClass = person. A fully qualified entry is known by its Distinguished Name and includes the entry used to identify it; for example, the DN for Alice could be dn: uid=Alice,ou=People,ou=unix,o=maabof.com (Figure 21-1).
What we need is a piece of software to house our directory. Commonly, that software will be Netscape Directory Services on UNIX (or it could alternately be the iplanet software). Windows 2000 uses Active Directory Services and could be used to store our UNIX usernames and passwords. The directory acts like a database. Like any other database, our directory has a schema associated with it. In a POSIX arena like HP-UX, we need a mechanism to ensure that the directory schema accommodates POSIX objects and attributes. This has been taken care of by RFC 2307 (http://www.ietf.org/rfc/rfc2307.txt), which provides a standard way to represent POSIX naming information in an LDAP directory. We need to ensure that our Directory Services product adheres to this schema. Netscape Directory Services 4.X has the RFC 2307 schema already installed. We next need to consider which LDAP Integration products we will use on HP-UX.
The LDAP-UX Integration products consist of two main products, the LDAP-UX Client Services and the NIS/LDAP Gateway. Each product provides a different approach for connecting your HP-UX system to an LDAP directory, allowing you to use an LDAP directory environment for HP-UX system management. The two products can be used together or separately.
The fundamental features of the LDAP-UX Integration products allow you to take your user and group information (which was once stored in /etc/passwd and /etc/group files, or in the NIS passwd and group databases) and place that data in an LDAP directory. HP-UX applications that conform to the POSIX API standard (ones that use getpwnam, for example) will be able to discover account and group information from LDAP without modification. RFC 2307 describes a standard schema for storing NIS information in an LDAP directory, which is used by both of these products. You can also extend existing directory entries using the RFC 2307 schema, merging information from multiple sources into one entry per person or per group in the directory. For example, you can combine HR, email, and HP-UX account information into one entry per person in your global directory.
Aside from providing a name resolution service, the LDAP-UX Integration product contains scripts that allow you to convert your account, group, and other NIS-based databases into LDIF (LDAP Directory Interchange Format.). This format will help you import your data into your LDAP directory.
The NIS/LDAP Gateway consists of a gateway server that converts requests from NIS clients into LDAP requests and queries the LDAP directory. The LDAP data is converted back to NIS data and is returned in a response to the NIS client.
The LDAP-UX Client Services product is installed directly on an HP-UX client. All user and group name service requests are routed through the Name Service Switch and then directly to the LDAP directory. In addition, aside from name services, the LDAP-UX Client Services product also supports the PAM (Pluggable Authentication Module) architecture. It is this product that we will be installing and configuring.
Both products are available as a complete bundle (J4269AA) and free to download from http://software.hp.com. I would strongly suggest that you download the accompanying documentation from http://docs.hp.com. I go through a similar process as detailed in the documentation, except I assume little or no knowledge of Netscape Directory Services and provide a step-by-step process to get Netscape Directory Services as well as the LDAP-UX Client Services software installed and running. Remember, this is a basic introduction to these products. Full integration and functionality will necessitate additional study and ideally additional training.
The purpose of this step-by-step guide is to get LDAP and the LDAP-UX Integration software up and running in a minimal configuration. The resulting configuration will, we hope, allow users to log in to our server, as normal, with their login details stored in a directory. We will also configure additional servers to utilize the directory. In effect, we could say that we are emulating an NIS-type environment, but we are using LDAP instead of NIS. The installation steps were undertaken with DNS configured using our domain name of maabof.com. This will become evident in some of the questions/responses from the various software components. Let's get started.
We need to install Netscape Directory Service 4.X. This software comes free of charge with HP-UX 11i Operating Environments but is not installed by default. Once installed using swinstall, there is a setup program we need to run in order to configure the basic features of our LDAP directory:
root@hpeos003[] swlist -l product NscapeDir40Srv
# Initializing...
# Contacting target "hpeos003"...
#
# Target: hpeos003:/
#
NscapeDir40Srv B.04.16 The Netscape Directory Server v4.
root@hpeos003[]
The LDAP-UX Integration products require a reboot in order to install them. We use these products a little later.
root@hpeos003[] swlist -l product J4269AA
# Initializing...
# Contacting target "hpeos003"...
#
# Target: hpeos003:/
#
# J4269AA B.03.10 LDAP-UX Integration
J4269AA.NisLdapServer B.03.10 The NIS/LDAP Gateway (ypldapd)
J4269AA.LdapUxClient B.03.10 LDAP-UX Client Services
root@hpeos003[]
The first part of this process is to run the Netscape setup program. This will ask us a series of questions. Most of the default values are fine. I won't list every detail of every screen, but just the questions and my responses:
root@hpeos003[] /var/opt/netscape/server4/setup/setup
Netscape Communications Corporation
Netscape Server Family Installation/Uninstallation
-----------------------------------------------------------------------------
Welcome to the Netscape Server Family installation program
This program will install Netscape Server products and the
Netscape Console on your computer.
It is recommended that you have "root" privilege to install the software.
During the installation:
- Press "Return" to choose the default and go to the next screen
- Type "Control-B" to go back to the previous screen
- Type "Control-C" to cancel the installation program
- Enter comma-separated list of numbers, e.g., 1, 2, 3, for selection
of multiple items.
Would you like to continue with setup? [Yes]:
…
Do you agree to the license terms? [No]: YES
…
Choose your installation type [2]:
…
Machine's name [hpeos003.hq.maabof.com]:
…
System User [www]:
System Group [other]:
…
Do you want to register this software with an existing Netscape configuration directory server? [No]:
…
Do you want to use another directory to store your data? [No]:
…
Directory server network port [389]:
…
Directory server identifier [hpeos003]:
…
Netscape configuration directory server administrator ID [admin]:
Password: <password>
Password (again): <password>
…
The suffix is the root of your directory tree. You may have more than
one suffix.
Suffix [o=maabof.com]:
…
Directory Manager DN [cn=Directory Manager]:
Password: <password>
Password (again): <password>
…
Administration Domain [maabof.com]:
…
Administration port [23929]:
…
Run Administration Server as [root]:
[slapd-hpeos003]: starting up server ...
[slapd-hpeos003]: [28/Nov/2003:11:30:20 +0000] - Netscape-Directory/4.16
B01.301.1944 starting up
[slapd-hpeos003]: [28/Nov/2003:11:30:29 +0000] - listening on all interfaces
port 389 for LDAP requests
[slapd-hpeos003]: [28/Nov/2003:11:30:29 +0000] - slapd started.
Your new directory server has been started.
Created new Directory Server
Start Slapd Starting Slapd server configuration.
Success Slapd Added Directory Server information to Configuration Server.
Configuring Administration Server...
Your parameters are now entered into the Administration Server
database, and the Administration Server will be started.
Changing ownership to admin user root...
Setting up Administration Server Instance...
Configuring Administration Tasks in Directory Server...
Configuring Global Parameters in Directory Server...
Netscape-Administrator/4.2 B2001.300.0756
startup: listening to http://hpeos003, port 26964 as root
warning: daemon is running as super-user
Info: Cache expiration set to 600 seconds
Info: Cache expiration set to 600 seconds
Press any key to continue...
Go to /var/opt/netscape/server4 and type startconsole to
begin managing your servers.
root@hpeos003[]
The SHLIB_PATH environment variable is commonly not set up for the root user. It must be set up with the contents of the /etc/SHLIB_PATH file in order for LDAP commands work properly:
root@hpeos003[] ldapsearch -b 'o=maabof.com' 'objectclass=*' /usr/lib/dld.sl: Can't find path for shared library: libnspr3.sl /usr/lib/dld.sl: No such file or directory Abort(coredump) root@hpeos003[] root@hpeos003[] export SHLIB_PATH=$(cat /etc/SHLIB_PATH) root@hpeos003[] root@hpeos003[] ldapsearch -b 'o=maabof.com' 'objectclass=*' | more dn: o=maabof.com objectclass: top objectclass: organization o: maabof.com aci: (targetattr = "*")(version 3.0; acl "Allow self entry modification"; allow (write)userdn = "ldap:///self";) aci: (targetattr != "userPassword") (version 3.0; acl "Anonymous access"; allow (read, search, compare)userdn = "ldap:///anyone";) aci: (targetattr = "*")(version 3.0; acl "Configuration Adminstrator"; allow ... root@hpeos003[]
This location is where clients will access information such as usernames and passwords. The base DN may be the organizational unit that is the top of our tree, i.e., ou=maabof.com. Sometimes, it makes sense to create a separate organizational unit to store this information. I followed the guidelines in the documentation and called my organizational unit unix. To create this, we can either use the Netscape Directory Service interface (/var/opt/netscape/server4/startconsole) or the command ldapmodify. I prefer to use the lpmodify command. I find the easiest way to apply changes to the Directory is to create a file containing the appropriate attributes and then pass the filename to the command. We need to recall the common name and password for the directory administrator that the setup program asked us about; the default is cn=directory manager. Here I am updating by adding the organizational unit unix to my Directory.
root@hpeos003[] cat /tmp/ldap.unix dn: ou=unix,o=maabof.com ou: unix objectClass: top objectClass: organizationalUnit root@hpeos003[] root@hpeos003[] ldapmodify -a -D 'cn=directory manager' -w <password> -f /tmp/ldap.unix adding new entry ou=unix,o=maabof.com root@hpeos003[]
The profile contains directory access information. It specifies how and where clients can find user and group data in the directory. You can put the profile anywhere you want as long as the client systems can read it. For example, you might put it near your user data, or in a separate administrative area. You should put the profile in the same directory as your user and group data to simplify access permissions. Clients must have access to both the profile and the user and group data. I am going to create a separate directory under the unix directory to store my profiles. I call it profiles and use the ldapmodify command again.
root@hpeos003[] cat /tmp/ldap.profile dn: ou=profiles,ou=unix,o=maabof.com ou: profiles objectClass: top objectClass: organizationalUnit root@hpeos003[] root@hpeos003[] ldapmodify -a -D 'cn=directory manager' -w <password> -f /tmp/ldap.profile adding new entry ou=profiles,ou=unix,o=maabof.com root@hpeos003[]
We could have combined both this and the previous actions into one file to pass to ldapmodify.
Netscape uses access control identifiers (ACI) to control access to entries in the directory. A top-level ACI allows users to change any of their password-related attributes.
root@hpeos003[] ldapsearch -b 'o=maabof.com' 'objectclass=*' |more dn: o=maabof.com objectclass: top objectclass: organization o: maabof.com aci: (targetattr = "*")(version 3.0; acl "Allow self entry modification"; allow (write)userdn = "ldap:///self";) ... root@hpeos003[]
I am going to modify this restrict access to important user-related attributes including uid, gid, and home directory. I could do this at the top-level or at the unix level down. In this example, I will set it at the unix directory level:
root@hpeos003[] cat /tmp/ldap.user.aci dn: ou=unix,o=maabof.com changetype: modify replace: aci aci: (targetattr != "uidnumber || gidnumber || homedirectory || uid") (version 3.0; acl "Allow self entry modification, except for important posix attributes"; allow (write)userdn = "ldap:///self";) root@hpeos003[] root@hpeos003[] ldapmodify -D "cn=directory manager" -w <password> -f /tmp/ ldap.user.aci modifying entry ou=unix,o=maabof.com root@hpeos003[]
There are other ACI that we may want to change; we do that in a minute.
There are various ways you can do this. The schema is described in the file /opt/ldapux/ypldapd/etc/slapd-v3.ni.conf. From that, you could extract all of the objectclasses and allow read access based on the classes you wanted users to read. Here's an example file where I am allowing read access only for the posixGroup objects, i.e., groups listed in /etc/group.
root@hpeos003[] cat /tmp/ldap.posix
dn: ou=unix,o=maabof.com
changetype: modify
add: aci
aci: (targetattr="*")(targetfilter = "(objectclass=posixGroup)") (version 3.0;
acl "Global read permission for POSIX group"; allow (compare,read,search) userdn
= "ldap:///anyone";)
root@hpeos003[]
I could add further entries for specific attributes and use ldapmodify to apply the changes. By default, everyone has read access to the directory anyway, so the restrictions I set up at the beginning of this exercise should suffice for most situations. The only change could be to restrict write access to the posixGroup entries such than only directory administrators can modify them:
root@hpeos003[] cat /tmp/ldap.group.aci dn: ou=unix,o=maabof.com changetype: modify add: aci aci: (targetattr = "*")(version 3.0;acl "Disallow modification of group entries"; deny (write) (groupdn != "ldap:///ou=Directory Administrators, o=maabof.com");) root@hpeos003[] ldapmodify -a -D 'cn=directory manager' -w <password> -f /tmp/ ldap.group.aci modifying entry ou=unix,o=maabof.com root@hpeos003[]
If we don't create a proxy user, we need to configure our name service data to be read anonymously (this will be part of the data migration process in a minute). I do this via the Directory Services console /var/opt/netscape/server4/startconsole: we will be asked for the Directory Services administrator password (the admin user created during the setup program) (Figure 21-2):
You need to take the following steps here:
Click on the “
User and Groups” tab.Bind to the directory using the directory manager DN. I click the “
Directory” button to bring up a “Change Directory” dialog box.Change the “
Bind Password” to be the password for the directory manager.Click OK.
Back at the Console window, click “
Create…”Click “
Special Users”. Click OK.Enter the following information:
First name =
ProxyLast Name =
UserUser ID =
proxyuserPassword/Confirm password = <your choice>
Click OK.
You can now shut down the Console if you want.
We need to allow the proxy user (if configured) to be able to read user attributes, except the user password attribute. I do this with ldapmodify:
root@hpeos003[] cat /tmp/ldap.proxy-read.aci dn: ou=unix,o=maabof.com changetype: modify add: aci aci: (target="ldap:///ou=unix,o=maabof.com")(targetattr!="userpassword") (version 3.0; acl "Proxy userpassword read rights"; allow (compare,read,search) userdn = "ldap:///uid=proxyuser,ou=Special Users,o=maabof.com";) root@hpeos003[] root@hpeos003[] ldapmodify -a -D 'cn=directory manager' -w <password> -f /tmp/ ldap.proxy-read.aci modifying entry ou=unix,o=maabof.com root@hpeos003[]
We are just about to migrate our user information into the directory. We might want to customize files like /etc/passwd, /etc/group, and so on. It's probably a good idea to remove user entries like root and system users. We will still maintain these users in our /etc/passwd file, and we don't want anyone to be able to see any information relating to the root user.
I am not using NIS, just simple /etc/passwd, /etc/group, and so on. With the LDAP-UX Client Services product, there is a utility that will migrate all of my user information into the directory with one command. The command is migrate_all_online.sh:
root@hpeos003[] cd /opt/ldapux/migrate root@hpeos003[migrate] ./migrate_all_online.sh Enter the X.500 naming context you wish to import into: [] ou=unix,o=maabof.com Enter the name of your LDAP server [ldap]: hpeos003.hq.maabof.com Enter the manager DN: [cn=manager,ou=unix,o=maabof.com]: cn=directory manager Enter the credentials to bind with: <directory manager password> Importing into ou=unix,o=maabof.com... Creating naming context entries... Migrating aliases... Migrating groups... Migrating hosts... Migrating networks... Migrating users... Migrating protocols... Migrating rpcs... Migrating services... Migrating netgroups... Migrating netgroups (by user)... Migrating netgroups (by host)... Your data has been migrated to the following ldif file: /tmp/nis.2939.ldif Do you wish to import that file into your directory now (y/n): y ... adding new entry cn=hpeos002.maabof.com.*,nisMapName=netgroup. byhost,ou=unix,o=maabof.com adding new entry cn=hpeos001.hq.maabof.com.*,nisMapName=netgroup. byhost,ou=unix,o=maabof.com /opt/ldapux/bin/ldapmodify -a -c: succeeded root@hpeos003[migrate]
I should now be able to see user entries in the directory as the proxyuser:
root@hpeos003[] ldapsearch -D 'uid=proxyuser,ou=special users,o=maabof.com' -w <password> -b 'o=maabof.com' uid=barney dn: uid=barney,ou=People,ou=unix,o=maabof.com uid: barney cn: barney objectclass: top objectclass: account objectclass: posixAccount loginshell: /sbin/sh uidnumber: 110 gidnumber: 107 homedirectory: /home/barney root@hpeos003[]
Notice that we can't see the userpassword. I will just check that barney can see his entry as well.
root@hpeos003[] ldapsearch -D 'uid=barney,ou=People,ou=unix,o=maabof.com' -w <barney password> -b 'o=maabof.com' uid=barney dn: uid=barney,ou=People,ou=unix,o=maabof.com uid: barney cn: barney objectclass: top objectclass: account objectclass: posixAccount loginshell: /sbin/sh uidnumber: 110 gidnumber: 107 homedirectory: /home/barney root@hpeos003[]
Everything looks okay so far!
This is achieved by the /opt/ldapux/config/setup command. There are a number of questions to answer. Again, I list simply the questions and my responses:
root@hpeos003[] cd /opt/ldapux/config root@hpeos003[config] ./setup screen 1 Hewlett-Packard Company LDAP-UX Client Services Setup Program ----------------------------------------------------------------------------- Welcome to the LDAP-UX Client Services Setup Program! You must have "root" privilege to run this Setup Program. If this is the first client you are setting up, this program will: - Extend your directory schema with the LDAP-UX configuration profile schema. - Create a new LDAP-UX configuration profile entry in your directory. - Configure the local client system to use the directory. If your directory already has one or more LDAP-UX configuration profile entries, this program will: - Optionally create another new LDAP-UX configuration profile entry in your directory and configure the local client system to use the directory; - or configure your client system with an existing profile entry. During the configuration: - Press "Return" to choose the default and go to the next screen - Type "Control-B" to go back to the previous screen - Type "Control-C" to cancel the setup program Would you like to continue with the setup? [Yes]: … To accept the default shown in brackets, press the Return key. Directory Server: [1]: … Directory server host [hpeos003.hq.maabof.com = 192.168.0.33]: … Directory Server port number [389]: … Would you like to extend the schema in this directory server? [Yes]: … User DN [cn=Directory Manager]: Password: <password> … Profile Entry DN: []: cn=defaultLDAPprofile,ou=profiles,ou=unix,o=maabof.com … User DN []: cn=directory manager Password: <password> … Default search host 1: [hpeos003:389 = 192.168.0.33:389] Default search host 2: [ ] Default search host 3: [ ] Enter 0 to accept these hosts and continue with the setup program or Enter the number of the hosts you want to specify [0]: … Default base DN [ou=profiles,ou=unix,o=maabof.com]: ou=unix,o=maabof.com … Accept remaining defaults? (y/n) [y]: n … Authentication method: [1]: … Select the type of client binding you want. 1. Anonymous 2. Proxy 3. Proxy; if proxy fails, then use anonymous To accept the default shown in brackets, press the Return key. Client binding: [1]: 3 … Proxy User DN: uid=proxyuser,ou=special users,o=maabof.com Password: <password> … Bind time limit [5 seconds]: … Search time limit [no limit]: … Do you want client searches of the directory to follow referrals? [Yes]: … Profile TTL [0 = infinite]: … Do you want to remap any of the standard RFC 2307 attribute? [No]: … Do you want to create custom search descriptors? [No]: … Are you ready to create the Profile Entry? [Yes]: Updated directory server at 192.168.0.33:389 with a profile entry at [cn=defaultLDAPprofile,ou=profiles,ou=unix,o=maabof.com] Updated the local client configuration file /etc/opt/ldapux/ldapux_client.conf Updated the local client profile entry LDIF file /etc/opt/ldapux/ldapux_profile.ldif Updated the local client profile entry cache file /etc/opt/ldapux/ldapux_profile.bin … Would you like to start/restart the LDAP-UX daemon (y/n)? [y]: Updated the LDAP-UX daemon configuration file /etc/opt/ldapux/ldapclientd.conf Restarted the LDAP-UX daemon! To enable the LDAP Pluggable Authentication Module, save a copy of the file /etc/pam.conf then add ldap to it. See /etc/pam.ldap for an example. To enable the LDAP Name Service Switch, save a copy of the file /etc/nsswitch.conf then add ldap to it. See /etc/nsswitch.ldap for an example. LDAP-UX Client Services setup complete. root@hpeos003[config]
We need to ensure that the login process references the LDAP directory whenever a user logs in and his entry is not listed in the /etc/passwd file. As you can see, the /etc/pam.ldap file is usually okay for most situations.
root@hpeos003[] cp /etc/pam.conf /etc/pam.org root@hpeos003[] cp /etc/pam.ldap /etc/pam.conf root@hpeos003[]
As well as /etc/pam.conf, we need to ensure that any utilities referencing user-level information can locate the proper source for data. The file to tell them the next source is /etc/nsswitch.conf. An example file /etc/nsswitch.ldap can be used as a template. You should customize /etc/nsswitch.conf to include LDAP as well as any other switch configuration you have in place, e.g., for hosts and ipnodes (Ipv6).
root@hpeos003[] cat /etc/nsswitch.conf
#
# /etc/nsswitch.ldap:
#
# An example file that could be copied over to /etc/nsswitch.conf. It
# uses LDAP (Lightweight Directory Access Protocol) in conjunction with
# dns & files.
#
passwd: files ldap
group: files ldap
hosts: files [NOTFOUND=continue] dns [NOTFOUND=continue] ldap
networks: files ldap
protocols: files ldap
rpc: files ldap
publickey: files
netgroup: files ldap
automount: files
aliases: files
services: files ldap
root@hpeos003[]
We need to ensure that basic user functionality has not been affected. Users must still be able to log in and perform all tasks they would normally do. We can test this functionality beforehand using commands like nsquery:
root@hpeos003[] nsquery passwd barney ldap Using "ldap" for the passwd policy. Searching ldap for barney User name: barney User Id: 110 Group Id: 107 Gecos: Home Directory: /home/barney Shell: /sbin/sh Switch configuration: Terminates Search root@hpeos003[] root@hpeos003[] nsquery hosts hpeos003 ldap Using "ldap" for the hosts policy. Searching ldap for hpeos003 Hostname: hpeos003 Aliases: hp003_lan0 hpeos003.hq.maabof.com Address: 192.168.0.33 Switch configuration: Terminates Search root@hpeos003[]
There is a contributed utility called beq, that comes as part of the LDAP-UX Integration software that allows you to query the directory server as if it were a UNIX utility making a query on usernames, password, network services, and so on. It can be useful for debugging problems. Here's an example of performing a query for the telnet service:
root@hpeos003[] cd /opt/ldapux/contrib/bin root@hpeos003[bin] ./beq -k n -s srv -l /usr/lib/libnss_ldap.1 telnet tcp nss_status .............. NSS_SUCCESS s_name...........(telnet) s_proto..........(tcp) s_port...........(23) s_aliases NONE root@hpeos003[bin]
Or a username from the password (pwd) service:
root@hpeos003[bin] ./beq -k n -s pwd -l /usr/lib/libnss_ldap.1 fred
nss_status .............. NSS_SUCCESS
pw_name...........(fred)
pw_passwd.........(*)
pw_uid............(109)
pw_gid............(20)
pw_age............()
pw_comment........()
pw_gecos..........()
pw_dir............(/home/fred)
pw_shell..........(/sbin/sh)
pw_audid..........(0)
pw_audflg.........(0)
root@hpeos003[bin]
Ultimately, the test we really need to perform is to remove all our non-system entries from the /etc/passwd and /etc/group files and ensure that users can still log in. Here is my /etc/passwd file:
root@hpeos003[] cat /etc/passwd
root:qSilPI22TtKuw:0:3::/.root:/sbin/sh
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
uucp:*:5:3::/var/spool/uucppublic:/usr/lbin/uucp/uucico
lp:*:9:7::/var/spool/lp:/sbin/sh
nuucp:*:11:11::/var/spool/uucppublic:/usr/lbin/uucp/uucico
hpdb:*:27:1:ALLBASE:/:/sbin/sh
oracle::102:102:Oracle:/home/oracle:/usr/bin/sh
www:*:30:1::/:
webadmin:*:40:1::/usr/obam/server/nologindir:/usr/bin/false
smbnull:*:101:101:DO NOT USE OR DELETE - needed by Samba:/home/smbnull:/sbin/sh
sshd:*:106:104:sshd privsep:/var/empty:/bin/false
ids:*:107:105:HP-UX Host IDS Administrator:/home/ids:/sbin/sh
mysql:*:104:106::/home/mysql:/sbin/sh
root@hpeos003[]
I need to ensure that users can still log in. I suppose I need to try it out!
root@hpeos003[] login login: barney Password: <password> Please wait...checking for disk quotas (c)Copyright 1983-2000 Hewlett-Packard Co., All Rights Reserved. (c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California (c)Copyright 1980, 1984, 1986 Novell, Inc. (c)Copyright 1986-1992 Sun Microsystems, Inc. (c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology (c)Copyright 1989-1993 The Open Software Foundation, Inc. (c)Copyright 1986 Digital Equipment Corp. (c)Copyright 1990 Motorola, Inc. (c)Copyright 1990, 1991, 1992 Cornell University (c)Copyright 1989-1991 The University of Maryland (c)Copyright 1988 Carnegie Mellon University (c)Copyright 1991-2000 Mentat Inc. (c)Copyright 1996 Morning Star Technologies, Inc. (c)Copyright 1996 Progressive Systems, Inc. (c)Copyright 1991-2000 Isogon Corporation, All Rights Reserved. RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS 252.227-7013. Hewlett-Packard Company 3000 Hanover Street Palo Alto, CA 94304 U.S.A. Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR 52.227-19(c)(1,2). You have mail. $ pwd /home/barney $ id uid=110(barney) gid=107(admin) $ $ pwget -n barney barney:*:110:107::/home/barney:/sbin/sh $
It looks as if barney is able to function as normal. You probably noticed that his password is represented by an asterisk. The default behavior of the POSIX schema is to represent passwords as an asterisk (a null, effectively) when some form of valid entry is required by a UNIX command. If we remember back to when we were setting up access controls on the directory, we disallowed read access to the userpassword attribute. This is still in force; it's just that pwget (and commands like it) needs to produce valid output.
To add another client into this network, I would perform the following steps:
Install LDAP-UX Integration software.
root@hpeos004[] swlist -l bundle J4269AA # Initializing... # Contacting target "hpeos004"... # # Target: hpeos004:/ # J4269AA B.03.10 LDAP-UX Integration root@hpeos004[]Copy the following files from the current directory server:
/etc/opt/ldapux/ldapux_client.conf/etc/opt/ldapus/pcred(as I am using a proxyuser)/etc/pam.conf/etc/nsswitch.conf
Start the LDA-UX client daemon.
root@hpeos004[] /sbin/init.d/ldapclientd.rc start ldapclientd started with <0> root@hpeos004[]Download the profile from the server by using the following command:
root@hpeos004[] cd /opt/ldapux/config root@hpeos004[config] ./get_profile_entry -s nss
Check that the proxy user configuration is valid, viewed from this machine:
root@hpeos004[config] ./ldap_proxy_config -p PROXY DN: uid=proxyuser,ou=Special Users,o=maabof.com root@hpeos004[config] ./ldap_proxy_config -v File Credentials verified - valid SCS Credentials verified - valid File copy & SCS copy are synchronized root@hpeos004[config]
Test user functionality. I suppose if this is all working as we would expect,
barneyshould now be visible as a user even though he hasn't been configured on this server:root@hpeos004[config] grep barney /etc/passwd root@hpeos004[config] pwget -n barney barney:*:110:107::/home/barney:/sbin/sh root@hpeos004[config]
In order for barney to login, all we would need to ensure is that his home directory was available.
This has been a brief introduction to LDAP-UX Client Services. There are still a number of jobs we need to concern ourselves with. The first is something called enumeration.
Enumeration requests are directory queries that request all of a database, for example, all users or all groups. Enumeration requests of large databases could reduce network and server performance. Commands like
pwget(with no options),finger,groups, and so on fall into this category. There are parameters (e.g., look-through size) we can set in a machine's profile that will affect enumerated commands and system calls.We should also consider setting up a Replica Server to provide redundancy in our network. If we set up a replica server, it has an impact on the how passwords are changed. Namely, passwords can't be modified on a Replica Server because it is supposed to be a replica of the real directory server. We can use the command
ldappaswddto affect password changes.We also need to consider integration with other directory server products such as Windows 2000 Active Directory Service (ADS). That poses the possibility of having all of our UNIX users and passwords stored on a Windows 2000 machine. We saw a variant of that approach when we talked about CIFS 9000 and the
libpam_ntlm.1authentication library in/etc/pam.conf. The biggest problem with integrating UNIX and Windows logins into one directory is the support for the POSIX attributes required by UNIX login and password features. When using multiple ADS domains, it is necessary to update the Global Catalog server with the relevant POSIX attributes. Depending on the version of ADS, the names of the POSIX attributes used will be changed. Again, if you are interested in such a solution, the documentation available on http://docs/hp.com is a great starting point. An excellent manual is the “Installing and Administering LDAP-UX Client Services with Microsoft Windows 2000 Active Directory” (part number J4269-90017) to explain all the intricacies of ADS versions and POSIX attributes.HP-UX Trusted Systems and LDAP cannot coexist using the current implementation of both software components. Realistically, HP-UX Trusted Systems is the software that will need to change because the structure used for the TCB is wholly proprietary and it is this structure that cannot fit into an LDAP directory as it stands. This is a major stumbling block for some sites where operating system security is a prime concern. At the time of this writing, there appears to be no solution on the horizon although HP has acknowledged the fact that a solution will have to be found. An alternative solution would be to look at HP's Shadow Password software (http://software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=ShadowPassword), which allows for a password file called
/etc/shadowwhereby the encrypted passwords are accessible only by therootuser. This software does not give any other benefits other than removing the encrypted passwords from the world-readable/etc/passwdfile; it does not give any of the auditing, time, and location-based access controls or password and account management features that a full-blown Trusted System offers. Although this is a significant limitation, it still offers a compromise solution until such time as HP reworks Trusted Systems to integrate with LDAP. Here is a quote from the Shadow Passwords documentation relating to integration with LDAP: “This product may be used with the LDAP-UX Integration product version B.03.00 or later.”The last thing to mention is the use of LDAP URLs in a browser. This is now a feature of many browsers. The format of an LDAP URL is explained in the associated RFC (http://www.ietf.org/rfc/rfc1959.txt), which has some excellent examples.
As you can see, the list of tasks associated with setting up a directory server grows the more we try to utilize it. If this brief introduction has whetted your appetite, I would strongly suggest that you get to the nearest Netscape Directory Services training class and do some detailed study of the LDAP-UX Integration products manual. The manual covers some of the additional tasks I have mentioned above. It also goes through commands to add entries into the directory; for example, to add users, we can use the ldapentry command.
More and more products are being written LDAP-aware in order to utilize its capabilities. Security products tend to be leading the way with the need to distribute information such as security keys used in encryption software. The mechanism used to distribute the keys is often a directory server. In this chapter, we went through a simple step-by-step cookbook in order to get a basic LDAP configuration up and running. What we were attempting to do was to introduce the concept of LDAP as well as make us aware of the steps required to get the software up and running. In addition, we used the LDAP-UX Client Services software to utilize the user information stored in the directory. At its heart, this software wants to store user details in the directory server. We have demonstrated that this is possible. LDAP set out to be a lightweight protocol to allow disparate applications access to corporate-wide information. It achieves this goal and looks like to be a dominant force in the marketplace. With more and more vendors signing up to have LDAP-aware products and features in their operating systems, we can even see the day when interoperability will be a feature we take for granted instead of the current state of affairs where interoperability between vendors is seldom seen and seldom works effectively. Keep you eyes trained on LDAP; it might just fundamentally change the way we work.
Looking at the example in Figure 21-3, what is the DN of the /data filesystem: | |
Some directory services products give write access to a user's own entries in a directory. When we import | |
Which two standard HP-UX configuration files should be updated to ensure that the HP-UX login process uses LDAP as a source of user and group data? | |
What are known as enumeration requests, and how can they impact my network and my server? | |
Is there anything we could do to hide UNIX-encrypted passwords in the |
