Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
  Previous   Contents   Next 
   
 
Chapter 15

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

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

Variable

Definition for Example Network

Port number at which an instance of the directory server is installed (DEFAULT=389)

default

Name of server

ipdserver (from the FQDN ipdserver.west.example.com or 192.168.0.0)

Replica server(s) (IPnumber:port number)

192.168.0.1 [for ipdrep.west.example.com]

Directory manager [dn: cn=directory manager]

default

Domain name to be served

west.example.com

Maximum time (in seconds) to process client requests before timing out

--1

Maximum number of entries returned for each search request

--1


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

Variable

Definition for Example Network

Profile name

WestUserProfile

Server list (defaults to the local subnet)

west.example.com or 192.168.0.0

Preferred server list (listed in order of which server to try first, second, and so on)

none

Search scope (number of levels down through the directory tree. 'One' or 'Sub')

one (default)

Credential used to gain access to server. Default is anonymous

proxy

Follow Referrals? ( a pointer to another server if the main server is unavailable) Default is no.

Y

Search time limit (in seconds, default 30) for waiting for server to return information.

default

Bind time limit (in seconds, default 30) for contacting server. The default is seconds.

2

Authentication method Default is none.

simple


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.

membernisnetgroup

pres,eq,sub

nisnetgrouptriple

pres,eq,sub

memberuid

pres,eq

uidNumber

pres,eq

gidNumber

pres,eq

ipHostNumber

pres,eq

ipNetworkNumber

pres,eq

ipProtocolNumber

pres,eq

oncRpcNumber

pres,eq

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
 
 
 
  Previous   Contents   Next