Installing and Configuring iDS

Installing and Configuring iDS

Configuring iDS is a two-stage process: the first stage involves installing and configuring the server to run iDS, and the second stage involves setting up iDS to support LDAP clients (as described in the next section). In order to begin the process of configuring the server to run iDS, the directoryserver program must be executed:

# /usr/sbin/directoryserver setup

You can install either the iPlanet Directory Server (iDS) or the stand-alone iPlanet Console. After selecting iDS, you are presented with three different installation options: express, which presents few opportunities for customization, but is very fast; typical, which offers some configuration before installation; and custom, which offers maximum flexibility but is the slowest installation method.

There are three packages that comprise the iDS installation:

  • Server Core Components, comprising all of the common objects used by iDS

  • iPlanet Directory Suite, which contains the management console and the iDS software

  • Administration Server, which contains packages for system administration and directory management

After selecting the appropriate packages to install, you need to indicate if the current installation will store configuration information, or whether this will be stored in another server. If data will be stored in another server, the hostname, port number, username, and password must all be entered so that the correct target iDS installation for configuration can be identified.

Following the selection of the configuration iDS target, you need to indicate if the current installation will store user and group information, or whether this will be stored in another server. Again, if data will be stored in another server, the hostname, port number, Distinguished Name (DN), password, and suffix must all be entered so that the correct target iDS installation for user and group data can be identified.

Next, the new iDS server must be set up with a unique server identifier, a port number that is not used by any other application, and the appropriate suffix for the local installation.


The default port number for LDAP is 389, while LDAP over SSL typically runs on port 636.

The administrator ID and password for the local iDS installation must be selected and entered next. This ID and password are also used for managing the local LDAP server using the management console.


Since the administrator ID and password can be used to gain access to the iDS server, and modify user and group data without restriction, it’s important that these credentials are chosen carefully so as to avoid easy guessing by rogue users.

The Administration Domain must be entered next. Since iDS can manage multiple domains simultaneously from a single server, it’s important that their data is kept functionally and physically separate. Typically, the Administration Domain matches the Internet domain name. However, each server needs to have a separate Administration Domain if they are located underneath a top-level domain. For example, if there are two separate iDS servers running in the domain, one for Engineering, and one for Sales, then the Administration Domains could be and, respectively.

The Directory Manager’s password for the local iDS installation must be selected and entered next. Since the Directory Manager ID and administrator ID password can be used to gain access to the iDS server and modify user and group data with few restrictions, it’s important that these credentials are chosen carefully so as to avoid dictionary-based cracking.

The Administration Server for iDS is used to manage all aspects of the LDAP service. The Administration Server runs as a web server, meaning that any HTML browser can be used to view and configure all current settings for the iDS server. A port must be chosen to access the iDS Administration Server. The URL for the Administration Server is then given by appending the port number with a colon to the hostname. For example, the URL suggests an LDAP server running on port 38575 of the host

Supporting LDAP Clients

In order to configure iDS to provide services to clients, the idsconfig command is used. The service configuration can either be manually entered on the command line or supplied from an external file when the -i option is passed. Alternatively, a configuration file from one system (generated by passing the -o option) can also be read in from an external file. If multiple iDS instances are installed, configuration information from the first installation can be used by subsequent installations. idsconfig can be started with the following command:

# /usr/lib/ldap/idsconfig

The following output shows a sample idsconfig session for In the first section, you are required to review the basic configuration of the directory service, including the port number and directory manager DN (and its password):

Enter the port number for iDS (h=help): [389]
Enter the directory manager DN: [cn=Directory Manager]
Enter passwd for cn=Directory Manager :
Enter the domainname to be served (h=help): []

Next, you need to review the directory and server details, including the BaseDN, profile name, and list of servers:

Enter LDAP BaseDN (h=help): [dc=sales,dc=cassowary,dc=net]
Enter the profile name (h=help): [default]
Are you sure you want to overwrite profile cn=default? y
Default server list (h=help): []
Preferred server list (h=help):
Choose desired search scope (one, sub, h=help): [one]

