Steps for configuring an LDAP server

To configure with the configuration utility:

  1. Copy the ds.profile file, found in /usr/lpp/ldap/etc, to a local directory and update it according to the commentary found in the file. (If you must update the advanced configuration files that are mentioned in Table 1, you must copy those files also. See Specifying advanced configuration options with the dsconfig utility for more details on these files.)

    Some statements in ds.profile do not have any preassigned values but are required for successful configuration. These are noted in the file. Assign values to all these required statements, referring to information in the file above each statement for assistance. The intended audience of the ds.profile file is the system administrator (or system programmer) and the LDAP Administrator. The file contains information required from both administrators.

    These ds.profile statements must be assigned values:
    • ADMINDN
    • PROG_SUFFIX
    • APF_JOBCARD_1
    • PRGCTRL_JOBCARD_1
    • DB2_JOBCARD_1
    • RACF_JOBCARD_1
    The JOBCARD statements must be assigned regardless of their need. They are the job cards for the JCL output that is generated by dsconfig. The dsconfig utility determines what backends are configured at the same time it processes the JOBCARD statements. Note the dsconfig utility uses only the appropriate job cards.

    See the ds.profile for all statement descriptions and examples.

    Note: Some statement values are case-sensitive and are denoted accordingly. Be sure to set up the editor to allow both upper and lowercase letters to be specified.

    Specify a distinguished name for ADMINDN that does not contain any of the suffixes that you are defining in the configuration. Also, specify a value for ADMINPW. This enables the root administrator defined in the configuration file to bind to the LDAP server and do the final setup of the LDAP server described in step 6. As part of that final setup, the adminDN option is changed and the adminPW option removed from the configuration file.

  2. Run the dsconfig utility. The utility generates a set of members in a partitioned data set, as specified on the OUTPUT_DATASET statement in the ds.profile file.

    The dsconfig utility generates:

    • APF member: A JCL job which sets APF authorizations on libraries used by the LDAP server product.
    • DBCLI member: A JCL job which binds the CLI packages to Db2® and the DSNACLI plan.
    • DSCONFIG member: The LDAP server configuration file.
    • DSENVVAR member: The LDAP server environment variables file.
    • DSNAOINI member: The Db2 DSNAOINI initialization file.
    • GDBSPUFI member: A set of Db2 SQL statements to be executed using the SPUFI tool that defines database tables for the GDBM Db2-based backend.
    • PRGMCTRL member: A JCL job which sets Program Control on libraries used by the LDAP server product.
    • PROGsuffix member: A member needed for APF authorization.
    • RACF® member: A JCL job which updates RACF to allow the LDAP server to run as a started task.
    • TDBSPUFI member: A set of Db2 SQL statements to be executed using the SPUFI tool that defines database tables for the TDBM backend.
    • A procedure member needed to start the LDAP server as a started task.
    Note: DBCLI, DSNAOINI, TDBSPUFI and GDBSPUFI are conditionally generated when either of the Db2-based backends are configured.
  3. Copy members and submit jobs.
    1. Copy the LDAP server started task procedure from the output data set to the target system’s procedure library. The name of the LDAP server started task procedure is the name of the LDAP user ID specified on the LDAPUSRID statement in the ds.profile file. The preassigned name of the LDAP user ID is GLDSRV.
    2. Copy the generated PROGsuffix member (where suffix is specified on the PROG_SUFFIX statement in the ds.profile file) from the output data set to the target system’s PARMLIB.
    3. Submit the following generated JCL jobs that can be found in the output data set in the following order:
      1. RACF member
      2. APF member
      3. DBCLI member, if TDBM or Db2-based GDBM is being configured
        Note: Be sure Db2 is started before submitting this job.
      4. PRGMCTRL member

        The PRGMCTRL member is only required if an SDBM backend is being configured and Program Control is active.

  4. Through the Db2 SPUFI interactive tool, submit the TDBSPUFI member, if a TDBM backend is being configured, and the GDBSPUFI member, if the Db2-based GDBM backend is being configured.
    Note: Update the table spaces in the GDBM database to set up for row level locking. See step 3 in Steps for configuring an LDAP server for more information.
  5. Start the LDAP server. The LDAP server can be started from SDSF or from the operator’s console.
    Note: The name of the LDAP server procedure is the same as the user ID specified on the LDAPUSRID statement. The preassigned value is GLDSRV.

    To start the LDAP server in SDSF, enter:

    /s user_id
    To start the LDAP server from the operator’s console, enter:
    s user_id
  6. Finalize setup of the LDAP server.
    1. If TDBM, LDBM, or CDBM is configured, modify the LDAP server schema entry to contain the schema needed for your usage of these backends. The schema.user.ldif and schema.IBM.ldif files found in the /usr/lpp/ldap/etc directory might contain the schema you need. schema.IBM.ldif requires that you first load schema.user.ldif.
      Note: The distinguished name (DN) of the LDAP server schema is cn=schema. If the ldif file containing your schema has a DN of cn=schema,suffix, then update the file to change the DN to cn=schema.
      Use the ldapmodify utility to modify the schema entry.
      ldapmodify -h ldaphost -p ldapport -D binddn -w passwd -f file

      where:

      ldaphost
      Is the host name of the system where the LDAP server is running.
      ldapport
      Is the TCP/IP port on which the LDAP server is running. The port is specified in an advanced profile file, ds.slapd.profile, on the LISTEN statement. The preassigned value is 389.
      binddn
      Is the root administrator DN of the LDAP server. The root administrator DN is specified in the ds.profile file on the ADMINDN statement. This value is required and not preassigned.
      passwd
      Is the root administrator password of the LDAP server. The root administrator password is specified in the ds.profile file on the ADMINPW statement. The example value is "secret".
      file
      Is a file containing modifications to the schema entry in LDIF format. More information about the schema can be found in LDAP directory schema.

      Following is an example of using ldapmodify to modify the schema entry:

      ldapmodify -h myhost -p 389 -D "cn=Admin" -w secret -f /usr/lpp/ldap/etc/schema.user.ldif

      More information about ldapmodify can be found in z/OS IBM Tivoli Directory Server Client Programming for z/OS.

      Multiple schemas might need to be loaded before applications that use the directory works. For example, in addition to the schema.user.ldif schema file, it is common for directory applications to require the elements defined in the schema.IBM.ldif schema file.

    2. Load the suffix entries for each configured TDBM and LDBM backend. Suffix entries are specified in the ds.profile file on the TDBM_SUFFIX and LDBM_SUFFIX statements.
      Note: If you intend to load large amounts of data in LDIF format into a TDBM backend, see ldif2ds utility for instructions on using the ldif2ds utility. In this case, do not load the suffix entry separately. Include the suffix instead with the rest of the entries to be loaded by ldif2ds.

      Use the ldapadd utility to load the suffix entry.

      ldapadd -h ldaphost-p ldapport -D binddn -w passwd -f file

      See descriptions of ldaphost, ldapport, binddn, and passwd above. file is a file containing the entries to be loaded in LDIF format.

      For example, if suffix.ldif contains the following suffix entry:
      dn: o=Your Company
      objectclass: organization
      o: Your Company
      then the suffix entry can be added by ldapadd as follows:
      ldapadd -h myhost -p 389 -D "cn=Admin" -w secret -f suffix.ldif

      More information about ldapadd can be found in z/OS IBM Tivoli Directory Server Client Programming for z/OS.

    3. Set an appropriate ACL for controlling access to change log entries for the GDBM backend, if configured. See Change logging for more information.
    4. Remove the adminPW option from the LDAP server configuration file, after initial setup of the LDAP server, See Establishing the root administrator DN and basic replication replica server DN and passwords for more information.

To confirm the LDAP server is configured and ready for client requests, see Configuration confirmation.

To load the data in LDIF format into a TDBM backend, you can use ldif2ds or ldapadd. However, if you intend to load more than 100,000 directory entries, use ldif2ds.

Configuration confirmation

Following is an optional Installation Verification Procedure (IVP) to confirm that the LDAP server configuration is successful.

Run the ldapsearch utility to verify the configuration.

ldapsearch -h ldaphost-p ldapport -D binddn -w passwd -s base -b "" "objectclass=*"

See descriptions of ldaphost, binddn, passwd, and ldapport above.

The -s base specifies the base scope for the search and the -b "" specifies the root DSE as the base.

The result of this search contains a list of all naming contexts supported by the LDAP server. For example, if both TDBM and SDBM are configured, the result of the search contains both naming contexts (suffixes) listed.

Following is an example using ldapsearch to verify a configuration:

ldapsearch -h myhost -p 389 -D cn=admin -w secret -s base -b "" "objectclass=*"

If the naming context is not returned, an error message is returned indicating a problem.

More information about ldapsearch can be found in z/OS IBM Tivoli Directory Server Client Programming for z/OS.