Skip to main content

If you don't have an IBM ID and password, register here.

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. This profile includes the first name, last name, and display name you identified when you registered with developerWorks. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

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

Senior Level Linux Professional (LPIC-3)

Sean A. Walberg (sean@ertw.com), Senior Network Engineer
Author photo
Sean Walberg has been working with Linux and UNIX systems since 1994 in academic, corporate, and Internet Service Provider environments. He has written extensively about systems administration over the past several years. You can contact him at sean@ertw.com.

Summary:  In this tutorial, Sean Walberg helps you prepare to take the Linux Professional Institute® Senior Level Linux Professional (LPIC-3) exam. In this first in a series of six tutorials, Sean introduces you to Lightweight Directory Access Protocol (LDAP) concepts, architecture, and design. By the end of this tutorial, you will know about LDAP concepts and architecture, directory design, and schemas.

Date:  23 Oct 2007
Level:  Intermediate PDF:  A4 and Letter (113 KB | 26 pages)Get Adobe® Reader®

Comments:  

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.


Listing 6. Part of the inetOrgPerson definition
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.


Table 3. Schemas that ship with OpenLDAP
File namePurpose
corba.schemaDefines some object classes and attributes for handling Common Object Request Broker Architecture (CORBA) object references across multiple machines.
core.schemaDefines many common attributes and object classes. This schema is where you will find the organizationalUnit, top, dcObject, and organizationalRole. core.schema is the first place you should look if you need to find something.
cosine.schemaAttributes and object classes from the X.500 specifications. While there are some useful things in here, there are often better alternatives in others such as core and inetorgperson.
dyngroup.schemaAn experimental set of objects used with Netscape Enterprise Server.
inetorgperson.schemaDefines the inetOrgPerson object (which extends objects from core.schema).
java.schemaLike corba.schema, this schema defines a series of object classes and attributes to handle the lookup of Java™ classes within an LDAP tree.
misc.schemaImplements some objects to handle mail lookups within the tree. It is best to consult your e-mail server's documentation to see which schema it uses.
nis.schemaThis is the schema you use if you move authentication to LDAP. nis.schema defines posixAccount, which provides attributes for storing authentication data within the user's object. It also has the various map types to handle groups, networks, services, and other files that go into network-based authentication mechanisms such as the Network Information System (NIS).
openldap.schemaThis is more for example purposes and shows some basic objects.
ppolicy.schemaA set of objects to implement password policies in LDAP, such as aging. Note that some of these are handled by the traditional UNIX shadow mechanisms and are already handled in nis.schema.

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.

4 of 7 | Previous | Next

Comments



Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Linux, Open source
ArticleID=431118
TutorialTitle=LPI exam 301 prep, Topic 301: Concepts, architecture, and design
publish-date=10232007
author1-email=sean@ertw.com
author1-email-cc=

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).

My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).