This section of the user guide explains how VSLDAP should be configured for testing a product against the LDAP Certified Base Profile.

 
• Configuring the Directory Server

 
• Configuring the Test Suite

 
• Configuration Checklist

 
• Certification testing

Configuring the Directory Server

1 Directory Administration

Configure the server with a root suffix of "o=IMC, c=US"

root dn is "cn=Directory Manager, o=IMC, c=US"

root password (plaintext) for simple bind authentication is "controller"

The following branches require search, compare, add, delete, modify and modifyDN permissions for cn=Directory Controller, o=IMC, c=US:
ou=Add, o=IMC, c=US
ou=Delete, o=IMC, c=US
ou=Modify, o=IMC, c=US
ou=ModifyDN, o=IMC, c=US

search access should be granted to anonymously bound users for these branches.

The following branch requires search and compare access to all users including anonymously bound users:
ou=Search, o=IMC, c=US

The server must be configured to allow the Directory Manager to add and modify an entry's objectclasses. This is required for example by test rfc2251/data model 1.3.2.5.

2 Populate the Directory

Where appropriate, BLITS test strategies have been employed in the VSLDAP tests. These tests have a standard directory layout which is provided in the VSLDAP.ldif file. In addition are two other ldif format files:

• VSLDAP.ldif
• Syntaxes.ldif
• Extras.ldif

Entries named using the X.500 naming convention (DC-based naming schemes are not supported in this version of VSLDAP).

The entries from all three LDIF files must be added to the directory. There is no single way to do this - it depends on the tools available for your system. If your import tool will not accept a particular entry it may be necessary to enter this entry using some other method. The ability to faultlessly import these ldif files is not a conformance requirement of the LDAP Certified program. The ability to maintain these entries in the directory under test is a conformance requirement however.

VSLDAP.ldif: this is based on the ldif for BLITS 2.4, but modified to include the extra requirements of VSLDAP. This must be imported first (because it creates the top level OUs)

Syntaxes.ldif: This file contains the ou=Syntaxes, ou=Search, o=IMC, c=US branch of the directory. These files are grouped to help isolate import problems that can occur with the unusual strings used in these DNs.

Extras.ldif: Some entries have proved difficult to import with certain LDIF tools. These entries are placed in Extras.ldif. These entries must be imported, using whatever tools are available, ldif-based or otherwise.

 

3 SSL Configuration

The server must be configured to accept SSL connections on port 636. This is a mandatory requirement of LDAP Certified.

Only server-authenticated connections are tested in the BASE profile. For this, it is necessary to import the server's authentication certificate into the test suite certificate database - a cert7.db file in vsldap/data/ssl.

The cert7.db file is managed using the Netscape NSS certutil tool. It is important to use the correct version of this tool: 3.1 or earlier. Later versions do not support the cert7.db format. This tool can be downloaded from http://www.mozilla.org/projects/security/pki/nss/tools/. For your convenience a precompiled version is included with this package, in bin/nss. This directory also contains the shared libraries required by this tool.

Your server certificate can be imported into the test suite in the following way:

1. Export your server certificate to a binary format file (e.g. "server.crt")
2. Import the DER file of the server certificate into the cert7.db file using the following command:
   
     certutil -A -n vsldap_server -t "P,P,P" -i server.crt -d vsldap/data/ssl/cert7.db
   
     Note the the -d option requires the full pathname to the cert7.db file.

In addition to the cert7.db file the following files are also included in data/ssl:

key3.db	Key database file. Stores the keys for the sample CA and client certificates. Password is 'vsldap-pki'. Not used for certification testing.
secmodule.db	Data used in PKI management. Created by Netscape certutil v3.1.

The location of the cert7.db and key3.db files must be made known to VSLDAP. Edit section #2 of the tetexec.cfg file to provide this information. The location given must be the full system pathname of the files

Configuring the Test Suite

The "build" and "clean" configuration files have no user-specific data. Unless you are modifying VSLDAP there is no need to edit the tetbuild.cfg and tetclean.cfg files. In "Execution" mode, there are several configuration variables that must be set prior to any test run.

These variables are declared in  tetexec.cfg. The file is divided into sections #1 to #11 in which different mandatory and optional parameters can be specified (the optional parameters are not used in certification testing).  Note that you must provide a value for each of the mandatory configuration variables in section #1 of tetexec.cfg (see table 1 for details).
 

Table 1.1: Section #1 configuration variables.

