| 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
deprecated password storage scheme
Directory Services Markup Language
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
virtual attributes only control
A salt is a collection of random data that may be combined with clear-text data (often a password) that can be used to change the way that it is encoded. In particular, the salt is used to introduce randomness into the encoding process to help thwart dictionary attacks. In general, the salt is appended to the clear-text password, which is the encoded using the desired message digest algorithm, and then the clear-text salt is appended to the message digest and the resulting value is base64 encoded. This makes it possible to determine what the salt was so that it can be used to determine whether a user-supplied password is correct.
The UNIX crypt algorithm uses a relatively weak 12-bit salt, which means that there are only 4096 ways of encoding any value. This is a relatively low number, and therefore it is possible to construct dictionaries of every possible encoding for a wide range of values for use in breaking user passwords. Other password storage schemes in the directory server use a 64-bit salt which provide 18446744073709551616 different ways of encoding any one value.
A proxy load balancing algorithm in which client requests are routed to a priority remote LDAP server. When the main remote LDAP server reaches its saturation threshold, the requests are routed to a secondary remote LDAP server.
The limit at which a notification is sent to the administrator to indicate that the remote LDAP server is overloaded. Usually, the saturation alert is set higher than the saturation threshold.
The saturation threshold is the limit at which the data source is considered overloaded and can no longer handle incoming requests in an optimal way. The saturation threshold is used as part of the proxy saturation algorithm.
The schema of a Directory Server defines a set of rules that govern the kinds of information that the server can hold. Directory schema includes a number of different elements, including:
Provide information about the kind of information that can be stored in an attribute.
Provide information about how to make comparisons against attribute values.
Indicate which attribute types may be used in conjunction with a particular matching rule.
Define an OID and a set of names that may be used to refer to a given attribute, and associates that attribute with a syntax and set of matching rules.
Define named collections of attributes and classify them into sets of required and optional attributes.
Define rules for the set of attributes that should be included in the RDN for an entry.
Define additional constraints about the object classes and attributes that may be used in conjunction with an entry.
Define rules that govern the kinds of subordinate entries that a given entry may have.
Attributes are the elements responsible for storing information in a directory, and the schema defines the rules for which attributes may be used in an entry, the kinds of values that those attributes may have, and how clients may interact with those values.
Clients may learn about the schema elements that the server supports by retrieving an appropriate subschema subentry.
Schema checking is the process of ensuring that an entry conforms to the constraints defined by the server schema. This includes:
Make sure the entry contains exactly one structural object class.
If there is a name form for the entry's structural class, ensure that the RDN attributes conform with that name form.
If there is a DIT content rule for the entry's structural class, make sure that all of the auxiliary classes are defined.
Make sure that all of the object classes contained in the entry are defined in the schema.
Make sure that all of the attribute contained in the entry are defined in the schema and allowed by the object classes and/or DIT content rule.
Make sure that all attributes required by the entry's object classes and/or DIT content rule are present.
Make sure that all single-valued attributes contained in the entry only have one value.
Make sure that the entry's position in the directory information tree conforms with DIT structure rule definitions.
The search attributes element of a search operation provides a way of representing the attribute that should be included in search result entry. In general, the set of search attributes is a list of zero or more attribute description for the attributes to return. If values are specified, then all user attribute and no operational attribute will be returned.
In addition to specific attribute descriptions, a number of special values can be provided with various meanings:
The string 1.1 indicates that no attributes should be included in matching entries.
The string * (the asterisk) indicates that all user attributes should be included in matching entries. This is needed if the server returns all user attributes in addition to one or more operational attributes.
The string + (the plus sign) indicates that all operational attributes should be included in matching entries.
An object class name can be provided, prefixed with the @ character. This indicates that all attributes referenced by that object class should be included in matching entries.
The search base DN is an element of the search operation that works in conjunction with the search scope to define the subtree of entries that should be considered when processing the search operation. Only entries at or below the search base DN and within the scope will be considered candidates for matching against the search filter.
See LDAP search filter.
The LDAP search operation can be used to identify entries in the Directory Server that match a given set of criteria. It may return zero or more entries, and also zero or more referrals.
The search request protocol op is defined as follows:
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2),
... },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeSelection }
The elements of the search request include:
The search base DN, which specifies the location in the directory information tree in which to perform the search.
The search scope, which specifies the scope of entries at or below the base DN to consider when processing the search.
The dereference policy to use if any aliases are encountered during processing.
The size limit, which specifies the maximum number of entries that should be returned from the search (or zero if there should not be any maximum number of entries).
The time limit, which specifies the maximum length of time in seconds that the server should spend processing the search (or zero if there should not be a maximum number of entries).
The typesOnly flag, which indicates whether the entries returned should include attribute types only or both types and values.
The search filter, which specifies the criteria to use to identify matching entries.
The search attributes that indicate which attributes should be included in matching entries, or an empty list to indicate that all user attribute should be returned.
There are three types of result elements that can be returned in response to a search request: zero or more search result entry, zero or more search result reference, and exactly one search result done message. The entries and references can be returned in any order (and with search entries and references interspersed), and the search result done message will come last to indicate that there are no more results.
The search result entry protocol op is defined as follows:
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF
partialAttribute PartialAttribute
Each search result entry includes the DN of the entry and zero or more attributes (potentially including only the attribute type names without the values if the typesOnly element of the request is true) as defined in the search attribute list.
The search result reference protocol op is defined as follows:
SearchResultReference ::= [APPLICATION 19] SEQUENCE
SIZE (1..MAX) OF uri URI
Each search result reference includes one or more LDAP URL specifying an alternate location in which the client may search for additional matching entries.
The search result done message is an LDAP result defined as follows:
SearchResultDone ::= [APPLICATION 5] LDAPResult
A search result done message is a message provided as part of a search operation to indicate that the search has completed and that there will be no more search result entry or search result reference messages.
A search result entry is an entry returned as part of a search operation. It will contain at least the distinguished name of the entry, and can contain zero or more attributes. The attributes can contain only attribute type names or both types and values (based on the value of the typesOnly flag from the search request). The attributes returned can be based on the search attributes from the client request, but can be pared down based on the server's access control configuration.
A search result reference provides a mechanism for returning information to clients as part of a search operation that indicates an alternate location in which the client may perform the search to locate additional matching entries. The alternate locations will be specified in the form of LDAP URLs.
The LDAP search scope indicates the set of entries at or below the search base DN that may be considered potential matches for a search operation.
There are four defined search scope values:
This specifies that the search operation should only be performed against the entry specified as the search base DN. No entries below it will be considered.
Consider a scenario of DIT, which has a baseObject scope with a search base DN of dc=example,dc=com.
This specifies that the search operation should only be performed against entries that are immediate subordinates of the entry specified as the search base DN. The base entry itself is not included, nor are any entries below the immediate subordinates of the search base entry.
This specifies that the search operation should be performed against the entry specified as the search base and all of its subordinates to any depth.
This specifies that the search operation should be performed against all subordinate entries below the search base to any depth, but the search base entry itself should not be included.
The Secure Hash Algorithm (SHA) is a one-way message digest algorithm. There are actually two different forms of the Secure Hash Algorithm:
SHA-1 is defined in RFC 3174 and generates a 160-bit digest.
SHA-2 is defined in RFC 4634 and can be used to generate 256-bit, 384-bit, or 512-bit digests.
All forms of the Secure Hash Algorithm are considered stronger than the MD5 algorithm. There have been recent advancements that may indicate a weakening of the SHA-1 variant, but nevertheless there is no evidence to suggest that the way it is used in the directory server is under any danger, nor is there any concern about any of the SHA-2 encodings.
The Secure Sockets Layer (SSL) is a mechanism for wrapping network communication in a security layer that can be used to encrypt communication between the client and the server. It also provides an integrity mechanism to ensure that the communication is not altered between the client and the server. The encryption is based on cryptography using certificate.
SSL was originally a proprietary protocol developed by Netscape Communications. It has since been standardized, but the name has been changed to Transport Security Layer. Nevertheless, SSL is still a commonly-used term to refer to this capability, and it is the term used throughout the directory server in order to avoid confusion with the StartTLS extended operation.
The server-side sort control is a type of control that can be attached to a search operation to request that the results be sorted before they are returned to the client. It is defined in RFC 2891.
The request control has an OID of 1.2.840.113556.1.4.473 and the value is encoded as follows:
SortKeyList ::= SEQUENCE OF SEQUENCE {
attributeType AttributeDescription,
orderingRule [0] MatchingRuleId OPTIONAL,
reverseOrder [1] BOOLEAN DEFAULT FALSE }
For an example of using this control in a search request, see To Search Using the Server-Side Sort Control in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
The response control has an OID of 1.2.840.113556.1.4.474 and its value is encoded as follows:
SortResult ::= SEQUENCE {
sortResult ENUMERATED {
success (0), -- results are sorted
operationsError (1), -- server internal failure
timeLimitExceeded (3), -- timelimit reached before
-- sorting was completed
strongAuthRequired (8), -- refused to return sorted
-- results via insecure
-- protocol
adminLimitExceeded (11), -- too many matching entries
-- for the server to sort
noSuchAttribute (16), -- unrecognized attribute
-- type in sort key
inappropriateMatching (18), -- unrecognized or
-- inappropriate matching
-- rule in sort key
insufficientAccessRights (50), -- refused to return sorted
-- results to this client
busy (51), -- too busy to process
unwillingToPerform (53), -- unable to sort
other (80)
},
attributeType [0] AttributeDescription OPTIONAL }
Simple authentication is the process of authentication to the Directory Server using a distinguished name and password. This is done using an bind operation (and when the bind is performed using simple authentication, it is often called a “simple bind”). The client uses the provided DN to identify itself to the server, and the password is used to verify that the client is who it claims to be.
Note that simple authentication does not protect the password in any way, and therefore it is generally recommended that it only be used over a secure communication channel like that provided by Secure Sockets Layer or StartTLS.
The Simple Authentication and Security Layer (SASL) is an extensible framework that is primarily used for authentication users, but in some cases it may also be used for protecting the underlying communication channel. The core functionality of SASL is described in RFC 4422, but a number of SASL mechanisms are described in other specifications.
The SASL mechanisms supported by the directory server include:
This mechanism doesn't actually authenticate users to the server, but can be used to destroy a previous authentication session.
This mechanism provides a way for users to authenticate to the server using a password in a manner that does not expose the password itself. It is similar to, but weaker than, the DIGEST-MD5 SASL mechanism, and doesn't provide any way for ensuring connection integrity or confidentiality.
This mechanism provides a way for users to authenticate to the server using a password in a manner that does not expose the password itself. It is similar to, but stronger than, the CRAM-MD5 SASL mechanism, and also provides a way to ensure connection integrity and/or confidentiality.
This mechanism provides a way for users to authenticate to the server using information available outside of the LDAP communication that has been performed (for example, the certificate that a client presented when performing SSL or StartTLS negotiation).
This mechanism provides a way for users to authenticate to the server using a Kerberos V5 session. It also provides a mechanism that can be used to ensure connection integrity and/or confidentiality.
This mechanism provides a way for users to authenticate to the server with a username and password. It is similar to the protection offered by simple authentication, but may be more convenient in that users can identify themselves with a username rather than a distinguished name.
The simple paged results control is a type of control that can be attached to a search operation to indicate that only a subset of the results should be returned. It may be used to iterate through the search results a page at a time. It is similar to the virtual list view control with the exception that it doesn't require the results to be sorted and can only be used to iterate sequentially through the search results.
The simple paged results control is defined in RFC 2696. The same control is used in both the search request and search result done messages. It has an OID of 1.2.840.113556.1.4.319, and the value is encoded as follows:
realSearchControlValue ::= SEQUENCE {
size INTEGER (0..maxInt),
-- requested page size from client
-- result set size estimate from server
cookie OCTET STRING
}
For an example of using this control in a search request, see To Search Using the Simple Paged Results Control in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
The server size limit is a configuration option that controls the maximum number of entries that may be returned from any single search operation. This is a server-wide setting and may be overridden by a per-user configuration in the ds-rlim-size-limit operational attribute in the user's entry.
The server size limit (or per-user value) may also be restricted by the size limit element in the search request message.
A smart referral is a special type of entry that can be placed in the directory information tree that reference content in another server and/or location of the DIT. Smart referral entries contain the referral object class with one or more instances of the ref attribute containing LDAP URLs that should be used in the referral.
The StartTLS extended operation is a type of extended operation that can be used to initiate a TLS-secured communication channel over an otherwise clear-text connection. It allows clients to use the same network port for both secure and insecure communication.
The StartTLS extended operation is defined in RFC 4511 and further described in RFC 4513. It uses an OID of 1.3.6.1.4.1.1466.20037 with no value. The response includes an OID of 1.3.6.1.4.1.1466.20037 (the same as the request OID) with no value.
A static group is a type of group in the directory server that defines its membership by providing an explicit set of distinguished name of the entry that are members of the group.
Static groups are very well supported by external clients, but are not as scalable as dynamic groups when handling large numbers of members.
A structural object class is one of the primary object class types. A structural object class is special in that it defines the core type for any entry that contains it. An entry must have exactly one structural class (although that structural class may inherit from other structural or abstract classes).
The structural object class for an entry may be used by other schema elements for defining constraints on directory data. It may be used by a name form definition to control the attributes used in the RDN for the entry, and in turn by a DIT structure rule to control the types of parent entries that it may have. The structural object class may also be used by a DIT content rule to control the set of auxiliary classes and required, allowed, and prohibited attribute types for the entry.
See LDAP Subentry.
A subschema subentry is a special entry within the Directory Server that provides information about the schema elements defined in the server. Attributes in this entry include:
The set of attribute syntaxes defined in the server schema.
The set of matching rules defined in the server schema.
The set of matching rule uses defined in the server schema.
The set of attribute types defined in the server schema.
The set of object classes defined in the server schema.
The set of name forms defined in the server schema.
The set of DIT content rules defined in the server schema.
The set of DIT structure rules defined in the server schema.
Note that all of these are operational attribute and therefore will not be returned unless explicitly requested.
Also note that it is technically possible for directory servers to have multiple subschema subentries with different sets of schema definitions that govern different portions of the directory information tree. The schema that applies to any given entry may be determined by retrieving the subschemaSubentry virtual attribute from that entry. The directory server currently supports only a single schema, and by default publishes that schema at cn=schema.
A substring assertion is the argument provided to a substring matching rule in the process of determining whether an attribute has any attribute value that matches a given substring.
The substring assertion contains at least one component from the following set:
Zero or one subInitial element, which must appear at the beginning of the target value.
Zero or more subAny elements, which may appear anywhere in the middle of the value. If there are multiple subAny elements, then a matching attribute value must contain all of the subAny elements in the order they appear in the substring assertion with no overlap (i.e., no character in an attribute value can be part of two different substring assertion components). If subInitial and/or subFinal components are present, then none of the subAny elements may overlap with them either.
Zero or one subFinal element, which must appear at the end of the target value.
The substring assertion is used when processing a substring search filter.
A substring index is a type of index that is used to keep track of which entries contain specific substrings. Index keys for a substring index consist of six-character substrings taken from attribute values and the corresponding values are ID lists containing the entry IDs of the entries containing those substrings. The attribute's substring matching rule is used to normalize the values for the index keys, and substring indexes cannot be defined for attributes that do not contain substring matching rules.
A substring search filter is a type of search filter that can be used to identify entries that contain a value for a given attribute that matches a specified substring. The server will use a substring matching rule to make the determination.
The substring search filter must contain a substring assertion, which will have at least one component from the following types:
A subInitial component, whose value should be contained at the start of any matching value. There may be either zero or one subInitial component in a substring filter.
A set of subAny components, whose values should be contained anywhere in the matching value. There may be zero or more subAny components in a substring filter, and they should be contained in the value in the order they appear in the substring filter, after any subInitial component and before any subFinal component.
A subFinal component, whose value should be contained at the end of a matching value. There may be either zero or one subFinal component in a substring filter.
The string representation of an LDAP substring filter comprises an opening parenthesis followed by the attribute name, an equal sign, the substring assertion with the individual components separated by asterisks, and the closing parenthesis. For example, a substring filter of (cn=ab*def*mno*stu*yz) contains a subInitial component of ab, subAny components of def, mno, and stu, and a subFinal component of yz.
There are two definitions for the term “subtree”.
The general definition for the term is simply a portion of the directory information tree, including an entry and all of its subordinates.
The term subtree is also described in RFC 3672 in the form of a subtree specification. A subtree specification provides a mechanism for grouping entries based on a given set of criteria.
The subtree delete control is a type of control that can be attached to a delete operation that will allow the entry and all of its subordinate entries to be deleted. Normal delete operations may target only leaf entries, but the subtree delete control may be used to target non-leaf entries.
The subtree delete request control has an OID of 1.2.840.113556.1.4.805 with no value. There is no corresponding response control.
The following example shows the use of this control to delete the ou=People,dc=example,dc=com subtree.
$ ldapdelete -p 1389 -h localhost -D cn=directory manager -w password \ -J 1.2.840.113556.1.4.805 ou=People,dc=example,dc=com Processing DELETE request for ou=People,dc=example,dc=com
A supported control is a mechanism for identifying the request control supported by the Directory Server. The OID of these controls are listed in the supportedControl attribute of the server's root DSE.
For a list of all controls currently supported in the directory server, see Supported LDAP Controls in Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory
A supported extension is a mechanism for identifying the extended operation supported by the Directory Server. The OID of these extended operations are listed in the supportedExtension attribute of the server's root DSE.
For a list of all supported extensions for the directory server, see Supported Extended Operations in Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory.
A supported feature is a mechanism for identifying optional capabilities that the Directory Server supports. A number of the features supported by the server are listed in the supportedFeatures attribute of the server's root DSE, which lists the OID of the supported features.
Some of the supported features for the directory server include:
Indicates that the server supports the use of the + indicator when requesting all operational attribute as specified in RFC 3673.
Indicates that the server supports the ability to include one or more object class names in the set of search attributes as specified in RFC 4529.
Indicates that the server supports the increment modification type, which is part of the increment modify extension as described in RFC 4525.
Indicates that the server supports LDAP true filters and LDAP false filters as described in RFC 4526.
Data synchronization is a mechanism for keeping track of changes in the directory environment and allowing them to be reflected elsewhere.
The primary type of data synchronization provided by the directory server is replication.
|