JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory 11g Release 1 (11.1.1)
search filter icon
search icon

Document Information


1.  Introduction

2.  The Directory Server Access Control Model

3.  Understanding the Directory Server Schema

Understanding Matching Rules

Matching Rule Description Format

Commonly Used Matching Rules

Relative Time Matching Rules

Partial Date Or Time Matching Rules

Value Normalization

Understanding Attribute Syntaxes

The Attribute Syntax Description Format

Commonly Used Attribute Syntaxes

The Pattern-Matching Syntax Extension

The Enumeration Syntax Extension

Substitution Syntax Extension

Understanding Attribute Types

Attribute Type Description Format

Attribute Type Inheritance

Attribute Type Implementation

Understanding Object Classes

Object Class Description Format

Object Class Kinds

Object Class Inheritance

Directory Server Object Class Implementation

Understanding Name Forms

Name Form Description Format

Understanding DIT Content Rules

DIT Content Rule Description Format

DIT Content Rule Implementation

Understanding DIT Structure Rules

DIT Structure Rule Description Format

DIT Structure Rules and Multiple Schemas

Understanding Matching Rule Uses

4.  Directory Server Index Databases

5.  Directory Server Replication

6.  Directory Server Root Users and the Privilege Subsystem

7.  Supported Controls and Operations

Understanding Matching Rules

Matching rules are used by Oracle Unified Directory 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:

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. A substring assertion is composed of at least one element from the following sets: at most one subInitial element, zero or more subAny elements, and at most one subFinal element.

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.

The following sections describe matching rules:

Matching Rule Description Format

The matching rule description format is described in RFC 4512, section 4.1.3, in Augmented Backus-Naur Form (ABNF). For more information about ABNF, see RFC 4234 and RFC 5234. This is the format that is used to display matching rules in the matchingRules attribute of the schema subentry, and it shows the properties that can be associated with a matching rule. The following example shows the definition of the matching rule description format:

MatchingRuleDescription = LPAREN WSP
numericoid                 ; object identifier
[ SP "NAME" SP qdescrs ]   ; short names (descriptors)
[ SP "DESC" SP qdstring ]  ; description
[ SP "OBSOLETE" ]          ; not active
SP "SYNTAX" SP numericoid  ; assertion syntax
extensions WSP RPAREN      ; extensions

The matching rule description includes these elements:


The numeric OID is used to uniquely identify the matching rule in Oracle Unified Directory. Every matching rule must have a unique OID.


The name elements are human-readable names assigned to the matching rule that can be used to refer to it in place of the OID. A matching rule is not required to have any human-readable names. If it has only a single name, then it is enclosed in single quotes. If there are multiple names for a matching rule, each is enclosed in single quotes with spaces between the names, and parentheses around the entire set of names.


The description element is a human-readable description for the matching rule. There can be at most one description, and if it is present, it should be enclosed in single quotation marks.


The OBSOLETE flag indicates whether this matching rule should be considered available for use. If a matching rule is marked OBSOLETE, then it should not be possible to create any new attribute types or matching rule uses that reference this matching rule.


The syntax element identifies the attribute syntax with which the matching rule is associated. This is used to indicate the acceptable format for values on which the matching rule operates. More information about attribute syntaxes can be found in Understanding Attribute Syntaxes. The syntax OID must be included in all matching rule descriptions.


The extensions for a matching rule can be used to identify other properties for that matching rule that might not be included in the standard definition. Oracle Unified Directory does not currently support any extensions for use in matching rules.

For example, the following is the matching rule description for the standard caseIgnoreMatch matching rule:

( NAME 'caseIgnoreMatch' SYNTAX )

In this case, the OID is There is one name, which is caseIgnoreMatch. There is no description. The OID of the associated syntax is (which is the Directory String syntax). There are no extensions.

Commonly Used Matching Rules

There are a number of matching rules defined in LDAP, both in the core protocol specification as well as in other related RFCs and Internet Drafts. Many of these matching rules are defined in RFC 4517 (LDAP Syntaxes and Matching Rules), in section 4.2. Some of the most commonly used matching rules include:

caseIgnoreMatch, caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch

These are equality, ordering, and substring matching rules, respectively, that ignore differences in capitalization and also treat multiple consecutive spaces as a single space.

