Data is valuable only if it can be stored and accessed. With multiple vendors of directory services solutions competing for your business, you may worry that their disparate systems will not be able to interoperate and that it will be difficult for clients to support multiple vendors. This chapter will help you to store and access data on Mac OS X server.

Troubleshoot problems with Open Directory records retrieved from an LDAP database

Interpret entries in a network user account to determine why a user is unable to log in correctly

Data is valuable only if it can be stored and accessed. With multiple vendors of directory services solutions competing for
your business, you may worry that their disparate systems will not be able to interoperate and that it will be difficult for
clients to support multiple vendors. Lightweight Directory Access Protocol (LDAP) addresses these concerns by providing a protocol that all vendors can support while still being able to differentiate themselves
on the basis of additional features, over and above what a simple data access protocol dictates.

This lesson introduces you to the LDAP specification and explains Mac OS X support for this nearly universal protocol. In Lesson 2, “Accessing Local Directory Services,” you saw how Open Directory provides a means of retrieving information from a local
data store to identify and authenticate user accounts on the local computer. Now you’ll learn how to request and retrieve
identification information stored in an LDAP directory on the network, in particular, the LDAP directory on Mac OS X Server.

By accessing the directory in Mac OS X Server on your network, you can take advantage of features such as automounting share
points, preferences management, and mobile user accounts.

Understanding LDAP

LDAP is an industry-standard method of accessing data from within a directory. If your organization already has a network directory
service in place, it is likely that the directory is based on LDAP or is accessible via LDAP. LDAP is many things, and can be described in different ways. It is:

An information model. It defines how data is accessed.

A namespace. It defines how to distinguish one piece of data from another, similar to a URL.

A protocol. It defines how a client can read, write, and search for data.

A distribution model. LDAPv3 defines how to distribute the logical information model physically. This means that data can
be partitioned and stored on multiple hosts, while still being one logical directory.

More Info

The distribution model aspect of LDAP is not covered in this book. Please refer to the References section at the end of this lesson for more information.

A way to standardize access to directory data, regardless of how or where that data is stored. This standardization, while
simple in in concept, is quite complex in implementation, requiring standardized naming (the namespace) and standardized searching.

Extensible. It can be customized to fit any organization’s directory services needs.

LDAP Information Model

The basic unit of LDAP is an entry, or an instance of related attributes. It consists of one or more attributes and the values for those attributes in the following
format:

attribute=value

LDAP uses the schema to define attributes, among other things. An object class specifies which attributes are required when populating
the LDAP directory and which attributes will be allowed when populating the LDAP directory. This attribute definition provides data integrity.

Object classes are defined in the schema. Because LDAP is so customizable, the schema can be tailored to meet the needs of many different deployments.

The LDAP Tree

An LDAP directory is arranged in a hierarchy called a tree. In a tree, each entry can have entries beneath it. One useful aspect of LDAP is that the structure of an LDAP hierarchy is not strictly defined, so it is open to different implementations depending on the site. This can lead to confusion
when attempting to understand someone else’s deployment, because the hierarchy has been customized.

The attributes are usually an abbreviation or mnemonic for a typical characteristic. For instance, dc stands for domain component and cn stands for common name. These abbreviations can be used in several locations within the tree and may not be specific to each entry within each entry.

LDAP Namespace

Because the structure of an LDAP directory can be different at each site, you have to tell any LDAP client where to find an entry. To request a particular entry, the client uses the logical path to the entry or the distinguished name (dn). This is similar to an absolute path in the Mac OS X file system. Here is an example of the dn for Warren Peece:

dn:uidNumber=501,cn=users,dc=mainserver,dc=pretendco,dc=com

The structure of the LDAP hierarchy is defined by the distinguished names.

In addition, one or more attributes in an entry can be used as the name of the entry itself. This is the entry’s relative distinguished name (rdn), which is similar to a relative path in the Mac OS X file system. For example

rdn:uidNumber=501

refers to all the attribute/value pairs in that entry.

LDAP Search Parameters

When a requestor (such as a login window) asks for data, some parameters must be defined.

Search Base

The search base is the point in the tree where the requestor starts the search. For instance, the client might want to start searching at
the entry cn=users. If this is the case, then the search base would be defined as

cn=users,dc=mainserver,dc=pretendco,dc=com

Scope

The scope defines how deep to go in the search. For instance, the search could be limited to the same level the search started, limited
to the same level and one level below, or open to all levels below the one where the search started. This becomes important
when searching a large LDAP database or using applications that frequently query the database. Walking down the entire tree consumes processor cycles
and RAM, which can be avoided by refining the scope of the search.

Filter

Finally, a filter specifies the item that is being searched for. In Mac OS X, the filter is automatically constructed by the LDAPv3 plug-in.
Filters, like scopes, can decrease the load on the directory by not searching entries that do not fit certain criteria. For
example, a request might be made to find any cn entries under cn=users. However, since the information under cn=users may
or may not be only user information, you can narrow the search to save time, which you’re about to learn how to do.

LDAP Search Transactions

When searching the LDAP directory with a tool such as ldapsearch, you would limit the request by specifying the search base and filter. The following figure demonstrates how to search for
the mount entries in the LDAP directory on mainserver.pretendco.com.

Breaking down the line of code in the figure above, you can see it does the following:

The -LLL option specifies that you want the output to be in standard LDAP Interchange Format (LDIF).

The -x option tells ldapsearch to make a simple (non-SASL) bind to the directory.

The -H option is used to specify the server (by URL) hosting the LDAP directory.

The -b option is used to specify the search base. In this figure, the filter specifies that you are looking for any entries where
the objectClass attribute is equal to apple-group.

At the end of the search command, you can specify which attributes you want displayed from the resulting entries. In this
case, the attributes are the common name and the objectClass. By default, the search is performed at the level indicated by
the search base and in all subtrees.

The results of the search are a listing of all the group entries (the dn, cn, and objectClass attributes listed) at the dc=mainserver,dc=pretendco,dc=com
level and below. The information is displayed in standard LDIF.

You can also use the ldapsearch command to display information about the root or base dn of an LDAP tree. For example,