PingDirectory

Managing object classes

Object classes are sets of related information objects that form entries in a directory information tree (DIT).

The PingDirectory server uses the schema to do the following:

  • Define the entries.

  • Specify the position of the entries in a DIT.

  • Control the operations of the server.

You can also extend the schema by adding your own schema definitions.

Object classes have the following general properties:

  • Object classes must have a globally unique name or identifier.

  • Object classes specify the required and allowed attributes in an entry.

  • Object classes can inherit the properties and the set of allowed attributes from its parent object classes, which might also be part of a hierarchical chain derived from the top abstract object class.

  • Object classes that are defined in the PingDirectory server can be searched using the objectClasses operational attribute.

    The PingDirectory server also has a special entry called the subschema subentry, which provides information about the available schema elements on the server.

Object classes types

Based on RFC 4512, object classes can be a combination of three different types:

Abstract object classes

Used as the base object class from which structural or auxiliary classes inherit its properties.

This inheritance is a one-way relationship because abstract object classes cannot be derived from structural or auxiliary classes. The most common abstract object class is top, which defines the highest level object class in a hierarchical chain of object classes.

Structural object classes

Define the basic attributes in an entry and define where an entry can be placed in a directory information tree (DIT).

All entries in a DIT belong to one structural object class. Structural object classes can inherit properties from other structural object classes and from abstract object classes to form a chain of inherited classes. For example, the inetOrgPerson structural object class inherits properties from the organizationalPerson structural class, which inherits from another object class, person.

Auxiliary object classes

Used together with structural object classes to define additional sets of attributes required in an entry.

The auxiliary object class cannot form an entry alone but must be present with a structural object class. Auxiliary object classes cannot derive from structural object classes or vice-versa. They can inherit properties from other auxiliary classes and from abstract classes.

Object class definition

You can specify new object classes with existing schema components that don’t require additional server code extensions for their implementation. To create new object classes, use the Schema Editor, which manages schema in the <server-root>/config/schema directory. For more information, see Extending the PingDirectory server schema.

RFC 4512, section 4.1.1, defines the following object class definition.

ObjectClassDescription = "(" wsp; Left parenthesis followed by a white space
numericoid                        ; Required numeric object identifier
[ sp "NAME" sp qdescrs ]          ; Short name descriptor as alias for the OID
[ sp "DESC" sp qdstring ]         ; Optional descriptive string
[ sp "OBSOLETE" ]                 ; Determines if the element is inactive
[ sp "SUP" sp oid ]               ; Specifies the direct superior object class
[ sp kind ]                       ; abstract, structural (default), auxiliary
[ sp "MUST" sp oids ]             ; Required attribute types
[ sp "MAY" sp oids ]              ; Allowed attribute type
extensions wsp ")"                ; Extensions followed by a white space and ")"

usage = "userApplications" /      ; Stores user data
  "directoryOperation" /          ; Stores internal server data
  "distributedOperation" /        ; Stores operational data that must be synchronized
                                  ;   across servers
  "dSAOperation"                  ; Stores operational data specific to a server and
                                  ;   should not be synchronized across servers

The following extensions are specific to PingDirectory server and aren’t defined in RFC 4512.

extensions = /
"X-ORIGIN" /             ; Specifies where the object class is defined
"X-SCHEMA-FILE" /        ; Specifies which schema file contains the definition
"X-READ-ONLY"            ; True or False. Specifies if the file that contains
                         ;   the schema element is marked as read-only
                         ;   in the server configuration.

Although RFC 4512 allows multiple superior object classes, PingDirectory server allows at most one superior object class, which is defined by the SUP element in the definition.

Basic object class properties

The Basic Properties table displays the standard elements in schema definition.

Attributes Description

Name

The globally unique name.

Description

An optional definition that describes the object class and its contents. The analogous LDIF equivalent is DESC.

OID

The object identifier assigned to the schema definition. You can obtain a specific OID for your company that allows you to define your own object classes and attributes from IANA or ANSI.

Parent

The schema definition’s hierarchical parent or superior object class, if any. An object class can have one parent.

Type

The type of schema definition, which can be abstract, structural, or auxiliary. The analogous LDIF equivalent is ABSTRACT, STRUCTURAL, or AUX.

Required Attributes

Specifies required attributes with the object class. The analogous LDIF equivalent is MUST.

The Schema Editor marks any inherited attributes from another object class. Double-click an attribute value to take you to the Properties View for that particular attribute.

Optional Attributes

Specifies optional attributes that can be used with the object class. The analogous LDIF equivalent is MAY.

The Schema Editor marks any inherited attributes from another object class. Double-click an attribute value to take you to the properties view for that particular attribute.

The Additional Properties table provides auxiliary information associated with the object class.

Attributes Description

Aliases

Specifies short-form alias names, if any. You could have any number of short-form names as long as they are all unique. The analogous LDIF equivalent appears as the secondary element with the NAME element although most object classes do not have aliases.

Origin

The origin of the schema definition. Typically, it could refer to a specific RFC or company.

Obsolete

Specifies if the schema definition is obsolete or not.

Stored in File

Specifies the schema file that stores the definition in the <server-root>/config/schema folder.

Viewing object classes

About this task

To view the object classes on your PingDirectory server, use any of the following:

  • The Administrative Console Schema Editor

  • LDAP with the ldapsearch tool

  • A third-party tool

The Schema Editor displays all of the object classes on the PingDirectory server instance. It shows the basic properties that are required elements and the extra properties that are allowed within the object class.

To view object classes over LDAP:

Steps

  • To view an operational attribute, run ldapsearch.

    Example:

    This example uses ldapsearch to view the multi-valued operational attribute objectClasses, which publishes the object class definitions on the PingDirectory server.

    The attribute is stored in the subschema subentry.

    		 
    $ bin/ldapsearch --baseDN cn=schema --searchScope base \
--dontWrap "(objectclass=*)" objectClasses

    Result:

    dn: cn=schema
objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass X-ORIGIN 'RFC 4512' )
objectClasses: ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName
  X-ORIGIN 'RFC 4512' )
objectClasses: ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
  MAY ( searchGuide $ description ) X-ORIGIN 'RFC 4519' )
...(more output)...