caseExactMatch, caseExactOrderingMatch, caseExactSubstringsMatch

These are equality, ordering, and substring matching rules, respectively, that treat values in a case-sensitive manner but do treat multiple consecutive spaces as a single space.

octetStringMatch, octetStringOrderingMatch, octetStringSubstringsMatch

These are equality, ordering, and substring matching rules, respectively, that perform byte-for-byte comparisons of the values, treating them as binary data rather than strings.

numericStringMatch, numericStringOrderingMatch, numericStringSubstringsMatch

These are equality, ordering, and substring matching rules, respectively, that operate on values that start with a numeric digit, and contain only numeric digits and spaces. Spaces are ignored when performing matching with these matching rules.


This is an equality matching rule that operates on distinguished name (DN) values. It ignores spaces around the commas or semicolons that separate DN components, spaces around plus signs that separate RDN components, and spaces around equal signs that separate RDN attribute type names from their corresponding values. Differences in capitalization are ignored for attribute type names. Equality matching for attribute values is performed using the equality matching rule for the corresponding attribute type.


This is an approximate matching rule that uses the double metaphone algorithm to perform a “sounds like” comparison. Note that this matching rule is not part of any official LDAP specification, but it is included in Oracle Unified Directory for added flexibility.

Relative Time Matching Rules

Oracle Unified Directory provides two matching rules for performing a match on relative dates in GeneralizedTime attributes, relativeTimeLTOrderingMatch and relativeTimeGTOrderingMatch, as defined here:

NAME ( 'relativeTimeLTOrderingMatch''' )
NAME ( 'relativeTimeGTOrderingMatch' '' )

The syntax applies to attributes with a GeneralizedTime syntax, but it does not take a generalized time string. Instead it takes an offset in the format of [+|-]number[unit] where:


Specifies a time in the past or future. A positive offset (+) computes a time in the future compared to the current time, and a negative offset (-) computes a time in the past compared to the current time. The default value is positive (+).


Specifies the number of time units as a positive integer


Specifies the time unit as a single letter, s, m, h, d, or w, for seconds, minutes, hours, days, or weeks

When processing the filter, the server computes the current GMT time, adds the offset and compares the attribute value with the new computed value.

The following example represents pwdExpirationTime >= (Now + 5 days).


Similarly, the following example represents pwdExpirationTime <= (Now + 5 days).


Partial Date Or Time Matching Rules

Oracle Unified Directory provides the partialDateAndTimeMatchingRule matching rule for performing a substring match on dates in GeneralizedTime attributes:

NAME 'partialDateAndTimeMatchingRule'

This matching rule applies to attributes with a GeneralizedTime syntax, but the value is not a generalized time. Instead, it specifies a pattern for the date, composed of one or more sequences of an integer followed by a tag. The currently supported tags are Y, M, D, h, m, and s .

The following examples use the attribute birthDate (described in with the following definition:

attributeTypes: ( NAME 'birthDate' 
DESC 'birthday' 
EQUALITY generalizedTimeMatch 
ORDERING generalizedTimeOrderingMatch
USAGE userApplications SINGLE-VALUE )

For example, the following filter matches all users born on September 21st.


As another example, the following filter matches all users born in 1965:


The following search operation returns all entries with a birthday the fourteenth day of any month:

$ ./ldapsearch -p 1389 -h localhost -D "cn=Directory Manager" -w password \
  -b "dc=example,dc=com" \
  "(birthDate:" birthDate

Value Normalization

One of the tasks that most matching rules need to perform is value normalization. This is the process of transforming a given value to a form that can be used to compare values efficiently. In most cases, the normalization process should reduce all logically equivalent values to the same string so that a very simple string comparison can be performed to determine whether the strings are equal. For example, the caseIgnoreMatch matching rule typically normalizes values by converting all characters to lowercase and replacing occurrences of multiple consecutive spaces with a single space. A more complicated example is the distinguishedNameMatch matching rule, which removes all unnecessary spaces (for example, around commas, equal signs, and plus signs), converts all attribute types to lowercase, and then uses the appropriate matching rules to normalize the attribute values for each RDN component.

Note that in some cases, normalization alone is not sufficient for determining whether two values are logically equivalent. This is particularly true for cases in which the value is transformed, and there can be multiple different transformations for the same value.