BigAdmin Feature Article: Sun Java System Directory Server 6.0 as an LDAP Naming Service: Part 1 -- Installation and Configuration

BigAdmin System Administration Portal

Feature Article

Submit Content | Check BigAdmin Bucks

Sun Java System Directory Server 6.0 as an LDAP Naming Service: Part 1 -- Installation and Configuration

Jonathan Gershater, Sun Microsystems, and Vineeth Katarki, Mascon Global Limited (MGL); October 2007 (Updated February 2008)

This article provides instructions for deploying Sun Java System Directory Server 6.0 (hereafter referred to as "Directory Server"), which is part of Sun Java System Directory Server 6.0 Enterprise Edition, as a naming service for UNIX clients that run AIX 5.3, Red Hat Linux Release 4 Update 4, or the Solaris 8, 9, or 10 Operating System.

Article Contents

This article is presented in the following four parts:

Note: When you run the commands shown in the procedures of this article, replace COMPANY with a value that is appropriate for your environment.

Part 1 -- Installation and Configuration

Part 1 Contents

Part 1 covers the following topics, which provide information related to installing and configuring Directory Server as a naming service for native LDAP clients:

Business Considerations and Implications
Architecture of Directory Service
Environment Requirements
Overview of Deployment Steps
Directory Server Documentation
Installing Directory Server
Configuring the Sun Java Web Console and Directory Server
Configuring SSL and the idsconfig Script
- Configuring SSL Using CA-Signed Certificates
- Modifying the idsconfig Script
Setting Up Replication
Backing Up and Restoring Data
Managing Group and Netgroup LDAP Entries
Tuning Settings
- Tuning the Operating System
- Tuning Directory Server
Uninstalling Directory Server
For More Information

Business Considerations and Implications

The business considerations and implications of migrating UNIX servers and workstations (clients) to using LDAP as a naming service must be carefully considered before embarking on the project.

When LDAP is used as a naming service for UNIX clients, then one unique UID number is established for each user and one unique GID number for each group. This means that if there is no consistent naming and numbering of users and groups prior to migration, then the following activities have to occur as part of the migration.

1. A consolidation effort will have to take place to select a unique UID number for each user and GID number for each group. This is a manual process of gathering all the /etc/passwd and /etc/group files from each client. Thereafter the data is analyzed in a spreadsheet. If there are many disparate UID and GID numbers for users and groups with the same name then a typical strategy is to select unique UID and GID numbers which have the most users and groups. For example, consolidating the dba group on two servers:

dba:x:1115:duncan,marion       In server1 /etc/group
dba:x:2000:kevin,jim           In server2 /etc/group

When the files are merged, the entry for group dba may be:

dba:x:2000:duncan,marion,kevin,jim

Spreadsheets are useful; a simple spreadsheet may look like Table 1.

Table 1: UNIX Group Names That Will Need to Change

Platform	Owner	Group Name	New Proposed GID	Current GIDs	Number of Hosts
Solaris	Smith, John	dba	2000	101	4
Solaris	Smith,John	admins	3000	102	8
AIX	Jones, Mary	finance	4000	103	2
AIX	Jones, Mary	crm-admin	5000	107	2
AIX	Jones, Mary	crm-user	5001	104	2
Linux	Chu, Ha	hr	6000	118	4
Linux	Smith, Cindy	brio	7000	102	3
Linux	Kennedy, Dave	oracle	8000	101	4
Linux	Kennedy, Dave	staff	9000	101	5

2. Since a new UID and GID numbers are assigned, there may be UNIX clients which have different UID and GID numbers for users and groups and thus when migrated the UID and GID numbers have to change. There may also be instances where home-grown applications have GID and UID numbers hard-coded. The impact of changing UID and GID numbers of UNIX workstations and servers means that chown and chgrp commands have to be run across the file system. Depending on the number of files this can be a time-consuming process. It also requires downtime since users should not be accessing files as the UID and GID numbers are changing. Thus it is highly recommended that the chown and chgrp commands be run when the server is in single-user mode (execute boot-s or init 0).

3. A server may have files with UID or GID numbers that no longer exist in /etc/passwd and /etc/group. It is possible to find such files with this command:

find / '(' -nouser -o -nogroup ')' -ls

This produces a list of files that probably should be examined manually to determine which new or existing users and/or groups should be reassigned.

The migration of UNIX servers and workstations to an LDAP naming service must make business allowances for the downtime of servers and impact to users and applications of a new UID or GID number.

Architecture of Directory Service

The configuration described in this document results in the following architecture:

Directory Server is installed on two servers in each data center (hereafter called "directory servers"), as shown in Figure 1. Two directory servers in each data center are replicated between one another and two directory servers between each data center are replicated. This architecture provides a highly available failover configuration for the clients that authenticate to either data center.
The clients, which previously were configured to use local /etc files, are converted to use Directory Server as a naming service.
Native LDAP clients that run AIX, Linux, or the Solaris OS connect to Directory Server over SSL. The directory servers are configured with SSL certificates signed by an internal Certificate Authority (CA), not with self-signed certificates.
Groups and netgroups are managed using the Directory Server Sun Java Web Console.

