Figure 2-5. organizationalUnit object class
Here's how to understand an objectClass definition:
An objectClass possesses an OID, just like attribute types, encoding syntaxes, and matching rules.
The keyword MUST denotes a set of attributes that must be present in any instance of this object. In this case, "present" means "possesses at least one value." Note
To represent a zero-length attribute value in LDIF syntax, the attribute name must be followed by a colon and zero or more spaces, and then a CR or CF/LF. For example, the following LDIF line stores a zero-length description:
description:
The keyword MAY defines a set of attributes whose presence is optional in an instance of the object.
The keyword SUP specifies the parent object from which this object was derived. A derived object possesses all the attribute type requirements of its parent. Attributes can be derived from other attributes as well, inheriting the syntax of its parent as well as matching rules, although the latter can be locally overridden by the new attribute. LDAP objects do not support multiple inheritance; they have a single parent object, like Java objects.
It is possible for two object classes to have common attribute members. Because the attribute type namespace is flat for an entire schema, the telephoneNumber attribute belonging to an organizationalUnit is the same attribute type as the telephoneNumber belonging to some other object class, such as a person (which is covered later in this chapter).
* * *
* * *
* * *
Object Class Types
Three types of object class definitions are used in LDAP directory servers:
Structural object classes
Represent a real-world object, such as a person or an organizationalUnit. Each entry within an LDAP directory must have exactly one structural object class listed in the objectClass attribute. According to the LDAP data model, once an entry's structural object class has been instantiated, it cannot be changed without deleting and re-adding the entire entry.
Auxiliary object classes
Add certain characteristics to a structural class. These classes cannot be used on their own, but only to supplement an existing structural object. There is a special auxiliary object class referred to in RFC 2252 named extensibleObject, which an LDAP server may support. This object class implicitly includes all attributes defined in the server's schema as optional members.
Abstract object classes
Act the same as their counterparts in object-oriented programming. These classes cannot be used directly, but only as ancestors of derived classes. The most common abstract class relating to LDAP (and X.500) that you will use is the top object class, which is the parent or ancestor of all LDAP object classes.
Note that the type of an object cannot be changed by a derived class.
* * *
What Is the dc Attribute?
Returning to our discussion of the topmost entry in Figure 2-1, we can now explain the meaning of the domain object class and the dc attribute. Here is the original LDIF listing for the entry:
# LDIF listing for the entry dn: dc=plainjoe,dc=org
dn: dc=plainjoe,dc=org
objectclass: domain
dc: plainjoe
The original recommendation for dividing the X.500 namespace was based on geographic and national regions. You frequently see this convention in LDAP directories as well, given the heritage that LDAP shares with X.500. For example, under X.500, the distinguished name for a directory server in the plainjoe.org domain might be:
dn: o=plainjoe,l=AL,c=US
Here, the o attribute is the organizationName, the l attribute is the locality of the organization, and the c attribute represents the country in which the organization exists. However, there is no central means of registering such names, and therefore no general way to refer to the naming context of a directory server. RFC 2247 introduced a system by which LDAP directory naming contexts can be piggybacked on top of an organization's existing DNS infrastructure. Because DNS domain names are guaranteed to be unique across the Internet and can be located easily, mapping an organization's domain name to an LDAP DN provides a simple way of determining the base suffix served by a directory and ensures that the naming context will be globally unique.
* * *
Note
A directory's naming context is the DN of its topmost entry. The naming context of the directory in our examples is dc=plainjoe,dc=org. This context is used by the LDAP server to determine whether it will be able to service a client request. For example, our directory server will return an error (or possibly a referral) to a client who attempts to look up the information in an entry named cn=gerald carter,ou=people,dc=taco,dc=org because the entry would be outside our naming context.
However, the server would search the directory (and return no information) if the client attempts to look up cn=gerald carter,ou=people,dc=taco,dc=plainjoe,dc=org. In this case, the directory's naming context does match the rightmost substring of the requested entry's DN. The server just does not have any information on the entry.
* * *
To support a mapping between a DNS domain name and an LDAP directory namespace, RFC 2247 defines two objects, shown in Figures 2-6 and 2-7, for storing domain components. The dcObject is an auxiliary class to augment an existing entry containing organizational information (e.g., an organizationalUnit). The domain object class acts as a standalone container for both the organizational information and the domain name component (i.e., the dc attribute). The organizationalUnit and domain objects have many common attributes.
Figure 2-6. domain object class
Figure 2-7. dcObject object class
Generating an LDAP DN to represent a DNS domain name is a simple process. An empty DN is used as a starting point. An RDN of dc= domain component is appended to the DN for each portion of the domain name. For example, the domain name plainjoe.org maps to our naming context of dc=plainjoe,dc=org.
Where Is dc=org?
As we saw in the previous section, dc=plainjoe,dc=org is the directory's naming context. If the directory's root entry was dc=org, with a child entry of dc=plainjoe,dc=org, then the naming context would have been dc=org. Our server would then unnecessarily respond to queries for any entry whose DN ended with dc=org, even though it only has knowledge of entries underneath dc=plainjoe,dc=org.
In this respect, designing an LDAP namespace is similar to designing a DNS hierarchy. Domain name servers for plainjoe.org have no need to service requests for the .org domain. These requests should be referred to the server that actually contains information about the requested hosts.
Schema References
One of the most frequent questions asked by newly designated LDAP administrators is, "What do all of these abbreviations mean?" Of course, the question refers to things such as cn, c, and sn. There is no single source of information describing all possible LDAPv3 attribute types and object classes, but there are a handful of online sites that can be consulted to cover the most common schema items:
RFC 3377 and related LDAPv3 standards (http://www.rfc-editor.org/)
The documents outlined in RFC 3377 provide a list of references for researching related LDAPv3 and X.500 topics. RFC 2256 in particular describes a set of X.500 schema items used with LDAPv3 directory servers.
LDAP Schema Viewer (http://ldap.akbkhome.com/)
This site, maintained by Alan Knowles, provides a nice means of browsing descriptions and dependencies among common LDAP attributes, object classes, and OIDs.
Object Identifiers Registry (http://www.alvestrand.no/objectid/)
This site can be helpful in tracking down the owner of specific OID arcs.
Sun Microsystems Product Documentation (http://docs.sun.com)
The SunOne Directory Server, formerly owned by Netscape Communications, includes a large set of reference documentation on various LDAP schema items. Even if you are not using the SunOne DS product, the schema
reference can be helpful in understanding the meaning of various LDAP acronyms. Search the site for "LDAP schema reference" to locate the most recent versions of the product documentation.
Authentication
Why is authentication needed in an LDAP directory? Remember that LDAP is a connection-oriented, message-based protocol. The authentication process is used to establish the client's privileges for each session. All searches, queries, etc. are controlled by the authorization level of the authenticated user.
Figure 2-8 describes the person object class and gives you an idea of what other attributes are available for the cn=gerald carter entry in Figure 2-1. In particular, you will need to define a userPassword attribute value to further explore LDAP authentication.
Figure 2-8. person objectClass
The LDIF representation for the expanded version cn=gerald carter is:
dn: cn=gerald carter,ou=people,dc=plainjoe,dc=org
objectClass: person
cn: gerald carter
sn: carter
telephoneNumber: 555-1234
userPassword: {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ= =
We have added an attribute named userPassword. This attribute stores a representation of the credentials necessary to authenticate a user. The prefix (in this case, {MD5}) describes how the credentials are encoded. The value in this case is simply the Base64 encoding of the MD5 hash of the word "secret."
RFC 2307 defines prefixes for several encryption algorithms. These are vendor-dependent, and you should consult your server's documentation to determine which are supported. Generating userPassword values will be covered in more detail in the context of various programming languages and APIs in later chapters. Some common encoding types are:
{CRYPT}
The password hash should be generated using the local system's crypt( ) function, which is normally included in the standard C library. The {CRYPT} prefix will be seen quite a bit in Chapter 6 when we discuss using LDAP as a replacement for NIS.
{MD5}
The password hash is the Base64 encoding of the MD5 digest of the user's password.
{SHA} (Secure Hash Algorithm)
The password hash is the Base64 encoding of the 160-bit SHA-1 hash (RFC 3174) of the user's password.
{SSHA} (Salted Secure Hash Algorithm)
This password-hashing algorithm developed by Netscape is a salted version of the previous SHA-1 mechanism. {SSHA} is the recommended scheme for securely storing password information in an LDAP directory.
The act of being authenticated by an LDAP directory is called binding. Most users are accustomed to providing a username and password pair when logging onto a system. When authenticating an LDAP client, the username is specified as a DN—in our example, cn=gerald carter,ou=people,dc=plainjoe,dc=org. The credentials used to authenticate this entry are given by the value of the userPassword attribute.
The LDAPv3 specifications define several mechanisms for authenticating clients:
Anonymous Authentication
Simple Authentication
Simple Authentication over SSL/TLS
Simple Authentication and Security Layer (SASL)
Anonymous Authentication
Anonymous Authentication is the process of binding to the directory using an empty DN and password. This form of authentication is very common; it's frequently used by client applications (for example, email clients searching an address book).
Simple Authentication
For Simple Authentication, the login name in the form of a DN is sent with a password in clear text to the LDAP server. The server then attempts to match this password with the userPassword value, or with some other predefined attribute that is contained in the entry for the specified DN. If the password is stored in a hashed format, the server must generate the hash of the transmitted password and compare it to the stored version. However, the original password has been transmitted over the network in the clear. If both passwords (or password hashes) match, the client is successfully authenticated. While this authentication method is supported by virtually all existing LDAP servers (including LDAPv2 servers), its major drawback is its dependency on the client transmitting clear-text values across the network.
Simple Authentication Over SSL/TLS
If sending usernames and passwords over the network is not particularly tasty to you, perhaps wrapping the information in an encrypted transport layer will make it more palatable. LDAP can negotiate an encrypted transport layer prior to performing any bind operations. Thus, all user information is kept secure (as well as anything else transmitted during the session).
There are two means of using SSL/TLS with LDAPv3:
LDAP over SSL (LDAPS - tcp/636) is well supported by many LDAP servers, both commercial and open source. Although frequently used, it has been deprecated in favor of the StartTLS LDAP extended operation.
RFC 2830 introduced an LDAPv3 extended operation for negotiating TLS over the standard tcp/389 port. This operation, which is known as StartTLS, allows a server to support both encrypted and nonencrypted sessions on the same port, depending on the clients' requests.
With the exception of the transport layer security negotiation, the binding process is the same as for Simple Authentication.
* * *
Tip
Designers of LDAPv3 defined two pieces of functionality, Extended Operations and Controls, to allow for additions to the original protocol without requiring a new version to be standardized. LDAP Controls apply only to individual requests and responses, similar to the way an adjective extends a noun. Depending on the client's needs, if a server does not support a specified Control, the request may fail, or the Control may simply be ignored and the request will continue normally. An Extended Operation is the equivalent of defining a new word that must be understood by both the client and server.
* * *
Simple Authentication and Security Layer (SASL)
SASL is an extensible security scheme defined in RFC 2222 that can be used to add additional authentication mechanisms to connection-oriented protocols such as IMAP and LDAP. In essence, SASL supports a pluggable authentication scheme by allowing a client and server to negotiate the authentication mechanism prior to the transmission of any user credentials.
In addition to negotiating an authentication mechanism, the communicating hosts may also negotiate a security layer (such as SSL/TLS) that will be used to encrypt all data during the session. The negotiation of transport layer security within SASL is not related either to the StartTLS Extended Operation or to LDAPS.
RFC 2222 defines the several authentication schemes for SASL, including:
Kerberos v4 (KERBEROS_V4)
The Generic Security Service Application Program Interface, Version 2 (GSSAPI), which is defined in RFC 2078
The S/Key mechanism (SKEY), which is a one-time password scheme based on the MD5 message digest algorithm
The External (EXTERNAL) mechanism, which allows an application to make use of a user's credentials provided by a lower protocol layer, such as authentication provided by SSL/TLS
In addition to these, RFC 2831 has added an SASL/DIGEST-MD5 mechanism. This mechanism is compatible with HTTP/1.1 Digest Access Authentication.
During the binding process, the client asks the server to authenticate its request using a particular SASL plug-in. The client and server then perform any extra steps necessary to validate the user's credentials. Once a success or failure condition has been reached, the server returns a response to the client's bind request as usual, and LDAP communication continues normally.
Distributed Directories
At this point we have completed examining the simple directory of Figure 2-1. Since we have covered the basics, let's expand Figure 2-1 to create a distributed directory. In a distributed directory, different hosts possess different portions of the directory tree.
Figure 2-9 illustrates how the directory would look if the people ou were housed on a separate host. There are many reasons for distribu
ting the directory tree across multiple hosts. These can include, but are not limited to:
Performance
Perhaps one section of the directory tree is heavily used. Placing this branch on a host by itself lets clients access the remaining subtrees more quickly.
Geographic location
Are all the clients that access a particular branch of the directory in one location? If so, it would make more sense to place this section of the directory closer to the client hosts that require it. In this way, trips across a possibly slow WAN link can be avoided.
Administrative boundaries
It is sometimes easier to delegate administrative control of a directory branch by placing the branch on a server controlled by the group responsible for the information in that branch. In this way, the server operators can have full access for duties such as replication and backups without interfering with a larger, more public server.
Figure 2-9. Building a distributed directory
To divide the directory tree between the two servers in Figure 2-9, you must configure two links between the main directory server and the server that holds people ou. To do so, create the superior and subordinate knowledge reference links as shown.
A subordinate knowledge link, often called simply a reference , logically connects a node within a directory tree to the naming context of another server. Most often, the naming context of the second server is a continuation of the directory. In this example, the people ou in the main directory tree has no children because all queries of entries in the ou=people,dc=plainjoe,dc=org tree should be served by the second server. The entry ou=people,dc=plainjoe,dc=org on the main directory server is now a placeholder that contains the referral to the actual directory server for this entry. Figure 2-10 shows the definition for the the referral object class defined in RFC 3296.
LDAP System Administration Page 4