Security choices must be made next, including the credential level and authentication method:

The following are the supported credential levels:
1 anonymous
2 proxy
3 proxy anonymous
Choose Credential level [h=help]: [1] 1
The following are the supported Authentication Methods:
1 none
2 simple
3 sasl/DIGEST-MD5
4 tls:simple
5 tls:sals/DIGEST-MD5
Choose Authentication Method (h=help): [1] 2
Current authenticationMethod: simple
Do you want to add another Authentication Method? N

After reviewing the server configuration, you now need to configure client access. This includes setting timeouts for profile and directory access, password formats, and time and size limits:

Do you want the clients to follow referrals (y/n/h)? [n] n
Do you want to modify the server timelimit value (y/n/h)? [n] n
Do you want to modify the server sizelimit value (y/n/h)? [n] n
Do you want to store passwd's in "crypt" format (y/n/h)? [n] y
Do you want to setup a Service Authentication Methods (y/n/h)? [n] n
Search time limit in seconds (h=help): [60]
Profile Time To Live in seconds (h=help): [3600]
Bind time limit in seconds (h=help): [10] 2
Do you wish to setup Service Search Descriptors (y/n/h)? [n] n

Finally, you are presented with a configuration summary before any actions are performed by idsconfig:

Summary of Configuration
1 Domain to serve :
2 BaseDN to setup : dc=sales,dc=cassowary,dc=net
3 Profile name to create : default
4 Default Server List :
5 Preferred Server List :
6 Default Search Scope : one
7 Credential Level : anonymous
8 Authentication Method : simple
9 Enable Follow Referrals : FALSE
10 iDS Time Limit :
11 iDS Size Limit :
12 Enable crypt passwd storage : 1
13 Service Auth Method pam_ldap :
14 Service Auth Method keyserv :
15 Service Auth Method passwd-cmd:
16 Search Time Limit : 30
17 Profile Time to Live : 43200
18 Bind Limit : 2
19 Service Search Descriptors Menu

Exercise 31-3 idsconfig Configuration  Review your idsconfig configuration. Are there any options that you would need to set differently from the previous example?

Creating LDAP Entries

The ldapaddent command is used to create entries in the LDAP container for all of the standard system databases stored in files underneath the /etc directory. All of the following Solaris databases (with the corresponding ou) can be transferred into LDAP by this method:

  • aliases (ou=Aliases)

  • bootparams (ou=Ethers)

  • ethers (requires bootparams database to be installed first) (ou=Ethers)

  • group (ou=Group)

  • hosts (ou=Hosts)

  • netgroup (ou=Netgroup)

  • netmasks (requires networks database to be installed first) (ou=Networks)

  • networks (ou=Networks)

  • passwd (ou=People)

  • shadow (requires passwd database to be installed first) (ou=People)

  • protocols (ou=Protocols)

  • publickey (ou=Hosts)

  • rpc (ou=Rpc)

  • services (ou=Services)

Starting a Client

The ldapclient program can be used for several purposes, including starting LDAP client services on client systems and reviewing the LDAP cache. In order to initialize a client you will need the address of the LDAP server and where its profile is stored. The LDAP cache manager (ldap_cachemgr) is responsible for ensuring that the correct configuration data is returned to a client upon initialization, especially if changes have been made to the profile. One of the following subcommands must be supplied on the command line to specify the behavior of ldapclient:

  • genprofile Creates an LDIF format configuration file that can exported to another system, or imported at some future time.

  • init Initializes an LDAP client from an LDAP server using a profile.

  • list Prints a list of entries stored in the client cache to standard output.

  • manual Initializes an LDAP client from an LDAP server using parameters specified on the command line.

  • mod Permits the modification of parameter values after initialization has been completed.

  • uninit Uninitializes an LDAP client from an LDAP server.