Figure 1: Architecture of Directory Service
(Click to Enlarge)

Historically, UNIX and Linux systems were typically configured for the NIS naming service or individually managed using local files in the /etc directory. Directory Server can be used as a naming service for native LDAP clients. This means Directory Server serves as a repository for:

Users who log in to AIX, Linux, and Solaris servers and workstations
Groups of users
Password policies governing user passwords
Netgroups restricting user access to specified servers and workstations
Policies governing inactive users

The Directory Server LDAP naming service architecture provides the following advantages:

A centralized repository for users, groups, password policies, and netgroups
A repository for replicating information, which provides high failover capability and high availability
A highly scalable repository, since the addition of incremental workstations results in minimal load on the directory servers

Environment Requirements

It is assumed that the following conditions apply to your environment currently or they will apply after you use the procedures in this document:

Directory Server version 6.0 is installed on the four directory servers, which run the Solaris 10 OS with all the required patches.
SSL will be used for all communication between the directory servers and between the directory servers and the AIX, Linux, and Solaris OS clients.
There is no existing NIS/NIS+ environment.
You will consolidate user data from the local /etc/passwd and /etc/group files on all native LDAP clients, and you will enforce uidNumber uniqueness.
The pam_ldap Solaris pluggable authentication module (PAM) is used exclusively for directory users and account management.
Netgroups will be used to control user access to any server managed by the Directory Server naming service.

Overview of Deployment Steps

The following are the high-level steps required to set up the naming service:

Install and configure Directory Server to support LDAP naming services for the clients.
Configure UNIX servers that run the Solaris 8, 9, or 10 OS, Red Hat Linux Release 4 Update 4 or AIX 5.3 to use the directory servers.
Load user data into the Directory Server software.

Directory Server Documentation

Here are links to related Directory Server documentation:

Installing Directory Server

Perform the following procedure on one directory server. Later, data will be copied to the other directory servers using standard Directory Server replication. Replication is outside the scope of this article, but it is well documented in the Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.

Note: It is highly recommended that the Directory Server software be installed in the sequence shown in this section.

1. Ensure that the required Solaris package, SUNWnisu, is installed.

2. Ensure that the following required Solaris patches are installed:

SunOS 5.10: Kernel patch 118833 (SUNWnisu must be installed first)
SunOS 5.10: Shared library patch for C++ 119963
SunOS 5.10: Update timezones patch 122032

3. Download the Directory Server package from http://www.sun.com/software/products/directory_srvr_ee/get1.jsp, as shown in Figure 2, and then install the package.

Note: Ensure that you download and install the Native Package (PKG) version of Directory Server.

Figure 2: Download Directory Server Package
(Click to Enlarge)

Configuring the Sun Java Web Console and Directory Server

Perform the following procedure on each directory server. If the Java Web Console and DSEE services are not started, then start them per instructions #1 and #2 below. Similarly, if you did not create a suffix during installation, create a suffix per instruction #3 below.

1. Start the Sun Java Web Console:

# /usr/sbin/smcwebserver start
Starting Sun Java(TM) Web Console Version 3.0.2 ...
The console is running

2. Start the Common Agent:


# /usr/sbin/cacaoadm start

3. Create the suffix:

# /opt/SUNWdsee/ds6/bin/dsconf create-suffix -h server1.COMPANY.com -p 389 dc=COMPANY,dc=com
Certificate "CN=server1.COMPANY.com, CN=636, CN=Directory Server,
  O=Sun Microsystems" presented by the server is not trusted.
Type "Y" to accept, "y" to accept just once, "n" to refuse,
  "d" for more details: Y
Enter "cn=Directory Manager" password:

4. Put the certificate database password in a file:

#pwd
/var/opt/SUNWdsee/dsins1
# cat > certpassword.txt
secretpassword^D

5. Set the certificate database password:

#/opt/SUNWdsee/ds6/bin/dsadm stop /var/opt/SUNWdsee/dsins1
#/opt/SUNWdsee/ds6/bin/dsadm set-flags /var/opt/SUNWdsee/dsins1
  cert-pwd-prompt=on
Choose the new certificate database password:
Confirm the new certificate database password:
Certificate database password successfully updated.

6. Start Directory Server:

# ./dsadm start --cert-pwd-file /var/opt/SUNWdsee/dsins1/
  certpassword.txt /var/opt/SUNWdsee/dsins1

7. Register the Directory Server instance in the Directory Service Control Center (DSCC):

# pwd
/opt/SUNWdsee/ds6/bin
# cd ../../dscc6/bin
# ./dsccreg add-server /var/opt/SUNWdsee/dsins1
Enter DSCC administrator's password:
/var/opt/SUNWdsee/dsins1 is an instance of DS
Enter password of "cn=Directory Manager" for
  /var/opt/SUNWdsee/dsins1:
