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: STANDARD


 

5 RFC2251


 

5.1 BER


 

5.2 ABANDON


 

5.3 ADD

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:


 

5.4 BIND


 

5.5 COMMON_ELEMENTS

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.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.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:


 

5.6 COMPARE


 

5.7 DATA_MODEL

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.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.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.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:


 

5.9 DISCONNECTION


 

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:


 

5.13 MODIFYDN

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


 

5.14 PROTOCOL


 

5.15 SEARCH

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.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.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.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.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.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


 

6 RFC2252


 

6.1 MATCHINGRULES


 

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.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


 

6.4 SYNTAXES


 

6.5 TYPE


 

7 RFC2253


 

7.1 CONVERSION


 

7.2 PARSING


 

7.3 RELATIONSHIP


 

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