Variable name	Value required	Mandatory?
VSLDAP_TEST_RUN	A name for the test run. Not used to configure any tests but useful for record keeping.	No
VSLDAP_SERVER_HOST	The hostname of the system that is hosting the LDAP server under test.	Yes
VSLDAP_PORT	The port number on which the server under test is receiving connections. Typically this will be 389, and MUST be 389 for a certification test run.	Yes
VSLDAP_CLIENT	This number specifies the client branch of the BLITS directory that is to be used for test involving add/delete/modify/modifyDN operations. See BLITS documentation for more details. This is a whole number between 1 and 10. Typically this is incremented after every test run that involves modification to directory data. When the ten digits are exhausted, rollover to '1' and increment the vendor number (see below). Thus it is possible to perform at least 10 × 20 = 200 clean test runs on a directory before the data has to be refreshed.	Yes
VSLDAP_VENDOR	This number specifies the vendor branch of the BLITS directory that is to be used for test involving add/delete/modify/modifyDN operations. See BLITS documentation for more details. This is a whole number between 1 and 20.	Yes

Table 1.2: Section #2 SSL configuration variables.

Variable name	Value required	Mandatory?
VSLDAP_SSL_PORT	The port used by the server under test to receive SSL connections. This MUST be 636 for certification testing.	Yes
VSLDAP_SSL_CERT	Use this to specify the full system pathname of the cert7.db file that contains the client (test suite) X509 certificate. A sample file is provided in data/ssl/cert7.db.	Yes
VSLDAP_USE_CBCA	If the server requires the cliet to authenticate itself (to provide a client certificate) then tset this to 'yes'. Other set to 'no'. Most servers have to optional of either allowing or requiring certificate-based client authentication. This option is only neccessary if the server insists that the client be authenticated.	No
VSLDAP_SSL_KEY	Use this to specifiy the full system pathname of the key3.db file that contains the key of the client certificate. It may be required for some mechanisms that use key exchange.	No

 

You will notice that there are other configuration variables in tetexec.cfg: these other variables are related to unsupported optional tests that are not part of the current LDAP Certified profile.
 
 

Configuration Checklist

1. Directory Administration
2. Import VSLDAP.ldif
3. Import Syntaxes.ldif
4. Import Extras.ldif
5. Configure server for SSL connections
6. Configure tetexec.cfg

 

Certification testing

The supplied scenario file "vsldap/ldap-certified-base.scn" contains a number of scenarios that test aspects of directory server behaviour. This scenario has been designed specifically for LDAP Certified Base profile testing but may also be used for general development testing.

The full set of scenarios for Base profile testing is listed in table 2. Note that all tests are mandatory. There are no optional features in this profile.

The 'all' scenario is the set of all mandatory BASE profile tests. The other scenarios are subsets of 'all' that exercise a particular aspect of directory server functionality. The intention is that the subset scenarios can be used to aid development testing. The 'all' scenario must be run for official certification testing.

Table 2: Base profile test scenarios.

 

To run a scenario, having first configured the server and set the appropriate variables in the tetexec.cfg file, run the command:
tcc -bec -s ldap-certified-base.scn . scenario_name

where scenario_name is any of the scenarios listed above (or one of your own creation). This command will compile the appropriate test scripts, execute them, logging the results to the indicated journal file, and then remove the executable files. Note that the -s option specifies the scenario file. If you wish to run Standard profile tests, provide the name of the Standard profile sceanrio file (ldap-certified-standard.scn) here.

For frequent test runs during development it may be more convenient to build the tests once and then invoke tcc in execution mode only.
e.g..
tcc -b -s ldap-certified-base.scn . all

To build every test, and then

tcc -e -s ldap-certified-base.scn . scenario_name

to run a particular scenario.
 

Note that for test case modify1_4_6_11, there may be situation that it has a UNRESOLVED result. In this situation, the following could be added to schema: dn: cn=schema changetype: modify add: attributetypes attributetypes: ( friends-OID NAME 'friends' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' DESC 'vsldap attr')
Base profile certification claims

A test journal of an `all' scenario test run from the ldap-certified-base.scn scenario file will be required as part of the submission procedure.

e.g.
tcc -bec -s ldap-certified-base.scn . all

and then copy the 'journal' file to a unique name, such as ldap-base-all.jnl and submit this file as part of your conformance claim.

Also you must run the program vsldap/bin/report on completion of the test run (the program reads the most recently generated test journal file). This will generate a summary report (to standard output by default). Make a copy of this summary and submit it along with the raw journal file. e.g.

bin/report > base-summary.rpt

Print a copy of the summary report and sign the disclaimer at the bottom. This signed copy must be sent with the conformance claim

Copyright ©  2007 The Open Group
All rights reserved.