iPlanet Directory Server 5.1 Setup (Tasks)

This chapter describes how to configure the iPlanet Directory Server 5.1 to support a network of Solaris LDAP naming service clients. The information is specific to the iPlanet Directory Server 5.1.

Note - You must have already performed all the procedures described in Chapter 11 before you can configure the iPlanet Directory Server 5.1 to work with Solaris LDAP clients.

Note - A directory server (an LDAP server) cannot be its own client.

This chapter covers the following topics.

• "Configuring iPlanet Directory Server 5.1 Using idsconfig"

• "Using Service Search Descriptors to Modify Client Access to Various Services"

• "Running idsconfig"

• "Populating the Directory Server Using ldapaddent"

• "Managing Printer Entries"

• "Populating the Server with Additional Profiles"

Configuring iPlanet Directory Server 5.1 Using idsconfig

Creating a Checklist Based on Your Server Installation

During the server installation process, you will have defined crucial variables, with which you should create a checklist similar to the one below before launching idsconfig. You can use the blank checklist provided in "Blank Checklists".

Note - The information included below will serve as the basis for all examples that follow in the LDAP related chapters. The example domain is of an widget company, Example, Inc. with stores nationwide. The examples will deal with the West Coast Division, with the domain west.example.com

Table 15-1 Server Variables Defined

Note - If you are using hostnames in defining defaultServerList or preferredServerList, you MUST ensure LDAP is not used for hosts lookup. This means ldap must not be in /etc/nsswitch.conf hosts line.

Table 15-2 Client Profile Variables Defined

Note - Client profiles are defined per domain. At least one profile must be defined for a given domain.

Attribute Indices

idsconfig indexes the following list of attributes for improved performance.

Schema Definitions

idsconfig(1M) automatically adds the necessary schema definitions. Unless you are very experienced in LDAP administration, do not manually modify the server schema. See Chapter 18, General Reference for an extended list of schemas used by the LDAP naming service.

Using Browsing Indices

The browsing index functionality of the iPlanet Directory Server, otherwise known as the virtual list view, provides a way in which a client can view a select group or number of entries from very long list, thus making the search process less time consuming for each client. Browsing Indexes provide optimized, predefined search parameters with which the Solaris LDAP naming client can access specific information from the various services more quickly. Keep in mind that if you do not create browsing indexes, the clients may not get all the entries of a given type because the server limits for search time or number of entries might not be enforced.

Indexes are configured on the directory server and the proxy user has read access to these indexes.

Refer to the iPlanet Directory Server Administrators Guide 5.1 for information on configuring indexes on the iPlanet Directory Server as well as the performance cost associated with using them.

In the following example, note that the -n option denotes the name of the database with the entries to be indexed and and the -s option denotes the instance of the directory server.

Note - idsconfig creates all the default VLV indices.

directoryserver -s ipdserver vlvindex -n userRoot -T getgrent directoryserver -s ipdserver vlvindex -n userRoot -T gethostent directoryserver -s ipdserver vlvindex -n userRoot -T getnetent directoryserver -s ipdserver vlvindex -n userRoot -T getpwent directoryserver -s ipdserver vlvindex -n userRoot -T getrpcent directoryserver -s ipdserver vlvindex -n userRoot -T getspent

Using Service Search Descriptors to Modify Client Access to Various Services

A service search descriptor (SSD) changes the default search request for a given operation in LDAP to a search you define. SSDs are particularly useful if, for example, you have been using LDAP with customized container definitions or another operating system and are now transitioning to Solaris 9. Using SSDs, you can configure Solaris 9 LDAP naming services without having to change your existing LDAP database and data.

Setting Up SSDs Using idsconfig

Assume your predecessor at Example, Inc. had configured LDAP, storing users in ou=Users container. You are now upgrading to Solaris 9. By definition, Solaris 9 LDAP assumes that user entries are stored in ou=People container. Thus, when it comes to searching the passwd service, LDAP will search the ou=people level of the DIT and not find the correct values.

One rather laborious solution to the above problem would be to completely overwrite Example, Inc.'s existing DIT and to rewrite all the exiting applications on Example, Inc.'s network so that they are compatible with the new LDAP naming service. A second, far preferable solution would be to use an SSD that would tell LDAP to look for user info in an ou=Users container instead the default ou=people container.

You would define the necessary SSD during the configuration of the iPlanet Directory Server 5.1 using idsconfig. The prompt line appears as follows.

Do you wish to setup Service Search Descriptors (y/n/h? y
 A  Add a Service Search Descriptor
  D  Delete a SSD
  M  Modify a SSD
  P  Display all SSD's
  H  Help
  X  Clear all SSD's

  Q  Exit menu
Enter menu choice: [Quit] a
Enter the service id: passwd
Enter the base: service ou=user,dc=west,dc=example,dc=com
Enter the scope: one[default]
  A  Add a Service Search Descriptor
  D  Delete a SSD
  M  Modify a SSD
  P  Display all SSD's
  H  Help
  X  Clear all SSD's

  Q  Exit menu
Enter menu choice: [Quit] p

Current Service Search Descriptors:
==================================
Passwd:ou=Users,ou=west,ou=example,ou=com?

Hit return to continue.

  A  Add a Service Search Descriptor
  D  Delete a SSD
  M  Modify a SSD
  P  Display all SSD's
  H  Help
  X  Clear all SSD's

  Q  Exit menu
Enter menu choice: [Quit] q