33 Managing Directory Schema
Topics:
For detailed information about specific schema elements, see Understanding the Oracle Unified Directory Schema Model.
33.1 Understanding Schema in Oracle Unified Directory
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 section covers the following topics:
33.1.1 About Oracle Unified Directory Schema
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.
33.1.2 Designing and Extending the Schema
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.
33.1.3 Default Schema Files
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 33-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: The definition in RFC 2739 contains some errors. This schema file has been altered from the standard definition to fix some 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. |
33.2 Configuring Schema Checking
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 must tune the server for maximum performance and you are certain that your clients will never make a change that causes a schema violation, then you can set the property tofalse
. The small performance benefits are minimal compared to the potential risks to your directory. -
invalid-attribute-syntax-behavior
. Possible values are:reject
(default),accept
, andwarn
. 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 toaccept
, then the server silently accepts attribute violations. If this attribute is set towarn
, the server accepts violations, but writes a message to the error log. If thecheck-schema
property is set tofalse
, invalid attribute syntax checking is not enforced. -
single-structural-objectclass-behavior
. Possible values are:reject
(default),accept
, andwarn
. 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 toaccept
, entries with no structural object classes are allowed. If this property is set towarn
, entries with no structural object classes (or more than one) are allowed, but a message is written to the error log. If thecheck-schema
property is set tofalse
, 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.
33.3 Working With Object Identifiers (OIDs)
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.
This section covers the following topics:
33.3.1 About Object Identifiers (OIDs)
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 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 33-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 33-3 Assigned OID Values for Attribute Types
OID Value | Attribute Type |
---|---|
|
|
|
|
|
|
|
|
|
|
Oracle Unified Directory allows the use of non-numeric OIDs if 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.
33.3.2 Obtaining a Base OID
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:
- Point your browser to the Internet Assigned Numbers Authority (IANA) website 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 website. - 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 addingExample
to aPerson
object class as inExamplePerson
. - 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.
33.4 Extending the Schema
Oracle Unified Directory supports multiple methods to extend the schema.
This section covers the following topics:
33.4.1 About Extending the Schema
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/99-user.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/99-user.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 elementX-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/99-user.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 99-user.ldif
file or to your designated schema file.
33.4.2 Managing Attribute Types
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.
This section covers the following topics:
33.4.2.1 List of Identifiers for Attribute Types
In typical applications, you can optionally include the following identifiers for the attribute type. To see the full set of attribute type elements, see Understanding Attribute Types.
-
OID
-
Required. 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 if 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. -
NAME
-
Optional. 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. -
SUP
-
Optional. 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.
-
DESC
-
Optional. Specifies a human-readable description of the attribute type.
-
SYNTAX
-
Optional. 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-VALUE
-
Optional. 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-MODIFICATION
-
Optional. 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).
-
USAGE
-
Optional. 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. -
extensions
-
Optional. 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 nonstandard 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.
33.4.2.2 Viewing Attribute Types
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.
33.4.2.3 Creating an Attribute Type
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
.
33.4.2.4 Deleting an Attribute Type
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.
33.4.3 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.
This section covers the following topics:
33.4.3.1 List of Optional identifiers for Object Classes
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 Schema in Oracle Unified Directory.
-
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 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 asperson-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
andSTRUCTURAL
. -
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 nonstandard 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.
33.4.3.2 Viewing Object Classes
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.
33.4.3.3 Creating 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 type that was created in the previous example.
33.4.3.4 Deleting 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 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.
33.5 About Replicating the Schema
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 Configuring Schema Replication.
33.6 Managing the Schema Using OUDSM
You can manage most elements of the directory schema with OUDSM. The following topics indicate the steps to manage the most common aspects of viewing and extending the schema.
This section covers the following topics:
33.6.1 Adding a New Attribute Type
Use Oracle Unified Directory Services Manager (OUDSM) to add a new attribute type to the schema.
To add a new attribute type to the schema by using OUDSM:
33.6.2 Adding an Attribute Based on an Existing Attribute
Use Oracle Unified Directory Services Manager to add an attribute type that is based on an existing attribute type.
To add an attribute type that is based on an existing attribute type:
33.6.3 Modifying an Attribute
Use Oracle Unified Directory Services Manager to modify an existing attribute type.
To modify an existing attribute type:
33.6.4 Deleting an Attribute
Use Oracle Unified Directory Services Manager to delete an existing attribute type.
To delete an existing attribute type:
- Connect to the directory server from OUDSM, as described in Connecting to the Server Using OUDSM.
- 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.
33.6.5 Viewing All Directory Attributes
Use Oracle Unified Directory Services Manager to view all existing attribute types.
To view all existing attribute types:
- Connect to the directory server from OUDSM, as described in Connecting to the Server Using OUDSM.
- 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.
33.6.6 Searching for Attributes
Use Oracle Unified Directory Services Manager to search for a specific attribute types.
To search for a specific attribute types:
33.6.7 Viewing the Indexing Details of an Attribute
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.
To view the indexes that are defined for an attribute by using OUDSM:
- Connect to the directory server from OUDSM, as described in Connecting to the Server Using OUDSM.
- 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.
33.6.8 Adding a New Object Class
Use Oracle Unified Directory Services Manager (OUDSM) to add a new attribute type to the schema.
To add a new attribute type to the schema by using OUDSM:
33.6.9 Adding an Object Class Based on an Existing Object Class
Use Oracle Unified Directory Services Manager to add an object class that is based on an existing object class.
To add an object class that is based on an existing object class:
33.6.10 Viewing the Properties of an Object Class
Use Oracle Unified Directory Services Manager to view the properties of an existing object class.
To view the properties of an existing object class:
- Connect to the directory server from OUDSM, as described in Connecting to the Server Using OUDSM.
- 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.
33.6.11 Modifying an Object Class
Use Oracle Unified Directory Services Manager to modify an existing object class.
To modify an existing object class:
33.6.12 Deleting an Object Class
Use Oracle Unified Directory Services Manager to delete an existing object class.
To delete an existing object class:
- Connect to the directory server from OUDSM, as described in Connecting to the Server Using OUDSM.
- 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.
33.6.13 Searching for Object Classes
Use Oracle Unified Directory Services Manager to search for a specific object class.
To search for a specific object class:
33.6.14 Displaying a List of LDAP Syntaxes
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 Configuring Schema Checking.
You cannot modify the LDAP syntaxes but you can view all existing LDAP syntaxes.
To view all existing LDAP syntaxes by using OUDSM:
33.6.15 Searching for a Syntax
Use Oracle Unified Directory Services Manager to search for a specific LDAP syntax.
To search for a specific LDAP syntax:
33.6.16 Displaying a List of LDAP Matching Rules
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.
To view all existing matching rules by using OUDSM:
33.6.17 Searching for a Matching Rule
Use Oracle Unified Directory Services Manager to search for a specific matching rule.
To search for a specific matching rule:
33.6.18 Displaying a List of Content Rules
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, then it will work 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.
To view all the content rules that are configure in the server by using OUDSM:
- Connect to the directory server from OUDSM, as described in Connecting to the Server Using OUDSM.
- 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.
33.6.19 Searching for a Content Rule
Use Oracle Unified Directory Services Manager to search for a specific content rule.
To search for a specific content rule:
- Connect to the directory server from OUDSM, as described in Connecting to the Server Using OUDSM.
- 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.
33.6.20 Creating a New Content Rule
Use Oracle Unified Directory Services Manager to add a new content rules to the schema.
To add a new content rules to the schema:
33.6.21 Creating a Content Rule Based on an Existing Content Rule
Use Oracle Unified Directory Services Manager to add a content rule that is based on an existing content rule.
To add a content rule that is based on an existing content rule:
33.6.22 Modifying a Content Rule
Use Oracle Unified Directory Services Manager to modify an existing content rule.
To modify an existing content rule:
33.6.23 Deleting a Content Rule
Use Oracle Unified Directory Services Manager to delete an existing content rule.
To delete an existing content rule:
- Connect to the directory server from OUDSM, as described in Connecting to the Server Using OUDSM.
- 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.