Understanding LDAP

LDAP lets people create directories of information that can be shared among client applications over a network. It is particularly geared toward applications that are used to look up information that is fairly stable over and over again (in other words, information that’s being looked at more than it’s being changed). That’s why LDAP is popular for uses like storing information about people, addresses, and other kinds of data that may require high access with relatively few changes.

Because of LDAP’s extraordinarily flexible design, as an LDAP developer or administrator you have a lot of control over:

  • How the information in the directories is organized.

  • How and by whom information can be accessed.

  • The scale, local to global, by which information is distributed. (Information can be replicated to other servers at any scale you choose and synced up automatically.)

Despite its flexibility, however, you don’t have to begin designing each directory you create from scratch. LDAP has many predefined structures of information you can rely on to build your LDAP directories. Those data structures are defined in several different standards documents referred to as RFCs (Request for Comments). (There are RFCs for almost every aspect of the Internet protocols and related application services.) Important RFCs for LDAP definitions include:

  • RFC 2252 — Defines the framework for LDAP.

  • RFC 2256 — Defines the X.500 user schema for LDAPv3.

  • RFCs 1274, 2079, 2247, 2307, 2587, 2589 — Define specifications for including user attributes, Uniform Resource Identifiers, domain names, NIS data, public key infrastructure (PKI), and dynamic directory services in LDAP directories.

The documents on which these RFCs are based include the CCITT X.500 standard and the related ISO IS95494 directory services standards. In particular, X.521 and X.520 define some of the most basic object classes and attribute types.

Keep in mind, however, that these standards provide guidelines. When you put together your own LDAP directory, your OpenLDAP server will have to deal directly with the schemas that implement those standards on the OpenLDAP server.


Microsoft’s Active Directory (AD) is often touted as an “LDAP-based” entity, giving some users high hopes of integrating OpenLDAP and AD. While it is possible to exchange information between AD and OpenLDAP, setting this up requires a lot of patience and skill. Unless you must interoperate with AD, a better path for supporting Windows clients is though the use of OpenLDAP and Samba. Check out the Samba-OpenLDAP Howto at www.idealx.org/prj/samba/smbldap-howto.en.html for more information about this kind of configuration.

Defining information in schemas

The elements that make up LDAP directories are organized into what are called schemas. When you create or use an LDAP directory, the types of information in the schemas you will be working include the following types of items:

  • Object classes — An object provides a name under which you would group together a bunch of attributes. So, with an address book, you might include the inetOrgPerson object class, under which you could store attributes associated with a person.

  • Attributes — As its name implies, an attribute holds a piece of information associated with an object class. For example, the inetOrgPerson object class could have attributes such as telephone number, e-mail address, and so on.


    If you are familiar with databases, the LDAP directory terminology might seem a bit different to you. You can think of attributes as fields and object classes as tables.

Examples of object classes include country, locality, organization, and many others. For each object class, there may be required attributes and a list of optional attributes. You can see the definitions for many standard object classes and attributes in the schema files that come with any LDAP server.

In OpenLDAP, several default schemas are included in the /etc/openldap/schema directory. The example e-mail address book I show you how to create in this chapter relies entirely on schemas provided with OpenLDAP. You don’t have to create any schema files yourself to do the examples in this chapter. If you need more objects and attributes than are provided by default, you can get schemas from other places or create your own.


For information on schemas included with OpenLDAP, refer to the OpenLDAP Schema Specification page (www.openldap.org/doc/admin22/schema.html). That page also describes how you can go about extending those schemas. Check those schemas, as well as the schema definitions in RFCs described earlier, before you create your own object classes or attributes.

As you begin dealing with your LDAP directory, you will access the object classes and attributes as names. To the LDAP server, however, each of those items is represented by a unique string of numbers and dots. Each string is referred to as an Object Identifier (OID). If you are not creating your own object classes or attributes, you don’t need to deal with OIDs. To understand what OIDs are and when you might want to get your own OID assignment, refer to the “Understanding OIDs” sidebar.

image from book
Understanding OIDs

If you look into a schema file (/etc/openldap/schema/*), you will see that every LDAP object class and attribute is mapped into a dot-separated number. That number is a hierarchical string that is referred to as an Object Identifier (OID).

Because LDAP is intended to be a global directory (where all entries can be unique), if you want to create a directory that can be accessed globally, you should try to use items that have existing OIDs assigned whenever possible. However, if you find that you need to create object classes or attributes that are not already defined, you can consider getting an Object Identifier (OID) for your organization. The alternative is to make up your own attribute name and OID, in which case you should either never expect that data to be globally accessible or try not to conflict with existing OIDs.

Like a domain name, an OID assignment enables you to create branches under that OID as you need them. If your organization has its own OID assigned, you are guaranteed of having every item you create under that number be globally unique (as long as you maintain those assignments properly yourself).

To give you some examples of OIDs, private enterprise numbers used primarily for companies using SNMP are stored under the OID number Companies represented under that OID include IBM (, Cisco Systems (, and Hewlett Packard (

If you break down each number into its component parts, you see that they start with the top-level OID 1 (for ISO-assigned OIDs), then 3 (ISO identified Organizations), then 6 (US Department of Defense), then 1 (Internet), then 4 (private), then 1 (enterprise). After that is the number representing each company.

You can see the complete list of enterprise numbers on the Private Enterprise Numbers list: www.iana.org/assignments/enterprise-numbers. Search for OID assignments (from the top node) from: www.alvestrand.no/objectid/top.html. You can request your OID from the Internet Assigned Numbers Authority (www.iana.org/cgi-bin/enterprise.pl).

image from book

Structuring your LDAP directories

While standards documents are used to keep the object classes, attributes, and other elements of LDAP directories unique, you are free to put together those elements into your own LDAP directories however you want. The structure you use to create your directories is the LDAP Data Interchange Format (LDIF).

Every piece of information you store in your LDAP directory must fall under a base distinguished name (or base dn). Because many organizations these days can be represented by a unique Internet domain name, the domain name is a popular way to identify your LDAP base dn. In fact, for the examples in this chapter, the base distinguished name I use is linuxtoys.net. If you are creating an LDAP directory for an organization that can be represented by a domain name you can replace linuxtoys.net with your domain name.

If you are creating an LDAP directory structure for a larger organization (in other words, more than just a single address book as I am doing here), you need to think hard about how you want the directory structured. You may want to add country codes (us, de, it, and so on) under your base distinguished name for a multinational company.

Red Hat Fedora Linux 3 Bible
Red Hat Fedora Linux 3 Bible
ISBN: 0764578723
EAN: 2147483647
Year: 2005
Pages: 286

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net