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 with 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.

Note 

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.

Cross-Reference 

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.

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 1.3.6.1.4.1. Companies represented under that OID include IBM (1.3.6.1.4.1.2), Cisco Systems (1.3.6.1.4.1.9), and Hewlett Packard (1.3.6.1.4.1.11).

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 (U.S. 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) at www.alvestrand.no/objectid/top.html . You can request your OID from the Internet Assigned Numbers Authority ( www.iana.org/cgi-bin/enterprise.pl ).

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.