Accessing Mac OS X Server Directory Services
This chapter is from the book
This chapter is from the book
This chapter is from the book
Time
This lesson takes approximately 2 hours to complete.
Goals
Understand how data is structured and how entries are distinguished in an LDAP database
Use command-line and GUI tools to search for a specific entries in a given LDAP database
Use Directory Access to add a Mac OS X server providing directory services for user authentication
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.
- 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,
ldapsearch -h "10.1.0.1" -x -a never -s base supportedSASLMechanisms namingContexts supportedLDAPVersion
will display the names of the SASL mechanisms, the naming contexts, and the versions of the LDAP protocol that are supported by the server named 10.1.0.1.