| 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
Simple Authentication and Security Layer
virtual attributes only control
In a proxy distribution deployment, the data is split into smaller chunks of data, each of which is known as a partition. A partition of data is typically stored on a separate remote LDAP server, or on a set of replicated remote LDAP servers to ensure high availability.
A password is a secret value that may be used to provide proof of identity in some authentication mechanisms. In particular, a password is used in simple authentication, as well as the CRAM-MD5, DIGEST-MD5 , and PLAIN SASL mechanisms.
The security that a password provides is based entirely on the fact that only the password's owner knows what the password is. If someone else learns a user's password through some means, then that third party can impersonate that user and may be able to perform any operation available to that user.
The Directory Server provides a number of password policy features that can be used to help ensure that passwords are not discovered by third-party individuals (for example, helping to ensure that users aren't allowed to use weak passwords, providing protection against brute-force attacks, requiring authentication attempts and password changes from being performed in a secure manner), but nevertheless passwords are often considered weaker forms of protection than other kinds of identification like certificate.
Password expiration is an element of the Directory Server password policy that can be used to limit the length of time that a user can continue to use the same password. If password expiration is enabled, once a user changes his or her password, they can use it for a length of time specified as the maximum password age. As the password expiration time draws near, the user may receive warning messages in the form of control in the bind response. Once the password has expired, the user will no longer be allowed to authentication.
Once the user's password has expired, it may be necessary for an administrator to password reset before the account may be used. Alternately, if the password policy is configured appropriately, the user may also be able to change their own expired password using the Password Modify extended operation.
A password generator is a piece of logic that may be used to generate a password for a user as part of a Password Modify extended operation. It will be used if the password modify request does not include a new password.
The Password Modify extended operation is a type of extended operation that may be used to change or reset user passwords. It is defined in RFC 3062 and both the request and response operations have an OID of 1.3.6.1.4.1.4203.1.11.1.
The value for the password modify request is:
PasswdModifyRequestValue ::= SEQUENCE {
userIdentity [0] OCTET STRING OPTIONAL
oldPasswd [1] OCTET STRING OPTIONAL
newPasswd [2] OCTET STRING OPTIONAL }
The value for the password modify response is:
PasswdModifyResponseValue ::= SEQUENCE {
genPasswd [0] OCTET STRING OPTIONAL }
The Directory Server password policy provides a mechanism for controlling how passwords will be stored and maintained in the server, and how users will be allowed to authenticate.
Elements of the password policy include:
The attribute used to store user passwords. By default, this is the userPassword attribute.
The default set of password storage schemes that will be used to encode passwords stored in the server.
A set of deprecated password storage schemes that can be used to authenticate users but cause the password to be re-encoded using the default schemes upon a successful bind.
A flag that indicates whether users will be allowed to change their own passwords.
A number of settings related to password expiration, including the maximum age for passwords, warnings before expiration, and whether users will be allowed to change their passwords after they expire.
A number of settings related to account lockout, which can be used to prevent users from authenticating after too many failed attempts.
Flags that indicate whether users will be required to change their passwords the first time they authenticate and/or whether they will be required to change their passwords after they have been reset by an administrator.
A set of password validators that can be used to determine whether proposed new password values are acceptable for use.
A flag that indicates whether users will be required to provide their current passwords to be allowed to change their passwords.
A flag that indicates whether clients will be allowed to specify new passwords that have already been encoded using one of the password storage schemes defined in the server. Allowing pre-encoded passwords may be necessary for some applications, but may allow the user to bypass certain restrictions, like password validators, that might otherwise be enforced.
Settings related to maintaining the last login time, including the attribute to use to store its value, the format to use for the time stamp, and whether to lock an account after too much time has elapsed without authenticating.
Flags that control whether the user will be required to authenticate in a secure manner and/or whether they will be required to change their passwords in a secure manner.
The password policy request control is a type of LDAP control that can be used to request information about the current password policy state for a user entry. It is defined in draft-sisbehera-ldap-password-policy. Both the request and response controls have an OID of 1.3.6.1.4.1.42.2.27.8.5.1. The request control does not have a value. The response control value is encoded as follows:
PasswordPolicyResponseValue ::= SEQUENCE {
warning [0] CHOICE {
timeBeforeExpiration [0] INTEGER (0 .. maxInt),
graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL,
error [1] ENUMERATED {
passwordExpired (0),
accountLocked (1),
changeAfterReset (2),
passwordModNotAllowed (3),
mustSupplyOldPassword (4),
insufficientPasswordQuality (5),
passwordTooShort (6),
passwordTooYoung (7),
passwordInHistory (8) } OPTIONAL }
For an example of using this control in a search request, see To Search Using the Password Policy Control in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
A password reset is the act of a server administrator changing a user's password. A password reset is a password change that is performed by any user other than the one that owns the account.
A password storage scheme provides a mechanism for encoding user passwords for storage in the server. In most cases, the password is encoded in a manner that prevents users from determining what the clear-text password is, while still allowing the server to determine whether the user-supplied password is correct. Password storage schemes currently available for use include:
The password will be encoded using triple DES. Triple DES is a variation of the Data Encryption Standard (DES) that is three times slower than its predecessor but provides stronger reliability. The algorithm uses three 64-bit keys for a combined key length of 192 bits. The data is encrypted with the first key, decrypted with the second key, and then re-encrypted with the third key. You must ensure that all three keys, the first and the second key, or the second and the third keys are not identical.
The Advanced Encryption Standard uses a symmetric block cipher that processes data blocks of 128 bits, using cipher keys with lengths of 128 (AES-128), 192 (AES-192), and 256 (AES-256) bits and is based on the Rijndael algorithm
The password will be base64–encoded, which provides a very weak form of protection and should only be used for cases in which clients require this storage scheme.
The password will be encoded using the BlowFish Algorithm with a 128 bits key length.
The password will be stored in clear-text. It will not provide any protection at all, so this should only be used for cases in which clients require this storage scheme.
The password will be encoded using the UNIX crypt algorithm. This is a one-way algorithm, but it is considered weak by current standards and should generally only be used for clients which require this storage scheme.
The password will be encoded using an unsalted version of the MD5 message digest algorithm. This is relatively secure, although a salted hash is preferred, and one of the SHA variants are considered stronger than MD5.
The password will be encoded using RC4, a stream cipher using a variable key-size stream cipher with byte-oriented operations. The algorithm is based on the use of a random permutation.
The password will be encoded using a salted version of the MD5 message digest algorithm.
The password will be encoded using an unsalted version of the SHA-1 Secure Hash Algorithm. The salted variant of this algorithm is preferred.
The password will be encoded using a salted version of the SHA-1 Secure Hash Algorithm. This is the default password storage scheme used by the directory server
The password will be encoded using a salted 256-bit version of the SHA-2 Secure Hash Algorithm.
The password will be encoded using a salted 384-bit version of the SHA-2 Secure Hash Algorithm.
The password will be encoded using a salted 512-bit version of the SHA-2 Secure Hash Algorithm.
Note that the directory server also supports the use of the authentication password syntax.
A password validator is a component of the directory server password policy that is used to determine whether a proposed password is acceptable for use. The directory server provides an extensible API for developing custom password validators, but it does come with a number of different types of password validators, including:
A validator that can be used to reject a password if the value exists in any of the attributes contained in the user's entry.
A validator that can be used to reject a password if the value does not contain characters from an acceptable range of character sets.
A validator that can be used to reject a password if it is a word that can be found in a dictionary.
A validator that can be used to reject a password if it is too long or too short.
A validator that can be used to reject a password if it contains a string of too many repeated characters.
A validator that can be used to reject a password if it is too similar to the user's current password.
A validator that can be used to reject a password if it does not contain enough unique characters.
The persistent search control is a type of LDAP control that may be used for clients to be notified of changes to entries that match the criteria from the associated LDAP search operation. The persistent search control is described in draft-ietf-ldapext-psearchand has an OID of 2.16.840.1.113730.3.4.3. It is defined as follows:
PersistentSearch ::= SEQUENCE {
changeTypes INTEGER,
changesOnly BOOLEAN,
returnECs BOOLEAN
}
Search result entries returned as part of this search may optionally include the entry change notification control to describe the way in which the entry changed. For an example of using this control in a search, see To Search Using the Persistent Search Control in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
The PLAIN Simple Authentication and Security Layer mechanism provides a way for clients to authentication to the Directory Server with a username and password. In general, it is very similar to simple authentication, with the exception that the client can identify itself with a username rather than a distinguished name. It also provides the ability for the client to specify an alternate authorization ID.
Like simple authentication, the PLAIN SASL mechanism does not provide any form of protection for the user password, so it may be advisable to only use this authentication method over secure communication channels like those provided by Secure Sockets Layer or StartTLS.
A plug-in is a piece of code that can be used to interject some custom logic into the way that the Directory Server performs its processing. The directory server supports a number of different types of plug-ins, including:
Pre-parse plug-ins, which allow the server to alter the contents of a request before the server begins processing on it. Pre-parse plug-ins are available for all types of operations.
Pre-operation plug-ins, which allow the server to take some action just before the core processing for an operation. Pre-operation plug-ins are available for all types of operations except abandon and unbind..
Post-operation plug-ins, which allow the server to take some action just after the core processing for an operation but before the response has been sent to the client (it may be used to alter the response to the client). Post-operation plug-ins are available for all types of operations.
Post-response plug-ins, which allow the server to take some action after all other processing for an operation has completed. Post-response plug-ins are available for all types of operations except abandon and unbind.
Search result entry plug-ins, which alter the contents of a search result entry being sent as part of a search operation.
Search result reference plug-ins, which alter the contents of a search result reference being sent as part of a search operation.
Intermediate response plug-ins, which alter the contents of an intermediate response being sent to a client.
Startup plug-ins, which perform some processing when the server is first starting.
Shutdown plug-ins, which perform some processing when the server is performing a graceful shutdown.
Post-connect plug-ins, which perform some processing as part of accepting a new client connection.
Post-disconnect plug-ins, which perform some processing immediately after a connection is terminated.
LDIF import plug-ins, which alter the contents of entries being imported from an LDIF file.
LDIF export plug-ins, which alter the contents of entries being exported from a server back end.
A presence index is a type of index that is used to keep track of the entries that have at least one value for a specified attribute. There is only a single presence index key per attribute, and its ID list contains the entry IDs for all entries that contain the specified attribute.
A presence search filter is a type of search filter that can be used to identify entries that have at least one value for a specified attribute. The string representation of an LDAP presence filter comprises an opening parenthesis followed by the attribute name, an equal sign, an asterisk, and the closing parenthesis. For example, an equality filter of (aci=*)will match any entry containing at least one value for the aci attribute.
The directory server provides a privilege subsystem, which can be used to define capabilities that will be granted to users. The privilege subsystem works in conjunction with the access control implementation in the process of determining whether a user will be allowed to perform a certain operation.
Some of the privileges defined in the directory server include:
Allows the user to bypass access control evaluation
Allows the user to modify access control rule defined in the server.
Allows the user to have read access to the server configuration
Allows the user to have write access to the server configuration
Allows the user to request that the server shut down
Allows the user to request that the server perform an in-core restart
Allows the user to request an operation with a different authorization ID
Allows the user to request an unindexed search
Allows the user to password reset for other users
Allows the user to update the server schema
See Chapter 6, Directory Server Root Users and the Privilege Subsystem, in Oracle Fusion Middleware Architecture Reference for Oracle Unified Directory for more information on the privilege subsystem.
A proxy load balancing algorithm in which client requests are distributed to a set of replicated remote LDAP servers. How many requests are sent to each remote LDAP server is determined by the weight set.
A protocol data unit (PDU) is a single complete element of network communication. For LDAP, the PDU is the message.
The protocol op is the element in the message that contains the heart of the request or response. That is, it indicates what type of message it is. There are several different kinds of protocol op elements, including:
The search request, search result entry, search result reference, and search result done protocol ops
The proxied authorization control is a type of control that can be used to request that the associated operation be performed under the authorization of another user.
There are actually two different forms of the proxied authorization control, both of which are request controls that may be attached to an add operation, compare operation, delete operation, modify operation, modify DN operation, or search operation operation.
The proxied authorization v1 control is defined in early versions of draft-weltman-ldapv3-proxy. It has an OID of 2.16.840.1.113730.3.4.12 and the control value should be encoded as:
proxyAuthValue::= SEQUENCE {
proxyDN LDAPDN
}
The proxied authorization v2 control is defined in RFC 4370. It has an OID of 2.16.840.1.113730.3.4.18 and the value is a string containing the desired authorization ID.
For an example of using this control in a search request, see To Search Using the Proxied Authorization Control in Oracle Fusion Middleware Administration Guide for Oracle Unified Directory.
|