| Skip Navigation Links | |
| Exit Print View | |
|
Oracle Fusion Middleware Glossary for Oracle Unified Directory 11g Release 1 (11.1.1) |
| 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
entry change notification control
extensible match search filter
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
A database is a repository that is used for storing information. In the directory server, databases are used as the mechanism for storing data in a back end. The primary database used by the directory server is the Berkeley DB Java Edition, although it is possible to create other back ends with different backing stores.
The database cache is a portion of memory that is reserved for holding content from the underlying database. Whenever an attempt is made to retrieve information from the database, the database will first check this cache before going to disk. The database cache can help significantly improve performance by avoiding costly disk I/O.
The database cache may be used either instead of or in addition to the server's entry cache. The database cache frequently creates a more compact representation of the data (which means that more data can be held in the cache in systems with limited memory), but the entry cache generally holds data in a format that can be more efficiently used by the server.
The debug log provides a mechanism for obtaining information that may be used for debugging problems that might occur in the server. Debug information is generally data that is useful only in the event of a problem, and is frequently too voluminous to maintain under normal operations. The debug log may be used to report information like:
Detailed information about exceptions thrown within the server
Information about data read from or written to network clients
Information about information read from or written to the database
Information about decisions made in areas like access control or password policy processing
The LDAP delete operation can be used to remove an entry from the server (or when used in conjunction with the subtree delete control, a subtree). The delete request protocol op is defined as follows:
DelRequest ::= [APPLICATION 10] LDAPDN
The request includes only the DN of the entry to delete.
The response to an LDAP delete operation is an LDAP result element as defined below:
DelResponse ::= [APPLICATION 11] LDAPResult
A deprecated password storage scheme is a password storage scheme that is available for use in the server, but is intended primarily for transitional use. If a user has a password encoded with a deprecated storage scheme, then the user will be allowed to authenticate but the password will be re-encoded using the set of default storage schemes defined in the password policy.
This mechanism is primarily intended for cases in which data has been migrated into the directory server from another server uses a password storage scheme that you do not want to continue using (for example, because it is weaker than the default schemes). As users authenticate to the server, their passwords will be transitioned from the deprecated schemes to the default schemes.
The dereference policy is an element of a search quest that specifies how the server should handle alias entries that may be encountered during search processing. Allowed alias dereference policy values include:
The server should not attempt to dereference any aliases that it encounters during search processing.
The server should dereference any entries within the scope of the search operation to determine whether they match the search criteria. The entry specified as the search base DN will not be dereferenced.
The server should dereference the entry referenced as the search base DN if it is an alias, but any other alias entries within the scope of the search operation will not be dereferenced.
The server will dereference any alias entries within the scope of the search operation and will also dereference the base entry if it is an alias.
The DIGEST-MD5 SASL mechanism provides a way for clients to authenticate to the Directory Server with a username and password in a manner that does not expose the clear-text password, so it is significantly safer than simple authentication or the PLAIN SASL mechanism when the connection between the client and the server is not secure.
The DIGEST-MD5 SASL mechanism is described in RFC 2831, but a revised specification is contained in draft-ietf-sasl-rfc2831bis. The process is as follows:
The client sends an LDAP message to the server with a bind request protocol op type using an authentication type of SASL with a mechanism name of DIGEST-MD5 and no credentials.
The server sends a bind response message back to the client with a result code of 14 (SASL bind in progress) and a server SASL credentials element including, among other things, some randomly-generated data (the nonce).
The client takes the nonce provided by the server, and some randomly generated data of its own (the cnonce), an authentication ID, an optional authorization ID, the user's clear-text password, and some other information and uses that to create an MD5 digest. The client then sends a second bind request message including that digest and some other clear-text information back to the server.
The server uses the authentication ID to identify the user, and then retrieves the clear-text password for that user (if the clear-text password cannot be obtained, then authentication will fail) and uses it to determine whether the provided digest is valid. The server will then send an appropriate response to the client (usually with a result of either success or invalid credentials) indicating whether the authentication was successful.
If the client requested a quality of protection (QoP) value indicating that the connection should be protected with integrity and/or confidentiality, then the server will initiate the necessary negotiation with the client. Note that at the present time, the directory server does not support the use of the DIGEST-MD5 mechanism with the use of integrity or confidentiality protection.
The DIGEST-MD5 SASL mechanism is very similar to CRAM-MD5, but it is somewhat strong because CRAM-MD5 includes only random data from the server whereas DIGEST-MD5 includes random data from both the client and the server. DIGEST-MD5 also provides a provision for ensuring connection integrity and/or confidentiality, which CRAM-MD5 does not offer.
The directory information tree, or DIT, refers to the hierarchical structure of the data in a Directory Server. The DIT contains one or more naming contexts, which are the base entries for the server, and every other entry is descended from one of those naming context entries. That is, a naming context entry is special in that it does not have a parent entry.
Consider a scenario, where the entry dc=example,dc=com is the naming context, and it has two immediate children, with DNs of ou=People,dc=example,dc=com and ou=Groups,dc=example,dc=com, respectively, and each of those entries has its own subordinate entries. There is no predefined limit to the maximum depth of a directory tree, and any entry can potentially have one or more subordinate entries. An entry that does not contain any subordinates is said to be a leaf entry, and any entry that has at least one subordinate entry is called a non-leaf entry.
The term directory manager is a common name used to refer to a root DN user in the Directory Server. It is so named because the default root user typically uses a bind DN of cn=Directory Manager. Unlike many other types of directory servers, the directory server allows multiple root DNs to be defined, although the default root DN is still cn=Directory Manager.
A directory server is a type of network daemon that stores data in a manner accessible to external clients. Directory servers typically use LDAP or DSML for communicating with clients, although some servers use other protocols like DAP or NDS.
Directory servers store data in a hierarchical form (called the directory information tree) and provide the ability for clients to interact with that information, including:
search operations, which make it possible to find all entry matching a given set of criteria
add operations, which make it possible to add new entries to the server
delete operations, which make it possible to remove entries from the server
modify operations, which make it possible to update existing information in the server
modify DN operations, which make it possible to rename entries in the server
bind operations, which make it possible to authenticate users to the server
compare operations, which make it possible to determine whether entries have a particular attribute-value pair
The directory server uses LDAPv3 for communicating with network clients, and provides a DSML gateway that can be used to handle DSML requests.
A directory server agent (DSA) is a single instance of a directory server.
The Directory Services Markup Language (DSML) is a protocol that may be used to communicate with directory servers. DSML is an alternative to LDAP, and uses an XML-based representation of requests and responses instead of the ASN.1 BER encoding that LDAP uses.
In general, DSML is seen as a relatively weak alternative to LDAP because it provides very little benefit and incurs a significant cost because the XML representation is much more verbose and expensive to process when compared with the BER encoding that LDAP uses. In most cases, it is recommended that LDAP be used instead of DSML to interact with the server.
A distinguished name (often referred to as a DN) is a string that uniquely identifies an entry in the Directory Server. It consists of zero or more relative distinguished name (RDN) components that identify the location of the entry in the DIT. An entry's distinguished name can be thought of as a kind of an analog to an absolute path in a filesystem in that it specifies both the name and hierarchical location.
The RDN components for a distinguished name are separated by commas and are ordered from right to left. The rightmost components of a DN are closest to the server's naming context, and the leftmost components are closest to the leaf entry. That is, if you think of a directory hierarchy as a kind of pyramid with the naming context at the top and the branches descending downward, then the order of RDN components in a DN are listed from bottom to top.
Even though a DN consists of a series of RDN components, when one refers to an entry's RDN, then it is a reference to the leftmost RDN component. The attributes contained in an entry's RDN must also be contained in that entry.
In a DIT, the top entry is the naming context and its DN is dc=example,dc=com. To conserve space, only the RDNs of the subordinate entries are displayed, but the full DNs can be obtained by appending the RDN components from bottom to top. For example, the DN of the leftmost entry on the bottom row would be uid=ann,ou=People,dc=example,dc=com.
See RFC 4514 for more information about LDAP distinguished names and the way in which they should be represented as strings.
Distribution is a Oracle Unified Directory proxy deployment type in which data is split into partitions. The split of data is determined by a distribution algorithm.
See directory information tree.
A DIT content rule is a schema element that specifies which auxiliary object classes are allowed to be used with an entry, as well as which attribute types are required, allowed, and prohibited for use with an entry, based on its structural object class.
The components of a DIT content rule definition include:
The numeric OID of the structural object class with which the DIT content rule is associated.
An optional set of names for the DIT content rule.
An optional set of auxiliary object class names or OIDs for the auxiliary classes that are allowed to be used with entries containing the associated structural class.
An optional set of attribute type names or OIDs for attribute types that are required to be present in entries with the associated structural class. These attributes will be required even if they are not allowed by any of the object classes in the entry.
An optional set of attribute type names or OIDs for attribute types that may optionally be present in entries with the associated structural class. These attributes will be allowed even if they are not allowed by any of the object classes in the entry.
An optional set of attribute type names or OIDs for attribute types that are prohibited to be present in entries with the associated structural class. These attributes will be prohibited even if they are allowed by any of the object classes in the entry.
The set of DIT content rules defined in the server may be determined by retrieving the dITContentRules attribute of the subschema subentry. For more information about DIT content rules, see Understanding DIT Content Rules in Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory.
A DIT structure rule is a schema element that may be used to define the hierarchical relationships between entries. In particular, it defines the kinds of parent entries (based on their structural object class) that an entry with a given structural class is allowed to have.
The components of a DIT structure rule definition include:
An integer rule ID value that is used to uniquely identify the rule.
An optional set of names for the DIT structure rule.
The name or OID of the name form with which the DIT structure rule is associated. The name form in turn links the DIT structure rule to a structural object class.
An optional set of superior rule IDs. If a set of superior rules is defined, then they are used to define the structural classes below which the structural class associated with the rule's name form is allowed to exist.
The set of DIT structure rules defined in the server may be determined by retrieving the dITStructureRules attribute of the subschema subentry. For more information about DIT structure rules, see the Understanding DIT Structure Rules in Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory.
See distinguished name.
A DSA-Specific Entry (DSE) is a special type of entry that provides information about a directory server agent (DSA), which is a synonym for directory server.
LDAP defines a special entry called the root DSE that provides information about the information contained in the server and the types of operations that it supports.
See DSA-specific entry.
See Directory Services Markup Language.
A DSML gateway (or DSML-to-LDAP gateway) is a special type of network daemon that is used to translate between DSML and LDAP. In general, a DSML gateway accepts DSML requests from clients, converts them to LDAP requests that it forwards to a directory server for processing. It then translates the LDAP response from the directory server back to DSML to return to the client.
The directory server supports DSML through a DSML gateway, which is implemented as a Web application that can run in an application server.
Certain configuration properties take a duration as their allowed value.
A duration includes an integer, and a unit, specified in weeks (w), days (d), hours (h), minutes (m), seconds (s), or miliseconds (ms), or some combination with multiple specifiers. For example, you can specify one week as 1w, 7d, 168h, 10080m, or 604800s. Or you can specify ten and a half days as 1w3d12h0m0s.
Not all properties that require a duration support all duration specifiers (w, d, h, m, s, and ms).
A duration property can also include the following:
Specifies the minimum granularity that can be used to specify duration property values. For example, if the base unit is in seconds, values represented in milliseconds are not permitted.
Specifies the largest duration unit that can be used to specify duration property values. Values presented in units greater than this unit are not permitted.
Specifies the smallest duration permitted by the property.
Specifies the largest duration permitted by the property.
Certain properties allow you to specify an unlimited duration. This is represented using the decoded value, -1, or the encoded string value unlimited.
A dynamic group is a type of group in the directory server that defines its membership using a set of search criteria in the form of an LDAP URL, as opposed to a static group in which the DNs of the members are explicitly specified.
Dynamic groups provide an efficient way to manage groups with very large numbers of members. They are much more scalable than static groups, and their membership is automatically updated as entries change so that the match or no longer match the group criteria.
|