This operation will restart /var/opt/SUNWdsee/dsins1.
Do you want to continue? (y/n) y
Connecting to /var/opt/SUNWdsee/dsins1
Enabling DSCC access to /var/opt/SUNWdsee/dsins1
Restarting /var/opt/SUNWdsee/dsins1
Registering /var/opt/SUNWdsee/dsins1 in DSCC on localhost.

8. Configure Directory Server to start automatically on reboot:

a. Enable the service (start Directory Server):

# ./dsadm enable-service --type SMF /var/opt/SUNWdsee/dsins1
Registering 'Directory Server' as 'application/sun/ds' in SMF ...
Registering '/var/opt/SUNWdsee/dsins1' as
  'ds--var-opt-SUNWdsee-dsins1' in SMF ...
Instance /var/opt/SUNWdsee/dsins1 registered in SMF

b. Confirm that the Service Management Facility (SMF) exists:

# svcs | grep ds
online    22:46:31 svc:/application/sun/ds:ds--var-opt-
  SUNWdsee-dsins1

c. Attempt to successfully connect to Directory Server:

# telnet localhost 389
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
^CConnection to localhost closed by foreign host.

d. Disable the service (stop Directory Server):

# svcadm disable ds:ds--var-opt-SUNWdsee-dsins1

e. Attempt to successfully connect to Directory Server:

# telnet localhost 389
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
Trying ::1...
telnet: Unable to connect to remote host: Network is unreachable

9. (Optional) Configure the Sun Java Web Console to start automatically using the following command:

# smcwebserver enable

10. (Optional) Set the Common Agent Container (cacao) to start automatically using the following command:

# cacaoadm enable

Configuring SSL and the idsconfig Script

Use the following procedures to make configuration changes to the standard Directory Server installation on each directory server.

Configuring SSL Using CA-Signed Certificates

1. Request CA certificates.

The exact information required depends on your Certificate Authority (CA). The following example is for an arbitrary city in California, USA.

a. Create a certificate request:

/opt/SUNWdsee/ds6/bin/dsadm request-cert --city "Any City"
--country "US" -F ascii --name server --org "Organization"
--org-unit "Org unit" --state CA -o /tmp/CertReq
/var/opt/SUNWdsee/dsins1

The request above is in ASCII format (-F ascii), and the output file reads as follows:

b. Request a server certificate from your CA.

The server certificate you receive from your CA is in PEM format. Copy the text from -----BEGIN CERTIFICATE ----- through -----END CERTIFICATE -----, paste it into a text editor, and save as a file on your workstation.

c. Upload the file to the Directory Server as /tmp/CertFile.

Note: In addition to requesting a server certificate, you must request the CA signing certificates from your CA, so that other Directory Servers and clients trust the CA-signed server certificate. These should be the root and any intermediate CA signing certificates. Upload these to the Directory Server as /tmp/CACert.

2. Add the server and CA certificates to Directory Server.

a. Add the server SSL certificate:

Using dsadm:

#/opt/SUNWdsee/ds6/bin/dsadm add-cert /var/opt/sun/dsins1
ServerCert /tmp/CerFile

Alternate method using certutil:

# /usr/sfw/bin/certutil -A -n ServerCert -t u,u,u -d
/var/opt/SUNWdsee/dsins1/alias -i /tmp/CertFile

b. Set the newly added server certificate as the default Directory Server certificate:

/opt/SUNWEdsee/ds6/bin/dsconf set-server-prop -e -p 389
ssl-rsa-cert-name:ServerCert

c. Add the CA signing certificates:

Using dsadm:

/opt/SUNWdsee/ds6/bin dsadm add-cert -C /var/opt/sun/dsins1
CACert /tmp/cacert.pem

Alternate method using certutil:

# /usr/sfw/bin/certutil -A -n CA -t CT,, -d
/var/opt/SUNWdsee/dsins1/alias -i /tmp/CACert

d. View the added server certificates:

Using dsadm:

e. View the added CA certificate:

/opt/SUNWdsee/ds6/bin/dsadm list-certs -C /var/opt/SUNWdsee/dsins1
Alias                                                                              Valid from        Expires on        Built-in?  Issued by                                                                                 Issued to
---------------------------------------------------------------------------------  ----------------  ----------------  ---------  ----------------------------------------------------------------------------------------  --------------
Builtin Object Token:ABAecom (sub., Am. Bankers Assn.) Root CA                     1999/07/12 17:33  2009/07/09 17:33  y          -                                                                                         Same as issuer

Builtin Object Token:beTRUSTed Root CA-Baltimore Implementation                    2002/04/11 07:38  2022/04/11 07:38  y          -                                                                                         Same as issuer
CACert                                                                             2005/08/16 22:48  2025/08/15 22:48  n          CN=Delivery Root CA,OU=Org unit,O=Company,C=US  Same as issuer
defaultCert                                                                        2008/01/28 18:04  2008/04/28 18:04  n          CN=server,CN=636,CN=Directory Server,O=Sun Microsystems                                   Same as issuer
106 certificates found

