LPI exam 301 prep, Topic 301: Concepts, architecture, and design

Page 4 of 8  Document options PDF - Fits A4 and Letter 108 KB (26 pages) Get Adobe® Reader® My developerWorks needs you! Connect to your technical community Rate this tutorial Help us improve this content

Schemas

This section covers material for topic 301.3 for the Senior Level Linux Professional (LPIC-3) exam 301. The topic has a weight of 3.

In this section, learn about:

• LDAP schema concepts
• How to create and modify schemas
• Attribute and object class syntax

Up until now, the schema has been mentioned several times but not fully explained. The schema is a collection of object classes and their attributes. A schema file contains one or more object classes and attributes in a text format the LDAP server can understand. You import the schema file into your LDAP server's configuration, and then use the object classes and attributes in your objects. If the available schemas don't fit your needs, you can create your own or extend an existing one.

LDAP schema concepts

Technically, a schema is a packaging mechanism for object classes and attributes. However, the grouping of object classes is not random. Schemas are generally organized along an application, such as a core, X.500 compatibility, UNIX network services, sendmail, and so on. If you have a need to integrate an application with LDAP, you generally have to add a schema to your LDAP server.

A more in-depth look at OpenLDAP configuration will be in a later tutorial in this series, but the way to add a schema is with include /path/to/file.schema. After restarting the server, the new schema will be available.

When the schema is loaded, you then apply the new object classes to the relevant objects. This can be done through an LDIF file or through the LDAP application program interface (API). Applying the object classes gives you more attributes to use.

Creating and modifying schemas

Schemas have a fairly simple format. Listing 6 shows the schema for the inetOrgPerson object class along with some of its attributes.

                    
attributetype ( 2.16.840.1.113730.3.1.241
        NAME 'displayName'
        DESC 'RFC2798: preferred name to be used when displaying entries'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE )

attributetype ( 0.9.2342.19200300.100.1.60
        NAME 'jpegPhoto'
        DESC 'RFC2798: a JPEG image'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )

objectclass     ( 2.16.840.1.113730.3.2.2
    NAME 'inetOrgPerson'
        DESC 'RFC2798: Internet Organizational Person'
    SUP organizationalPerson 
    STRUCTURAL
        MAY ( 
                audio $ businessCategory $ carLicense $ departmentNumber $
                displayName $ employeeNumber $ employeeType $ givenName $
                homePhone $ homePostalAddress $ initials $ jpegPhoto $
                labeledURI $ mail $ manager $ mobile $ o $ pager $
                photo $ roomNumber $ secretary $ uid $ userCertificate $
                x500uniqueIdentifier $ preferredLanguage $
                userSMIMECertificate $ userPKCS12 )
        ) 

Line spacing is not important in schema files -- it is mostly there for human readability. The first definition is an attributetype, which means an attribute. The parentheses enclose the definition of the attribute. First comes a series of numbers, separated by periods, called the object ID, or OID, which is a globally unique number. The OID is also hierarchical, such that if you're assigned the 1.1 tree, you can create anything like 1.1.1 or 1.1.2.3.4.5.6 without having to register it.

Registering OIDs You can't just pick any series of numbers for your own OID because you don't know if the value you choose is, or will be, in use elsewhere. OIDs must be unique. Some servers let you specify textual OIDs (mycompany.1.2) which would be unique, just not necessarily compatible. Anything under the 1.1 namespace can be used locally but is not guaranteed to be unique. The best solution is to register your own OID. There are many ways to do this, depending on if you are a country, a telephone carrier, or fall under other categories. Luckily, the Internet Assigned Numbers Authority (IANA) will freely give you your own branch under .1.3.6.4.1 if you ask.

Following the OID is a series of keywords, each of which may have a value after it. First the NAME of the attribute defines the name that humans will use, such as in the LDIF file or when retrieving the information through the LDAP API. Sometimes you might see the name in the form of NAME ( 'foo' 'bar' ), which means that either foo or bar are acceptable. The server, however, considers the first to be the primary name of the attribute.

DESC provides a description of the attribute. This helps you understand the attribute if you're browsing the schema file. EQUALITY, SUBSTR, and ORDERING (not shown) require a matching rule. This defines how strings are compared, searched, and sorted, respectively. caseIgnoreMatch is a case-insensitive match, and caseIgnoreSubstringsMatch is also case insensitive. See the Resources section for Web sites that define all the standard matching rules. Like most things in LDAP, a server can define its own matching methods for its own attributes, so there are no comprehensive lists of matching rules.

The SYNTAX of the attribute defines the format of the data by referencing an OID. RFC 2252 lists the standard syntaxes and their OIDs. If the OID is immediately followed by a number in curly braces ({}), this represents the maximum length of the data. 1.3.6.1.4.1.1466.115.121.1.15 represents a DirectoryString that is a UTF-8 string.

Finally, the SINGLE-VALUE keyword has no arguments and specifies that only one instance of displayName is allowed.

The jpegPhoto attribute has a very short definition: just the OID, the name and description, and a syntax meaning a JPEG object, which is an encoded string of the binary data. It is not practical to search or sort a picture, and multiple photos can exist in a single record.

Defining an object class follows a similar method. The objectclass keyword starts the definition, followed by parentheses, the OID of the object class, and then the definitions. NAME and DESC are the same as before. SUP defines a superior object class, which is another way of saying that the object class being defined inherits from the object class specified by the SUP keyword. Thus, an inetOrgPerson carries the attributes of an organizationalPerson.

The STRUCTURAL keyword defines this as a structural object class, which can be considered the primary type of the object. Other options are AUXILIARY, which adds attributes to an existing object, and ABSTRACT, which is the same as structural but cannot be used directly. Abstract object classes must be inherited by another object class, which can then be used. The top object class is abstract. It is inherited by most other structural object classes, including person, which is the parent of organizationalPerson, which, in turn, is inherited by inetOrgPerson.

Two keywords, MAY and MUST, define the attributes that are allowed and mandatory, respectively, for records using that particular object class. For mandatory items, you may not save a record without all the items being defined. Each attribute is separated by a dollar sign ($), even if the line continues on the next line.

It is not a good idea to modify structural object classes, or even existing, well-known, auxiliary object classes. Because these are well known, you may cause incompatibility issues in the future if your server is different. Usually the best solution is to define your own auxiliary object class, create a local schema, and apply it to your records. For instance, if you are a university and want to store student attributes, you might consider creating a student object class that is inherited from either organizationalPerson or inetOrgPerson and adding your own attributes. You could then create auxiliary object classes to add more attributes such as class schedules.

Understanding which schemas to use

After learning about how schemas are created, it is tempting to start fresh -- to create your own schema based on your environment. This would certainly take care of your present needs, but it could quite possibly make things more difficult in the long run as you add more functionality to your LDAP tree and integrate other systems. The best approach is to stick with standard object classes and attributes when you can and extend when you must.

OpenLDAP usually stores its schema files in /etc/openldap/schema, in files with a .schema extension. Table 3 lists the default schemas along with their purposes.

In addition, RFC 4519 explains common attributes. After finding the attributes you want, you can then look through the schema files to determine which files need to be included in your LDAP configuration and which object classes you must use for your records.

	Page 4 of 8