Skip Navigation Links | |
Exit Print View | |
Oracle Fusion Middleware Glossary for Oracle Unified Directory 11g Release 1 (11.1.1) |
access control instruction (ACI)
authentication password syntax
authorization identity control
Common Development and Distribution License
deprecated password storage scheme
Directory Services Markup Language
greater than or equal to search filter
less than or equal to search filter
Lightweight Directory Access Protocol
notice of disconnection unsolicited notification
Password Modify extended operation
Simple Authentication and Security Layer
virtual attributes only control
An entry is the structure that holds information in a directory server. It consists of the following components:
A distinguished name that uniquely identifies the entry among all other entries in the server.
A collection of object class values that are used to govern the contents of the entry.
A collection of attribute that contain the actual data for the entry.
An entry must always have exactly one structural object class that defines what type of entry it is. It may have zero or more auxiliary object classes that may be used identify other characteristics for the entry. Together, the structural and auxiliary classes define a set of required attributes, which must be present in the entry, and optional attributes, which may be included in the entry but are not required.
The entry cache is a mechanism that uses system memory for holding entries in a manner that may be quickly accessed so that it is not necessary to decode them from the database whenever they are needed. Entry caching mechanisms are particularly effective when used with applications that access the same entry multiple times in a sequence of operations. For example, an application which first searches to find a user entry and then binds as that user to verify a password, which is a very common usage pattern.
The entry cache may be used either instead of or in addition to the server's database cache. The database cache generally uses a more compact representation of the data, but the entry cache generally holds data in a format that can be more efficiently used by the server.
Unlike the database cache which is maintained by the underlying database, the entry cache is managed by the directory server itself. There are a number of different entry cache implementations that may be used.
The entry change notification control is a control that is included in search result entries returned to clients in response to a search operation that uses the persistent search control. This control contains additional information about the change made to the entry, including the type of change made, the change number (which corresponds to an item in the server's change log, if the server supports a change log), and, if the entry was renamed, the old DN of the entry. The control is described in draft-ietf-ldapext-psearch-03 and has an OID of 2.16.840.1.113730.3.4.7.
The control is defined as follows:
EntryChangeNotification ::= SEQUENCE { changeType ENUMERATED { add (1), delete (2), modify (4), modDN (8) }, previousDN LDAPDN OPTIONAL, -- modifyDN ops. only changeNumber INTEGER OPTIONAL -- if supported }
An entryDN is an operational attribute that provides a copy of the entry's current DN. Because a DN is not an attribute of the entry, it cannot be used to perform attribute value assertions. The entryDN provides a mechanism to access an entry's DN and is described in RFC 5020.
An entry ID is an integer value that is used to uniquely identify an entry in the Directory Server back end. Although the entry's distinguished name could be used for this purpose, the numeric entry ID is much more compact and more efficient to decode, so it is more appropriate for widespread use.
The entry ID is used as the key to the actual entry data in the id2entry database, and it is used in ID lists to identify entries matching the associated index key.
An entryUUID is a universally unique identifier that is contained in the entryUUID operational attribute and is assigned to each entry in the directory server. It is defined in RFC 4530 and it is intended to be a unique identifier that will not change over the life of the entry (as opposed to the distinguished name, which can change as a result of a modify DN operation). Because of the greater stability of the entryUUID, it is used by the replication subsystem to track entries even if the DN does change.
An equality index is a type of indexwhich is used to identify efficiently which entries are exactly equal to a given assertion value. An equality index may only be maintained for attributes that have a corresponding equality matching rule. That matching rule will be used to normalize values to use as index keys, and the value for that key will be the ID list containing the entry IDs of the entries with values that are equal to that normalized value.
An equality search filter is a type of search filter that can be used to identify entries that contain a specific value for a given attribute. The server will use an equality matching rule to make the determination.
The string representation of an LDAP equality filter comprises an opening parenthesis followed by the attribute name, an equal sign, the attribute value, and the closing parenthesis. For example, an equality filter of (uid=john.doe) will match any entry in which the uid attribute contains a value of john.doe.
The error log provides a mechanism for reporting errors, warnings, and other significant events that happen in the life of the server. Each message written to the error log will include a category (indicating the area of the server in which the message was generated) and severity (indicating the relative importance of the message), along with an integer value that uniquely identifies the associated message string.
See LDIF export.
The LDAP extended operation provides a degree of extensibility to the LDAP protocol by allowing clients to request operations not defined in the core protocol specification. Examples of LDAP extended operations include:
This operation may be used to cancel a previously-requested operation.
This operation may be used to change a user password.
This operation may be used to initiate a secure communication channel over an existing connection.
This operation may be used to determine the authorization identity associated with the client connection.
The extended request protocol op is defined as follows:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL }
The elements of the extended request include:
The OID that is used to indicate the type of operation to perform.
An optional value containing additional information to use during the course of processing the request.
The response to an LDAP extended operation is defined as follows:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] LDAPOID OPTIONAL, responseValue [11] OCTET STRING OPTIONAL }
The extended response includes these elements:
The elements of the LDAP result object.
An optional OID used to indicate the type of response.
An optional encoded value with additional information to include in the response.
An extensible match index is a type of index that is used to help accelerate search operations using an extensible match filter. Index keys are values that have been normalized using a specified matching rule, and the corresponding ID list contains the entry IDs for all entries that match the value according to that matching rule.
An extensible match search filter is a type of search filter that can be used to identify matching entries using a specified matching rule.
An extensible matching filter contains the following components:
The OID of the matching rule to use for the determination. This is an optional element, and if it isn't provided then the attribute type must be given and its default equality matching rule will be used.
The name of the attribute type that will be targeted. If this is not provided, then all attributes contained in the entry will be examined.
A flag that indicates whether the matching should be performed against the attributes of the entry's DN and the attributes contained in the entry.
An assertion value that should be used as the target for the matching rule.
The string representation of an LDAP extensible match filter comprises the following components in order:
An opening parenthesis
The name of the attribute type, or an empty string if none was provided
The string :dn if the dnAttributes flag is set, or an empty string if not
If a matching rule ID is available, then a string composed of a colon followed by that OID, or an empty string if there is no matching rule ID
The string :=
The string representation of the assertion value
A closing parenthesis
The EXTERNAL SASL mechanism provides a way for clients to authenticate to the Directory Server using information that is available outside of the communication performed at the LDAP protocol level. The most common use of EXTERNAL authentication (and at present, the only form that the directory server supports) is for the server to identify the client based on a certificate that the client presented during SSL or StartTLS negotiation. The Directory Server will use a certificate mapper to map the client's certificate to a user in the directory, and may optionally perform additional validation (for example, ensuring that the presented certificate actually exists in the user's entry).