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
|