M

MakeLDIF command

The MakeLDIF command provides a mechanism for generating entry in LDIF form. The entries will be generated based on a template containing a number of tags that can be used to control the way that the data is generated.

See make-ldif in Oracle Fusion Middleware Command-Line Usage Guide for Oracle Unified Directory for information on using this command. Creating MakeLDIF Template Files in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory describes the valid structure and content for MakeLDIF template files.

manage DSA IT control

The Manage DSA IT control is a type of control that can be used to request that the server treat smart referral as regular entries. It can be attached to a delete operation, modify operation, or modify DN operation operation to request that the server apply the operation to the entry containing the smart referral rather than sending the referral back to the client. It may also be attached to a search operation to indicate that the server should return the entries containing the smart referrals as search result entry rather than search result reference.

The Manage DSA IT control is defined in RFC 3296. It has an OID of 2.16.840.1.113730.3.4.2 with no value.

For an example of using this control in a search request, see To Search Using the Manage DSA IT Control in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.

matched DN

A matched DN is an element of an LDAP result object that can provide additional information about the closest matching entry found in the server. It is generally used when a request targets an entry that does not exist, in which case the matched DN should contain the distinguished name of an entry that does exist in the server and is the closest ancestor of the specified entry. For example, if an operation targeted an entry uid=doesnt.exist,ou=People,dc=example,dc=com that did not exist but the entry ou=People,dc=example,dc=com does exist in the server, then that may be returned as the matched DN.

There is no guarantee that a matched DN is returned from an operation targeting an entry that does not exist, in which case the matched DN element of the LDAP result will be an empty string. This may be used, for example, if the request targeted an entry that does not have any hierarchical relationship with any other entry in the server.

matched values control

The matched values control is a type of control that can be attached to a search operation to indicate that only values matching a specified filter should be included in entries returned to the client. It is described in RFC 3876.

The request control should have an OID of 1.2.826.0.1.3344810.2.3. The value should be encoded as follows:

          ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem

          SimpleFilterItem ::= CHOICE { 
               equalityMatch   [3] AttributeValueAssertion,
               substrings      [4] SubstringFilter,
               greaterOrEqual  [5] AttributeValueAssertion,
               lessOrEqual     [6] AttributeValueAssertion,
               present         [7] AttributeDescription,
               approxMatch     [8] AttributeValueAssertion,
               extensibleMatch [9] SimpleMatchingAssertion }

          SimpleMatchingAssertion ::= SEQUENCE {
               matchingRule    [1] MatchingRuleId OPTIONAL,
               type            [2] AttributeDescription OPTIONAL,
--- at least one of the above must be present
               matchValue      [3] AssertionValue}

There is no corresponding response control.

For an example of using this control in a search request, see To Search Using the Matched Values Filter Control in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.

matching rule

A matching rule is a schema element that defines how the server should interact with values of an attribute. There are three standard types of matching rules:

• Equality matching rules are used to determine whether one attribute value is equal to another. This determination is generally made based on the normalized value, and ignores insignificant differences (for example, differences in capitalization or extra spaces).

• Ordering matching rules are used to determine the relative order between two values in a sorted list. This is used when performing server-side sort control, but it is also used for greater than or equal to search filter and less than or equal to search filter filter components.

• Substring matching rules are used to determine whether a value contains a given substring search filter.

In addition to these standard matching rules, the directory server defines a fourth type, approximate matching rules, which are used to determine whether one value is approximately equal to another. The definition of “approximately equal to” can vary, but one common use is “sounds like”.

Common examples of matching rules include:

booleanMatch

An equality matching rule that determines whether two Boolean values are equal to each other.

caseExactMatch

An equality matching rule that determines whether two string values are equal to each other, without ignoring differences in capitalization.

caseExactOrderingMatch

An ordering matching rule that is used to determine the relative order between two string values, without ignoring differences in capitalization.

caseExactSubstringsMatch

A substring matching rule that is used to determine whether a string value contains a given substring, without ignoring differences in capitalization.

caseIgnoreMatch

An equality matching rule that determines whether two string values are equal to each other, ignoring differences in capitalization.

caseIgnoreOrderingMatch

An ordering matching rule that is used to determine the relative order between two string values, ignoring differences in capitalization.

caseIgnoreSubstringsMatch

A substring matching rule that is used to determine whether a string value contains a given substring, ignoring differences in capitalization.

distinguishedNameMatch

An equality matching rule that determines whether two distinguished name are equal to each other, ignoring extra spaces around commas separating RDN components and equal signs separating RDN names from values. The individual RDN values will be compared based on the matching rules associated with the corresponding RDN attributes.

generalizedTimeMatch

An equality matching rule that determines whether two generalized time values are equal to each other.

generalizedTimeOrderingMatch

An ordering matching rule that is used to determine the relative order between two generalized time values.

integerMatch

An equality matching rule that determines whether two integer values are equal to each other.

