Test Assertions for VSLDAP


The distribution and review of this document is limited to The Open Group,technical advisors to the Directory Interoperability Forum and licensees of VSLDAP.

This document is copyright of The Open Group, 2001-2007. All rights reserved.

The Open Group
Thames Tower
37-45 Station Road
Reading, UK, RG1 1LX
Tel: +44 118 950 3051
Fax: +44 118 9500110

http://www.opengroup.org



Table of Contents

1 Document History
2 Definitions and Abbreviations
3 Introduction
4 Test Suite Version

5 RFC2251

5.1 BER
5.2 ABANDON
5.3 ADD
5.4 BIND
5.5 COMMON_ELEMENTS
5.6 COMPARE
5.7 DATA_MODEL
5.8 DELETE
5.9 DISCONNECTION
5.10 EXTENDED
5.11 IMPLEMENTATION
5.12 MODIFY
5.13 MODIFYDN
5.14 PROTOCOL
5.15 SEARCH
5.16 SERVER-SPECIFIC
5.17 SPECIFIC
5.18 UNBIND
6 RFC2252
6.1 MATCHINGRULES
6.2 OPERATIONAL
6.3 STANDARD
6.4 SYNTAXES
6.5 TYPE
7 RFC2253
7.1 CONVERSION
7.2 PARSING
7.3 RELATIONSHIP
8 RFC2254
8.1 FILTER
9 RFC2255
9.1 DEFINITION
10 RFC2256
10.1 ATTRIBUTETYPES
10.2 OBJECTCLASSES


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