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 negated is FALSE.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.2.2.1
|
| ID: | 1.4.5.25 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter contains a "not" choice
then the choice evaluates to FALSE if the filter being negated is TRUE.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | inverse of BLITS 3.3.2.2.2.1 - expect 2 entries, both title!=Director
|
| ID: | 1.4.5.26 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter contains a "not" choice
then the choice evaluates to Undefined if the filter being negated is Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.4.3 strategy proved unsuitable for testing. There is no obvious way to
test this feature without generating non-zero result codes.
|
| ID: | 1.4.5.27 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter contains a present match
then the match evaluates to TRUE where there is an attribute or subtype of the specified
attribute description present in an entry.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.1.6 - modified for a wholeSubtree search of
"ou=Shareholder Services, ou=Fin-Accounting, ou=Americas, ou=Search, o=IMC, c=US"
EXPECTED: Expect 37 entries with title attribute present in all.
|
| ID: | 1.4.5.28 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter contains a present match
then the match evaluates to FALSE where there is no attribute or subtype of the specified
attribute description present in an entry.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.1.6 - modified for a wholeSubtree search of
"ou=Shareholder Services, ou=Fin-Accounting, ou=Americas, ou=Search, o=IMC, c=US"
filter: (uid=*)
EXPECTED: Expect no entries with foo attribute present.
|
| ID: | 1.4.5.29 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the filter contains a present match
then the match evaluates to FALSE when the specified attribute description is not
recognised.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.1.6 - modified for a wholeSubtree search of
"ou=Shareholder Services, ou=Fin-Accounting, ou=Americas, ou=Search, o=IMC, c=US"
filter: (foo=*)
EXPECTED: Expect no entries with foo attribute present.
|
| ID: | 1.4.5.30 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a search request and the filter contains an
extensibleMatch and the matchingRule field is absent then the match evaluates
to the result of the equality match performed for the type specified in the type
field.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.31 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a search request and the filter contains an
extensibleMatch and the type field is absent and the matchingRule field is
present and the matchValue matches at least one attribute in the entry according
to the matching rule specified in the matchingRule field then the filter item
evaluates to TRUE.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.32 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a search request and the filter contains
an extensibleMatch and the type field is absent and the matchingRule field
is present and the matchValue does not match any attribute in the entry
according to the matching rule specified in the matchingRule field then the
filter item evaluates to FALSE.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.33 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a search request and the filter contains an
extensibleMatch and the type field is absent and the matchingRule field is
present and the matchingRule is not recognised then the filter item evaluates
to Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.34 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a search request and the filter contains an
extensibleMatch and the type field is absent and the matchingRule field is
present and the assertionValue cannot be parsed then the filter item evaluates
to Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.35 |
| Class: | B |
| Profile: | ADVANCED |
| Text: | When a server receives a search request and the filter contains an
extensibleMatch and the type field is present and the matchingRule field is
present and the matchingRule is not one permitted for use with that type then
the filter item evaluates to Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | Not portable
|
| ID: | 1.4.5.36 |
| Class: | B |
| Profile: | ADVANCED |
| Text: | When a server receives a search request and the filter contains an
extensibleMatch and the type field is present and the matchingRule field is
present and the matchingRule is one permitted for use with that type and the
dnAttributes field is set to TRUE and there is at least one attribute in the
entry's distinguished name for which the filter item evaluates to TRUE the
then the filter item evaluates to TRUE for the match.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | Not Portable
|
| ID: | 1.4.5.37 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a search request and the server is not able
to determine whether the assertion value for a filter item matches an entry
then the filter item evaluates to Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | Unable to portably test a servers ability to not match an entry
|
| ID: | 1.4.5.38 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and an attribute description in
an equalityMatch is not recognised by the server then the filter evaluates to
Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.1.1 - modified to use filter (bn=Pat Bakers). Expect zero
entries returned: Undefined filter.
|
| ID: | 1.4.5.39 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and an attribute description
in a substrings match is not recognised by the server then the filter evaluates
to Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.1.2 - modified to use filter (foo=p*smith). Expect no entries
returned. (Filter Undefined)
|
| ID: | 1.4.5.40 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and an attribute description in a
greaterOrEqual match is not recognised by the server then the filter evaluates to Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.1.5 - modified to use filter (foo>=2200500). Expect no entries
returned. (Filter Undefined)
|
| ID: | 1.4.5.41 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and an attribute description
in a lessOrEqual match is not recognised by the server then the filter
evaluates to Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.42 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and an attribute description
in an approxMatch is not recognised by the server then the filter evaluates to
Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.1.3 - modified to use filter (foo~=clint). Expect no entries
returned. (Filter Undefined)
|
| ID: | 1.4.5.43 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a search request and an attribute description
in an extensibleMatch is not recognised by the server then the filter evaluates
to Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.44 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a search request and a matching rule id
in an extensibleMatch is not recognised by the server then the filter
evaluates to Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.45 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the assertion value
cannot be parsed by the server then the filter evaluates to Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | BLITS 3.3.2.9.1 - test with user-supplied result code
|
| ID: | 1.4.5.46 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a search request and the type of
filtering requested is not implemented by the server then the filter
evaluates to Undefined.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.47 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | When a server receives a search request and the server does
not recognise a matching rule id then it does not return an error.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | This uses same strategy as 1.4.5.44
EXPECTED: Search returns resultCode `success'
|
| ID: | 1.4.5.48 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and it cannot parse an assertion
value then it does not return an error.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | use filter containing non-textual values. Expect zero entries returned.
filter: (cn=Pa\n\t\rt Bakers)
baseObject: "ou=Search, o=IMC, c=US"
|
| ID: | 1.4.5.49 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request then the attributes that
it returns from each entry which matches the search filter are those specified
in the attributes field of the search request.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | baseObject search: Request attributes (givenname, password, title)
baseObject: "ou=Americas, ou=Search, o=IMC, c=US"
filter: (cn=Clint Eastwood)
|
| ID: | 1.4.5.50 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the attributes field contains
an empty list then the server returns all user attributes from each entry which
matches the search filter.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.51 |
| Class: | A |
| Profile: | BASE |
| Text: | Each entry returned in a
SearchResultEntry will contain all attributes, complete with associated
values if necessary, as specified in the attributes field of the Search
Request. Return of attributes is subject to access control and other
administrative policy.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.52 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a search request then it returns any attribute at
most once in an entry.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | Untestable - can not portably force server to return an attribute more than once
per entry
|
| ID: | 1.4.5.53 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and there are attribute descriptions
in the attributes field that it does not recognise then it ignores those attribute
descriptions.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.54 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a search request and the attributes field contains a
list containing only the attribute with OID "1.1" then the server will not return any
attributes.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.55 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request then it will only
return operational attributes that are listed by name.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.56 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a search request in an LDAP session that is operating
over TCP then the server will return to the client a sequence of responses in separate
LDAP messages, including a response message containing a SearchResultEntry for each entry
found during the search.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.57 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a search request in an LDAP session that is operating
over TCP then the server will return to the client a sequence of responses in separate
LDAP messages, including a response message containing a SearchResultReference for each
area not explored during the search.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.58 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a search request in an LDAP session that is operating
over TCP then the server will return to the client a sequence of responses in separate
LDAP messages, including SearchResultEntry or SearchResultReference response messages,
then a SearchResultDone message will follow all the SearchResultEntry and SearchResultReference
response messages.
|
| Ref: | rfc2251#4.5.1 |
| Strategy: | |
| ID: | 1.4.5.59 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request and can not locate the
baseObject then it does not return a SearchResultReference.
|
| Ref: | rfc2251#4.5.3 |
| Strategy: | |
5.16 SERVER-SPECIFIC
5.17 SPECIFIC
| ID: | 1.3.4.1 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server maintains a supportedLDAPVersion attribute in the root DSE that identifies the LDAP versions that it implements. These include LDAP v3.
|
| Ref: | rfc2251#3.4 |
| Strategy: | |
| ID: | 1.3.4.1 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a search request starting at root, with
subtree scope the root DSE attributes are not accessible.
|
| Ref: | rfc2251#3.4 |
| Strategy: | Not portably testable.
|
| ID: | 1.3.4.3 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server maintains a namingContext attribute in the root DSE
that identifies the naming contexts held in the server.
|
| Ref: | rfc2251#3.4 |
| Strategy: | |
| ID: | 1.3.4.2 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server maintains a subschemaSubentry attribute in the root DSE
that identifies the subschema entries known by the server.
|
| Ref: | rfc2251#3.4 |
| Strategy: | BLITS 3.3.13.1.1
|
| ID: | 1.3.4.5 |
| Class: | B |
| Profile: | BASE |
| Text: | A server maintains an altServer attribute in the root DSE
that identifies alternative servers that may be used when it is unavailable.
|
| Ref: | rfc2251#3.4 |
| Strategy: | test removed - altSever attribute not mandatory
|
| ID: | 1.3.4.6 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server maintains a supportedExtension attribute in the root DSE
that identifies its supported extended operations.
|
| Ref: | rfc2251#3.4 |
| Strategy: | |
| ID: | 1.3.4.7 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | A server maintains a supportedControl attribute in the root DSE
that identifies its supported controls.
|
| Ref: | rfc2251#3.4 |
| Strategy: | |
| ID: | 1.3.4.8 |
| Class: | C |
| Profile: | ADVANCED |
| Text: | A server maintains a supportedSASLMechanisms attribute in the
root DSE that identifies its supported SASL security features.
|
| Ref: | rfc2251#3.4 |
| Strategy: | |
| ID: | 1.3.4.9 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server maintains a supportedLDAPVersion attribute in the
root DSE that identifies the LDAP versions that it implements.
|
| Ref: | rfc2251#3.4 |
| Strategy: | |
5.18 UNBIND
| ID: | 1.4.3.1 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives an unbind request it will terminate the protocol session
|
| Ref: | rfc2251#1.4.3 |
| Strategy: | BLITS 3.3.1.2
|
6 RFC2252
6.1 MATCHINGRULES
| ID: | 2.8.4.1 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | If a server allows subschema entries to be modified by clients then
it supports the integerFirstComponentMatch matching rule defined in
section 8.4 of RFC 2252.
|
| Ref: | rfc2252#8.4.1 |
| Strategy: | BLITS 3.3.13.1.3
|
| ID: | 2.8.4.2 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | If a server allows subschema entries to be modified by clients
then it supports the objectIdentifierFirstComponentMatch matching
rule defined in section 8.4 of RFC 2252.
|
| Ref: | rfc2252#8.4.2 |
| Strategy: | BLITS 3.3.13.1.3
|
6.2 OPERATIONAL
| ID: | 2.5.2.1 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server maintains in the root DSE a namingContext attribute that identifies
the naming contexts held in the server.
|
| Ref: | rfc2252#5.2.1 |
| Strategy: |
EXPECTED: attribute namingContexts returned
|
| ID: | 2.5.2.2 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server maintains in the root DSE a altServer attribute that identifies
the naming contexts held in the server.
|
| Ref: | rfc2252#5.2.2 |
| Strategy: |
EXPECTED: attribute altServer returned
|
| ID: | 2.5.2.3 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server maintains a supportedExtension attribute in the root DSE that identifies its
supported extended operations.
|
| Ref: | rfc2252#5.2.3 |
| Strategy: |
EXPECTED: supportExtension returned with zero or more values.
|
| ID: | 2.5.2.4 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | The server maintains a supportedControl attribute in the root DSE that identifies its
supported controls.
|
| Ref: | rfc2252#5.2.4 |
| Strategy: |
EXPECTED: attribute supportControl returned with declared OID as a value
|
| ID: | 2.5.2.5 |
| Class: | C |
| Profile: | ADVANCED |
| Text: | A server recognizes the supportedSASLMechanisms attribute.
|
| Ref: | rfc2252#5.2.5 |
| Strategy: |
EXPECTED: EXTERNAL to be declared as an attribute value.
|
| ID: | 2.5.2.6 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server maintains a supportedLDAPVersion attribute in the root DSE that identifies the
LDAP versions that it implements. These include LDAP v3
|
| Ref: | rfc2252#5.2.6 |
| Strategy: |
EXPECTED: attribute supportedLDAPVersion returned with value '3'
|
6.3 STANDARD
| ID: | 2.5.1.1 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server recognizes the createTimestamp attribute
|
| Ref: | rfc2252#5.1.1 |
| Strategy: |
EXPECTED: attribute createTimestamp returned
|
| ID: | 2.5.1.2 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server recognizes the modifyTimestamp attribute.
|
| Ref: | rfc2252#5.1.2 |
| Strategy: |
EXPECTED: attribute modifyTimestamp returned (value irrelevant)
|
| ID: | 2.5.1.3 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server recognizes the creatorsName attribute.
|
| Ref: | rfc2252#5.1.3 |
| Strategy: |
EXPECTED: attribute creatorsName returned
|
| ID: | 2.5.1.4 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server recognizes the modifiersName attribute.
|
| Ref: | rfc2252#5.1.4 |
| Strategy: |
EXPECTED: attribute modifiersName returned (value irrelevant)
|
| ID: | 2.5.1.5 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server recognizes the subschemaSubentry attribute.
|
| Ref: | rfc2252#5 |
| Strategy: |
EXPECTED: attribute subschemaSubentry returned
|
| ID: | 2.5.1.6 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server recognizes the attributeTypes attribute.
|
| Ref: | rfc2252#5.1.6 |
| Strategy: |
EXPECTED: attribute attributeTypes returned
|
| ID: | 2.5.1.7 |
| Class: | A |
| Profile: | STANDARD |
| Text: | A server recognizes the objectClasses attribute.
|
| Ref: | rfc2252#5.1.7 |
| Strategy: |
EXPECTED: attribute objectClasses returned
|
| ID: | 2.5.1.8 |
| Class: | B |
| Profile: | ADVANCED |
| Text: | A server recognizes the matchingRules attribute.
|
| Ref: | rfc2252#5.1.8 |
| Strategy: | This assertion is currently classified untestable following DIF resolution
petaining to problem report VSLDAP-2.0-beta3-0038. Issue - should servers maintain values for
standard matchingRules or just non-standard ones?
EXPECTED: attribute matchingRules returned
|
| ID: | 2.5.1.9 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | A server recognizes the matchingRuleUse attribute.
|
| Ref: | rfc2252#5.1.9 |
| Strategy: |
EXPECTED: attribute matchingRuleUse returned
|
6.4 SYNTAXES
| ID: | 2.4.3.1 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server generates an encoding where an arbitrary string, not
a distinguished Name, is used as part of a larger production, and
other than as part of a Distinguished name, and the string contains
a backslash character('\' ASCII 92), then the backslash character is
represented in the encoding by '\5c' or '\5C'.
|
| Ref: | rfc2252#4.3.1 |
| Strategy: | not portably testable
|
| ID: | 2.4.3.2 |
| Class: | A |
| Profile: | |
| Text: | When a server processes an encoding where an arbitrary string,
is used as part of a larger production,
other than as part of a distinguished name, and the encoding
contains '\5c' or '\5C', then the '\5c' or '\5C' is recognised
as the encoding of the backslash character('\'ASCII 92).
|
| Ref: | rfc2252#4.3.2 |
| Strategy: |
EXPECTED: entry cn=Network Manager,... with attribute postalAddress containing the string "14\z"
|
| ID: | 2.4.3.3 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server generates an encoding where an arbitrary string, not
a Distinguished name, is used as part of a larger production, and other
than as part of a Distiguished name, and the string contains an
apostrophe character (''' ASCII 39), then the apostrophe character is
represented in the encoding by '\27'.
|
| Ref: | rfc2252#4.3.3 |
| Strategy: | not portably testable
|
| ID: | 2.4.3.4 |
| Class: | A |
| Profile: | |
| Text: | When a server processes an encoding where an arbitrary string,
is used as part of a larger production,
other than as part of a Distinguished name, and the encoding contains
'\27', then the '\27' is recognized as the encoding of the apostrophe
character (''' ASCII 39).
|
| Ref: | rfc2252#4.3 |
| Strategy: |
EXPECTED: entry cn=SyntaxTest,... returned
|
| ID: | 2.4.3.5 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server generates an encoding where an arbitrary string,
not a distinguished name, is used as part of a larger production,
and other than as part of a Distiguished Name, and the string contains
a dollar character ('$' ASCII 36), then the dollar character is
represented in the encoding by '\24'.
|
| Ref: | rfc2252#4.3.5 |
| Strategy: | not portably testable
|
| ID: | 2.4.3.6 |
| Class: | A |
| Profile: | |
| Text: | When a server proceses an encoding where an arbitrary string
is used as part of a larger production,
other than as part of a Distinguished name, and the encoding contains
'\24', then the '\24' is recognised as the encoding of the dollar
character ('$' ASCII 36).
|
| Ref: | rfc2252#4.3.6 |
| Strategy: |
EXPECTED: entry cn=SyntaxTest returned
|
| ID: | 2.4.3.7 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server generates an encoding where an arbitrary string,
not a Distinguished Name, is used as part of a larger production,
and other than as part of a Distinguished Name, and the string
contains an octothorpe character ('#' ASCII 35), then the octothorpe
character is represented in the encoding by '\23'.
|
| Ref: | rfc2252#4.3.7 |
| Strategy: | not portably testable
|
| ID: | 2.4.3.8 |
| Class: | A |
| Profile: | |
| Text: | When a server proceses an encoding where an arbitrary string is used as
part of a larger production, other than as part of a Distinguished Name,
and the encoding contains '\23', then the '\23' is recognised as the
encoding of the octothorpe character ('#' ASCII 35).
|
| Ref: | rfc2251#4.3.8 |
| Strategy: |
EXPECTED: entry cn=SyntaxTest returned
|
| ID: | 2.4.3.9 |
| Class: | A |
| Profile: | |
| Text: | When a server generates attribute values in search responses
and the attribute syntax name is that of Binary then server
implements the form defined in section 4.3.1 of RFC 2252 for
generating those values.
|
| Ref: | rfc2252#4.3.9 |
| Strategy: |
EXPECTED: entry cn=Jupiter Jones with attribute bval;binary returned.
|
| ID: | 2.4.3.10 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server parses attribute values in add requests and the attribute type
is recognised and the attribute syntax name is that of Binary then the server
implements the form defined in section 4.3.1 of RFC 2252 for parsing those values.
|
| Ref: | rfc2251#4.3.10 |
| Strategy: | |
| ID: | 2.4.3.11 |
| Class: | A |
| Profile: | BASE |
| Text: | If a server parses attribute values in a compare request and the attribute
syntax name is that of Binary then the server implements the form defined
in section 4.3.1 of RFC 2252 for parsing those values.
|
| Ref: | rfc2252#4.3.11 |
| Strategy: | |
| ID: | 2.4.3.12 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server parses attribute values in modify requests and
the attribute type is recognised and the attribute syntax name is
that of binary than the server implements the form defined in
section 4.3.1 of RFC 2252 for parsing those values.
|
| Ref: | rfc2252#4.3.12 |
| Strategy: | |
6.5 TYPE
| ID: | 2.4.2.1 |
| Class: | B |
| Profile: | BASE |
| Text: | A server correctly processes Attributes TypeDescription quantities.
|
| Ref: | rfc2252#2.4.2 |
| Strategy: | Removed.
|
| ID: | 2.4.2.2 |
| Class: | B |
| Profile: | BASE |
| Text: | A server correctly generates attribute TypeDescription quantities.
|
| Ref: | rfc2252#2.4.2 |
| Strategy: | Removed.
|
| ID: | 2.4.2.3 |
| Class: | B |
| Profile: | BASE |
| Text: | For each additional name or attribute not listed in RFC2252 that
a server recognizes, the server publishes the definition of the type
in the attributeTypes attribute of its subschema entries.
|
| Ref: | rfc2252#4.2.3 |
| Strategy: | Not portably testable.
|
| ID: | 2.4.2.4 |
| Class: | B |
| Profile: | BASE |
| Text: | For each additional object class not listed in RFC2252 that
a server implements the server publishes the definition of
the class in the objectClasses attribute of its subschema entries.
|
| Ref: | rfc2252#4.2.4 |
| Strategy: | Not portably testable.
|
| ID: | 2.4.2.5 |
| Class: | B |
| Profile: | BASE |
| Text: | For each additional matchingRule not listed in RFC2252 that
a server implements the server publishes the definition of
the matching rule in the matchingRules attribute of its subschema entries.
|
| Ref: | rfc2252#4.2.5 |
| Strategy: | Not portably testable.
|
| ID: | 2.4.2.6 |
| Class: | A |
| Profile: | ADVANCED |
| Text: | If a server supports the extensibleMatch, it publishes the relationship
between the matchingRule and its attributes in the matchingRuleUse attribute.
|
| Ref: | rfc2252#2.4.6 |
| Strategy: | BLITS 3.3.13.1.3
|
7 RFC2253
7.1 CONVERSION
| ID: | 3.2.1.1 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representation of a DistinguishedName
in which the RDNSequence component is an empty sequence, then the RDNSequence
is decoded as an empty (or zero length) string.
|
| Ref: | rfc2253#2.1.1 |
| Strategy: | BLITS 3.3.13.1.3
|
| ID: | 3.2.1.2 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representation of a DistinguishedName
in which the RDNSequence component is not an empty sequence, then the RDNsequence
is converted to a sequence of UTF-8 string-encoded relativeDistinguishedNames
with the elements occuring in reverse order(i.e last element comes first) in the
representation.
|
| Ref: | rfc2253#2.1.2 |
| Strategy: |
EXPECTED: entry cn=syntaxtest returned
|
| ID: | 3.2.1.3 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a non-empty string representation of an RDNSequence
the adjoining Relative Distinguished Name elements are separated by a comma
character(',' ASCII 44)in representation.
|
| Ref: | rfc2253#2.1.3 |
| Strategy: |
EXPECTED: entry cn=SyntaxTest returned
|
| ID: | 3.2.2.1 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representation of an RDNSequence containing
multi-valued RDN element, then the values of the RDN are seperated by a
plus character('+' ASCII 43) in the representation.
|
| Ref: | rfc2253#2.2.1 |
| Strategy: |
EXPECTED: entry ou=Corporate Tax returned.
|
| ID: | 3.2.2.2 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server generates a RelativeDistinguishedName in a Distinguished Name,
the output consists of the string encodings of each AttributeTypeAndValue.
(Note: they can be in any order.)
|
| Ref: | rfc2253#2.2.2 |
| Strategy: |
EXPECTED: entry cn=SyntaxTest returned
|
| ID: | 3.2.3.1 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representation of a DistinguishedName,
each AttributeTypeValue in the DN is generated as the string
representation of the attributeType, followed by an equals character
('=' ASCII 61), followed by the string representation of the AttributeValue.
|
| Ref: | rfc2253#2.3.1 |
| Strategy: |
EXPECTED: entry cn= Apollo returned
|
| ID: | 3.2.3.2 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representation of a Distinguished Name
and an AttributeType is in a published table of attribute types
associated with RFC2252, then the type name string from that
table is used in the representation.
|
| Ref: | rfc2252#2.3.2 |
| Strategy: | BLITS 3.3.13.1.3
|
| ID: | 3.2.3.3 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server produces a string representation of a DistinguishedName and
an AttributeType is not in published table of attribute types associated with RFC2252,
then the generated type name string is the dotted-decimal encoding of the AttributeType's
OBJECT IDENTIFIER.
|
| Ref: | rfc2252#2.3.3 |
| Strategy: | not testable
|
| ID: | 3.2.4.1 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representation of a RelativeDistiguishedName
that contains an attributeValue which is of a type that does not have a string
representation defined for it then it is generated in UTF-8 string form as an
octothorpe character('#' ASCII 35) followed by the hexadecimal representation of
each of the bytes of the BER encoding of the AttributeValue.
|
| Ref: | rfc2253#2.4.1 |
| Strategy: | |
| ID: | 3.2.4.2 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server produces a string representation of a RelativeDistinguishedName
and the RDN contains an AttributeValue containing an initial space
character(''ASCII 32), then the character is represented in the output string
representation by a space character prefixed by a backslash character ('\' ASCII 92).
|
| Ref: | rfc2253#2.4.2 |
| Strategy: |
EXPECTED: entry cn= Apollo returned
|
| ID: | 3.2.4.3 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representation of a RelativeDistinguishedName
and the RDN contains an AttributeValue containing an initial octothorpe
character('#' ASCII 35) then the character is represented in the output string
by an initial octothorpe character prefixed by a backslash character ('\' ASCII 92).
|
| Ref: | rfc2252#2.4.3 |
| Strategy: |
EXPECTED: entry cn=Ac#illes returned
|
| ID: | 3.2.4.4 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server produces a string representation of a relativeDistinguishedName
and the RDN contains an AttributeValue containing a space character(''ASCII32)
at the end of the string then the character is represented in the output string
by a space character prefixed by a backslash character('\'ASCII 92).
|
| Ref: | rfc2252#2.4.4 |
| Strategy: |
EXPECTED: entry cn=Hector returned
|
| ID: | 3.2.4.5 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representaton of a RelativeDistinguishedName
and the RDN contains an AttributeValue containing a comma character
(',' ACSII 43) then the character is represented in output string by a comma
character prifixed by a backslash character ('\' ASCII 92).
|
| Ref: | rfc2252#2.4.5 |
| Strategy: |
EXPECTED: entry cn=Aurelius,Marcus returned
|
| ID: | 3.2.4.6 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server produces a string representation of a RelativeDistinguishedName
and the RDN contains an AttributeValue containing a plus character
('+' ASCII 43) then the character is represented in the output string by
a plus character prefixed by a backslash character(\' ASCII 92).
|
| Ref: | rfc2252#2.4.6 |
| Strategy: | Test is not portable. Cannot guarantee that server will import the test entry.
|
| ID: | 3.2.4.7 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representation of a RelativeDistinguishedName
and the RDN contains an AttributeValue containing a quote character
('"' ASCII 34) then the character is represented in output string by a quote
character prefixed by a backslash character ('\' ASCII 92).
|
| Ref: | rfc2252#2.4.2 |
| Strategy: |
EXPECTED: entry cn="Paris" returned
|
| ID: | 3.2.4.8 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representation of a RelativeDistinguishedName
and the RDN contains an AttributeValue containing a backslash character ('\' ASCII 92)
then the character is represented in the output string by a backslash character
prefixed by a backslash character.
|
| Ref: | rfc2252#2.4.8 |
| Strategy: |
EXPECTED: entry cn=Mars\Ares returned
|
| ID: | 3.2.4.9 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representation of a RelativeDistinguishedName
and the RDN contains an AttributeValue containing a less-than character
('<' ASCII 60) then the character is represented in output string by a less-than
character prefixed by a backslash character ('\' ASCII 92).
|
| Ref: | rfc2252#2.4.9 |
| Strategy: |
EXPECTED: entry cn=Rome |
| ID: | 3.2.4.10 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representation of a Relative Distinguished Name
and the RDN contains an AtrributeValue containing a greater-than character
('>' ASCII 62) then the character is represented in the output string by a
greater-than character prefixed by backslash character ('\' ASCII 92).
|
| Ref: | rfc2252#2.4.10 |
| Strategy: |
EXPECTED: entry cn=Athens> returned
|
| ID: | 3.2.4.11 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server produces a string representation of a Relative Distinguished Name
and the RDN contains an AttributeValue containing a semi-colon character
(';' ASCII 59) then the character is represented in output string by a semi-colon
character prefixed by a backslash character('\' ACSII 92).
|
| Ref: | rfc2252#2.4.11 |
| Strategy: |
EXPECTED: entry cn=Perse;phone with attribute cn=Perse;phone
|
| ID: | 3.2.4.12 |
| Class: | A |
| Profile: | |
| Text: | When a server generates a representation of RelativeDistinguishedName
and the RDN contains an AttributeValue that is of a type that does not have a string
representation defined for it and a character other than those listed in section 2.4 of
RFC 2253 has the escape mechanism applied to it, then that character is represented in
the output by a backslash and two hex digits which form a single byte in the code of
the character.
|
| Ref: | rfc2252#2.4.12 |
| Strategy: |
EXPECTED: entry cn=ui returned
|
| ID: | 3.2.4.13 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server produces a string representation of RelativeDistinguishedName
and the RDN contains that it is of a type that does not have a string representation
defined for it then the output generated for the AttributeValue consists of the UTF-8
string in accordance with the syntax definition, possibly modified by applying
the escape mechanism to certain characters.
|
| Ref: | rfc2252#2.4.13 |
| Strategy: | |
7.2 PARSING
| ID: | 3.3.0.1 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a string representation of a DistinguishedName
any comma character (',' ASCII 43) that is not prefixed by a backslash character
('\' ASCII 92) is interpreted as name-component separator.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry cn=Pat Bakers returned
|
| ID: | 3.3.0.2 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a string representation of a Distinguished Name,
any plus character ('+' ACSII 43) that is not prefixed by a backslash character
('\' ASCII 92) is interpreted as an attributeTypeAndValue separator.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry ou=Corporate Tax returned.
|
| ID: | 3.3.0.3 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a string representation of Distinguished Name,
any equal character ('=' ASCII 43) that is not prefixed by a backslashed
character ('\' ASCII 92) is interpreted as a attributeType-attributeValue
separator.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry cn=Pat Bakers returned
|
| ID: | 3.3.0.4 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a string representation of Distinguished Name,
any attributeType that is not composed of either an ALPHA/DIGIT/'-' combination
or a DIGIT.'.' OID combination is not interpreted as a valid attributeType name.
|
| Ref: | rfc2253#3 |
| Strategy: | Not portably testable. Cannot guarantee that server will import entry.
|
| ID: | 3.3.0.5 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a string representation of a Distinguished Name,
any attributeType that is composed of ALPHA/DIGIT/'-' combination is
intepreted as a valid attribute type identifier.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: no entry returned
|
| ID: | 3.3.0.6 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server recieves a string representation of Distinguished Name,
any attributeType that is composed of a dotted decimal oid string is
interpreted as a valid attribute identifier.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry cn=Pat Bakers with OID returned
|
| ID: | 3.3.0.7 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a string representation of Distinguished Name,
in any attributeValue that contains a comma character (',' ASCII 44)
prefixed by a backslash character ('\' ASCII 92), the server interprets
the pair of characters as a single literal comma character.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry cn=Aurelius,Marcus returned
|
| ID: | 3.3.0.8 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a string representation of a Distinguished Name,
in any attributevalue that contains an equal character ('=' ASCII 61)
prefixed by a backslash character ('\' ASCII 92), the server interprets
the pair of characters as a single literal equals character.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry cn=Time=Money returned
|
| ID: | 3.3.0.9 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a string of Distinguished Name, in any
attributeValue that contains a plus character ('+' ASCII 43)
prefixed by a backslash character ('\' ASCII 92), the server
interprets the pair of characters as a single literal character.
|
| Ref: | rfc2253#3 |
| Strategy: | Not portably testable. Cannot guarantee that server will import the test entry
|
| ID: | 3.3.0.10 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a string representation of a Distingushed Name,
in any AttributeValue that contains a less-than character ('<' ASCII 62)
prefixed by a backslash character ('\' ASCII 92), the server interprets the
pair of characters as single literal less-than character.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry cn=Rome |
| ID: | 3.3.0.11 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a string representation of a Distinguished Name,
in any AttributeValue that contains a greater-than character ('>' ASCII 62)
prefixed by a backslash character ('\' ASCII 92), the server interprets the pair
of characters as a single literal greater-than character.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry cn=Athens>Rome returned
|
| ID: | 3.3.0.12 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server recieves a string representation of a Distinguished Name,
in any AttributeValue that contains an octothorpe character ('#' ASCII 35)
prefixed by a backslash character ('\' ASCII 92), the server interprets the
pair of characters as a single literal octothorpe character.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry cn=Ac#illes returned
|
| ID: | 3.3.0.13 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives string representation of a Distinguished Name,
in any AttributevValue that contains an semicolon character (';' ASCII 59)
prefixed by a backslash character ('\' ASCII 92), the server interpretes
the pair of character as a single literal semicolon character.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry cn=Perse;phone returned
|
| ID: | 3.3.0.14 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a string representation of a Distingiushed Name,
in any attributeValue that contains a backslash character ('\' ASCII 92)
prefixed by a backslash character ('\' ASCII 92), the server interprets the
pair of characters as a single literal backslash character.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry cn=Mars\Ares returned
|
| ID: | 3.3.0.15 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a string representation of a Distinguished Name,
in any AttributeValue that contains a quote character ('"' ASCII 34)
prefixed by a backslash character ('\' ACSII 92), the server interprets
the pair of characters as a single literal quote character.
|
| Ref: | rfc2253#3 |
| Strategy: | Removed since 1.0patch2 - not portably testable
|
| ID: | 3.3.0.16 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a string representation of a Distinguished Name,
in any AttributeValue that contains an backslash character ('\' ASCII 34)
that immediately followed by a pair of hexadecimal digits, the backslash is
ignored and the digits are interpreted as a single character whose UTF-8 code
is specified by the two-digit hexadecimal number.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry cn=ui,... returned
|
| ID: | 3.3.0.17 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a string representation of Distinguished Name,
in any attributeValue that contains a quote character ('"' ASCII 34)
that is not prefixed by a backslash character ('\' ACSII 92) the quote
character is ignored.
|
| Ref: | rfc2253#3 |
| Strategy: | Test removed, no relevant text in RFC2253 to justify assertion.
|
| ID: | 3.3.0.18 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a string representation of a Distinguished Name,
in any AttributeValue that contains an even number of hexadecimal digits
that are prefixed by an octothorpe character ('#' ASCII 35), the octothorpe
character is ignored and the haxadecimal digit are interpreted as the BER
encoding of the X.5000 attributeValue.
|
| Ref: | rfc2253#3 |
| Strategy: |
EXPECTED: entry cn=ui returned
|
7.3 RELATIONSHIP
| ID: | 3.4.0.1 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a Distinguished Name string in which the RDNs
are separated by semicolon characters (';' ASCII 59) then the server
accepts this DN and replaces the semicolons with comma characters
(',' ASCII 44).
|
| Ref: | rfc2252#2.4.1 |
| Strategy: |
EXPECTED: entry cn=Pat Bakers returned
|
| ID: | 3.4.0.2 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a Distinguished Name string in which
the character that separates the RDNs has adjacent white space
then the whitespace characters are ignored.
|
| Ref: | rfc2252#2.4.2 |
| Strategy: |
EXPECTED: entry cn=Pat Bakers returned
|
| ID: | 3.4.0.3 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a Distinguished name string in which the oid
component of an AttributeType is prefixed by the string "OID.", then
the server will accept this as a normal OID.
|
| Ref: | rfc2252#4.0.3 |
| Strategy: | Outside scope of LDAP Certified
EXPECTED: Entry cn=Pat Bakers returned.
|
| ID: | 3.4.0.4 |
| Class: | B |
| Profile: | BASE |
| Text: | When a server receives a Distinguished Name string in which the oid
component of an AttributeType is prefixed by the string "oid", then
the server will accept this as a normal OID.
|
| Ref: | rfc2252#4.0.4 |
| Strategy: | Outside scope of LDAP Certified
EXPECTED: Entry cn=Pat Bakers returned
|
| ID: | 3.4.0.5 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a Distinguished Name string in which there
are one or more space characters(''ASCII 32) between the name-components
then the space characters are ignored.
|
| Ref: | rfc2252#4.0.5 |
| Strategy: |
EXPECTED: entry cn=Pat Bakers returned
|
| ID: | 3.4.0.6 |
| Class: | A |
| Profile: | |
| Text: | When a server receives a Distinguished name string in which there are comma
characters (',' ASCII 44) between the attributeTypeAndValue elements of a
name-component then the comma characters are ignored.
|
| Ref: | rfc2252#4.0.6 |
| Strategy: |
EXPECTED: entry cn=Pat Bakers with comma,... returned
|
| ID: | 3.4.0.7 |
| Class: | B |
| Profile: | NONE |
| Text: | When a server receives a Distinguished name string in which
there are plus characters ('+' ASCII 43) between the AttributeType
elemenents of an AttributeTypeAndValue component then the plus
characters are ignored.
|
| Ref: | rfc2252#4.0.7 |
| Strategy: | Test removed, no relevant requirement in RFC2253
|
| ID: | 3.4.0.8 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a Distinguished name string in which there are
quote characters ('=' ASCII 34) between the "=" and AttributeValue elements
of an AttributeTypeValue component then the equals characters are ignored.
|
| Ref: | rfc2252#4.0.8 |
| Strategy: |
EXPECTED: entry cn=Pat Bakers returned
|
| ID: | 3.4.0.9 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a Distinguished Name string in which there are values
enclosed within quote characters('"' ASCII 34) then the quotes are ignored and
the value is accepted.
|
| Ref: | rfc2252#4.0.9 |
| Strategy: |
EXPECTED: entry cn=Pat Bakers in quotes returned
|
| ID: | 3.4.0.10 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server received a Distinguished Name string in which there are values
enclosed within quote characters ('"' ASCII 34) that contain a comma character
(',', ASCII 44) then the comma is interpreted as a single literal comma character.
|
| Ref: | rfc2253#4.0.10 |
| Strategy: |
EXPECTED: entry cn="Easy Come, Easy Go" returned
|
| ID: | 3.4.0.11 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a Distinguished Name string in which there
is a value enclosed within quote characters ('"', ASCII 34) that contains
a equal character ('=' ASCII 44) then the equal character is interpreted
as a single literal equal character.
|
| Ref: | rfc2253#4.0.11 |
| Strategy: |
EXPECTED: entry cn=Pat Bakers returned
|
| ID: | 3.4.0.12 |
| Class: | A |
| Profile: | BASE |
| Text: | Whena server receives a Distingushed Name string in which
there is a value enclosed within quote characters ('"'ASCII 34)
that contains an plus character ('+' ASCII) then the plus
character is interpreted as single literal plus character.
|
| Ref: | rfc2252#4.0.12 |
| Strategy: |
EXPECTED: entry cn=\"Laurel+Hardy\" returned
|
| ID: | 3.4.0.13 |
| Class: | A |
| Profile: | BASE |
| Text: | When aserver receives a Distinguished Name string in which there
is a value enclosed within quote character ('"', ASCII 34) that
contains a less-than character ('<' ASCII 43) then the less-than character
is interpreted s single literal less-than character.
|
| Ref: | rfc2253#4.0.13 |
| Strategy: |
EXPECTED: entry cn="Beatles |
| ID: | 3.4.0.14 |
| Class: | A |
| Profile: | BASE |
| Text: | When aserver receives a Distinguished Name string in which
there is a value enclosed within quote characters ('"', ASCII 34)
that contains an greater-than character ('>' ASCII 60) then the greater-than
character is interpreted as a single literal greater-than character.
|
| Ref: | rfc2253#4.0.14 |
| Strategy: |
EXPECTED: entry cn="Salmon>Haddock" returned
|
| ID: | 3.4.0.15 |
| Class: | A |
| Profile: | BASE |
| Text: | When a server receives a Distinguished Name string in which
there is a value enclosed within quote characters ('"', ASCII 34)
that contains an octothorpe character ('#' ASCII 35) then the octothorpe
character is interpreted as a single literal octothorpe character
|
| Ref: | rfc2253#4.0.15 |
| Strategy: |
EXPECTED: entry cn="Room#101" returned
|
| ID: | 3.4.0.16 |
| Class: | A |
| Profile: | BASE |
| Text: | When aserver receives a Distinguished Name string in which
there is a value enclosed witin quote characters ('"', ASCII 34)
that contains an octothorpe character (';' ASCII 59) then the semicolon
character is interpreted as a single literal semicolon character
|
| Ref: | rfc2253#4.0.16 |
| Strategy: |
EXPECTED: entry cn="Old;New" returned
|
8 RFC2254
8.1 FILTER
| ID: | 4.4.0.1 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a continuation reference and the
URL contains a 'equal' filter component then the filter type is represented in the LDAP
URL by an equals character (`=` ASCII 61).
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url returned with either no filter or one which contains filter 'cn=John%20Humphreys'
|
| ID: | 4.4.0.2 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request which contains a
filter of type 'substring' which contains the 'any' operator and
the server replies with a continuation reference then the 'any' operator
is represented in the LDAP URL by an asterisk character ('*' ASCII 42)
that is not immediately preceded by an equals character ('=' ASCII 61).
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: reference to ou=Servers. Url which contains substring 'cn=*Humphreys*' (or no filter)
|
| ID: | 4.4.0.3 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request which contains a filter of type
'less' and the server replies with a continuation reference then the filter
type is represented in the LDAP URL by the three characters "%3c" or "%3C"
immediately followed by an equals character ('=' ASCII 61).
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring 'cn%3c=John%20Humphreys' or 'cn%3C=John%20Humphreys'
returned (or no filter)
|
| ID: | 4.4.0.4 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request which contains a filter
of type 'greater' and the server replies with a continuation reference that includes
the search filter then the filter is represented in the LDAP URL by the three characters
"%3e" or "%3E" immediatelly followed by an equals character('=' ASCII 61).
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url with either no filter or one which contains filter 'cn%3e=John%20Humphreys' or 'cn%3E=John%20Humphreys'
|
| ID: | 4.4.0.5 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request which contains a filter
of type 'and' and the server replies with a continuation reference
then the filter type is represented in the LDAP URL by an ampersand character
('&' ASCII 38).
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains no filter, or filer substring '&(cn=John%20Humphreys)(sn=Humphreys)'
|
| ID: | 4.4.0.6 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request which contains a filter of type
'or' and the server replies with a continuation reference then the filter
type is represented in the LDAP URL by the three characters "%7c" or "%7C".
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains no filter, or filter substring '%7c(cn=John%20Humphreys)(sn=Humphreys)' or '%7C(cn=John%20Humphreys)(sn=Humphreys)'
|
| ID: | 4.4.0.7 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request which contains a filter of type
'not' and the server replies with a continuation reference then the filter
type is represented in the LDAP URL by an exclamation mark character
('!' ASCII 33)
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains no filter or filter substring '!(cn=John%20Humphreys)' returned
|
| ID: | 4.4.0.8 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request containing a filter which
contains a backslash character ('\' ASCII 92) and the server replies with
a continuation reference then the backslash is encoded in the LDAP URL
as the five characters "%5c5c" of "%5C5C".
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains no filter, or filter substring 'cn=%5c5cJohn%20Humphreys' or 'cn=%5C5CJohn%20Humphreys'
|
| ID: | 4.4.0.9 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request containing a filter which
contains a space character (' ' ASCII 32) and the server replies with a
continuation reference then the space is encoded in the LDAP URL as the
three character "%20".
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains no filter, or filter substring 'cn=John%20Humphreys' returned
|
| ID: | 4.4.0.10 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request containing a filter which
contains a left paren character ('(' ASCII 40) and the server replies with a
continuation reference then the character is encoded in the LDAP URL as the
five character "%5c28" or "%5C28".
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains no filter, or filter substring 'cn=%5c28John%20Humphreys' or 'cn=%5C28John%20Humphreys'
|
| ID: | 4.4.0.11 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request containing a filter which
contains a right paren character ')' ASCII 41) and the server replies with a
continuation reference then the character is encoded in the LDAP URL as the
five character "%5c29"or "%5C29".
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring 'cn=John%20Humphreys%5c29' or 'cn=John%20Humphreys%5C29'
|
| ID: | 4.4.0.12 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server receives a search request containing a filter which
contains an asterisk character ('*' ASCII 42) and the server replies with a
continuation reference then the asterisk character is encoded in the LDAP URL
as the five characters "%5c2a"or "%5C2A".
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains no filter or filter substring 'cn=John%5c2a%20Humphreys' or 'cn=John%5C2A%20Humphreys'
|
| ID: | 4.4.0.13 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral and the URL
contains a filter type is represented in the LDAP URL by an
equals character ('=' ASCII 61)
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring 'cn=John%20Humphreys' returned
|
| ID: | 4.4.0.14 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server genearates an LDAP URL as a referral and the URL contains
a filter of type 'substring' which contains an 'any' operator then the
operator is represented in the LDAP URL by an asterisk characetr ('*' ASCII 42)
that is not immediately preceded by an equal characeter ('=' ASCII 61)
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring 'cn=*Humphreys*'
|
| ID: | 4.4.0.15 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP as a referral and the URL contains a
filter of type 'less' then the filter type is represented in the URL
by the three characters "%3c" or "%3C" immediately followed by an equals
character ('=' ASCII 61)
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring 'cn%3c=John%20Humphreys' or 'cn%3C=John%20Humphreys' returned
|
| ID: | 4.4.0.16 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral and the URL contains
a filter of type 'greater' then the filetr type is represented in the
LDAP URL by the three characters "%3e" or "%3E" immediately followed
by an equals character ('=' ASCII 61)
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring 'cn%3e=John%20Humphreys' or 'cn%3E=John%20Humphreys'
|
| ID: | 4.4.0.17 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral and the URL contains
a filter of type 'and' the the filter type is represented in the LDAP URL by
an ampersand character ('&' ASCII 38)
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring '&(cn=John%20Humphreys)(sn=Humphreys)'
|
| ID: | 4.4.0.18 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral and the URL contains
a filter of type 'or' then the filter type is represented in the LDAP URL
by the three characters "%7c" or "%7C" .
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url wich contains substring '%7c(cn=John%20Humphreys)(sn=Humphreys)'
|
| ID: | 4.4.0.19 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral and the URL contains
a filter of type 'not' then the filter type is represented in the LDAP URL
by an exclamation mark character ('!' ASCII 33).
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring '!(cn=John%20Humphreys)'
|
| ID: | 4.4.0.20 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as referral and the URL contains a
backslash character ('\' ASCII 92) then the backslash is encoded in the
LDAP URL as the five characters "%5C5C" or "%5c5c".
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring 'cn=%5C5CJohn%20Humphreys' or 'cn=%5c5cJohn%20Humphreys'
|
| ID: | 4.4.0.21 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral and the URL
contains a space character (' ' ACSII 32) then the space is encoded
in the LDAP URL as the three character "%20".
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring 'cn=John%20Humphreys'
|
| ID: | 4.4.0.22 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as referral and the URL contains
a left paren character ('(' ASCII 40) then the character is encoded in the LDAP URL
as the five characters "%5c28" or "%5C28".
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring 'cn=%5c28John%20Humphreys' or 'cn=%5C28John%20Humphreys'
|
| ID: | 4.4.0.23 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral and the URL contains a
right paren character (')' ASCII 41) then the character is encoded in the
LDAP URL as the five characters "%5c29" or "%5C29".
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring 'cn=John%20Humphreys%5C29' or 'cn=John%20Humphreys%5c29'
|
| ID: | 4.4.0.24 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral and the URL contains a
asterisk character ('*' ASCII 42) then the character is encoded in the
LDAP URL as the five characters "%5c2a" or "%5C2A" or %5C2a" or "%5C5A".
|
| Ref: | rfc2254#4 |
| Strategy: |
EXPECTED: url which contains substring 'cn=John%5c2a%20Humphreys' or 'cn=John%5C2A%20Humphreys'
or 'cn=John%5C2a%20Humphreys' or 'cn=John%5c2A%20Humphreys'
|
9 RFC2255
9.1 DEFINITION
| ID: | 5.3.0.1 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a continuation reference the URL
has the form 'ldap://[hostport]['/'[dn['?'[attributes]['?'[scope]['?'[filter]['?'extensons]]]]]]'
|
| Ref: | rfc2255#3.0.1 |
| Strategy: |
EXPECTED: url with correct format returned
|
| ID: | 5.3.0.2 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a continuation reference and the
URL contains a DN component then the DN component is an LDAP DistiguishedName
using the string format described in RFC2253.
|
| Ref: | rfc2255#3.0.2 |
| Strategy: |
EXPECTED: url which contains a DN with correct format returned
|
| ID: | 5.3.0.3 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a continuation reference
then the value of the scope component of the LDAP URL is one of base', 'one' or 'sub'.
|
| Ref: | rfc2255#3 |
| Strategy: |
EXPECTED: url which contains no scope, or either the scope 'base', 'one' or 'sub'
|
| ID: | 5.3.0.4 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a continuation reference and the
URL contains an attributes component then the 'attrdesc' names are
represented using the AttributeDescription syntax of RFC2251.
|
| Ref: | rfc2255#3.0.4 |
| Strategy: |
EXPECTED: url which contains 'attrdesc' with correct syntax returned
|
| ID: | 5.3.0.5 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a continuation reference and
the URL contains an hostport component then the component is represented
using the syntax of RFC1738 section 5.
|
| Ref: | rfc2255#3 |
| Strategy: |
EXPECTED: url which contains an optional hostport component with correct syntax returned
|
| ID: | 5.3.0.6 |
| Class: | B |
| Profile: | STANDARD |
| Text: | When a server geneartes an LDAP URL as a continuation reference and
the URL contains an extensions component then the component is of the
form '!extype=exvalue' where extype is an OIDtoken and exvalue is represented
using the LDAPString syntax of RFC2251 section 4.1.2.
|
| Ref: | rfc2255#3 |
| Strategy: | extensions not portably testable
|
| ID: | 5.3.0.7 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral the URL has the form
'ldap://[hostport]['/'[dn['?'[attributes]['?'[scope]['?'[filter]['?'
extensions]]]]]]'
|
| Ref: | rfc2255#3 |
| Strategy: |
EXPECTED: url with correct format returned
|
| ID: | 5.3.0.8 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral and the URL contains a
dn component then the dn component is an LDAP Distinguished Name using
the string format described in RFC2253.
|
| Ref: | rfc2255#3 |
| Strategy: | |
| ID: | 5.3.0.9 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral then the value of the
scope component of the LDAP URL is one of 'base', 'one'or 'sub'
|
| Ref: | rfc2255#3 |
| Strategy: |
EXPECTED: url containing value of scope 'base' or 'one' or 'sub' returned
|
| ID: | 5.3.0.10 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral and the URL contains an
attributes component then the 'attrdesc' names are represented using the
AttributeDescription syntax of RFC2251.
|
| Ref: | rfc2255#3 |
| Strategy: |
EXPECTED: url which contains 'attrdesc' with correct syntax returned
|
| ID: | 5.3.0.11 |
| Class: | A |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral and the URL contains
a hostport component then the component is represented using the syntax of RFC1738 section 5.
|
| Ref: | rfc2255#3.0.11 |
| Strategy: |
EXPECTED: url contains no hostport, or a hostport with correct syntax
|
| ID: | 5.3.0.12 |
| Class: | B |
| Profile: | STANDARD |
| Text: | When a server generates an LDAP URL as a referral and the URL contains
an extensions component then the component if of the form '!extype=exvalue'
where extype is an OID token and exvalue is represented using the LDAPString
syntax of RFC2251 section 4.1.2.
|
| Ref: | rfc2255#3.0.12 |
| Strategy: | not testable
|
10 RFC2256
10.1 ATTRIBUTETYPES
| ID: | 6.5.0.1 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'objectClass' attribute type.
|
| Ref: | rfc2256#5.1 |
| Strategy: | This is implicitly tested elsewhere.
|
| ID: | 6.5.0.2 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'aliasedObjectName' attribute type.
|
| Ref: | rfc2256#5.2 |
| Strategy: | this is implicitly tested elsewhere
|
| ID: | 6.5.0.3 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'cn' attribute type.
|
| Ref: | rfc2256#5.4 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.4 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'sn' attribute type.
|
| Ref: | rfc2256#5.5 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.5 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'serialNumber' attribute type.
|
| Ref: | rfc2256#5.6 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.6 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'c' attribute type.
|
| Ref: | rfc2256#5.7 |
| Strategy: |
|
| ID: | 6.5.0.7 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'l' attribute type.
|
| Ref: | rfc2256#5.8 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.8 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'st' attribute type.
|
| Ref: | rfc2256#5.9 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.9 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'street' attribute type.
|
| Ref: | rfc2256#5.10 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.10 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'o' attribute type.
|
| Ref: | rfc2256#5.11 |
| Strategy: |
|
| ID: | 6.5.0.11 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'ou' attribute type.
|
| Ref: | rfc2256#5.12 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.12 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'title' attribute type.
|
| Ref: | rfc2256#5.13 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.13 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'description' attribute type.
|
| Ref: | rfc2256#5.14 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.14 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'searchGuide' attribute type.
|
| Ref: | rfc2256#5.15 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.15 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'businessCategory' attribute type.
|
| Ref: | rfc2256#5.16 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.16 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'postalAddress' attribute type.
|
| Ref: | rfc2256#5.17 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.17 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'postalCode' attribute type.
|
| Ref: | rfc2256#5.18 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.18 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'postOfficeBox' attribute type.
|
| Ref: | rfc2256#5.19 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.19 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'physicalDeliveryOfficeName' attribute type.
|
| Ref: | rfc2256#5.20 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.20 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'telephoneNumber' attribute type.
|
| Ref: | rfc2256#5.21 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.21 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'telexNumber' attribute type.
|
| Ref: | rfc2256#5.22 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.22 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'teletexTerminalIdentifier' attribute type.
|
| Ref: | rfc2256#5.23 |
| Strategy: |
|
| ID: | 6.5.0.23 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'facsimileTelephoneNumber' attribute type.
|
| Ref: | rfc2256#5.24 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.24 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'x121Address' attribute type.
|
| Ref: | rfc2256#5.25 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.25 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'internationaliSDNNumber' attribute type.
|
| Ref: | rfc2256#5.26 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.26 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'registeredAddress' attribute type.
|
| Ref: | rfc2256#5.27 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.27 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'destinationIndicator' attribute type.
|
| Ref: | rfc2256#5.28 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.28 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'preferredDeliveryMethod' attribute type.
|
| Ref: | rfc2256#5.29 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.29 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'supportedApplicationContext' attribute type.
|
| Ref: | rfc2256#5.31 |
| Strategy: | Not portably testable.
|
| ID: | 6.5.0.30 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'member' attribute type.
|
| Ref: | rfc2256#5.32 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.31 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'owner' attribute type.
|
| Ref: | rfc2256#5.33 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.32 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'roleOccupant' attribute type.
|
| Ref: | rfc2256#5.34 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.33 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'seeAlso' attribute type.
|
| Ref: | rfc2256#5.35 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.34 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'userPassword' attribute type.
|
| Ref: | rfc2256#5.36 |
| Strategy: | Not portably testable due to varying security policy on the return of this attribute
|
| ID: | 6.5.0.35 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'name' attribute type.
|
| Ref: | rfc2256#5.42 |
| Strategy: | Not portably testable.
|
| ID: | 6.5.0.36 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'givenName' attribute type.
|
| Ref: | rfc2256#5.43 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.37 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'initials' attribute type.
|
| Ref: | rfc2256#5.44 |
| Strategy: | No mandated object class uses this attribute.
|
| ID: | 6.5.0.38 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'generationQualifier' attribute type.
|
| Ref: | rfc2256#5.45 |
| Strategy: |
|
| ID: | 6.5.0.39 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'x500UniqueIdentifier' attribute type.
|
| Ref: | rfc2256#5.46 |
| Strategy: |
|
| ID: | 6.5.0.40 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'dnQualifier' attribute type.
|
| Ref: | rfc2256#5.47 |
| Strategy: |
|
| ID: | 6.5.0.41 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'enhancedSearchGuide' attribute type.
|
| Ref: | rfc2256#5.48 |
| Strategy: | No mandated object class uses this attribute.
|
| ID: | 6.5.0.42 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'distinguishedName' attribute type.
|
| Ref: | rfc2256#5.50 |
| Strategy: | Not portably testable.
|
| ID: | 6.5.0.43 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'uniqueMember' attribute type.
|
| Ref: | rfc2256#5.51 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.5.0.44 |
| Class: | B |
| Profile: | STANDARD |
| Text: | The server recognizes the 'houseIdentifier' attribute type.
|
| Ref: | rfc2256#5.52 |
| Strategy: |
|
10.2 OBJECTCLASSES
| ID: | 6.7.0.1 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'top' value of the objectClass attribute.
|
| Ref: | rfc2256#7.1 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.7.0.2 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'alias' value of the objectClass attribute.
|
| Ref: | rfc2256#7.2 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.7.0.3 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'country', 'locality', 'organization' and 'organizationalUnit'
values of the objectClass attribute.
|
| Ref: | rfc2256#7.3,4,5,6 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.7.0.4 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'person',and 'organizationalPerson' values of the
objectClass attribute.
|
| Ref: | rfc2256#7.7,8 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.7.0.5 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'organizationalRole' value of the objectClass attribute.
|
| Ref: | rfc2256#7.9 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.7.0.6 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'residentialPerson' value of the objectClass attribute.
|
| Ref: | rfc2256#7.11 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.7.0.7 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'groupOfNames' value of the objectClass attribute.
|
| Ref: | rfc2256#7.10 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.7.0.8 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'device' value of the objectClass attribute.
|
| Ref: | rfc2256#7.15 |
| Strategy: |
EXPECTED: search success
|
| ID: | 6.7.0.9 |
| Class: | A |
| Profile: | STANDARD |
| Text: | The server recognizes the 'groupOfUniqueNames' value of the objectClass attribute.
|
| Ref: | rfc2256#7.11 |
| Strategy: |
EXPECTED: search success
|