integerOrderingMatch

An ordering matching rule that is used to determine the relative order between two integer values.

octetStringMatch

An equality matching rule that determines whether two values are exactly equal to each other using a byte-for-byte comparison.

In most cases, the directory server will use matching rules in a completely “behind the scenes” manner without the client needing to know about it. Whenever the client references a given attribute type, then the server will automatically know to use the appropriate matching rules for that attribute. However, it is also possible for the client to request that the server use a specific matching rule when performing an operation through the use of an extensible match filter.

The set of matching rules defined in the server may be determined by retrieving the matchingRules attribute of the subschema subentry. For more information about matching rules, see Understanding Matching Rules in Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory.

matching rule use

A matching rule use is a schema element that can be used to determine which attribute type can be used in conjunction with a given matching rule. Note that this only applies when using extensible match filters.

A matching rule use definition includes an OID for the matching rule that it applies to and a list of the names or OIDs of the attribute types that may be used in conjunction with that matching rule. If an attribute is not included in this list, then it cannot be used in conjunction with the associated matching rule. If there is no matching rule use defined for a given matching rule, then it should be assumed that the matching rule can be used with any attribute type.

The set of matching rule uses defined in the server may be determined by retrieving the matchingRuleUse attribute of the subschema subentry. For more information about matching rule uses, see Understanding Matching Rule Uses in Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory document.

MD5

MD5 is a one-way message digest algorithm defined in RFC 1321. It can be used to encode a value of an arbitrary length into a 128-bit value that cannot be reversed to determine the original cleartext. It is commonly used as a mechanism for checksumming data, and it is also commonly used for encoding passwords and other sensitive information.

Note that recent advances in cryptography have discovered weaknesses in the MD5 algorithm. These discoveries do not directly impact the security of the way that the MD5 algorithm is used by the directory server, but nevertheless it may be wise to use a stronger mechanism like the Secure Hash Algorithm.

message

See LDAP message.

message ID

The message ID is an integer value that is contained in the message and is used to correlate request and response messages. The client chooses a message ID value to include in the request message, and the server will use the same message ID in all response messages. This makes it possible for the client to have multiple requests in progress on the same connection at any given time. All requests in progress at any given time must have different message IDs. The client will typically keep a sequentially-increasing counter for all request messages so that each request gets a different message ID than the last.

Note that unsolicited notification messages will always have a message ID value of zero. All other LDAP messages should have a message ID value between 1 and 2147483647.

modification

A modification is an element of an LDAP modify operation that describes a change to a single attribute. A modify request may include one or more modifications to the target entry.

A modification consists of a modification type that describes the type of change (add, delete, replace, or increment), and the attribute including the attribute description and zero or more attribute values.

modification type

A modification type describes one of the four ways in which an attribute can have its attribute value altered in a modification. The defined modification types are:

add

One or more values are to be added to the target attribute. If the attribute does not exist in the target entry, then it will be added with the given values; otherwise the provided values will be appended to the set of values already defined for that attribute. An add modification type must always supply at least one value.

delete

One or more values are to be removed from the target attribute, or that attribute is to be removed entirely from the target entry. If one or more specific values are given, then only those values are to be removed from the target attribute (and if they represent the entire set of values for that attribute, then that attribute will be removed from the entry). If no values are given, then the entire attribute (regardless of the number of values it contains) is to be removed from the entry.

replace

The set of values for the target attribute should be replaced with the given set of values. A replace can have zero or more values, and the behavior is as follows:

• If the target attribute already exists in the entry with one or more values, and the replace modification does not have any of its own values, then the target attribute will be removed from the entry.

• If the target attribute already exists in the entry with one or more values, and the replace modification has one or more of its own values, then the existing set of values will be replaced with the new set of values.

• If the target attribute does not exist in the entry and the replace modification does not have any of its own values, then no action will be taken.

• If the target attribute does not exist in the entry and the replace modification has one or more of its own values, then the attribute will be created in the entry with the specified set of values.

increment

The value of the target attribute should be incremented by the specified amount. The target attribute must exist in the entry with exactly one value, and that value must be an integer. The increment modification must also include exactly one value and that value must be an integer. The existing value is to be incremented by an amount specified by the increment value. If the increment value is negative, then the existing value will be deprecated by an amount equal to the absolute value of the increment value.

modify DN operation

See LDAP modify DN operation.

modify operation

See LDAP modify operation.

monitor entry

A monitor entry is a type of entry in the server that provides information about a server component. It may provide statistical information for performance monitoring, information about the health of the server, or other information that could be of value.

The directory server provides a general-purpose monitor entry with a distinguished name of cn=monitor. A number of other monitor entries exist below that point, including:

• Information about each back end configured in the server

• Information about each connection handler configured in the server

• General information about the system on which the server is running

• Information about the state of the server work queue

• Version information for the server

• A stack trace of all threads currently active in the server