The following parameters can be modified by using the ldapclient mod command, or passed directly for manual initialization using the ldapclient manual command:

  • attributeMap Used to modify the default schema for a specific service.

  • authenticationMethod Stipulates the authentication method to be used (none, simple, sasl/CRAM-MD5, sasl/DIGEST-MD5, tls:simple, tls:sasl/CRAM-MD5, or tls:sasl/DIGEST-MD5). None means no security at all, while simple means that a password is sent in the clear and is vulnerable to interception. The other methods use a message digest algorithm to enhance security.

  • bindTimeLimit Maximum number of seconds allowed for a bind operation to be performed.

  • certificatePath Full path to the certificate database.

  • credentialLevel Specifies the type of credential required for authentication (either anonymous or proxy).

  • defaultSearchBase Specifies the BaseDN for searching.

  • defaultSearchScope Determines the scope for searching on the client side.

  • domainName Fully qualified domain name.

  • followReferrals Determines whether the referral setting is used.

  • objectclassMap Used to designate a different schema.

  • preferredServerList Lists a set of alternative LDAP servers to be contacted prior to the default.

  • profileName Determines the name of the client profile.

  • profileTTL Refresh epoch for the client cache to obtain new information from the server.

  • proxyDN Specifies the DN for the proxy server.

  • proxyPassword States the password for the proxy server.

  • searchTimeLimit Restricts the amount of time for each LDAP search.

  • serviceAuthenticationMethod Determines the authentication method for the passwd-cmd, keyserv, and pam_ldap services.

  • serviceCredentialLevel Specifies the type of credential required for service authentication (either anonymous or proxy). Proxy access for clients can occur only if a proxy account has previously been created in the directory and the proxyDN and proxyPassword attributes have been defined. Anonymous is not recommended, because it provides no security at all.

  • serviceSearchDescriptor Allows a different BaseDN to be specified on a per-service basis.

Let’s look at some different examples of how LDAP clients can be initialized by using ldapclient. In the first example, the LDAP server will be used to initialize the local client by using the init subcommand:

# ldapclient init

No additional parameters are necessary. However, a manual installation is much more complex, as all nondefault parameters must be specified. Sometimes only a single parameter will differ from the default; for example, if simple authentication was required, instead of no authentication (the default), the following command would be used:

# ldapclient manual –a authenticationMethod=simple \
         –a defaultServerList=

Alternatively, if a higher-level search base needed to be specified, the following command could be used:

# ldapclient manual –a authenticationMethod=simple \
         -a defaultSearchBase=dc=cassowary,dc=net    \
         –a defaultServerList=

To generate an LDIF format configuration file, we would use the genprofile subcommand, and redirect the output to a file (/tmp/default.ldif):

# ldapclient genprofile -a profileName=default \
-a defaultSearchBase=dc=cassowary,dc=net \
-a defaultServerList= \
> /tmp/default.ldif

Using the LDAP-NIS+ Interface

The nisldapmaptest command is used to operate on data stored within LDAP by using a NIS+ interface. This is particularly important when testing to see that NIS+ and LDAP services are correctly integrated. It can also be useful for experienced NIS+ administrators who want to add, delete, or modify LDAP records by using a familiar NIS+ interface. There are several options that can be passed to the nisldapmaptest command, including

  • -d Enables deletion of data

  • -r Updates data or add new data

  • -s Searches for existing data

  • -t Name of the target NIS+ object

Let’s look at some examples of how the nisldapmaptest command can be used. First, we will examine how to determine whether a user entry ("pwatters") exists in the password table:

# nisldapmaptest -t passwd.org_dir name=pwatters

Any of the following tables can be queried in this way:

  • auto_home

  • auto_master

  • bootparams

  • client_info

  • cred

  • ethers

  • group

  • hosts

  • mail_aliases

  • netgroup

  • netmasks

  • networks

  • passwd

  • protocols

  • rpc

  • sendmailvars

  • services

  • timezone

For example, to obtain a list of hosts stored in the hosts table, we would use the following command:

# nisldapmaptest -t hosts.org_dir

If a host was found in the table that was no longer valid, it could be deleted by using the following command:

# nisldapmaptest -d -t hosts.org_dir name=oldhost

Part I: Solaris 9 Operating Environment, Exam I