Schema Schema definitions describe the data, and especially the object classes and attribute types that can be stored in the directory. By default OpenDJ conforms strictly to LDAPv3 standards pertaining to schema definitions and attribute syntax checking, ensuring that data stored is valid and properly formed. Unless your data use only standard schema present in OpenDJ when you install, then you must add additional schema definitions to account the data your applications stored. Out of the box, OpenDJ comes with many standard schema definitions. In addition you can update and extend schema definitions while OpenDJ is online. As a result you can add new applications requiring additional data without stopping your directory service. This chapter demonstrates how to change and to extend OpenDJ schema. This chapter also identifies the standard schema definitions available when you install OpenDJ.

Directory schema, described in RFC 4512, define the kinds of information you find in the directory, and can define how the information are related. This chapter focuses primarily on two types of directory schema definitions. Attribute type definitions describe attributes of directory entries, such as givenName or mail. Here is an example of an attribute type definition. # Attribute type definition attributeTypes: ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' ) EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} X-ORIGIN 'RFC 4524' ) Attribute type definitions start with an object identifier (OID), and generally a short name or names that are easier to remember than the OID. The attribute type definition can specify how attribute values should be collated for sorting, and what syntax they use. The X-ORIGIN is an extension to identify where the definition originated. When you define your one schema, you likely want to provide an X-ORIGIN to help you to track versions of definitions, and where the definitions came from. Object class definitions identify the attribute types that an entry must have, and may have. Examples of object classes include person and organizationalUnit. Here is an example of an object class definition. # Object class definition objectClasses: ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) X-ORIGIN 'RFC 4519' ) Entries all have an attribute identifying their object classes, called objectClass. Object class definitions start with an object identifier (OID), and generally a short name that is easier to remember than the OID. The definition here says that the person object class inherits from the top object class, which is the top-level parent of all object classes. When you view the objectclass attribute values on an entry, you see the list of object classes that the entry takes. An entry can have one STRUCTURAL object class inheritance branch, such as top - person - organizationalPerson - inetOrgPerson. Yet entries can have multiple AUXILIARY object classes. The object class then defines the attribute types that must be included, and the attribute types that may be included on entries having the object class. OpenDJ exposes schema over protocol through the cn=schema entry. OpenDJ stores the schema definitions corresponding to the entry in LDIF under the config/schema/ directory. Many standard definitions and definitions pertaining to the server configuration are included at installation time.

Replication Schema definitions OpenDJ directory server is designed to permit updating the list of directory schema definitions while the server is running. As a result you can add support for new applications that require new attributes or new kinds of entries without interrupting the directory service. OpenDJ also replicates schema definitions, so the schema you add on one replica are propagated to other replicas without you having to intervene manually. As it is easy to introduce typos into schema definitions, the best way to start defining your own schema is with the OpenDJ Control Panel. Open the Control Panel > Schema > Manage Schema window to get started creating your custom object classes and attribute types. As object classes reference attribute types, you first create custom attribute types, and then create the object class that references the attribute types. Create a custom attribute type through the New Attribute window. Using the New Object Class window, create an auxiliary object class that allows your new custom attribute type. You set the type to Auxiliary under Extra Options. When you finish, the schema changes show up by default in the file config/schema/99-user.ldif. Notice that the file name starts with a number, 99. This number is larger than the numbers prefixing other schema file names. In fact, OpenDJ reads the schema files in sorted order, reading schema definitions as they occur. If OpenDJ reads a schema definition for an object class before it has read the definitions of the attribute types mentioned in the object class definition, then it displays an error. Therefore, when naming your schema file, make sure the name appears in the sorted list of file names after all the schema files containing definitions that your schema definitions depends on. The default file name for your schema, 99-user.ldif, ensures that your definitions load only after all of the schema files installed by default. You can create this file in the lab using the Control Panel, and then apply the definitions in production by adapting the content for use with the ldapmodify command, for example. $ cat config/schema/99-user.ldif dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema attributeTypes: ( temporary-fake-attr-id NAME 'myCustomAttribute' EQUALITY case IgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstrings Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) objectClasses: ( temporary-fake-oc-id NAME 'myCustomObjClass ' SUP top AUXILIARY MAY myCustomAttribute ) modifiersName: cn=Directory Manager,cn=Root DNs,cn=config modifyTimestamp: 20110620095948Z To test your schema definition, add the object class and attribute to an entry. $ cat custom-attr.ldif dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify add: objectClass objectClass: myCustomObjClass - add: myCustomAttribute myCustomAttribute: Testing 1, 2, 3... $ ldapmodify --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --filename custom-attr.ldif Processing MODIFY request for uid=bjensen,ou=People,dc=example,dc=com MODIFY operation successful for DN uid=bjensen,ou=People,dc=example,dc=com $ ldapsearch --port 1389 --baseDN dc=example,dc=com uid=bjensen myCustomAttribute dn: uid=bjensen,ou=People,dc=example,dc=com myCustomAttribute: Testing 1, 2, 3...

