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 |
Basic object class properties
The Basic Properties table displays the standard elements in schema definition.
Attributes | Description | ||
---|---|---|---|
|
The globally unique name. |
||
|
An optional definition that describes the object class and its contents. The analogous LDIF equivalent is |
||
|
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. |
||
|
The schema definition’s hierarchical parent or superior object class, if any. An object class can have one parent. |
||
|
The type of schema definition, which can be abstract, structural, or auxiliary. The analogous LDIF equivalent is |
||
|
Specifies required attributes with the object class. The analogous LDIF equivalent is
|
||
|
Specifies optional attributes that can be used with the object class. The analogous LDIF equivalent is
|
The Additional Properties table provides auxiliary information associated with the object class.
Attributes | Description |
---|---|
|
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 |
|
The origin of the schema definition. Typically, it could refer to a specific RFC or company. |
|
Specifies if the schema definition is obsolete or not. |
|
Specifies the schema file that stores the definition in the |
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 attributeobjectClasses
, 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)...