Managing Object Classes

Object classes are named sets of attribute definitions that are used to control the types of data stored in entries. You can add new object classes to the schema by using the ldapmodify command. The object class syntax requires that you provide at least a valid OID to define your new element. In typical applications, you will also include the following optional identifiers for the object class type. For more information about the object class definition, see Understanding the Directory Server Schema in Sun OpenDS Standard Edition 2.0 Architectural Reference.

Table 9

Object Class Elements

Object Class Elements	Description
`OID`	Required. Specifies the OID that uniquely identifies the object class in the directory server. The LDAP v3 specification requires the OID to be a numeric number, but Sun OpenDS SE supports the use of non-numeric OIDs for easy identification because the schema is used internally within the organization. For example, the format is objectClassName`\-oid`, such as `person-oid`.
`NAME`	Optional. Specifies the set of human-readable names that are used to refer to the object class. If there is a single name, enclose it in single quotes, for example, `'blogURL'`. If there are multiple names, enclose each name in single quotes separated by spaces, and then enclose the entire set of names within parentheses, for example, `( 'blog' 'blogURL' )`. Ensure that there is a space between the left parenthesis and the name, and a space before the closing parenthesis.
`DESC`	Optional. Specifies a human-readable description of the object class. If specified, the description should be enclosed in single quotation marks.
`SUP`	Optional. Specifies the superior object class when you want it to inherit elements from another object class. The directory server allows only one superior object class, although the LDAP v3 specification allows for multiple superior object classes.
`OBSOLETE`	Optional. Indicates whether the object class is active or not. If an object class is marked as `OBSOLETE`, then it should not be referenced by any new elements created in the directory server.
`SUP` oids	Optional. The `SUP` keyword should be followed by the OID of the superior class.
`KIND`	Optional. Indicates the type of object class that is being defined. Allowed values are `ABSTRACT`, `AUXILIARY` and `STRUCTURAL`.
`MUST` oids	Optional. Specifies the set of attribute types that are required to be present (that is, have at least one value) in entries with that object class. If there is only a single required attribute, then the `MUST` keyword should be followed by the name or the OID of that attribute type. If there are multiple required attribute types, then separate them with dollar signs ($) and enclose the entire set of attribute types in parentheses. For example, `MUST ( sn $ cn )`.
`MAY` oids	Optional. Specifies the set of attribute types that are allowed but not required to be present in entries with that object class. If there is only a single required attribute, then the `MAY` keyword should be followed by the name or the OID of that attribute type. If multiple required attribute types are specified, then separate them by dollar signs (`$`) and enclose the entire set of attribute types in parentheses. For example, `MAY ( userPassword $ telephoneNumber $ seeAlso $ description )`.
extensions	Optional. Specifies the extensions available to the object class. The directory server provides the following extensions: `X-ORIGIN`. Provides information on where the object class is defined. The element is a non-standard tool that the user can use to conveniently locate the schema element. Examples could include the RFC number `RFC4517`, `OpenDS Directory Server` and others. `X-SCHEMA-FILE`. Indicates which schema file contains the object class definition. Used for internal purposes only and is not exposed to clients. You can use this extension to specify where the directory server is to store your custom schema definitions.

For example, you can specify the addition of a new object class, blogger, in an LDIF file to be added to the schema.

$ cat blogger.ldif
dn: cn=schema
changetype: modify
add: objectClasses
objectClasses: ( 1.3.6.1.4.1.26037.1.999.2000
NAME ( 'blogger' )
DESC 'Someone who has a blog'
SUP inetOrgPerson
STRUCTURAL
MAY blog
X-ORIGIN 'OpenDS Directory Server' )

Note - Pay special attention to the spaces in your object class declaration. The LDAP specification requires that a space exist between the opening parenthesis and the OID, and the value of the X-ORIGIN element and the closing parenthesis. Further, the LDIF specification states that LDIF parsers should ignore exactly one space at the beginning of each line. Therefore, it is a good practice to add two spaces before the line that begins with an element keyword, such as, NAME, DESC, SUP, STRUCTURAL, MAY, and X-ORIGIN in the previous example.

To View Object Classes

The cn=schema entry has a multivalued attribute, objectClass, that contains definitions of each object class in the directory schema. You can view the schema definitions by using the ldapsearch command.

Manipulation of the cn=schema suffix is regarded as an administrative action and, as such, it is recommended that you use the administration connector when accessing this suffix. See Managing Administration Traffic to the Server for more information.

Use the ldapsearch command.

$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \
  -b cn=schema -s base "(objectclass=*)" objectClasses
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 ( searchGu
ide $ description ) X-ORIGIN 'RFC 4519' )
objectClasses: ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL MAY ( street $ seeAl
so $ searchGuide $ st $ l $ description ) X-ORIGIN 'RFC 4519' )
objectClasses: ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o MAY ( use
rPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registered
Address $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ telete
xTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTele
phoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDel
iveryOfficeName $ st $ l $ description ) X-ORIGIN 'RFC 4519' )
...(more output)...

(Optional) Use the --dontWrap option and the grep command to search for a specific object class.

$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X \
  --useSSL -b cn=schema -s base --dontWrap "(objectclass=*)" \
  objectClasses | grep "inetOrgPerson"
objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' 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 ) X-ORIGIN 'RFC 2798' )

To Create an Object Class

The cn=schema entry has a multivalued attribute, objectClasses, that contains definitions of each object class in the directory schema. You add custom schema by using the ldapmodify command. This example adds an object class blogger based on the attribute created in the previous example.

Using a text editor, create an LDIF file with your schema extensions.

dn: cn=schema
changetype: modify
add: objectClasses
objectClasses: ( 1.3.6.1.4.1.26037.1.999.2000
NAME ( 'blogger' )
DESC 'Someone who has a blog'
SUP inetOrgPerson
STRUCTURAL
MAY blog
X-ORIGIN 'OpenDS Directory Server' )

Use the ldapmodify command to add the file.

$ ldapmodify -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \
  -a -f blogger.ldif
Processing MODIFY request for cn=schema
MODIFY operation successful for DN cn=schema

Verify the addition by displaying it with ldapsearch.

$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \
  -b cn=schema -s base --dontWrap "(objectclass=*)" objectClasses | grep 'blogger'

Note - The directory server automatically adds new object class definitions to the 99user.ldif file.

To Delete an Object Class

The cn=schema entry has a multivalued attribute, objectClasses, that contains definitions for each object class in the directory schema. You can delete these definitions by using the ldapmodify command.

Caution - Be careful when deleting object classes, because doing so can harm your directory. Do not delete an object class unless absolutely necessary.

Create the delete request in LDIF format.

dn: cn=schema
changetype: modify
delete: objectClasses
objectClasses: ( 1.3.6.1.4.1.26037.1.999.2000
NAME ( 'blogger' )
DESC 'Someone who has a blog'
SUP inetOrgPerson
STRUCTURAL
MAY blog
X-ORIGIN 'OpenDS Directory Server' )

Remove the object class by using ldapmodify to apply the LDIF file.

$ ldapmodify -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \
  --fileName "remove_objectclass_schema.ldif"

Exit Print View
Sun OpenDS Standard Edition 2.0 Administration Guide