Schema Legacy data By default, OpenDJ accepts data that follows the standards in terms of what is allowed and what is rejected. You might have legacy data from a directory service that is more lenient, allowing non-standard constructions such as multiple structural object classes per entry, not checking attribute value syntax, or even not respecting schema definitions. For example, when importing data with multiple structural object classes defined per entry, you can relax schema checking to warn rather than reject entries having this issue. $ dsconfig set-global-configuration-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --set single-structural-objectclass-behavior:warn --trustAll --no-prompt You can allow attribute values that do not respect the defined syntax with the dsconfig command as well. $ dsconfig set-global-configuration-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --set invalid-attribute-syntax-behavior:warn --trustAll --no-prompt You can even turn off schema checking altogether, although turning off schema checking only really makes sense when you are absolutely sure that the entries and attribute values respect the schema definitions, and you simply want to turn off schema checking temporarily to speed up import processing. $ dsconfig set-global-configuration-prop --hostname opendj.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --set check-schema:false --trustAll --no-prompt

Schema Bundled definitions The following files under config/schema/ contain schema definitions out of the box. 00-core.ldif This file contains a core set of attribute type and objectlass definitions from several standard LDAP documents, including draft-ietf-boreham-numsubordinates, draft-findlay-ldap-groupofentries, draft-furuseth-ldap-untypedobject, draft-good-ldap-changelog, draft-ietf-ldup-subentry, draft-wahl-ldap-adminaddr, RFC 1274, RFC 2079, RFC 2256, RFC 2798, RFC 3045, RFC 3296, RFC 3671, RFC 3672, RFC 4512, RFC 4519, RFC 4523, RFC 4524, RFC 4530, RFC 5020, and X.501. 01-pwpolicy.ldif This file contains schema definitions from draft-behera-ldap-password-policy, which defines a mechanism for storing password policy information in an LDAP directory server. 02-config.ldif This file contains the attribute type and objectclass definitions for use with the directory server configuration. 03-changelog.ldif This file contains schema definitions from draft-good-ldap-changelog, which defines a mechanism for storing information about changes to directory server data. 03-rfc2713.ldif This file contains schema definitions from RFC 2713, which defines a mechanism for storing serialized Java objects in the directory server. 03-rfc2714.ldif This file contains schema definitions from RFC 2714, which defines a mechanism for storing CORBA objects in the directory server. 03-rfc2739.ldif This file contains schema definitions from RFC 2739, which defines a mechanism for storing calendar and vCard objects in the directory server. Note that the definition in RFC 2739 contains a number of errors, and this schema file has been altered from the standard definition in order to fix a number of those problems. 03-rfc2926.ldif This file contains schema definitions from RFC 2926, which defines a mechanism for mapping between Service Location Protocol (SLP) advertisements and LDAP. 03-rfc3112.ldif This file contains schema definitions from RFC 3112, which defines the authentication password schema. 03-rfc3712.ldif This file contains schema definitions from RFC 3712, which defines a mechanism for storing printer information in the directory server. 03-uddiv3.ldif This file contains schema definitions from RFC 4403, which defines a mechanism for storing UDDIv3 information in the directory server. 04-rfc2307bis.ldif This file contains schema definitions from the draft-howard-rfc2307bis specification, used to store naming service information in the directory server. 05-rfc4876.ldif This file contains schema definitions from RFC 4876, which defines a schema for storing Directory User Agent (DUA) profiles and preferences in the directory server. 05-samba.ldif This file contains schema definitions required when storing Samba user accounts in the directory server. 05-solaris.ldif This file contains schema definitions required for Solaris and OpenSolaris LDAP naming services. 06-compat.ldif This file contains the attribute type and objectclass definitions for use with the directory server configuration.