1 Document History
| Issue |
Date |
Author |
Comments |
| 0.0 |
22 May 2000 |
A. Thackrah |
1st Draft (review by 05-Jun-2000) |
| 0.1 |
01 Aug 2000 |
A. Thackrah |
Incorporates changes resulting from external review. |
| 1.0 |
19 Oct 2000 |
A. Thackrah |
Editorial changes and some re-classifcations during beta testing. |
| 1.1+ |
25 Jun 2001 |
A. Thackrah |
Automatic updates for each test suite release (see Test Suite Version) |
| 2.0 |
10 Jun 2003 |
A. Thackrah |
Profile information added |
2 Definitions and Abbreviations
BLITS - Basic
LDAP Interoperability Test Suite
IETF - Internet
Engineering Task Force
LDAP - Lightweight
Directory Access Protocol
RFC - Request
For Comments document
3 Introduction
This is the test specification for the VSLDAP test suite, defining the functional coverage.
VSLDAP is a test suite provided by The Open Group in support of the Open Brand for
LDAP. For more details see The Open Group web site .
This document lists assertions derived from RFC2251 to RFC2256 inclusive
The standard practice followed by The Open Group when creating a
test suite is to define a list of assertions from the standards that the
test suite covers. An assertion is included in the list for each statement
in a standard that places a requirement on an implementation. "MUST" statements
in RFCs are obvious examples of this. However, there are often implied
MUSTs in RFC that are not explicitly stated as such. For example, an RFC
may say that an implementation "does", or "will do", something or other.
Even though the word "MUST" is not used, the requirement on the implementation
is clear.
Organisation.
Assertions are grouped by subject matter with a relevant section heading.
e.g. all assertions derived from the specification of the search operation
are in the "Search" section.
Each assertion is presented as follows:
ID: A unique identifying name for the assertion. This is a dotted-decimal
of the form w.x.y.z.
w indicates the document from which the assertion is derived, x.y denotes
the relevant section and sub-section of document w, and z is the number
of the assertion within that section.
If the document has no relevevant subsection, y = 0
Documents: (w)
RFC2251 : 1
RFC2251 : 2
RFC2253 : 3
RFC2254 : 4
RFC2255 : 5
RFC2256 : 6
RFC2459 : 7
SSLv3 : 8
Some document IDs have been specified for future use.
Identification of a document does not necessarily imply conformance requirements at present.
Class: The test class A, B, C or D based on the ISO 1003.3 definition:
A : Mandatory, testable assertion
B : Mandatory, untestable assertion
C : Optional, testable assertion
D : Optional, untestable assertion
Profile: The name of the product standard profile that this test belongs to (or NONE if None apply)
Text: The text of the assertion
Ref: Optional reference if the ID is not sufficient. "Document_name#section.number"
is the usual format.
Strategy: Optional notes on implementation of the assertion as a test.
This could simply be a reference to an existing test strategy such as a
BLITS test. These notes are purely informative and do not constitute a committment
to implement a particular testing strategy.
4 Test Suite Version
This version of the specification defines coverage for version 2.3-GA
of the VSLDAP test suite.
Profile Coverage
This document lists tests for the following LDAP Certified profiles: All
5 RFC2251
5.1 BER
| ID: | 1.5.1.1 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server generates BER encodings other than in ASN.1
types encapsulated inside of OCTET STRING values then only the definite
form of length encoding is used.
|
| Ref: | rfc2251#5.1 |
| Strategy: | |
| ID: | 1.5.1.2 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server generates BER encodings other than in ASN.1 types
encapsulated inside of OCTET STRING values then OCTET STRING values are
encoded in the primitive form only.
|
| Ref: | rfc2251#5.1 |
| Strategy: | |
| ID: | 1.5.1.3 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server generates BER encodings other than in ASN.1 types
encapsulated inside of OCTET STRING values and the value of a BOOLEAN type
is true then the encoding has its contents octets set to hex "FF"
|
| Ref: | rfc2251#5.1 |
| Strategy: | |
| ID: | 1.5.1.4 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server generates BER encodings other than in ASN.1 types
encapsulated inside of OCTET STRING values and a value of a type is its default
value then it is absent.
|
| Ref: | rfc2251#5.1 |
| Strategy: | |
5.2 ABANDON
| ID: | 1.4.11.1 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives an abandon request and the operation
whose message ID is specified in the request is that of an operation which
was requested earlier in connection and which is still in progress then the
server will abandon that operation.
|
| Ref: | rfc2251#4.11 |
| Strategy: | can not portably test assertions which rely on operation processing time.
|
| ID: | 1.4.11.2 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives an abandon request for a search operation
and is in the midst of transmitting responses to the search then it ceases
transmitting those responses immediately and does not send the
SearchResponseDone message.
|
| Ref: | rfc2251#4.11 |
| Strategy: | Can not test for the non-receipt of a response.
|
| ID: | 1.4.11.3 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives an abandon request with a message ID
that it does not recognise then it discards the request.
|
| Ref: | rfc2251#4.11 |
| Strategy: | |
| ID: | 1.4.11.4 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives an abandon request for an operation
that cannot be abandoned then it discards the request.
|
| Ref: | rfc2251#4.11 |
| Strategy: | |
| ID: | 1.4.11.5 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives an abandon request for an operation that
has already been abandoned then it discards the request.
|
| Ref: | rfc2251#4.11 |
| Strategy: | |
5.3 ADD
| ID: | 1.4.7.1 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives an add request then it will take the distinguished
name of the entry to be added from the entry field of the request.
|
| Ref: | rfc2251#4.7 |
| Strategy: | BLITS 3.3.4.1
|
| ID: | 1.4.7.2 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives an add request then it will not dereference
any aliases in locating the entry to be added.
|
| Ref: | rfc2251#4.7 |
| Strategy: | |
| ID: | 1.4.7.3 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives an add request then it will take the content
of the entry being added from the attributes field of the request.
|
| Ref: | rfc2251#4.7 |
| Strategy: | BLITS 3.3.4.1 modified to add Marge Vader instead of Austin Powers.
|
| ID: | 1.4.7.4 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives an add request and the entry named in the entry
field already exists then the request will not succeed and the server will return
a result code of `entryAlreadyExists'.
|
| Ref: | rfc2251#4.7 |
| Strategy: | BLITS 3.3.4.2.3
|
| ID: | 1.4.7.5 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives an add request and the parent of the entry to
be added does not exist then the request will not succeed.
|
| Ref: | rfc2251#4.7 |
| Strategy: | BLITS 3.3.4.2.1
|
| ID: | 1.4.7.6 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives an add request and the parent of the entry to
be added does not exist then the server will return an AddResponse message with the
resultCode `noSuchObject' and the name of the grandparent in the MatchedDN.
|
| Ref: | rfc2251#4.7 |
| Strategy: | BLITS 3.3.4.2.1 (based on)
PROCEDURE: Attempt to add entry to ficticious branch
INPUT: add:entry = "cn=Frank Skywalker, ou=Dantooine"
EXPECTED: resultCode noSuchObject, superior = ou=ClientX, ou=VendorY,
ou=Add, o=IMC, c=US
|
| ID: | 1.4.7.7 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives an add request in which one or more mandatory
values of the objectclass type have not been specified then the operation will
fail and the server will return a result code of `objectClassViolation'.
|
| Ref: | rfc2251#4.7 |
| Strategy: | BLITS 3.3.4.2.4
|
5.4 BIND
| ID: | 1.4.2.1 |
| Class: | D |
| Profile: | NONE |
| Text: | If a client requests protocol version 2, a server that supports the
version 2 protocol as described in RFC 1777 will not return any v3-specific protocol
fields
|
| Ref: | rfc2251#4.2 |
| Strategy: | This test is not portable and has been removed from VSLDAP-2.0
|
| ID: | 1.4.2.2 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a bind request in which the name is a zero length string
and the password is a zero-length string and when authentication has not been performed
at a lower layer and when SASL credentials with a mechanism that includes the LDAPDN
in the credentials are not in use then the server will bind the client anonymously.
|
| Ref: | rfc2251#4.2 |
| Strategy: |
|
| ID: | 1.4.2.3 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a bind request in which the name is not a zero
length string and the authentication field is not empty then the server will
authenticate the requesting client.
|
| Ref: | rfc2251#4.2 |
| Strategy: | BLITS 3.3.1.3.1
|
| ID: | 1.4.2.4 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a bind request in which the name is not
a zero length string and the authentication field is empty then the server
will not authenticate the requesting client.
|
| Ref: | rfc2251#4.2 |
| Strategy: | BLITS 3.3.1.4.4 (modified).
|
| ID: | 1.4.2.5 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a bind request in which the name is not a zero
length string and the authentication field is invalid then the server will
return a result with code `invalidCredentials'
|
| Ref: | rfc2251#4.2 |
| Strategy: | BLITS 3.3.1.4.1
|
| ID: | 1.4.2.6 |
| Class: | B |
| Profile: | NONE |
| Text: | When a server receives an unbind request during the course of the bind
process then it will abort the bind process.
|
| Ref: | rfc2251#4.2 |
| Strategy: | It is not possible to portably guarantee the order of events and operations in the
server
|
| ID: | 1.4.2.7 |
| Class: | B |
| Profile: | NONE |
| Text: | When during the course of a SASL bind negotiation a server receives a bind
request with a different value in the mechanism field of SaslCredentials or an
AuthenticationChoice other than sasl then the server will abort the bind process.
|
| Ref: | rfc2251#4.2 |
| Strategy: | It is not possible to portably guarantee the order of events and operations in the
server
|
| ID: | 1.4.2.8 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a bind request with the sasl mechanism
field as an empty string then it will return a BindResponse with
`authMethodNotSupported' as the result code.
|
| Ref: | rfc2251#4.2 |
| Strategy: | |
| ID: | 1.4.2.9 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives LDAP requests other than bind requests
from a client that has not yet bound and the server is not configured to
require the client to bind before browsing or modifying the directory then
the server will process those requests as unauthenticated operations.
|
| Ref: | rfc2251#4.2 |
| Strategy: | |
| ID: | 1.4.2.10 |
| Class: | B |
| Profile: | NONE |
| Text: | When a server receives a bind request from a client that has already
bound then it will abandon all operations outstanding on the connection.
|
| Ref: | rfc2251#4.2 |
| Strategy: | It is not possible to portably guarantee the order of events and operations in the
server
|
| ID: | 1.4.2.11 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a bind request from a client that has already bound
then it will ignore authentication from earlier binds.
|
| Ref: | rfc2251#4.2 |
| Strategy: | |
| ID: | 1.4.2.12 |
| Class: | D |
| Profile: | ADVANCED |
| Text: | When a server receives a bind request in which the authentication field
contains a sasl AuthenticationChoice and it supports the SASL mechanism named in the
mechanism field then it will authenticate the client using the SASL mechanism of
obtaining the data for authentication from inside an OCTET STRING wrapper in the
credentials field.
|
| Ref: | rfc2251#4.2 |
| Strategy: | Only required SASL mechanism is EXTERNAL and this does not require credential data
(since it is provided externally by x509 certificates)
|
| ID: | 1.4.2.13 |
| Class: | C |
| Profile: | ADVANCED |
| Text: | When a server authenticates a client using SASL and any SASL-based
integrity or confidentiality services are enabled then the server will
implement those services following the transmission by the server of the final
bind response with resultCode `success'.
|
| Ref: | rfc2251#4.2 |
| Strategy: | |
| ID: | 1.4.2.14 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server returns a bind response after a successful bind then the
ResultCode will be `success'
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | BLITS 3.3.1.1
|
| ID: | 1.4.2.15 |
| Class: | B |
| Profile: | NONE |
| Text: | When a server returns a bind response after a bind during which it
encountered an internal error then the result code will be `operationsError'.
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | No portable way to generate internal server errors
|
| ID: | 1.4.2.16 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server returns a bind response after a bind in which an
unrecognised version number was supplied then the ResultCode will be
`protocolError'.
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | BLITS 3.3.1.4.5
|
| ID: | 1.4.2.17 |
| Class: | B |
| Profile: | NONE |
| Text: | When a server returns a bind response after a bind in which a PDU with
incorrect structure was received then the result code will be `protocolError'.
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | Access to PDU not portably testable
|
| ID: | 1.4.2.18 |
| Class: | A |
| Profile: | NONE |
| Text: | When a server returns a bind response after a bind in which an
unrecognised SASL mechanism name was supplied then the resultCode will be
`authMethodNotSupported'.
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | Send bind request with ficticious mechanism name; Inspect result.
EXPECTED: resultCode 7 (authMethodNotSupported)
|
| ID: | 1.4.2.19 |
| Class: | C |
| Profile: | ADVANCED |
| Text: | When a server returns a bind response after a bind in which an
authentication was not provided with a SASL mechanism but the server is
configured to require authentication to be provided with a SASL mechanism
then the resultCode will be `strongAuthRequired'.
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | |
| ID: | 1.4.2.20 |
| Class: | B |
| Profile: | NONE |
| Text: | When a server returns a bind response after a bind which it can not
accept because the client should try another server then the resultCode will be
`referral'.
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | Outside the scope of a single-server test suite
|
| ID: | 1.4.2.21 |
| Class: | D |
| Profile: | ADVANCED |
| Text: | When a server returns a bind response during a bind using a SASL
mechanism and the server requires the client to send a new bind request, with
the same sasl mechanism, to continue the authentication process then the result
code will be `saslBindInProgess'.
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | Not able to portably force a server to require a rebind.
|
| ID: | 1.4.2.22 |
| Class: | D |
| Profile: | ADVANCED |
| Text: | When a server returns a bind response after an anonymous bind
and the server is configured to require the client to provide credentials
then the resultCode will be `inappropriateAuthentication'.
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | Untestable. Only supported auth method is SASL External, which requires no credentials.
|
| ID: | 1.4.2.23 |
| Class: | A |
| Profile: | |
| Text: | When a server returns a bind response after a bind in which the client
did not supply credentials but the server is configured to require the client to
provide credentials then the resultCode will be `inappropriateAuthentication'.
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | BLITS 3.3.1.4.4
|
| ID: | 1.4.2.24 |
| Class: | A |
| Profile: | BASE |
| Text: | The server accepts SSL-based connections on port 636.
|
| Ref: | LDAP Certified Product Standard. |
| Strategy: |
|
| ID: | 1.4.2.25 |
| Class: | B |
| Profile: | NONE |
| Text: | When a server returns a bind response after a bind request while it
was shutting down then the result code will be `unavailable'
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | Requires control of server - not portable
|
| ID: | 1.4.2.26 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a bind request in which the authentication
field contains a simple AuthenticationChoice then the server's response will
not include a serverSaslCreds field.
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | |
| ID: | 1.4.2.27 |
| Class: | C |
| Profile: | ADVANCED |
| Text: | When a server receives a bind request in which the authentication field
contains a saslAuthenticationChoice and the SASL mechanism does not require the
server to return information to the client then the server's response will not include
a serverSaslCreds field.
|
| Ref: | rfc2251#4.2.3 |
| Strategy: | |
| ID: | 1.4.2.28 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a simple bind request over an SSL connnection in which the
password is of zero length then the server treats the client as being anonymously authenticated.
|
| Ref: | rfc2251#4.2 |
| Strategy: | |
| ID: | 1.4.2.29 |
| Class: | A |
| Profile: | |
| Text: | When a server receives a simple bind request over an SSL connnection and the bind
request fails then the server treats the client as being anonymously authenticated.
|
| Ref: | rfc2251#4.2 |
| Strategy: | |
| ID: | 1.4.2.30 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a simple bind request over an SSL connnection and the content
of the request authentication field is a password then the server authenticates the client
by that password.
|
| Ref: | rfc2251#4.2 |
| Strategy: | |
5.5 COMMON_ELEMENTS
| ID: | 1.4.1.1 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server issues an LDAP protocol message the message is
encapsulated in an LDAPMessage envelope.
|
| Ref: | rfc2251#4.1.1 |
| Strategy: | Implicitly tested by all VSLDAP tests using LDAP SDK - included here for
completeness
EXPECTED: LDAPResult object has the expected resultCode = `success'
|
| ID: | 1.4.1.2 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a PDU from a client in which the LDAPMessage
SEQUENCE tag cannot be recognised then the server returns a notice of disconnection
with resultCode `protocolError' and immediately closes the connection.
|
| Ref: | rfc2251#4.1.1 |
| Strategy: | Untestable - can not modify PDU
|
| ID: | 1.4.1.3 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a PDU from a client in which the messageID
cannot be parsed then the server returns a notice of disconnection with
resultCode `protocolError' and immediately closes the connection.
|
| Ref: | rfc2251#4.1.1 |
| Strategy: | Untestable - can not modify PDU
|
| ID: | 1.4.1.4 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a PDU from a client in which the tag
of the protocolOp is not recognised as a request then the server returns
a notice of disconnection with resultCode protocolError and immediately
closes the connection.
|
| Ref: | rfc2251#4.1.1 |
| Strategy: | Untestable - can not modify PDU
|
| ID: | 1.4.1.5 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a PDU from a client in which the encoding
structures are found to be incorrect then the server returns a notice of
disconnection with resultCode `protocolError' and immediately closes
the connection.
|
| Ref: | rfc2251#4.1.1 |
| Strategy: | Untestable - can not modify PDU
|
| ID: | 1.4.1.6 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a PDU from a client in which the lengths
of data fields are found to be incorrect then the server returns a notice
of disconnection with resultCode `protocolError' and immediately closes
the connection.
|
| Ref: | rfc2251#4.1.1 |
| Strategy: | Untestable - can not modify PDU
|
| ID: | 1.4.1.7 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a PDU from the client in which the LDAPMessage
SEQUENCE tag can be recognized, the messageID can be parsed, the tag of the
protocolOp is recognized as a request, and the encoding structures lengths of
data fields are correct, but the server cannot parse the request, the server
returns an appropriate response to the request, with the resultCode set to `protocolError'.
|
| Ref: | rfc2251#4.1.1 |
| Strategy: | Untestable - can not modify PDU
|
| ID: | 1.4.1.8 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server generates an LDAPMessage envelope encapsulating
a response the envelope contains the message ID value of the corresponding
request LDAPMessage.
|
| Ref: | rfc2251#4.1.1.1 |
| Strategy: | |
| ID: | 1.4.1.9 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server returns the value of an attributeType that value
is the textual string associated with the attributeType in its specification.
|
| Ref: | rfc2251#4.1.4 |
| Strategy: | Information not accessible
|
| ID: | 1.4.1.10 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and it has a textual
name for an attribute type then it uses the textual name for attributes
returned in search results.
|
| Ref: | rfc2251#4.1.4 |
| Strategy: | |
| ID: | 1.4.1.11 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives an attributeDescription with one or
more options then the server treats it as a subtype of the attribute
type without any options.
|
| Ref: | rfc2251#4.1.5 |
| Strategy: | Only one option defined for LDAPv3
|
| ID: | 1.4.1.12 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives an attributeDescription with one or
more options then the server does not treat the options as mutually exclusive.
|
| Ref: | rfc2251#4.1.5 |
| Strategy: | Only one option defined for LDAPv3
|
| ID: | 1.4.1.13 |
| Class: | B |
| Profile: | BASE |
| Text: | When a response message contains an attribute description with
more than one option, the options are in ascending order.
|
| Ref: | rfc2251#4.1.5 |
| Strategy: | Only one option defined for LDAPv3
|
| ID: | 1.4.1.14 |
| Class: | B |
| Profile: | BASE |
| Text: | A server treats any two attributeDescriptions with the same
attribute type and options as equivalent.
|
| Ref: | rfc2251#4.1.5 |
| Strategy: | Only one option defined for LDAPv3
|
| ID: | 1.4.1.15 |
| Class: | A |
| Profile: | BASE |
| Text: | A server treats an attributeDescription with any options that
it does not implement as an unrecognised attribute type
|
| Ref: | rfc2251#4.1.5 |
| Strategy: | BLITS 3.3.2.5
|
| ID: | 1.4.1.16 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives an attributeDescription with the "binary"
option present then it transfers the attribute as a binary value encoded
using the Basic Encoding Rules.
|
| Ref: | rfc2251#4.1.5.1 |
| Strategy: | Not portably testable
|
| ID: | 1.4.1.17 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a request to return an attribute in
the binary format and the server cannot generate that format then the
server treats the attribute type as an unrecognised attribute type.
|
| Ref: | rfc2251#4.1.5.1 |
| Strategy: | Binary encoding policy of server is not portably testable.
|
| ID: | 1.4.1.18 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a field of type AttributeValue and the
"binary" option is present in the companion attribute description then
the server treats the field as an OCTET STRING containing an
encoded binary value
|
| Ref: | rfc2251#4.1.6 |
| Strategy: | Not portably testable
|
| ID: | 1.4.1.19 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a field of type AttributeValue and the
"binary" option is not present in the companion attribute description then
the server treats the field as containing a string encoding of an
AttributeValue data type.
|
| Ref: | rfc2251#4.1.5.6 |
| Strategy: | Binary encoding policy of server is not portably testable.
|
| ID: | 1.4.1.20 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives an AttributeValueAssertion with an
attributeDesc in which the "binary" option is present then it treats
the assertionValue as a binary encoding of the assertion value.
AttributeValue data type.
|
| Ref: | rfc2251#4.1.5.7 |
| Strategy: | Not portably testable
|
| ID: | 1.4.1.21 |
| Class: | A |
| Profile: | BASE |
| Text: | An attribute has at least one value when stored.
|
| Ref: | rfc2251#4.1.8 |
| Strategy: | |
| ID: | 1.4.1.22 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server generates an attribute the attribute values are
all distinct.
|
| Ref: | rfc2251#4.1.8 |
| Strategy: | |
| ID: | 1.4.1.23 |
| Class: | C |
| Profile: | NONE |
| Text: | If a server supports matching rules for use in the extensibleMatch
search filter then it lists the matching rules that it implements in subschema
entries, using the matchingRules attributes.
|
| Ref: | rfc2251#4.1.9 |
| Strategy: | |
| ID: | 1.4.1.24 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server generates an LDAPResult message the errorMessage
field contains either a string containing a human-readable diagnostic or
a zero length string .
|
| Ref: | rfc2251#4.1.10 |
| Strategy: | Human-readable imples manual testing - outside scope of this test suite.
|
| ID: | 1.4.1.25 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server returns a result code of `noSuchObject' and no
aliases were dereferenced while attempting to locate the entry the matchedDN
field is set to the name of the lowest entry (object or alias) in the Directory
that was matched, which will be a truncated form of the name provided
|
| Ref: | rfc2251#4.1.10 |
| Strategy: | |
| ID: | 1.4.1.26 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server returns a result code of `noSuchObject' and
aliases were dereferenced while attempting to locate the entry the matchedDN
field is set to the name of the lowest entry (object or alias) in the Directory
that was matched, which will be the resulting name as defined in X.511.
|
| Ref: | rfc2251#4.1.10 |
| Strategy: | Can't force server to generate noSuchObject error.
|
| ID: | 1.4.1.27 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server returns a result code of `aliasProblem' and no
aliases were dereferenced while attempting to locate the entry the
matchedDN field is set to the name of the lowest entry (object or alias)
in the Directory that was matched, which will be a truncated form of the
name provided.
|
| Ref: | rfc2251#4.1.10 |
| Strategy: | Can't force server to generate aliasProblem error.
|
| ID: | 1.4.1.28 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server returns a result code of `aliasProblem' and
aliases were dereferenced while attempting to locate the entry the
matchedDN field is set to the name of the lowest entry (object or alias)
in the Directory that was matched, which will be the resulting name as
defined in X.511.
|
| Ref: | rfc2251#4.1.10 |
| Strategy: | Can't force server to generate aliasProblem error.
|
| ID: | 1.4.1.29 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server returns a result code of `invalidDNSyntax' and
no aliases were dereferenced while attempting to locate the entry the
matchedDN field is set to the name of the lowest entry (object or alias)
in the Directory that was matched, which will be a truncated form of the
name provided.
|
| Ref: | rfc2251#4.1.10 |
| Strategy: | Can't force server to generate invalidDNSntax error.
|
| ID: | 1.4.1.30 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server returns a result code of invalidDNSyntax and
aliases were dereferenced while attempting to locate the entry the
matchedDN field is set to the name of the lowest entry (object or alias)
in the Directory that was matched, which will be the resulting name as
defined in X.511.
|
| Ref: | rfc2251#4.1.10 |
| Strategy: | Can't force server to generate invalidDNSntax error.
|
| ID: | 1.4.1.31 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server returns a result code of aliasDereferencingProblem
and no aliases were dereferenced while attempting to locate the entry the
matchedDN field is set to the name of the lowest entry (object or alias)
in the Directory that was matched, which will be a truncated form of the
name provided.
|
| Ref: | rfc2251#4.1.10 |
| Strategy: | Can't force server to generate aliasDereferencingProblem error.
|
| ID: | 1.4.1.32 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server returns a result code of aliasDereferencingProblem
and aliases were dereferenced while attempting to locate the entry the
matchedDN field is set to the name of the lowest entry (object or alias)
in the Directory that was matched, which will be the resulting name as
defined in X.511.
|
| Ref: | rfc2251#4.1.10 |
| Strategy: | Can't force server to generate aliasDereferencingProblem error.
|
| ID: | 1.4.1.33 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server returns a result code other than noSuchObject,
aliasProblem, invalidDNSyntax and aliasDereferencingProblem, the matchedDN
field is set to a zero length string.
|
| Ref: | rfc2251#4.1.10 |
| Strategy: | Can't force server to generate arbitrary error.
|
| ID: | 1.4.1.34 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server returns a referral result code then the message
includes a referral field.
|
| Ref: | rfc2251#4.1.11 |
| Strategy: | BLITS 3.3.14.3.3
NOTES: The referred server does not exist - do not follow the referral
|
| ID: | 1.4.1.35 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server returns a result code other than referral then
the message does not include a referral field.
|
| Ref: | rfc2251#4.1.11 |
| Strategy: | |
| ID: | 1.4.1.36 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server returns a referral then it includes at least one URL.
|
| Ref: | rfc2251#4.1.11 |
| Strategy: | based on BLITS 3.3.14.3.3
|
| ID: | 1.4.1.37 |
| Class: | B |
| Profile: | BASE |
| Text: | When a singleLevel search request is made in which the search
scope spans multiple naming contexts and several different servers would
need to be contacted to complete the search then a referral is not
returned.
|
| Ref: | rfc2251#4.1.11 |
| Strategy: | Outside the scope of the product standard
|
| ID: | 1.4.1.38 |
| Class: | B |
| Profile: | BASE |
| Text: | When a wholeSubtree search request is made in which the search
scope spans multiple naming contexts and several different servers would
need to be contacted to complete the search then a referral is not
returned.
|
| Ref: | rfc2251#4.1.11 |
| Strategy: | Outside the scope of the product standard
|
| ID: | 1.4.1.39 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a referral is returned and an alias was dereferenced then
the part of the URL is present with the new target object name.
|
| Ref: | rfc2251#4.1.11 |
| Strategy: | |
| ID: | 1.4.1.40 |
| Class: | B |
| Profile: | ADVANCED |
| Text: | A control which is sent as part of a request applies only to
that request and is not saved.
|
| Ref: | rfc2251#4.1.12 |
| Strategy: | Untestable - specific control required, so not portable.
|
| ID: | 1.4.1.41 |
| Class: | B |
| Profile: | ADVANCED |
| Text: | When a server recognises a control type and it is appropriate
for the operation then the server makes use of the control when performing
the operation.
|
| Ref: | rfc2251#4.1.12 |
| Strategy: | Untestable - specific control required, so not portable.
|
| ID: | 1.4.1.42 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a control type that it does not
recognise and that is marked critical then the server does not perform
the operation but returns the resultCode `unsupportedCriticalExtension'.
|
| Ref: | rfc2251#4.1.12 |
| Strategy: | The assertion (and RFC) refer to `unsupportedCriticalExtension' but
the resultCode as defined in VSLDAP (and RFC) is `anavailableCriticalExtension'
(same resultCode number).
|
| ID: | 1.4.1.43 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a control type that is not appropriate
for the operation and that is marked critical then the server does not
perform the operation but returns the resultCode `unsupportedCriticalExtension'.
|
| Ref: | rfc2251#4.1.12 |
| Strategy: | The assertion (and RFC) refer to `unsupportedCriticalExtension' but
the resultCode as defined in VSLDAP (and RFC) is `unavailableCriticalExtension'
(same resultCode number).
|
| ID: | 1.4.1.44 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a control type that it does not recognise
and that is not marked critical then the server ignores the control.
|
| Ref: | rfc2251#4.1.12 |
| Strategy: | |
| ID: | 1.4.1.45 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a control type that is not appropriate
for the operation and that is not marked critical then the server ignores
the control.
|
| Ref: | rfc2251#4.1.12 |
| Strategy: | |
| ID: | 1.4.1.46 |
| Class: | B |
| Profile: | BASE |
| Text: | A server can handle arbitrary contents of the controlValue octet
string, including zero bytes.
|
| Ref: | rfc2251#4.1.12 |
| Strategy: | Can not test arbitray values (exhaustive).
|
5.6 COMPARE
| ID: | 1.4.10.1 |
| Class: | A |
| Profile: | BASE |
| Text: | If the result of a comparison operation is False, then the server
returns a Compare response with result code `compareFalse'.
|
| Ref: | rfc2251#4.10 |
| Strategy: | BLITS 3.3.7.1
|
| ID: | 1.4.10.2 |
| Class: | A |
| Profile: | BASE |
| Text: | If the result of a comparison operation is True, then the server
returns a Compare response with result code `compareTrue'.
|
| Ref: | rfc2251#4.10 |
| Strategy: | BLITS 3.3.7.2
|
| ID: | 1.4.10.3 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a compare request that includes a purported
AttributeValueAssertion not present in an entry then the operation fails and a compare
response is returned with result code `noSuchAttribute'.
|
| Ref: | rfc2251#4.10 |
| Strategy: | BLITS 3.3.7.3.1
|
| ID: | 1.4.10.4 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a compare request that includes a specification of a
non-existant object then the operation fails and a compare response is returned with
resultCode `noSuchObject'.
|
| Ref: | rfc2251#4.10 |
| Strategy: | BLITS 3.3.7.3.2
|
5.7 DATA_MODEL
| ID: | 1.3.2.1 |
| Class: | B |
| Profile: | BASE |
| Text: | Every entry has an objectClass attribute
|
| Ref: | rfc2251#3.2.1 |
| Strategy: | `Every' statements require exhaustive testing
|
| ID: | 1.3.2.2 |
| Class: | A |
| Profile: | BASE |
| Text: | The objectClass attribute of an entry specifies the entry's
permitted attributes.
|
| Ref: | rfc2251#3.2.1 |
| Strategy: | |
| ID: | 1.3.2.3 |
| Class: | A |
| Profile: | BASE |
| Text: | The objectClass attribute of an entry can not be removed.
|
| Ref: | rfc2251#3.2.1 |
| Strategy: | |
| ID: | 1.3.2.4 |
| Class: | A |
| Profile: | BASE |
| Text: | When an entry is created all superclasses of the named classes are
implicitly added as well if not already present.
|
| Ref: | rfc2251#3.2.1 |
| Strategy: | |
| ID: | 1.3.2.5 |
| Class: | A |
| Profile: | |
| Text: | When an objectClass value is added to an entry all superclasses
of the named classes are implicitly added as well if not already present.
|
| Ref: | rfc2251#3.2.1 |
| Strategy: | |
| ID: | 1.3.2.6 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server does not permit clients to add attributes to an entry
unless those attributes are permitted by the objectClass definitions or the
schema controlling that entry, or unless those attributes are operational
attributes known to the server and used for administrative purposes.
|
| Ref: | rfc2251#3.2.1 |
| Strategy: | |
| ID: | 1.3.2.7 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | A server permits a client to add all user attributes to
an `extensibleObject' attribute.
|
| Ref: | rfc2251#3.2.1 |
| Strategy: | |
| ID: | 1.3.2.8 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a request to modify the creatorsname operational attribute
in an entry then that request will be rejected.
|
| Ref: | rfc2251#3.2.1 |
| Strategy: | |
| ID: | 1.3.2.9 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a request to modify the createTimestamp
operational attribute in an entry then that request will be rejected.
|
| Ref: | rfc2251#3.2.1 |
| Strategy: | |
| ID: | 1.3.2.10 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a request to modify the modifiersName
operational attribute in an entry then that request will be rejected.
|
| Ref: | rfc2251#3.2.1 |
| Strategy: | |
| ID: | 1.3.2.11 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a request to modify the modifyTimestamp
operational attribute in an entry then that request will be rejected.
|
| Ref: | rfc2251#3.2.1 |
| Strategy: | |
| ID: | 1.3.2.12 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a request to modify the subschemaSubentry
operational attribute in an entry then that request will be rejected.
|
| Ref: | rfc2251#3.2.1 |
| Strategy: | |
| ID: | 1.3.2.13 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server implements and provides access to subschema entries for any
entry that clients can modify.
|
| Ref: | rfc2251#3.2.2 |
| Strategy: | BLITS 3.3.13.1.2
EXPECTED: 2 entries returned with only the attribute subschemasubentry.
|
| ID: | 1.3.2.14 |
| Class: | B |
| Profile: | BASE |
| Text: | Every subschema entry includes a cn attribute that is used to form
its RDN.
|
| Ref: | rfc2251#3.2.2 |
| Strategy: | Exhaustive testing required.
|
| ID: | 1.3.2.15 |
| Class: | B |
| Profile: | BASE |
| Text: | Every subschema entry includes an objectClass attribute that has at
least the values "top" and "subschema".
|
| Ref: | rfc2251#3.2.2 |
| Strategy: | Exhaustive testing required.
|
| ID: | 1.3.2.16 |
| Class: | B |
| Profile: | BASE |
| Text: | Every subschema entry includes an objectClasses attribute, each
value of which specifies an object class known to the server.
|
| Ref: | rfc2251#3.2.2 |
| Strategy: | Exhaustive testing required.
|
| ID: | 1.3.2.17 |
| Class: | B |
| Profile: | BASE |
| Text: | Every subschema entry includes an attributeTypes attribute,
each value of which specifies an attribute type known to the server.
|
| Ref: | rfc2251#3.2.2 |
| Strategy: | Exhaustive testing required.
|
| ID: | 1.3.2.18 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request that requests a baseObject
search of the entry with a search filter "(objectClass=subschema)" then the
server returns the attributes from the subschema entry.
|
| Ref: | rfc2251#3.2.2 |
| Strategy: | BLITS 3.3.13.1.3
|
5.8 DELETE
| ID: | 1.4.8.1 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a delete request then it will attempt to delete
the entry whose distinguished name is contained in the request.
|
| Ref: | rfc2251#4.8 |
| Strategy: | BLITS 3.3.5.1
|
| ID: | 1.4.8.2 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a delete request then it will not dereference
aliases while resolving the name of the target entry to be removed.
|
| Ref: | rfc2251#4.8 |
| Strategy: | |
| ID: | 1.4.8.3 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a delete request that requests deletion of an entry
that has subordinate entries then the request will fail.
|
| Ref: | rfc2251#4.8 |
| Strategy: | BLITS 3.3.5.2.3
|
| ID: | 1.4.8.4 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a delete request then it will return the result
in a delete response.
|
| Ref: | rfc2251#4.8 |
| Strategy: | BLITS 3.3.5.2.1 (also allows #34 invalidDNSyntax)
|
5.9 DISCONNECTION
| ID: | 1.4.4.1 |
| Class: | B |
| Profile: | BASE |
| Text: | An unsolicited notification is sent by the server in the form of an LDAPMessage.
|
| Ref: | rfc2251#4.4 |
| Strategy: | Can not portably generate an unsolicited notification
|
| ID: | 1.4.4.2 |
| Class: | B |
| Profile: | BASE |
| Text: | The MessageID field in the LDAPMessage object sent by an unsolicited
notification has the value zero.
|
| Ref: | rfc2251#4.4 |
| Strategy: | Can not portably generate an unsolicited notification
|
| ID: | 1.4.4.3 |
| Class: | B |
| Profile: | BASE |
| Text: | The protocolOp of an unsolicited notification is of the extendedResp form.
|
| Ref: | rfc2251#4.4.0 |
| Strategy: | Can not portably generate an unsolicited notification
|
| ID: | 1.4.4.4 |
| Class: | B |
| Profile: | BASE |
| Text: | The responseName field of an unsolicited ExtendedResponse is present
and has the value 1.3.6.1.4.1.1466.20036
|
| Ref: | rfc2251#4.4.1 |
| Strategy: | Can not portably generate an unsolicited notification
|
| ID: | 1.4.4.5 |
| Class: | B |
| Profile: | BASE |
| Text: | The response filed of an unsolicited ExtendedResponse is absent.
|
| Ref: | rfc2251#4.4.1 |
| Strategy: | Can not portably generate an unsolicited notification
|
| ID: | 1.4.4.6 |
| Class: | B |
| Profile: | BASE |
| Text: | If the server has received data from the client in which the LDAPMessage structure
could not be parsed, then the server sends a notice of disconnection in which the resultCode
field has the value `protocolError'.
|
| Ref: | rfc2251#4.4.1 |
| Strategy: | Can not portably generate an unsolicited notification
|
| ID: | 1.4.4.7 |
| Class: | B |
| Profile: | BASE |
| Text: | If the server has detected that an established underlying security association
protecting communication between the client and server has unexpectedly failed or been
compromised then the server sends a notice of disconnection in which the resultCode field
has the value `strongAuthRequired'.
|
| Ref: | rfc2251#4.4.1 |
| Strategy: | Can not portably generate an unsolicited notification
|
| ID: | 1.4.4.8 |
| Class: | B |
| Profile: | BASE |
| Text: | If the server returns a notification of disconnection with the resultCode
field set to the value of `unavailable' then the server will not accept new
connections for an extended period of time.
|
| Ref: | rfc2251#4.4.1 |
| Strategy: | Can not portably generate an unsolicited notification. Also, `extended period of time' not rigorously defined.
|
| ID: | 1.4.4.9 |
| Class: | B |
| Profile: | BASE |
| Text: | If the server returns a notice of disconnection with the resultCode field
set to the value of `unavailable' then the server will not accept any new operation
requests on existing connections for an extended period of time.
|
| Ref: | rfc2251#4.4 |
| Strategy: | Can not portably generate an unsolicited notification. Also `extended period of time' not rigorously defined.
|
| ID: | 1.4.4.10 |
| Class: | B |
| Profile: | BASE |
| Text: | The LDAPOID value of the LDAPMessage sent by a server as an unsolicited
notification is unique for that notification and is not used in any other situation.
|
| Ref: | rfc2251#4.4.0 |
| Strategy: | Can not portably generate an unsolicited notification
|
| ID: | 1.4.4.11 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server sends a notice of disconnection then it will immediately
afterwards close the connection.
|
| Ref: | rfc2251#4.4.0 |
| Strategy: | Can not portably generate an unsolicited notification
|
5.10 EXTENDED
| ID: | 1.4.12.1 |
| Class: | B |
| Profile: | STANDARD |
| Text: | When a server receives an extended request then it will take
the OBJECT IDENTIFIER of the request name from the requestName field.
|
| Ref: | rfc2251#4.12 |
| Strategy: | Can't portably supoprt extended requests.
|
| ID: | 1.4.12.2 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives an extended request then it will respond
with a message containing an extended response.
|
| Ref: | rfc2251#4.12 |
| Strategy: | |
| ID: | 1.4.12.3 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives an extended request with a name that
it does not recognise then it returns only response fields from LDAPResult,
containing the `protocolError' result code.
|
| Ref: | rfc2251#4.12 |
| Strategy: | |
5.11 IMPLEMENTATION
5.12 MODIFY
| ID: | 1.4.6.1 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a modify request then it will not perform any
alias dereferencing in determining the object to be modified.
|
| Ref: | rfc2251#4.6 |
| Strategy: | |
| ID: | 1.4.6.2 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modify request then it performs the
modifications requested in the modification field of the request in the
order that they are listed as a single atomic operation.
|
| Ref: | rfc2251#4.6 |
| Strategy: | |
| ID: | 1.4.6.3 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modify request that includes an add modification
for an attribute that exists then it will add the listed values to the
attribute.
|
| Ref: | rfc2251#4.6 |
| Strategy: | BLITS 3.3.3.1.2
|
| ID: | 1.4.6.4 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modify request that includes an add modification
for an attribute that does not exist then it will create the attribute and add
the listed values to it.
|
| Ref: | rfc2251#4.6 |
| Strategy: | BLITS 3.3.3.1.1
|
| ID: | 1.4.6.5 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modify request that includes a delete modification
that does not list any values then it will remove the entire attribute.
|
| Ref: | rfc2251#4.6 |
| Strategy: | BLITS 3.3.3.2.3 - modified to test that attribute has been removed.
|
| ID: | 1.4.6.6 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modify request that includes a delete modification
that lists some values but not all current values of the attribute then it will
delete those values from the attribute.
|
| Ref: | rfc2251#4.6 |
| Strategy: | BLITS 3.3.3.2.1
|
| ID: | 1.4.6.7 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modify request that includes a delete modification
that lists all current values of an attribute then it will remove the entire
attribute.
|
| Ref: | rfc2251#4.6 |
| Strategy: | BLITS 3.3.3.2.3 modified to test for the removal of the attribute.
|
| ID: | 1.4.6.8 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modify request that includes a replace modification
with values for an attribute that exists then it will replace all current
values of that attribute with the new values.
|
| Ref: | rfc2251#4.6 |
| Strategy: | BLITS 3.3.3.3.2 (modified)
|
| ID: | 1.4.6.9 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modify request that includes a replace modification
with values for an attribute that does not exist then it will create a new
attribute with those values.
|
| Ref: | rfc2251#4.6 |
| Strategy: | |
| ID: | 1.4.6.10 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modify request that includes a replace modification
with no values for an attribute that exists then it will delete the entire
attribute.
|
| Ref: | rfc2251#4.6 |
| Strategy: | BLITS 3.3.3.3.3
|
| ID: | 1.4.6.11 |
| Class: | A |
| Profile: | |
| Text: | When a server receives a modify request that includes a replace modification
with no values for an attribute that does not exist then it will ignore that replace
modification.
|
| Ref: | rfc2251#4.6 |
| Strategy: | |
| ID: | 1.4.6.12 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modify request and does not complete the DIT
modification successfully then it returns a modify response indicating the reason that
the modification failed
|
| Ref: | rfc2251#4.6 |
| Strategy: | BLITS 3.3.3.1.3.1
|
| ID: | 1.4.6.13 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modify request and does not complete the DIT
modification successfully then it does not perform any of the requested modifications.
|
| Ref: | rfc2251#4.6 |
| Strategy: | BLITS 3.3.3.1.3.2
|
| ID: | 1.4.6.14 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modify request that includes a request to remove
any of the values that form the entry's distingushed name then the server will
return the result code `notAllowedOnRDN'.
|
| Ref: | rfc2251#4.6 |
| Strategy: | BLITS 3.3.3.3.4.2
|
5.13 MODIFYDN
| ID: | 1.4.9.1 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modifyDN request then it will take the
distinguished name of the entry to be changed from the entry field of the
request.
|
| Ref: | rfc2251#4.9 |
| Strategy: | BLITS 3.3.6.1
|
| ID: | 1.4.9.2 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modifyDN request then it will form the leftmost
component of the new name of the entry from the contents of the newrdn field of
the request.
|
| Ref: | rfc2251#4.9 |
| Strategy: | BLITS 3.3.6.3
|
| ID: | 1.4.9.3 |
| Class: | A |
| Profile: | |
| Text: | When a server receives a modifyDN request and the deleteoldrdn field
is TRUE then the old RDN attribute values will be deleted from the entry.
|
| Ref: | rfc2251#4.9 |
| Strategy: | BLITS 3.3.6.5
|
| ID: | 1.4.9.4 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modifyDN request and the deleteoldrdn field
is FALSE then the old RDN attribute values will be retained as non-distinguished
attributes of the entry.
|
| Ref: | rfc2251#4.9 |
| Strategy: | |
| ID: | 1.4.9.5 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a modifyDN request and the newSuperior field is
present then the entry whose distinguished name is in that field will become the
immediate superior of the existing entry.
|
| Ref: | rfc2251#4.9 |
| Strategy: | BLITS 3.3.6.2
|
| ID: | 1.4.9.6 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modifyDN request then it will attempt to perform
the name change and will return the result of the attempt in a modifyDN response.
|
| Ref: | rfc2251#4.9 |
| Strategy: | BLITS 3.3.6.7.2
|
| ID: | 1.4.9.7 |
| Class: | A |
| Profile: | BASE |
| Text: | If a modifyDN request is made to change an entry name to a new target
name, and the newSuperior parameter is absent and an entry already exists with the
target name then the operation will fail and a result code of `entryAlreadyExists'
is returned.
|
| Ref: | rfc2251#4.9 |
| Strategy: | BLITS 3.3.6.7.1
Using cn=Harold Wilson instead of Paul Cezanne to avoid side-effects.
|
| ID: | 1.4.9.8 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a modifyDN request for which the setting of the deleteoldrdn
parameter would cause a schema inconsistency in the entry then it will not perform the
operation and will return an error code.
|
| Ref: | rfc2251#4.9 |
| Strategy: | |
5.14 PROTOCOL
| ID: | 1.4.0.1 |
| Class: | B |
| Profile: | BASE |
| Text: | A server ignores elements of SEQUENCE encodings whose tags it does not recognise.
|
| Ref: | rfc2251#4.0 |
| Strategy: | No portable way to modify encoded message.
|
| ID: | 1.4.0.2 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives an LDAP request from a client that has
not first issued a bind request then the server assumes that the client
supports LDAP version 3.
|
| Ref: | rfc2251#4.0 |
| Strategy: | |
5.15 SEARCH
| ID: | 1.4.5.1 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request then it performs the search relative to the
base object entry specified by the distinguished name in the baseObject field.
|
| Ref: | rfc2251#4.5 |
| Strategy: | BLITS 3.3.2.1.1
|
| ID: | 1.4.5.2 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request with a scope of
baseObject then it performs the search in the entry specified by the
baseObject field.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.3 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request with a scope of singleLevel then it
performs the search in the entries that are first level children of the entry specified
by the baseObject field.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.1.6
|
| ID: | 1.4.5.4 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request with a scope of
wholeSubtree then it performs the search in the entire subtree whose
root is the entry specified by the baseObject field.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.5 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request with the derefAliases field set to
neverDerefAliases then it will not dereference aliases in searching or in locating the base
object of the search.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.7.1
|
| ID: | 1.4.5.6 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request with the derefAliases field set to
derefInSearching then it will dereference aliases in subordinates of the base object in
searching.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | Modified version of BLITS 3.3.2.7.4. See DIF resolution 2003-04-01. Jonny Adams is
an alias in ou=Americas and points to Jonathan Adams in ou=Europe. A search on ou=Americas
should dereference Jonny Adams and lead to Jonathan Adams for a postive match.
|
| ID: | 1.4.5.7 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request with the derefAliases field set to
derefInSearching then it will not dereference aliases in locating the base object of the
search.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.7.3
|
| ID: | 1.4.5.8 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request with the derefAliases field set
to derefFindingBaseObj then it will dereference aliases in locating the base object
of the search.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.7.5
|
| ID: | 1.4.5.9 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request with the derefAliases field set to
derefFindingBaseObj then it will not dereference aliases when searching subordinates of the
base object.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | formerly BLITS 3.3.2.7.6, changed since VSLDAP-2.0-beta3
|
| ID: | 1.4.5.10 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request with the derefAliases field set to
derefAlways then it will dereference aliases both in searching and in locating the base
object of the search.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.7.7
|
| ID: | 1.4.5.11 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request with a value other than 0 in the
sizelimit field then it will restrict the maximum number of entries that it will return to
that value.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.8.1
|
| ID: | 1.4.5.12 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request with a value other than 0 in the
timelimit field then it will restrict the maximum time allowed for the search to that
value, measured in seconds.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.8.2
|
| ID: | 1.4.5.13 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request with the typesOnly field set to TRUE
then it will return only attribute types, not values.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.8.3
|
| ID: | 1.4.5.14 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request with the typesOnly field set to FALSE
then it will return both attribute types and values.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | cf 1.4.5.14 - i.e. inverse of BLITS 3.3.2.8.3
|
| ID: | 1.4.5.15 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter evaluates to TRUE for a
particular entry then it returns the attributes of that entry as part of the search
result, subject to any applicable access control restrictions.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.16 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter evaluates to FALSE for a
particular entry then it ignores that entry for the search.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | wholeSubtree search - for Sophia Loren and Fried Egg. There is no Fried Egg, so expect only Sophia Loren to be returned.
|
| ID: | 1.4.5.17 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter evaluates to
Undefined for a particular entry then it ignores that entry for the search.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | wholeSubtree search - filter contains two elements - one evaluates TRUE, the other UNDEFINED. Expect a single entry from the TRUE filter.
|
| ID: | 1.4.5.18 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter contains an "and"
choice then the choice evaluates to TRUE if all the filters in the choice SET OF evaluate
to TRUE.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.2.1.1
|
| ID: | 1.4.5.19 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter contains an "and" choice
then the choice evaluates to FALSE if at least one filter in the choice SET OF evaluates
to FALSE.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | wholeSubtree search for two objects - one real, one false. Expect zero entries
returned.
|
| ID: | 1.4.5.20 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter contains an "and" choice
then the choice evaluates to Undefined if not all filters in the choice SET OF evaluate
to TRUE and no filter in the choice SET OF evaluates to FALSE.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.4.1
|
| ID: | 1.4.5.21 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter contains an "or" choice
then the choice evaluates to FALSE if all the filters in the choice SET OF evaluate to
FALSE.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | wholeSubtree search - filter has two items, both false, which are combined by
OR. Expect: No entries returned.
|
| ID: | 1.4.5.22 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter contains an "or" choice
then the choice evaluates to TRUE if at least one filter in the choice SET OF evaluates to
TRUE.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.2.1.3
|
| ID: | 1.4.5.23 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter contains an "or" choice
then the choice evaluates to Undefined if not all filters in the choice SET OF evaluate to
FALSE and no filter in the choice SET OF evaluates to TRUE.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | wholeSubtree search: filter has two components, (foo=bar) evaluates Undefined,
(cn=Fried Egg) evaluates False. Expect no entries returned.
|
| ID: | 1.4.5.24 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter contains a "not" choice
then the choice evaluates to TRUE if the filter being n |