The schema defines and governs the types of information objects that can be stored in a directory. A schema defines the types of entries in the directory information tree, maintains element uniqueness, and prevents unchecked schema growth that can arise when new elements are added to the directory.
This chapter provides instructions on viewing and extending the schema provided with the directory server, and covers the following topics:
For detailed information about specific schema elements, see Chapter 9, "Understanding the Oracle Unified Directory Schema Model."
A directory server instance reads the schema once at startup and then uses the schema information to match a search filter request or assertion to an entry's attributes to determine if any add or modify operations are permitted by the client.
In most cases, the default schema should be sufficient for most applications. However, you can take advantage of the flexibility of the directory server to extend the schema to suit your applications. The general procedure is not to relinquish the standard schema to a new custom schema, but to use the standard attributes or object classes wherever possible. If you require custom attributes or object classes that are not handled with the standard schema, you can create or extend the standard schema with auxiliary attributes and object classes required for your application.
The schema is stored in the directory under the suffix (cn=schema). The directory server also has a subschema subentry that defines the schema elements plus the set of operational attributes in the directory.
You can extend the schema in one of two ways:
Extend the schema over LDAP.
Create a custom schema definition file.
Before you consider extending the default schema, or designing your own schema, ensure that you have a solid understanding of schema syntax and design.
The basic steps to design or extend a schema are as follows:
Map the data to the default schema. Where possible, use the existing schema elements that are defined in the directory server. Standard schema elements help to ensure compatibility with directory-enabled applications. Because the schema is based on the LDAP standard, it has been reviewed and agreed upon by a large number of directory users.
Identify unmatched data. The default schema was designed to accommodate a large variety of information objects. However, if the schema does not handle your specific data type, then make note of it and any other data types needed for your directory.
Extend the default schema to define new elements. For optimal performance, reuse existing schema elements wherever possible. Also, minimize the number of mandatory attributes that you define for each object class. Keep the schema as simple as possible. Do not define more than one object class or attribute for the same purpose.
Use schema checking. Schema checking ensures that attributes and object classes conform to the schema rules.
Select and apply a consistent data format. The LDAP schema allows you to place any data on any attribute value. However, you should store data consistently by selecting a format appropriate for your LDAP client application and directory users.
The default schema provided with the directory server is a collection of LDIF files stored in OUD_ORACLE_HOME/config/schema. These schema files are applied to every server instance that is associated with that OUD_ORACLE_HOME.
A directory server instance loads the schema files in alphanumeric order (numerals first) at server startup.
Caution:
Never modify the standard schema definitions and internal operational attributes in these files.
The following table describes the default schema files and their contents.
Table 27-1 Default Schema Files
| Schema File | Description |
|---|---|
|
|
Contains the schema definitions for the LDAPv3 standard user and organization. |
|
|
Contains the schema definitions for password policies based on the |
|
|
Contains the schema definitions for the attribute and object class definitions in the directory configuration file. |
|
|
Contains the schema definitions for storing changes to directory data based on the |
|
|
Contains the schema definitions for representing Java objects in an LDAP directory based on RFC 2713. |
|
|
Contains the schema definitions for representing CORBA object references in an LDAP directory based on RFC 2714. The Common Object Request Broker Architecture (CORBA) integrates machines in a multivendor, multiplatform environments using CORBA objects. A directory server can be a repository for CORBA object references, which allow for a centrally administered service for CORBA-compliant applications. |
|
|
Contains the schema definitions for representing calendar attributes for a vCard directory based on RFC 2739. Calendar applications require a calendar user agent to locate a URI, located in a directory, for an individual's calendar. Note that the definition in RFC 2739 contains a number of errors. This schema file has been altered from the standard definition in order to fix a number of those problems. |
|
|
Contains the schema definitions for mapping Service Location Protocol (SLP) advertisements based on RFC 2926. This specification allows directory servers to serve SLP directory agent back ends that create mappings between SLP templates and the LDAP directory schema. |
|
|
Contains the schema definitions for the authentication password syntax based on RFC 3112. |
|
|
Contains the schema definitions for storing printer information in the directory based on RFC 3712. |
|
|
Contains the schema definitions for storing UDDI v3 information in the directory based on RFC 4403. Universal Description, Discovery and Integration (UDDI) is a platform-independent, XML-based registry for companies on the Internet. UDDI enables companies to publish service listings and defines which software applications interact together over the Internet. |
|
|
Contains the schema definitions for storing naming service information in the directory based on |
|
|
Contains schema definitions from RFC 4876, which defines a schema for storing Directory User Agent (DUA) profiles and preferences. |
|
|
Contains schema definitions required for Solaris and OpenSolaris LDAP naming services. |
|
|
Contains the attribute type and objectclass definitions for use with the directory server configuration. |
|
|
Contains schema definitions required for the Active Directory paging function. |
|
|
Contains the schema definitions required for the distribution functionality of a proxy server instance. |
|
|
Contains the schema definitions required for the global indexing functionality of a proxy server instance. |
|
|
Contains the schema definitions required for the load balancing functionality of a proxy server instance. |
|
|
Contains the schema definitions specific to a proxy server instance. |
|
|
Contains the schema definitions specific to a replication gateway server instance. |
|
|
Contains the schema definitions required for the virtualization functionality of a proxy server instance. |
Oracle Unified Directory provides a schema-checking mechanism that verifies whether newly-written or added entries conform to the directory server's schema. This mechanism ensures that data imported using import-ldif, or added using ldapmodify, meets the syntax rules of the schema.
The schema checking configuration is part of the advanced global configuration, and can be displayed with the following command:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ --advanced get-global-configuration-prop Property : Value(s) ---------------------------------------:--------------------------------------- ... check-schema : true ... invalid-attribute-syntax-behavior : reject ... single-structural-objectclass-behavior : reject ...
The following configuration properties control schema-checking:
check-schema. Possible values: true (default), false. This property controls whether the directory server should do schema-checking on newly imported or added entries. By default, the property is set to true. If you need to tune the server for maximum performance and you are certain that your clients will never make a change that causes a schema violation, you can set the property to false. The small performance benefits are minimal compared to the potential risks to your directory.
invalid-attribute-syntax-behavior. Possible values are: reject (default), accept, and warn. This property controls how the server should behave if an attempt is made to use an attribute value that violates the associated syntax. By default, the server rejects any requests to use attributes that violate the schema. If this property is set to accept, the server silently accepts attribute violations. If this attribute is set to warn, the server accepts violations, but writes a message to the error log. If the check-schema property is set to false, invalid attribute syntax checking is not enforced.
single-structural-objectclass-behavior. Possible values are: reject (default), accept, and warn. This property controls how the server should behave if an attempt is made to create or alter an entry that does not have exactly one structural object class. This means that object classes with no structural object classes or more than one are rejected by default. If this property is set to accept, entries with no structural object classes are allowed. If this property is set to warn, entries with no structural object classes (or more than one) are allowed, but a message is written to the error log. If the check-schema property is set to false, single structural object class checking is not enforced.
Caution:
Changing the value of these properties from the default puts the integrity of the schema at risk, so you should generally not alter these values.
An object identifier (OID) is a numeric string used to uniquely identify an object in a directory. OIDs are used in directory schema, controls, and extended operations that require unique identification of elements.
LDAP object classes and attributes require a base object identifier (OID) that must be unique within your organization to avoid naming conflicts in the directory. If you plan to use your directory internally within your organization, use the OIDs provided in the directory server. If you plan to export your schema or publicly expose your schema in any way, consider entering a request for a unique OID for your organization. For more information, see Section 27.3.1, "Obtaining a Base OID".
After you have obtained a base OID, you can add branches to it for your organization's object classes and attributes. For example, the directory server uses an assigned base OID of 1.3.6.1.4.1.26027. For each component type, the directory server provides unique branch numbers to the base OID for each schema component.
Oracle Unified Directory provides a comprehensive set of OIDs that should be sufficient for most applications.
The following table shows the base OIDs used for each schema component:
Table 27-2 Base OIDs Used for Each Schema Component
| OID Value | Type |
|---|---|
|
|
Attribute |
|
|
Object classes |
|
|
Attribute syntaxes |
|
|
Matching rules |
|
|
Controls |
|
|
Extended operations |
|
|
General use |
|
|
Experimental use |
For each schema type, a unique branch number is added to the base OID. For example, attribute types use a branch number of 1 to form the OID of 1.3.5.1.4.1.26027.1.*1*. For each specific attribute type, the directory server assigns another set of branch numbers, one for each attribute type.
The following table displays a (partial) list of assigned OID values for attribute types.
Table 27-3 Assigned OID Values for Attribute Types
| OID Value | Attribute Type |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Oracle Unified Directory allows the use of non-numeric OIDs as long as a corresponding numeric OID is defined within the schema. For example, you can use a non-numeric OID, mytestattribute-oid for the named attribute, myTestAttribute. The non-numeric OID must be all lowercase with the -oid appended to the named attribute. The use of non-numeric OIDs is an LDAP-specification violation but is permissible for ease of use.
If you plan to make your directory server publicly available, or if you plan to redistribute your schema definitions for custom applications, you can obtain a base OID for your organization. You can use your own OIDs in a custom schema file if you plan to create custom extensions to the directory server. Alternatively, you can modify the schema configuration files by adding your base OID with its respective branch number.
Note:
Do not modify the default OIDs unless you are sure of what you are doing. Modifying the OIDs can potentially damage your directory server.
To obtain and create base OIDs for your organization, perform the following steps:
Point your browser to the Internet Assigned Numbers Authority (IANA) web site at (http://www.iana.org) or a national organization in your country that handles such tasks. In some countries, corporations already have OIDs assigned to them. If your organization does not already have an OID, you can fill out a request at the IANA web site.
Determine the unique object classes, attributes, names, and other schema elements. Ensure that the names are descriptive to make it easier to manage the schema. One trick is to add a custom prefix to your custom object classes and attributes. For example, if your organization is Example.com, you can add the prefix Example before each custom schema element, such as adding Example to a Person object class as in ExamplePerson.
Create an OID registry to keep track of OID assignments. The registry is nothing more than a list that you maintain to ensure that OIDs and their descriptions are unique within your directory. The registry should be sufficiently protected so that only a privileged administrator can modify the registry.
Create branches in the OID tree to accommodate the schema elements.
Shut down the directory servers in your topology.
Manually edit the schema configuration files on each directory server in your topology. Replace each OID with your company's OID. This avoids problems with schema replication seeing differences in the schema and attempting to synchronize the information.
Manually edit any custom schema extensions. Ideally, you should define any custom extensions in a separate file.
Oracle Unified Directory supports multiple methods to extend the schema. The standard schema files are a set of LDIF files located in OUD_ORACLE_HOME/config/schema. Do not modify these files directly, because doing so can result in unpredictable server behavior.
The standard schema definitions apply to every server instance associated with that OUD_ORACLE_HOME. Custom schema definitions located in instance-dir/OUD/config/schema/99user.ldif apply only to the server instance in which they are created.
You can extend the schema as follows:
Extend the schema over LDAP. Define your schema extensions, write the definitions to an LDIF file, and add the custom schema extensions by using the ldapmodify command.
When you use this method, the directory server automatically writes the new schema definitions to the file:
instance-dir/OUD/config/schema/99user.ldif
To specify a different schema file, include the X-SCHEMA-FILE element with the name of your schema file. For example, as part of your attribute type definition, include the element X-SCHEMA-FILE '98myschema.ldif'.
When you extend the schema over LDAP, you do not need to restart the server to take the schema modifications into account.
Create a custom schema file. Create a custom schema file with your definitions and move the file to the directory:
instance-dir/OUD/config/schema/
The directory server loads schema files in alphanumeric order with numbers loaded first. As such, you should name custom schema files as follows: [00-99]filename.ldif. The number should be higher than any standard schema file that has already been defined. If you name custom schema files with a number that is lower than the standard schema files, the server might encounter errors when loading the schema.
When you extend the schema with a custom schema file, the server must be restarted before the schema modifications are taken into account.
Modify an existing schema file. You can add a custom schema extension to an existing custom schema file, such as instance-dir/OUD/config/schema/99user.ldif.
When you extend the schema by modifying an existing schema file, the server must be restarted before the schema modifications are taken into account.
When you add new schema elements, all attributes must be defined before they can be used in an object class. If you are creating several object classes that inherit from other object classes, you must create the parent object class first.
Each custom attribute or object class that you create should be defined in only one schema file.
When you define new schema definitions manually, the best practice is to add these definitions to the 99user.ldif file or to your designated schema file.
You can add new attribute types to the schema by using the ldapmodify command. The attribute types syntax requires that you provide at least a valid OID to define a new element. In typical applications, you can optionally include the following identifiers for the attribute type. To see the full set of attribute type elements, see Section 9.3, "Understanding Attribute Types".
OIDRequired. Specifies the OID that uniquely identifies the attribute type in the directory server. The LDAP v3 specification requires the OID to be a UTF-8 encoded dotted decimal. However, Oracle Unified Directory supports the use of non-numeric OIDs for easy identification as long as the schema is used internally within the organization. The format is attributename-oid, for example, telephoneNumber-oid. Each non-numeric OID must have its corresponding dotted decimal OID defined in the schema.
NAMEOptional. Specifies the set of human-readable names that are used to refer to the attribute type. 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.
SUPOptional. Specifies the superior attribute type when you want one attribute type to inherit elements from another attribute type. The matching rule and attribute syntax specifications from the superior attribute type can be inherited by the subordinate type if it does not override the superior attribute type definition. The OID, any of the human-readable names associated with the superior attribute type or both can be used to collectively reference all of the subordinate attribute types.
DESCOptional. Specifies a human-readable description of the attribute type.
SYNTAXOptional. Specifies the attribute syntax for use with the attribute type. If provided, it should be given as a numeric OID. The core syntaxes are defined in section 3.3. of RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt) and in Appendix A of the same document.
SINGLE-VALUEOptional. Specifies whether the attributes of that type are allowed to have only a single value in any entry in which they appear. If SINGLE-VALUE is not present, the attributes are allowed to have multiple distinct values in the same entry.
NO-USER-MODIFICATIONOptional. Indicates that the values of the attributes of the given type cannot be modified by external clients (that is, the values can be modified only by internal processing within the directory server).
USAGEOptional. Indicates how the attribute is to be used. Possible values are as follows: userApplications. Used to store user data. directoryOperation. Used to store data required for internal processing within the directory server. distributeOperation. Used to store operational data that must be synchronized across directory servers in the topology. dSAOperation. Used to store operational data that is specific to a particular directory server and should not be synchronized across the topology.
extensionsOptional. Specifies the extensions available to the attribute type. Oracle Unified Directory provides the following extensions:
X-ORIGIN. Provides information on where the attribute type is defined. The element is a non-standard tool that you can use to locate the schema element, for example, the RFC number (RFC4517).
X-SCHEMA-FILE. Indicates which schema file contains the attribute type definition. Used for internal purposes only and is not exposed to clients. You can use this extension to specify where the directory server should store your custom schema definitions.
X-APPROX. Indicates which approximate matching rule should be used for the attribute type. If specified, the value should be the name of the OID of a registered approximate matching rule.
For example, you can specify the addition of a new attribute type, blogURL, in an LDIF file that will be added to the schema.
$ cat blogURL.ldif dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Oracle Unified Directory Server' USAGE userApplications )
Note:
Pay special attention to the spaces in an attribute type declaration. The LDAP specification requires that a space exist between the opening parenthesis and the OID, and the value of the USAGE 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 (2) spaces at the beginning of the line that starts with an element keyword. For example, add two spaces before NAME, DESC, SYNTAX, SINGLE-VALUE, X-ORIGIN, and USAGE in the previous example.
The OIDs used in this example are for illustration purposes only and should not be implemented in your directory.
The cn=schema entry has a multivalued attribute, attributeTypes, that contains definitions of each attribute type in the directory schema. You can view the schema definitions by using the ldapsearch command. Schema elements are represented as LDAP subentries, and searches on cn=schema must therefore include the LDAP Subentry search control.
Use the ldapsearch command with the LDAP Subentry search control, as follows:
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b "cn=schema" -s base "(objectclass=*)" attributeTypes
dn: cn=schema
attributeTypes: ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch SUBSTR
caseIgnoreeSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768}
X-ORIGIN 'RFC 4519' )
attributeTypes: ( 2.5.4.49 NAME 'distinguishedName' EQUALITY
distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN
'RFC 4519' )
attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 X-ORIGIN 'RFC 4512' )
...(more output)...
To view a specific attribute type, use the --dontWrap option and then use the grep command (on UNIX systems) to search for the required attribute.
The following example searches for attribute types that contain the string telexNumber.
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b cn=schema -s base --dontWrap "(objectclass=*)" \ attributeTypes | grep "telexNumber" attributeTypes: ( 2.5.4.21 NAME 'telexNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 X-ORIGIN 'RFC 4519' ) attributeTypes: ( 2.5.4.21.1 NAME 'c-TelexNumber' SUP telexNumber COLLECTIVE X-ORIGIN 'RFC 3671' )
The cn=schema entry has a multivalued attribute, attributeTypes, that contains definitions of each attribute type in the directory schema. You can add custom schema definitions by using the ldapmodify command. This example adds an attribute named blog.
Using a text editor, create an LDIF file with your schema extensions.
dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Oracle Unified Directory Server' USAGE userApplications )
Use ldapmodify to add the file.
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -a -f blogURL.ldif Processing MODIFY request for cn=schema MODIFY operation successful for DN cn=schema
Verify the addition by displaying it using ldapsearch.
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b "cn=schema" -s base --dontWrap "(objectclass=*)" \ attributeTypes | grep 'blog' attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Oracle Unified Directory Server' USAGE userApplications )
Note:
Oracle Unified Directory automatically adds new attribute definitions to the file instance-dir/OUD/config/schema/99user.ldif.
The cn=schema entry has a multivalued attribute, attributeTypes, that contains definitions of each attribute type in the directory schema. You can delete custom schema definitions by using the ldapmodify command. Oracle Unified Directory does not allow deletions to standard schema definitions.
Caution:
Be careful when deleting attribute types, because doing so can harm your directory. Do not delete an attribute type unless absolutely necessary.
Create the delete request in an LDIF file.
dn: cn=schema changetype: modify delete: attributeTypes attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Oracle Unified Directory Server' USAGE userApplications )
Use the ldapmodify command to process the delete request.
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --fileName "remove_blogURL.ldif" Processing MODIFY request for cn=schema MODIFY operation successful for DN cn=schema
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 Section 27.1, "Oracle Unified Directory Schema Overview".
OIDRequired. Specifies the OID that uniquely identifies the object class in the directory server. The LDAP v3 specification requires the OID to be a UTF-8 encoded dotted decimal. However, Oracle Unified Directory 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.
NAMEOptional. 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.
DESCOptional. Specifies a human-readable description of the object class. If specified, the description should be enclosed in single quotation marks.
SUPOptional. 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.
OBSOLETEOptional. 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 oidsOptional. The SUP keyword should be followed by the OID of the superior class.
KINDOptional. Indicates the type of object class that is being defined. Allowed values are ABSTRACT, AUXILIARY and STRUCTURAL.
MUST oidsOptional. 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 oidsOptional. 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).
extensionsOptional. 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. 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.32473.1.1.10 NAME ( 'blogger' ) DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog X-ORIGIN 'Oracle Unified Directory Server' )
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.
The OIDs used in this example are for illustration purposes only and should not be implemented in your directory.
The cn=schema entry has a multivalued attribute, objectClasses, that contains definitions of each object class in the directory schema. You can view the schema definitions by using the ldapsearch command.
Use the ldapsearch command to view object class definitions.
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -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 ( searchGuide $ description ) X-ORIGIN 'RFC 4519' ) objectClasses: ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) X-ORIGIN 'RFC 4519' ) objectClasses: ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registered Address $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) X-ORIGIN 'RFC 4519' ) ...(more output)...
Use the --dontWrap option and the grep command to search for a specific object class.
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -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' )
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 type that was 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.32473.1.1.10 NAME ( 'blogger' ) DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog X-ORIGIN 'Oracle Unified Directory Server' )
Use the ldapmodify command to add the file.
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -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 1389 -D "cn=Directory Manager" -j pwd-file \ -b cn=schema -s base --dontWrap "(objectclass=*)" \ objectClasses | grep 'blogger'
Note:
Oracle Unified Directory automatically adds new object class definitions to the file instance-dir/OUD/config/schema/99user.ldif.
The cn=schema entry has a multivalued attribute, objectClasses, that contains definitions for each object class in the directory schema. You can delete custom object class 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.32473.1.1.10 NAME ( 'blogger' ) DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog X-ORIGIN 'Oracle Unified Directory Server' )
Remove the object class by using ldapmodify to apply the LDIF file.
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --fileName "remove_objectclass_schema.ldif"
In a replicated topology, schema definitions are automatically replicated to ensure that all servers use a single schema. Schema modifications on any server are replicated to all other servers in the topology.
When you configure replication, the schema of the first server is used to initialize the schema of the second server by default. You can, however, specify that the schema of the second server be used to initialize the schema of the first server. You can also specify that schema replication be disabled altogether. For more information, see Section 26.6, "Configuring Schema Replication".
You can manage most elements of the directory schema with ODSM. The following topics indicate the steps to manage the most common aspects of viewing and extending the schema.
You can add a new attribute type to the schema by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
The Attributes panel is expanded by default. If it is not expanded, click the arrow to expand it.
Click the Add icon.
Complete the following information on the Create new attribute window:
Name. Enter a unique name for the new attribute type.
Object ID. Specify the OID that uniquely identifies the attribute type in the directory server. Oracle Unified Directory supports the use of non-numeric OIDs for easy identification as long as the schema is used internally within the organization. However, for this release ODSM supports numeric OIDs only.
Description. Enter a human-readable description of the attribute type.
Syntax. Enter the attribute syntax for use with the attribute type. If provided, the syntax should be specified as a numeric OID. The core syntaxes are defined in section 3.3. of RFC 4517 and in Appendix A of the same document.
Size. Enter a maximum size for the value of the attribute, in bytes. In the case of multi-valued attributes, this refers to the maximum size of a single value, not of the combined values.
Usage. Specify how the attribute will be used. Possible values are as follows:
userApplications. The attribute will be used to store user data.
directoryOperation. The attribute will be used to store data that is required for internal processing within the directory server.
distributedOperation. The attribute will be used to store operational data that must be synchronized across directory servers in the topology.
dSAOperation. The attribute will be used to store operational data that is specific to a particular directory server and should not be synchronized across the topology.
Ordering. Select the ordering index details for this attribute type. For more information see Section 17.7, "Indexing Directory Data".
Equality. Select the equality index details for this attribute type. For more information see Section 17.7, "Indexing Directory Data".
Substring. Select the substring index details for this attribute type. For more information see Section 17.7, "Indexing Directory Data".
Obsolete. Select this box if the attribute type is no longer in use but is retained for compatibility.
Single Value. Indicate whether attributes of this type may have only a single value in any entry in which they appear. If this checkbox is not selected, the attributes may have multiple distinct values in the same entry.
Collective. Indicate whether the attribute is a collective attribute. For more information, see Section 17.12, "Using Collective Attributes".
Super. If this new attribute extends an existing attribute, enter or select the name of the existing super type.
Origin. Enter the source of this new attribute type, for example, RFC 4512.
To view the source of all the schema elements in the directory, select Show All from the View menu.
Schema File Extension. If the attribute type's definition is contained in a file, enter the path to the file.
Click Create to create the new attribute.
You can add an attribute type that is based on an existing attribute type by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
The Attributes panel is expanded by default. If it is not expanded, click the arrow to expand it.
Select the attribute on which you want to base the new attribute type.
Click the Create like icon.
Certain fields are completed by default, based on the attribute that you selected.
Complete the remaining fields for the new attribute type.
For information about the fields and their values, see Section 27.6.1, "Add a New Attribute Type".
Click Create to create the new attribute.
You can modify an existing attribute type by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
The Attributes panel is expanded by default. If it is not expanded, click the arrow to expand it.
Select the attribute type that you want to modify.
Modify the required fields, on the right hand pane.
For information about the fields, see Section 27.6.1, "Add a New Attribute Type".
Click Apply to save your changes.
You can delete an existing attribute type by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
The Attributes panel is expanded by default. If it is not expanded, click the arrow to expand it.
Select the attribute type that you want to delete.
Click the Delete icon and click OK to confirm the deletion.
Click Apply to save your changes.
Click the Refresh icon to refresh the list of attributes on the left hand pane and confirm that the attribute has been deleted from the schema.
Note:
The server will return an error if you attempt to delete an attribute type that is already referenced by one or more entries in the server.
You can view all existing attribute types by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
The Attributes panel is expanded by default. If it is not expanded, click the arrow to expand it.
All the attributes that are defined in the schema are listed in the left hand pane.
Select an attribute to display its properties in the right hand pane.
You can search for a specific attribute types by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
The Attributes panel is expanded by default. If it is not expanded, click the arrow to expand it.
All the attributes that are defined in the schema are listed in the left hand pane.
Enter part or all of the attribute name in the Search field and click the Go icon.
The search field supports pattern matching. For example, enter *uid to find all attributes that end with the string uid.
Select an attribute to display its properties in the right hand pane.
Indexes are configured per server and index configuration is not replicated. A local database index is used to find entries that match search criteria. A VLV index is used to process searches efficiently with VLV controls. Unindexed searches are denied by default, unless the user has the unindexed-search privilege.
A local database index can be one of the following types:
approximate - Improves the efficiency of searches using approximate search filters.
equality - Improves the efficiency of searches using equality search filters.
ordering - Improves the efficiency of searches using "greater than or equal to" or "less than or equal to" search filters.
presence - Improves the efficiency of searches using presence search filters.
substring - Improves the efficiency of searches using substring search filters.
You can view the indexes that are defined for an attribute by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
The Attributes panel is expanded by default. If it is not expanded, click the arrow to expand it.
Select an attribute to display its properties in the right hand pane.
Scroll down to the Indexed property to view the indexing details for that attribute.
You can add a new attribute type to the schema by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager,".
Select the Schema tab.
Click the Object classes panel to expand it.
All existing object classes are displayed on the left pane.
Click the Add icon.
Complete the following information on the Create new object class window:
Name. Enter a unique name for the new object class.
Object ID. Specify the OID that uniquely identifies the object class in the directory server. Oracle Unified Directory supports the use of non-numeric OIDs for easy identification as long as the schema is used internally within the organization. However, for this release ODSM supports numeric OIDs only.
Description. Enter a human-readable description of the object class.
Type. Specify the type of object class. Possible values are as follows:
Structural. A structural object class defines the core type for any entry that contains it. An entry must have exactly one structural class (although that structural class can inherit from other structural or abstract classes).
Auxiliary. An auxiliary object class does not define the core type of an entry, but defines additional characteristics of that entry. An entry can contain zero or more auxiliary object classes. The set of auxiliary classes that are allowed for use in an entry can be controlled by a DIT content rule that is associated with that entry's structural object class.
Abstract. An abstract object class cannot be used directly in an entry but must be subclassed by either a structural object class or an auxiliary object class. The subclasses will inherit any required and/or optional attribute type defined by the abstract class.
Superclass. Click the Add icon to specify one or more superior object classes. The new object class will inherit elements from its superior object classes.
Mandatory Attributes. Click the Add icon to specify the set of attribute types that are required to be present (that is, have at least one value) in entries with that object class.
Optional Attributes. Click the Add icon to specify the set of attribute types that are allowed but not required to be present in entries with that object class.
Inherited Attributes. After the object class has been created, this field indicates the attributes that are inherited from the superior object classes of this object class.
Origin. Enter the source of this new object class, for example, RFC 4512.
To view the source of all the schema elements in the directory, select Show All from the View menu.
Schema File Extension. If the definition of the new object class is contained in a file, enter the path to the file.
Click Create to create the new object class.
You can add an object class that is based on an existing object class by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Object classes panel.
Select the object class on which you want to base the new object class.
Click the Create like icon.
Certain fields are completed by default, based on the object class that you selected. The existing object class is used as the superior object class for the new object class
Complete the remaining fields for the new object class.
For information about the fields and their values, see Section 27.6.8, "Add a New Object Class".
Click Create to create the new object class.
You can view the properties of an existing object class by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Object Classes panel.
All the object classes that are defined in the schema are listed in the left hand pane.
Select an object class to display its properties in the right hand pane.
You can modify an existing object class by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Object Classes panel.
Select the object class that you want to modify.
Modify the required fields, on the right hand pane.
For information about the fields, see Section 27.6.8, "Add a New Object Class".
Click Apply to save your changes.
You can delete an existing object class by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Object Classes panel.
Select the object class that you want to delete.
Click the Delete icon and click OK to confirm the deletion.
Click Apply to save your changes.
Click the Refresh icon to refresh the list of attributes on the left hand pane and confirm that the object class has been deleted from the schema.
Note:
The server will return an error if you attempt to delete an object class that is already referenced by one or more entries in the server.
You can search for a specific object class by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Object Classes panel.
All the object classes that are defined in the schema are listed in the left hand pane.
Enter part or all of the object class name in the Search field and click the Go icon.
The search field supports pattern matching. For example, enter *person to find all object classes that end with the string person.
Select an object class to display its properties in the right hand pane.
LDAP syntaxes are essentially data type definitions. The syntax for an attribute type indicates the type of data that should be held by the corresponding values. Syntaxes can be used to determine whether a particular value is acceptable for a given attribute, and to provide information about how the directory server should interact with existing values.
Oracle Unified Directory supports the ability to reject values that violate the associated attribute syntax, and this is the default behavior for the purposes of standards compliance. It is possible to disable attribute syntax checking completely if necessary. It is also possible to accept values that violate the associated syntax but log a warning message to the directory server's error log when this occurs. For information about disabling schema checking, see Section 27.2, "Configuring Schema Checking".
You cannot modify the LDAP syntaxes but you can view all existing LDAP syntaxes by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Syntaxes panel.
All the supported LDAP syntaxes are listed in the left hand pane.
Select a syntax to display its properties in the right hand pane.
The information that is displayed includes all of the attributes and matching rules that currently refer to that syntax.
You can search for a specific LDAP syntax by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Syntaxes panel.
All the supported LDAP syntaxes are listed in the left hand pane.
Enter part or all of the syntax name in the Search field and click the Go icon.
The search field supports pattern matching. For example, enter *time to find all syntaxes that end with the string time.
Select a syntax to display its properties in the right hand pane.
Matching rules are used by the directory server to compare two values for the same attribute, that is, to perform matching operations on them. There are several different types of matching rules, including the following:
Equality matching rules. These matching rules are used to determine whether two values are logically equal to each other. Different implementations of equality matching rules can use different criteria for making this determination (for example, whether to ignore differences in capitalization or deciding which spaces are significant).
Ordering matching rules. These matching rules are used to determine the relative order for two values, for example, when evaluating greater-or-equal or less-or-equal searches, or when the results need to be sorted.
Substring matching rules. These matching rules are used to determine whether a given substring assertion matches a particular value.
Approximate matching rules. These matching rules are used to determine whether two values are approximately equal to each other. This is frequently based on "sounds like" or some other kind of fuzzy algorithm. Approximate matching rules are not part of the official LDAP specification, but they are included in Oracle Unified Directory for added flexibility.
You cannot modify the matching rules but you can view all existing matching rules by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Matching Rules panel.
All the configured matching rules are listed in the left hand pane.
Select a matching rule to display its properties in the right hand pane.
The information that is displayed includes all of the attributes and matching rules that currently refer to that matching rule.
You can search for a specific matching rule by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Matching Rules panel.
All the configured matching rules are listed in the left hand pane.
Enter part or all of the matching rule name in the Search field and click the Go icon.
The search field supports pattern matching. For example, enter *match to find all matching rules that end with the string match.
Select a matching rule to display its properties in the right hand pane.
Content rules provide a mechanism for defining the content that can appear in an entry. At most one content rule may be associated with an entry, based on its structural object class. If such a rule exists for an entry, it will work in conjunction with the object classes contained in that entry to define which attribute types must, may, and must not be present in the entry, as well as which auxiliary classes the entry may include.
You can view all the content rules that are configure in the server by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Content Rules panel.
All the configured content rules are listed in the left hand pane.
Select a content rule to display its properties in the right hand pane.
You can search for a specific content rule by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Content Rules panel.
All the configured content rules are listed in the left hand pane.
Enter part or all of the content rule name in the Search field and click the Go icon.
Select a content rule to display its properties in the right hand pane.
You can add a new content rules to the schema by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Content Rules panel.
Click the Add icon.
Complete the following information on the Create new content rule window:
Name. Enter a unique name for the new content rule.
Structural Object Class. Specify the name of the structural object class with which this content rule is associated.
Description. Enter a human-readable description of the content rule.
Auxiliary Object Classes. Click the Add icon to specify the list of auxiliary object classes that may be present in entries with the associated structural class. If no values are provided, such entries will not be allowed to have any auxiliary object classes. You can specify the allowed auxiliary object classes by using their names or OIDs.
Mandatory Attributes. Click the Add icon to specify the list of attribute types that are required to be present in entries with the associated structural class. This list is in addition to the attribute types that are required by the object classes included in the entry. These additional attribute types do not need to be allowed by any of those object classes. You can specify the mandatory attributes by using their names or OIDs.
Optional Attributes. Click the Add icon to specify the list of attribute types that are allowed, but not required, to be present in entries with the associated structural class. This list is in addition to the attribute types that are allowed by the object classes included in the entry. You can specify the optional attributes by using their names or OIDs.
Disallowed Attributes. Click the Add icon to specify the list of attribute types that are prohibited from being present in entries with the associated structural class. This list may not include any attribute types that are required by the structural class or any of the allowed auxiliary classes. The list can be used to prevent the inclusion of attribute types which would otherwise be allowed by one of those object classes. You can specify the disallowed attributes by using their names or OIDs.
Origin. Enter the source of this new content rule, for example, RFC 4517.
To view the source of all the schema elements in the directory, select Show All from the View menu.
Schema File Extension. If the content rule's definition is contained in a file, enter the path to the file.
Click Create to create the new content rule.
You can add a content rule that is based on an existing content rule by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Content Rules panel.
Select the content rule on which you want to base the new content rule.
Click the Create like icon.
Certain fields are completed by default, based on the content rule that you selected.
Complete the remaining fields for the new content rule.
For information about the fields and their values, see Section 27.6.20, "Create a New Content Rule".
Click Create to create the new content rule.
You can modify an existing content rule by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Content Rules panel.
Select the content rule that you want to modify.
Modify the required fields, on the right hand pane.
For information about the fields, see Section 27.6.20, "Create a New Content Rule".
Click Apply to save your changes.
You can delete an existing content rule by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager".
Select the Schema tab.
Expand the Content Rules panel.
Select the content rule that you want to delete.
Click the Delete icon and click OK to confirm the deletion.
Click Apply to save your changes.
Click the Refresh icon to refresh the list of content rules on the left hand pane and confirm that the content rule has been deleted from the schema.