| 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
notice of disconnection unsolicited notification
Password Modify extended operation
Simple Authentication and Security Layer
virtual attributes only control
The last login time feature of the Directory Server is a mechanism that can be used to write the time that the user last authenticated to the server using a bind operation. The last login time may be written to a specified attribute with a user-defined format.
Note that in many servers, it may be desirable to define the last login time format to contain only the date but not the time of day. If this format is used, then the value will be only updated once per day, thereby reducing the potential impact on performance for users that authenticate several times throughout the day.
The last login time may be maintained for informational purposes, but it can also be used to enable the idle account lockout feature.
The lastmod plug-in is a pre-operation idle account lockout that can be used to add the creatorsName and createTimestamp attributes to an entry as part of an add operation, or update the modifiersName and modifyTimestamp attributes in an entry as part of a modify operation or modify DN operation operation.
The LDAP assertion control is a type of control that may be used to perform an operation only if the target entry matches a given assertion filter. It may be used in conjunction with compare operation, delete operation, modify operation, modify DN operation, and search operation.
The LDAP assertion control is described in RFC 4528 and has an OID of 1.3.6.1.1.12. The value of the control should be encoded as an LDAP search filter.
For an example of using this control in a search request, see To Search Using the LDAP Assertion Control in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
The ldapcompare command-line may be used to request LDAP compare operation.
See ldapcompare in Oracle Fusion Middleware Command-Line Usage Guide for Oracle Unified Directory for detailed information on using this command.
The LDAP Data Interchange Format (LDIF) is a mechanism form representing directory data in text form. The LDIF specification is contained in RFC 2849 and describes a format not only for representing directory data but also a mechanism for making changes to that data.
In general, an LDIF record consists of a series of name-value pairs. The name can be followed by a single colon, zero or more spaces, and associated value, or it can be followed by two colons, zero or more spaces, and the base64 encoding representation of the value. Each name-value pair is given on a separate line, and long lines may be wrapped onto two or more lines using an end-of-line character followed by exactly one space at the beginning of the next line. LDIF records should be separated from each other by at least one blank line. Any line that begins with an octothorpe (#) character will be treated as a comment and ignored.
For an LDIF representation of an entry, the first line should contain the distinguished name of the entry. The remaining lines of the LDIF record will represent the attribute of the entry, with the attribute description used as the name. Multivalued attributes will be represented with a separate line per value.
The following provides an example of a user entry represented in the LDAP Data Interchange Format:
dn: uid=john.doe,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: john.doe
givenName: John
sn: Doe
cn: John Doe
mail: john.doe@example.com
userCertificate;binary:: MIIB5TCCAU6gAwIBAgIERloIajANBgkqhkiG9w0BAQUFADA3M
QswCQYDVQQGEwJVUzEVMBMGA1UEChMMRXhhbXBsZSBDb3JwMREwDwYDVQQDEwhKb2huIERvZT
AeFw0wNzA1MjcyMjM4MzRaFw0wNzA4MjUyMjM4MzRaMDcxCzAJBgNVBAYTAlVTMRUwEwYDVQQ
KEwxFeGFtcGxlIENvcnAxETAPBgNVBAMTCEpvaG4gRG9lMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCWNZB4qs1UvjYgvGvB9udmiUi4X4DeaSm3o0p8PSwpOFxSqgWdSwKgUugZ1EJVy
YoakljDFsJ0GVown+dIB24V4ozNs6wa0YotIKTV2AcySQkmzzP3e+OnE9Aa1wlB/PVnh1CFLg
k1UOoruLE10bac5HA8QiAmfNMorU26AwFTcwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAGrzMKN
bBRWn+LIfYTfqKYUc258XVbhFri1OV0oF82vyvciYWZzyxLc52EPDsymLmcDh+CdWxy3bVkjd
Mg1WEtMGr1GsxOVi/vWe+kT4tPhinnB4Fowf8zgqiUKo9/FJN26y7Fpvy1IODiBInDrKZRvNf
qemCf7o3+Cp00OmF5ey
userPassword: {SSHA}s4Bd9M0tCpRDr8/U+IXetRcAbd8bJY3AFKsn+A==
To represent an LDAP add operation in LDIF, the format is exactly the same as to represent an entry, with the exception that the line immediately after the DN should indicate a changetype of add, as shown in the following example:
dn: uid=john.doe,ou=People,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: john.doe givenName: John sn: Doe cn: John Doe mail: john.doe@example.com userCertificate;binary:: MIIB5TCCAU6gAwIBAgIERloIajANBgkqhkiG9w0BAQUFADA3M QswCQYDVQQGEwJVUzEVMBMGA1UEChMMRXhhbXBsZSBDb3JwMREwDwYDVQQDEwhKb2huIERvZT AeFw0wNzA1MjcyMjM4MzRaFw0wNzA4MjUyMjM4MzRaMDcxCzAJBgNVBAYTAlVTMRUwEwYDVQQ KEwxFeGFtcGxlIENvcnAxETAPBgNVBAMTCEpvaG4gRG9lMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCWNZB4qs1UvjYgvGvB9udmiUi4X4DeaSm3o0p8PSwpOFxSqgWdSwKgUugZ1EJVy YoakljDFsJ0GVown+dIB24V4ozNs6wa0YotIKTV2AcySQkmzzP3e+OnE9Aa1wlB/PVnh1CFLg k1UOoruLE10bac5HA8QiAmfNMorU26AwFTcwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAGrzMKN bBRWn+LIfYTfqKYUc258XVbhFri1OV0oF82vyvciYWZzyxLc52EPDsymLmcDh+CdWxy3bVkjd Mg1WEtMGr1GsxOVi/vWe+kT4tPhinnB4Fowf8zgqiUKo9/FJN26y7Fpvy1IODiBInDrKZRvNf qemCf7o3+Cp00OmF5ey userPassword: password
To represent an LDAP delete operation in LDIF, the format is simply a line containing the DN of the entry followed by a line indicating a changetype of delete, like:
dn: uid=john.doe,ou=People,dc=example,dc=com changetype: delete
To represent an LDAP modify operation in LDIF, the format is a little more complex. The first line should contain the DN of the entry, and the second should contain a changetype of modify. The third line should specify the attribute modification type (add, delete, replace, or increment) followed by the attribute description, and there may be additional lines that specify specific values for that change, with the name portion being the attribute description and the value being the corresponding attribute value. There may be multiple attribute modifications described in a single modify change record, with each of them separated by a line containing only a dash, as shown in the following example:
dn: uid=john.doe,ou=People,dc=example,dc=com changetype: modify replace: userPassword userPassword: newpassword - replace: description description: This is the first description value description: This is the second description value
To represent an LDAP modify DN operation in LDIF, the first line should contain the DN of the entry, and the second line should contain a changetype of moddn. The third line should have a name of newrdn with a value equal to the new RDN to assign to the entry, and the fourth should have a name of deleteoldrdn followed by a value of either 1 (if the deleteOldRDN flag should be true) or 0 (if it should be false). There can be an optional fifth line with a name of newsuperior and a value of the new superior DN if one is included in the request. For example:
dn: uid=john.doe,ou=People,dc=example,dc=com changetype: moddn newrdn: uid=johnathan.doe deleteoldrdn: 1
The ldapdelete command may be used to request LDAP delete operation.
See the ldapdelete in Oracle Fusion Middleware Command-Line Usage Guide for Oracle Unified Directory for detailed information on using this command.
An LDAP false filter is a special type of OR search filter that does not contain any embedded filter components. It is called an “LDAP false filter” because it always evaluates to false and will never match any entry.
The string representation for an LDAP true filter is (|). LDAP false filters are described in RFC 4526.
The LDAP intermediate response message is a special type of protocol op that allows the server to send additional messages providing information about the state of an operation before it has completed processing and the final response message is sent. Prior to the introduction of the intermediate response in RFC 3771, only search operations were allowed to send multiple responses.
The intermediate response protocol op is defined as follows:
IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
responseValue [1] OCTET STRING OPTIONAL }
At present, the directory server does not support any operations that make use of intermediate response messages.
The LDAP message is the fundamental protocol data unit for LDAP communication. It is the container that is used to hold all request and response elements.
The LDAP message is defined as shown in the following example:
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse,
...,
intermediateResponse IntermediateResponse },
controls [0] Controls OPTIONAL }
The LDAP message includes these elements:
The message ID, which is the unique identifier that is used to correlate requests and responses. The client includes a message ID in the request, and all response messages for that request will have the same message ID.
The protocol op, which is the container for the actual request or response.
An optional set of control that can be used to provide additional information about the way that the request should be processed, or additional information about the response from the server.
The LDAP modify DN operation can be used to change the distinguished name of an entry in the Directory Server. It can alter the RDN of the entry and/or it can move the entry below a new parent. If the target entry has subordinate entries, then it may be used to move or rename that subtree.
The modify DN request protocol op is defined as follows:
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
The modify DN request includes these elements:
The DN of the entry to rename and/or move.
The new RDN to use for the entry. If the entry is simply to be moved below a new parent, then it may be the same as the current RDN.
A flag that indicates whether the current RDN attribute values should be removed from the entry.
An optional DN specifying the new parent for the entry.
The response to an LDAP modify DN operation is an LDAP result as defined as follows:
ModifyDNResponse ::= [APPLICATION 13] LDAPResult}
The LDAP modify operation can be used to alter an existing entry in the Directory Server. The modify request protocol op is defined as follows:
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
changes SEQUENCE OF change SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2),
... },
modification PartialAttribute } }
The modify request includes these elements:
The DN of the entry to modify
One or more modification elements indicating the changes to make in the entry
The response to an LDAP modify operation is an LDAP result defined as shown here:
ModifyResponse ::= [APPLICATION 7] LDAPResult
The ldapmodify command may be used to request LDAP add, delete, modify, and modify DN operations.
See ldapmodify in Oracle Fusion Middleware Command-Line Usage Guide for Oracle Unified Directory for detailed information on using this command.
The LDAP no-op control is a type of control that may be attached to an LDAP add operation, delete operation, modify operation, or modify DN operation to indicate that it should not actually make any change to the content in the server.
The LDAP no-op control is defined in draft-zeilenga-ldap-noop. This is a specification that is still in progress, but the directory server does provide basic support for this control using an OID of 1.3.6.1.4.1.4203.1.10.2. The control does not have a value.
The following example shows the use of the no-op control in an ldapmodify operation.
ldapmodify -h localhost -p 1389 -D "cn=directory manager" -w password \ -J 1.3.6.1.4.1.4203.1.10.2 dn: uid=aaltay,ou=People,dc=example,dc=com changetype: modify replace: telephoneNumber telephoneNumber: +1 995 589 3333 Processing MODIFY request for uid=aaltay,ou=People,dc=example,dc=com MODIFY operation failed Result Code: 16654 (No Operation) Additional Information: The modify operation was not actually performed in the Directory Server back end because the LDAP no-op control was present in the request
The LDAP post-read control is a type of control that may be attached to an LDAP add operation, modify operation, or modify DN operation operation to request that the server return a copy of the target entry exactly as it was at the end of the processing for that operation. It is one of the LDAP read entry controls defined in RFC 4527.
The post-read request control has an OID of 1.3.6.1.1.13.2, and the value should be encoded in the same way as the search attributes in a search operation. The response control has an OID of 1.3.6.1.1.13.2 (the same as the OID for the request control), and the value should be encoded in the same was as a search result entry.
The following example shows the use of the post-read control in an ldapmodify request:
$ ldapmodify -h localhost -p 1389 -D "cn=directory manager" -w password \ --postReadAttributes=telephoneNumber dn: uid=aaltay,ou=People,dc=example,dc=com changetype: modify replace: telephoneNumber telephoneNumber: +1 995 589 3333 Processing MODIFY request for uid=aaltay,ou=People,dc=example,dc=com MODIFY operation successful for DN uid=aaltay,ou=People,dc=example,dc=com Target entry after the operation: dn: uid=aaltay,ou=People,dc=example,dc=com telephoneNumber: +1 995 589 3333
The LDAP pre-read control is a type of control that may be attached to an LDAP delete operation, modify operation, or modify DN operation operation to request that the server return a copy of the target entry exactly as it was immediately before the processing for that operation. It is one of the LDAP read entry controls defined in RFC 4527.
The pre-read request control has an OID of 1.3.6.1.1.13.1, and the value should be encoded in the same way as the search attributes in a search operation. The response control has an OID of 1.3.6.1.1.13.1 (the same as the OID for the request control), and the value should be encoded in the same was as a search result entry.
The following example shows the use of the pre-read control in an ldapmodify request:
$ ldapmodify -h localhost -p 1389 -D "cn=directory manager" -w password \ --preReadAttributes=telephoneNumber dn: uid=aaltay,ou=People,dc=example,dc=com changetype: modify replace: telephoneNumber telephoneNumber: +1 995 589 4444 Processing MODIFY request for uid=user.199,ou=People,dc=exampele,dc=com MODIFY operation successful for DN uid=aaltay,ou=People,dc=example,dc=com Target entry before the operation: dn: uid=aaltay.199,ou=People,dc=example,dc=com telephoneNumber: +1 995 589 3333
The LDAP result element is a generic protocol op that is used for the responses of several types of LDAP operations. The basic definition for the LDAP result is as follows:
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success (0),
operationsError (1),
protocolError (2),
timeLimitExceeded (3),
sizeLimitExceeded (4),
compareFalse (5),
compareTrue (6),
authMethodNotSupported (7),
strongerAuthRequired (8),
-- 9 reserved --
referral (10),
adminLimitExceeded (11),
unavailableCriticalExtension (12),
confidentialityRequired (13),
saslBindInProgress (14),
noSuchAttribute (16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject (32),
aliasProblem (33),
invalidDNSyntax (34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),
invalidCredentials (49),
insufficientAccessRights (50),
busy (51),
unavailable (52),
unwillingToPerform (53),
loopDetect (54),
-- 55-63 unused --
namingViolation (64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN (67),
entryAlreadyExists (68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71),
-- 72-79 unused --
other (80), ... },
matchedDN LDAPDN,
diagnosticMessage LDAPString,
referral [3] Referral OPTIONAL }
The elements of the LDAP result are:
An integer value that provides generic information about the result of the operation. The definition above specifies several result codes, but a number of other values are defined in other specifications.
A DN value that may specify the DN of the closest superior entry found if the request specified an entry that did not exist. It may be an empty DN if the matched DN element is not appropriate for the response.
A human-readable message that provides additional information about the result of the processing. It is typically used for error messages, but it may also be present in successful operations. It may be an empty string if there is no message.
A set of LDAP URLs to other servers in which the client may attempt the operation. This element may be absent if there are no referrals.
LDAPS is a term that is used to refer to LDAP communication over Secure Sockets Layer.
A search filter provides a mechanism for defining the criteria for defining matching entries in an LDAP search operation. There are ten different types of search filters defined in LDAP:
Serve as a container for holding zero or more search filter elements. All search filters contained in the AND filter must match the target entry for the AND filter to match.
Serve as a container for holding zero or more search filter elements. At least one of the search filters contained in the OR filter must match the target entry for the OR filter to match.
Serves as a container for exactly one search filter element. The embedded filter must not match the target entry for the NOT filter to match.
Provides a mechanism for identifying entries that contain a specified value for a given attribute.
Provides a mechanism for identifying entries with attribute values matching a specified substring.
Provides a mechanism for identifying entries with attribute values greater than or equal to a specific value.
Provides a mechanism for identifying entries with attribute values less than or equal to a specific value.
Provides a mechanism for identifying entries that contain at least one value for a specified attribute.
Provides a mechanism for identifying entries with attribute values that are approximately equal to a given value.
Provides a mechanism for using a matching rule to identify matching entries using an extensible mechanism.
See RFC 4515 for more information about LDAP search filters and a mechanism for representing them as strings.
The ldapsearch command may be used to request LDAP search operation.
See ldapsearch in Oracle Fusion Middleware Command-Line Usage Guide for Oracle Unified Directory for detailed information on using this command.
An LDAP true filter is a special type of AND search filter that does not contain any embedded filter components. It is called an “LDAP true filter” because it always evaluates to true and will match any entry.
The string representation for an LDAP true filter is (&). LDAP true filters are described in RFC 4526.
An LDAP subentry is a type of entry that contains the ldapSubEntry object class. These entries are meant to hold operational data for the server. They are kind of like operational attribute in that they are not returned to clients unless explicitly requested by including a request control with an OID of 1.3.6.1.4.1.7628.5.101.1 and no value. This behavior is described in draft-ietf-ldup-subentry.
For an example of using this control in a search, see To Search Using the LDAP Subentry Control in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
An LDAP URL is a type of URL that may be used to reference an entry or set of search criteria. The format of an LDAP URL is described in RFC 4516 and may include the following elements:
The address of the directory server
The port number of the directory server
The search base DN
A set of search attributes
The scope for the search
A search filter for identifying the entries to match
A set of extensions that provide information about the way in which the search should be processed
All of these elements are optional. Technically, all that is required of an LDAP URL is the string ldap://. However, a more complete URL might be ldap://directory.example.com:389/dc=example,dc=com?cn,givenName,sn?sub?(uid=john.doe).
An LDIF export operation is a process by which all or part of the content in a Directory Server back end is written to a file using the LDAP Data Interchange Format. An LDIF export may be initiated using either the export-ldif command or an LDIF export task.
An LDIF import operation is a process by which data can be added to a Directory Server back end from a file with information in the LDAP Data Interchange Format. An LDIF import provides a significantly more efficient means of adding a large number of entries to the server than LDAP add operations.
An LDIF import operation can be initiated using the import-ldif command or with the LDIF import task.
A leaf entry is an entry that does not have any subordinate entries in the server.
An less or equal search filter is a type of search filter that can be used to identify entries that contain a specific value for a given attribute that is less than or equal to the provided assertion value. The server will use an ordering matching rule to make the determination.
The string representation of an LDAP less or equal search filter is composed of an opening parenthesis followed by the attribute name, a less than sign, an equal sign, the assertion value, and the closing parenthesis. For example, a less or equal filter of (createTimestamp<=20070101000000Z) will match any entry that has a createTimestamp value that is less than or equal to 20070101000000Z.
A proxy distribution algorithm, in which the data is split into partitions based on alphabetical delimitations. For example, [A-E[ for one partition and [E-H[ for the next partition.
The Lightweight Directory Access Protocol (LDAP) is a protocol that may be used to communicate with a directory server. It is an open standard that uses the Basic Encoding Rules subset of Abstract Syntax Notation One to encode communication into message.
The core LDAPv3 specification is in RFC 4510, with RFC 4511 defining the actual encoding for the protocol. A number of other specifications are defined in a number of request for comments and Internet Draft.
LDAP defines a number of different types of operations, including:
Provides a way to abort the processing for an operation in progress
Provides a way to add a new entry to the server
Provides a way to authentication to the server
Provides a way to determine whether an entry has a specified attribute value assertion
Provides a way to remove entries from the server
Provides a way to perform custom processing implemented as an extension to the core LDAP protocol
Provides a way to alter the contents of an entry in the server
Provides a way to rename an entry in the server
Provides a way to identify all entries that match a given set of criteria
Provides a way to indicate that the client wishes to disconnect from the server
Load balancing is a proxy deployment type which provides single access to a set of replicated remote LDAP servers. The choice of the remote LDAP server to which a client requests is sent is determined by a load balancing algorithm.
The lookthrough limit is a configuration option within the Directory Server that can be used to enforce a limit on the number of entries that the server will examine in the course of processing a search operation. This limit applies to all entries that the server examines, regardless of whether it matches the provided search criteria.
The lookthrough limit configuration attribute can be used to limit the impact of unindexed searches, or searches with a very large candidate list.
For information about configuring the lookthrough limit, see Setting Resource Limits on a User Account in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory and Setting Root User Resource Limits in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
|