Alternate method using certutil:

/usr/sfw/bin/certutil -L -P slapd- -d /var/opt/SUNWdsee/dsins1/alias

defaultCert                                             CTu,u,u
ServerCert                                                u,u,u
Root CA                                                 CT,,

f. Restart your Directory Server:

/opt/SUNWdsee/dsadm restart /var/opt/SUNWdsee/dsins1

Modifying the idsconfig Script

The purpose of the idsconfig script is to configure Directory Server for use by native LDAP clients. The script adds schema, objects, and indexes required for native LDAP clients to authenticate and obtain UNIX information from Directory Server. The script is located in /usr/lib/ldap/idsconfig.

Use the following procedure if Directory Server is installed on a server running the Solaris 10 11/06 OS or an earlier version of the Solaris OS.

1. The script checks whether Directory Server is version 5 and exits if any other version is used. Therefore, you need to comment out the second exit 1 statement, as shown in bold in the following example:

chk_ids_version()
{
[ $DEBUG -eq 1 ] &&  "In chk_ids_version()"
# check iDS version number.
eval "  -b cn=monitor -s base
  \"objectclass=*\" version |  \"^version=\" | cut -f2 -d'/'
  | cut -f1 -d' ' > /checkDSver 2>&1"
if [ $? -ne 0 ]; then
 "ERROR: Can not determine the version number of iDS!"
exit 1
fi
IDS_VER=`cat /checkDSver`
IDS_MAJVER=`  | cut -f1 -d.`
IDS_MINVER=`  | cut -f2 -d.`
if [ "" != "5" ]; then
 "ERROR: $PROG only works with iDS version 5.x, not
  ."

# exit 1
fi
if [ $DEBUG -eq 1 ]; then
 " IDS_MAJVER = $IDS_MAJVER"
 " IDS_MINVER = $IDS_MINVER"
fi

2. The end of the script instructs you to manually run directoryserver commands for virtual list view (VLV) indexes, but /usr/sbin/directoryserver does not apply to Directory Server 6.0. Here are the equivalent commands for Directory Server 6.0. Replace company and the instance of your Directory Server, as needed.

.../dsadm reindex -l -t company.com.getgrent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.gethostent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getnetent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getrpcent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getspent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getauhoent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getauhoent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getsoluent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getauhoent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getauduent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getauthent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getexecent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getprofent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getmailent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getbootent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getethent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getngrpent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getipnent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getmaskent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getprent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getip4ent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com
.../dsadm reindex -l -t company.com.getip6ent
/var/opt/SUNWdsee/dsins2 dc=company,dc=com

The following is output from a captured idsconfig session:

Script started on Mon Apr 30 21:59:35 2007

#pwd
/usr/lib/ldap
# ./idsconfig

It is strongly recommended that you BACKUP the directory server
before running idsconfig.

Hit Ctrl-C at any time before the final confirmation to exit.

Do you wish to continue with server setup (y/n/h)? [n] y
Enter the iPlanet Directory Server's (iDS) hostname to setup:
  server1
Enter the port number for iDS (h=help): [389]
ERROR: idsconfig only works with iDS version 5.x, not 6.0.
Enter the directory manager DN: [cn=Directory Manager]
Enter passwd for cn=Directory Manager :
Enter the domainname to be served (h=help): [COMPANY.com]
Enter LDAP Base DN (h=help): [dc=COMPANY,dc=com]
  Checking LDAP Base DN ...
  Validating LDAP Base DN and Suffix ...
Enter the profile name (h=help): [default]
Default server list (h=help): [10.200.131.38]  10.200.131.38
  10.200.131.39
Preferred server list (h=help): 10.200.131.38  10.200.131.38
  10.200.131.39
Choose desired search scope (one, sub, h=help):  [one] sub
The following are the supported credential levels:
  1  anonymous
  2  proxy
  3  proxy anonymous
Choose Credential level [h=help]: [1] 2
The following are the supported Authentication Methods:
  1  none
  2  simple
  3  sasl/DIGEST-MD5
  4  tls:simple
  5  tls:sasl/DIGEST-MD5
Choose Authentication Method (h=help): [1] 4

Current authenticationMethod: tls:simple

Do you want to add another Authentication Method? n
Do you want the clients to follow referrals (y/n/h)? [n]
Do you want to modify the server timelimit value (y/n/h)? [n]
Do you want to modify the server sizelimit value (y/n/h)? [n]
Do you want to store passwords in "crypt" format (y/n/h)? [n]
Do you want to setup a Service Authentication Methods (y/n/h)? [n]
Client search time limit in seconds (h=help): [30]
Profile Time To Live in seconds (h=help): [43200]
Bind time limit in seconds (h=help): [10]
Do you wish to setup Service Search Descriptors (y/n/h)? [n]

Summary of Configuration

1  Domain to serve               : COMPANY.com
  2  Base DN to setup              : dc=COMPANY,dc=com
  3  Profile name to create        : default
  4  Default Server List           : 10.200.131.38
  5  Preferred Server List         : 10.200.131.38
  6  Default Search Scope          : sub
  7  Credential Level              : proxy
  8  Authentication Method         : tls:simple
  9  Enable Follow Referrals       : FALSE
 10  iDS Time Limit                :
 11  iDS Size Limit                :
 12  Enable crypt password storage : FALSE
 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                    : 10
 19  Service Search Descriptors Menu

Enter config value to change: (1-19 0=commit changes) [0]
Enter DN for proxy agent: [cn=proxyagent,ou=profile,dc=COMPANY,
  dc=com]
Enter passwd for proxyagent:
Re-enter passwd:

WARNING: About to start committing changes. (y=continue, n=EXIT) y

1. Schema attributes have been updated.
  2. Schema objectclass definitions have been added.
  3. NisDomainObject added to dc=COMPANY,dc=com.
  4. Top level "ou" containers complete.
  5. automount maps: auto_home auto_direct auto_master auto_shared
    processed.
  6. ACI for dc=COMPANY,dc=com modified to disable self modify.
  7. Add of VLV Access Control Information (ACI).
  8. Proxy Agent cn=proxyagent,ou=profile,dc=COMPANY,dc=com added.
  9. Give cn=proxyagent,ou=profile,dc=COMPANY,dc=com read
    permission for password.
  10. Generated client profile and loaded on server.
  11. Processing eq,pres indexes:
      uidNumber (eq,pres)   Finished indexing.
      ipNetworkNumber (eq,pres)   Finished indexing.
      gidnumber (eq,pres)   Finished indexing.
      oncrpcnumber (eq,pres)   Finished indexing.
      automountKey (eq,pres)   Finished indexing.
  12. Processing eq,pres,sub indexes:
      ipHostNumber (eq,pres,sub)   Finished indexing.
      membernisnetgroup (eq,pres,sub)   Finished indexing.
      nisnetgrouptriple (eq,pres,sub)   Finished indexing.
  13. Processing VLV indexes:
      COMPANY.com.getgrent vlv_index   Entry created
      COMPANY.com.gethostent vlv_index   Entry created
      COMPANY.com.getnetent vlv_index   Entry created
      COMPANY.com.getpwent vlv_index   Entry created
      COMPANY.com.getrpcent vlv_index   Entry created
      COMPANY.com.getspent vlv_index   Entry created
      COMPANY.com.getauhoent vlv_index   Entry created
      COMPANY.com.getsoluent vlv_index   Entry created
      COMPANY.com.getauduent vlv_index   Entry created
      COMPANY.com.getauthent vlv_index   Entry created
      COMPANY.com.getexecent vlv_index   Entry created
      COMPANY.com.getprofent vlv_index   Entry created
      COMPANY.com.getmailent vlv_index   Entry created
      COMPANY.com.getbootent vlv_index   Entry created
      COMPANY.com.getethent vlv_index   Entry created
      COMPANY.com.getngrpent vlv_index   Entry created
      COMPANY.com.getipnent vlv_index   Entry created
      COMPANY.com.getmaskent vlv_index   Entry created
      COMPANY.com.getprent vlv_index   Entry created
      COMPANY.com.getip4ent vlv_index   Entry created
      COMPANY.com.getip6ent vlv_index   Entry created

idsconfig: Setup of iDS server server1 is complete.

Note: idsconfig has created entries for VLV indexes.  Use the
      directoryserver(1m) script on server1 to stop
      the server and then enter the following vlvindex
      sub-commands to create the actual VLV indexes:

directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getgrent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.gethostent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getnetent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getpwent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getrpcent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getspent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getauhoent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getsoluent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getauduent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getauthent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getexecent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getprofent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getmailent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getbootent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getethent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getngrpent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getipnent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getmaskent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getprent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getip4ent
  directoryserver -s <server-instance> vlvindex -n COMPANY -T
    COMPANY.com.getip6ent
#
script done on Mon Apr 30 22:01:12 2007

Setting Up Replication

After Directory Server has been installed and configured on the four directory servers, proceed as follows to set up replication over SSL on each of the two pairs of directory servers (referred to below as "directory server #1" and "directory server #2").

1. Set up the temporary replication manager password:

a. Run the following command on both servers:

# echo password > var/opt/SUNWdsee/dsins1/replpassword.txt

b. On directory server #1, run the following command:

# /opt/SUNWdsee/ds6/bin/dsconf set-server-prop -e  -h
  server1.COMPANY.com -p 389
def-repl-manager-pwd-file:/var/opt/SUNWdsee/dsins1/replpassword.txt

c. On directory server #2, run the following command:

# /opt/SUNWdsee/ds6/bin/dsconf set-server-prop -e  -h
  server2.COMPANY.com -p 389
def-repl-manager-pwd-file:/var/opt/SUNWdsee/dsins1/replpassword.txt

2. Enable master-to-master replication:

a. Run the following command on directory server #1:

# /opt/SUNWdsee/ds6/bin/dsconf enable-repl -h
  server1.COMPANY.com -p 389 -e -d 1
  master dc=COMPANY,dc=com

b. Run the following command on directory server #2:

# /opt/SUNWdsee/ds6/bin/dsconf enable-repl -h
  server2.COMPANY.com  -p 389 -e -d 2
  master dc=COMPANY,dc=com

3. Exchange CA-signed server certificates to enable replication over SSL:

Note: See the "To Export and Import a CA-Signed Server Certificate" section of the administration guide for more information.

a. On directory server #1, run the following command:

#/opt/SUNWdsee/ds6/bin/dsadm export-cert -o /var/tmp/certfile1
  /var/opt/SUNWdsee/dsins1 "CompanyCertificate"

b. Copy certfile1 to server2.COMPANY.com by running the following command on directory server #2:

#/opt/SUNWdsee/ds6/bin/dsadm export-cert -o /var/tmp/certfile2
  /var/opt/SUNWdsee/dsins1 "CompanyCertificate"

c. Copy certfile2 to server1.COMPANY.com using FTP or any similar method.

4. Add the exported server certificates to the respective servers:

Note: In the following example, dsins1 is acting as directory server #1, and dsins2 is acting as directory server #2.

# /opt/SUNWdsee/ds6/bin/dsadm add-cert /var/opt/SUNWdsee/dsins1
  "COMPANYCert" certfile2

# /opt/SUNWdsee/ds6/bin/dsadm add-cert --ca /var/opt/SUNWdsee/dsins2/
  "ds2 Repl Manager Cert" certfile1

# /opt/SUNWdsee/ds6/bin/dsadm import-cert /var/opt/SUNWdsee/dsins1
  certfile2
Enter the PKCS#12 file password:
A certificate with the same subject (CN=VI CATest2,O=COMPANY,C=US)
  already exists in the database.
Do you want to continue [y/n]? y
A certificate with the same subject (CN=TEST COMPANY, O=COMPANY,C=US)
  already exists in the database.
Do you want to continue [y/n]? y

5. Create replication agreements:

Note: Secure LDAP ports are used for the replication agreements.

a. Run the following command on directory server #1:

# /opt/SUNWdsee/ds6/bin/dsconf create-repl-agmt -h
  server1.COMPANY.com  -p 389 -e --auth-protocol "ssl-simple"
  dc=COMPANY,dc=com server2.COMPANY.com:636

b. Run the following command on directory server #2:

# /opt/SUNWdsee/ds6/bin/dsconf create-repl-agmt -h
  server2.COMPANY.com  -p 389 -e --auth-protocol "ssl-simple"
  dc=COMPANY,dc=com server1.COMPANY.com:636

6. Configure the authentication password file to be used by replication manager:

a. Run the following command on directory server #1:

# /opt/SUNWdsee/ds6/bin/dsconf set-repl-agmt-prop -h
  server1.COMPANY.com -p 389 -e dc=COMPANY,dc=com
  server2.COMPANY.com:636
  auth-pwd-file:/var/opt/SUNWdsee/dsins1/replpassword.txt

b. Run the following command on directory server #2:

# /opt/SUNWdsee/ds6/bin/dsconf set-repl-agmt-prop -h
  server2.COMPANY.com -p 389 -e dc=COMPANY,dc=com
  server1.COMPANY.com:636
  auth-pwd-file:/var/opt/SUNWdsee/dsins1/replpassword.txt

7. Restart the directory servers:

# /opt/SUNWdsee/ds6/bin/dsadm restart /var/opt/SUNWdsee/dsins1

8. (Optional) Initialize the suffix on directory server #1 with data from directory server #2 by running the following command on directory server #1:

#/opt/SUNWdsee/ds6/bin/dsconf init-repl-dest -e -h
  server1.COMPANY.com -p 389 dc=COMPANY,dc=com
  server2.COMPANY.com.server:636

	Started initialization of "server1.COMPANY.com:389"; May 7,
	  2007 11:08:28 PM
	Sent 109 entries...
	Sent 349 entries...
	Sent 549 entries...
	Sent 550 entries.
	Completed initialization of "server1.COMPANY.com:389"; May 7,
	  2007 11:08:35 PM

Backing up and Restoring Data

Backing up and restoring data is well documented in the Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.

Since the directory servers are in a multi-master replication, if one directory server fails, its data can be replicated easily from one of the other directory servers. Since there is not a large amount of data, this is the preferred method for restoring data.

See the "Initializing Replicas" section of the administration guide for more information.

Also see the general replication information in the administration guide.

Managing Group and Netgroup LDAP Entries

To manage information using the Sun Java Web Console, access the console using the following address:

https://server1.COMPANY.com:6789/

Adding Netgroups Using the Console

To add netgroups using the console, access the console and then perform the following steps.

1. Select Entry Management.

Figure 3: Directory Entry Management Screen
(Click to Enlarge)

2. Enter the domain name (DN).

Figure 4: Specify Entry Location Screen
(Click to Enlarge)

3. Select the nisNetgroup object class.

Figure 5: Choose Object Class Screen
(Click to Enlarge)

4. Fill in the attributes, as shown in Figure 6, and refer to Figure 7, as needed.

Figure 6: Configure Attributes Screen
(Click to Enlarge)

Figure 7: Summary Screen
(Click to Enlarge)

Adding Netgroups Using the Command Line

1. Create a Lightweight Directory Interchange Format (LDIF) file:

# more netgroup.ldif

dn: cn=mynisnetgroup,ou=netgroup,dc=COMPANY,dc=com
changetype: add
nisNetgroupTriple: (,user345789,)
description: SunServer
objectClass: nisNetgroup
objectClass: top
memberNisNetgroup: server3

2. Execute the ldapmodify command:


# ldapmodify -h server2.COMPANY.com -D "cn=Directory Manager" -f
  netgroup.ldif
Enter bind password:
adding new entry cn=mynisnetgroup,ou=netgroup,dc=COMPANY,
  dc=com

3. Run the ldapsearch command to verify the status:

# ldapsearch -b "ou=netgroup,dc=COMPANY,dc=com" -D "cn=Directory Manager"
  "cn=mynisnetgroup"
Enter bind password:

version: 1
dn: cn=mynisnetgroup,ou=netgroup,dc=COMPANY,dc=com
nisNetgroupTriple: (,user345789,)
description: SunServer
objectClass: nisNetgroup
objectClass: top
memberNisNetgroup: server3
cn: mynisnetgroup

Modifying Netgroups Using the Console

To modify netgroups using the console, access the console and then perform the following steps.

1. Search for the netgroup, as shown in Figure 8.

Figure 8: Searching for a Netgroup
(Click to Enlarge)

2. Edit the attributes and click OK.

Figure 9: Editing Attributes
(Click to Enlarge)

Modifying Netgroups Using the Command Line

1. Create an LDIF file:

# more netgroup.ldif
dn: cn=mynisnetgroup,ou=netgroup,dc=COMPANY,dc=com
changetype: modify
replace: nisNetgroupTriple
nisNetgroupTriple: (,user345,)

2. Execute ldapmodify:

# ldapmodify -h server2.COMPANY.com -D "cn=Directory Manager" -f
  netgroup.ldif
Enter bind password:
modifying entry cn=mynisnetgroup,ou=netgroup,dc=COMPANY,dc=com

3. Run ldapsearch to verify the status:

# ldapsearch -b "ou=netgroup,dc=COMPANY,dc=com" -D "cn=Directory
  Manager"
"cn=mynisnetgroup"

Enter bind password:
version: 1
dn: cn=mynisnetgroup,ou=netgroup,dc=COMPANY,
  dc=com
nisNetgroupTriple: (,user345,)
description: ss7ed06Server
objectClass: nisNetgroup
objectClass: top
memberNisNetgroup: ss72ed06
cn: mynisnetgroup

Deleting Netgroups Using the Console

To delete netgroups using the console, access the console and then perform the following steps.

1. Search for the netgroup, as described in Modifying Netgroups Using the Console.

2. Select and delete the netgroup, as shown in Figure 10.

Figure 10: Searching for a Netgroup
(Click to Enlarge)

Deleting Netgroups Using the Command Line

1. Create an LDIF file:

# more netgroup.ldif
dn: cn=mynisnetgroup,ou=netgroup,dc=COMPANY,dc=com
changetype: delete

2. Execute ldapmodify:

# ldapmodify -h server2.COMPANY.com -D "cn=Directory Manager" -f netgroup.ldif
Enter bind password:
deleting entry cn=mynisnetgroup,ou=netgroup,dc=COMPANY,dc=com

3. Run ldapsearch to verify the status:

# ldapsearch -v -b "ou=netgroup,dc=COMPANY,dc=com" -D "cn=Directory
  Manager" -w password  "cn=mynisnetgroup"
ldapsearch: started Tue May  8 21:58:10 2007

ldap_init( localhost, 389 )
filter pattern: cn=mynisnetgroup
returning: ALL
filter is: (cn=mynisnetgroup)
0 matches

Adding Groups Using the Console

To add groups using the console, access the console and then perform the following steps.

1. Select Entry Management.

Figure 11: Directory Entry Management Screen
(Click to Enlarge)

2. Enter the DN, and ensure you select ou=group, not ou=Groups.

Figure 12: Specify Entry Location Screen
(Click to Enlarge)

3. Select the posixGroup object class.

Figure 13: Choose Object Class Screen
(Click to Enlarge)

4. Fill in the attributes, as shown in Figure 14, and refer to Figure 15, as needed.

Figure 14: Configure Attributes Screen
(Click to Enlarge)

Figure 15: Summary Screen
(Click to Enlarge)

Adding Groups Using the Command Line

1. Create an LDIF file:

# more group.ldif
dn: cn=solarisgroup,ou=group,dc=COMPANY,dc=com
changetype: add
objectClass: posixGroup
objectClass: top
memberuid: sunuser300
gidNumber:4001

2. Execute ldapmodify:

# ldapmodify -h server2.COMPANY.com -D "cn=Directory Manager" -f
  group.ldif
Enter bind password:
adding new entry cn=solarisgroup,ou=group,dc=COMPANY,dc=com

3. Run ldapsearch to verify the status:

# ldapsearch -v -b "ou=group,dc=COMPANY,dc=com" -D "cn=Directory
  Manager"  "cn=solarisgroup"

ldapsearch: started Tue May  8 22:49:33 2007
	ldap_init( localhost, 389 )
filter pattern: cn=solarisgroup
returning: ALL
filter is: (cn=solarisgroup)
version: 1
dn: cn=solarisgroup,ou=group,dc=COMPANY,dc=com
objectClass: posixGroup
objectClass: top
memberUid: sunuser300
gidNumber: 4001
cn: solarisgroup
1 matches

Modifying Groups Using the Console

To modify groups using the console, access the console and then perform the following steps.

1. Search for the group, as shown in Figure 16.

Figure 16: Searching for a Group
(Click to Enlarge)

2. Edit the attributes and click OK.

Figure 17: Editing Attributes
(Click to Enlarge)

Modifying Groups Using the Command Line

1. Create an LDIF file:


# more group.ldif
dn: cn=solarisgroup,ou=group,dc=COMPANY,dc=com
changetype: modify
memberuid: sunuser300, sunuser999

2. Execute ldapmodify:

# ldapmodify -h server2.COMPANY.com -D "cn=Directory Manager" -f
  group.ldif
Enter bind password:
modifying entry cn=solarisgroup,ou=group,dc=COMPANY,dc=com

3. Run ldapsearch to verify the status:

# ldapsearch -v -b "ou=group,dc=COMPANY,dc=com" -D "cn=Directory
    Manager" -w password "cn=solarisgroup"
ldapsearch: started Tue May  8 22:53:12 2007

	ldap_init( localhost, 389 )
	filter pattern: cn=solarisgroup
	returning: ALL
	filter is: (cn=solarisgroup)
	version: 1
	dn: cn=solarisgroup,ou=group,dc=COMPANY,dc=com
	objectClass: posixGroup
	objectClass: top
	memberUid: sunuser300
	memberUid: sunuser300, sunuser999
	gidNumber: 4001
	cn: solarisgroup
	1 matches

Deleting Groups Using the Console

To delete groups using the console, access the console and then perform the following steps.

1. Search for the group, as described in Modifying Groups Using the Console.

2. Select and delete the group, as shown in Figure 18.

Figure 18: Searching for a Group
(Click to Enlarge)

Deleting Groups Using the Command Line

1. Create an LDIF file:

# more group.ldif
dn: cn=solarisgroup,ou=group,dc=COMPANY,dc=com
changetype: delete

2. Execute ldapmodify:

# ldapmodify -h server2.COMPANY.com -D "cn=Directory Manager" -f
  group.ldif
Enter bind password:
deleting entry cn=solarisgroup,ou=group,dc=COMPANY,dc=com

3. Run the ldapsearch to verify the status:

# ldapsearch -v -b "ou=group,dc=COMPANY,dc=com" -D "cn=Directory
  Manager" -w 	password  "cn=solarisgroup"
ldapsearch: started Tue May  8 23:00:16 2007

	ldap_init( localhost, 389 )
	filter pattern: cn=solarisgroup
	returning: ALL
	filter is: (cn=solarisgroup)
	0 matches

Tuning Settings

The following two procedures describe tuning steps you should perform for optimal performance of Directory Server. Perform these procedures on all four directory servers.

Refer to the article Solaris OS Networking -- The Magic Revealed for tuning Solaris 10 networking settings.

Tuning the Operating System

1. In /etc/system, set the following:

set rlim_fd_max=65536
set rlim_fd_cur=32768

2. For TCP stack tuning, in the /etc/init.d/inetinit file, set the following:

ndd -set /dev/tcp tcp_time_wait_interval        30000
ndd -set /dev/tcp tcp_conn_req_max_q            4096
ndd -set /dev/tcp tcp_keepalive_interval        600000
ndd -set /dev/tcp tcp_rexmit_interval_initial   500
ndd -set /dev/tcp tcp_smallest_anon_port        8192
ndd -set /dev/tcp tcp_deferred_ack_interval     5

Tuning Directory Server

You must stop each Directory Server instance before modifying dse.ldif.

In <instance_path>/config/dse.ldif, modify and verify the following settings:

nsslapd-maxdescriptors:65536
nsslapd-dbcachesize: 2147483648
nsslapd-db-home-directory: <tmpfs filesystem such as /tmp/slapd>

Note: If you are using the nsslapd-db-home-directory setting above, ensure that the directory is created during system startup time and that there is enough swap space (tmpfs/0 to hold the 2GB of cache and the remaining temp files).

Uninstalling Directory Server

If you need to uninstall Directory Server, follow the uninstallation procedures in the Sun Java System Directory Server Enterprise Edition 6.0 Installation Guide.