Print-friendly Version

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:

• Part 1 -- Installation and Configuration
• Part 2 -- Client Configurations for the Solaris OS
• Part 3 -- Client Configurations for Red Hat Linux and AIX
• Part 4 -- Post-Configuration Tasks

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
  • Adding Netgroups Using the Console
  • Adding Netgroups Using the Command Line
  • Modifying Netgroups Using the Console
  • Modifying Netgroups Using the Command Line
  • Deleting Netgroups Using the Console
  • Deleting Netgroups Using the Command Line
  • Adding Groups Using the Console
  • Adding Groups Using the Command Line
  • Modifying Groups Using the Console
  • Modifying Groups Using the Command Line
  • Deleting Groups Using the Console
  • Deleting Groups Using the Command Line
• 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.

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:

1. Install and configure Directory Server to support LDAP naming services for the clients.
2. 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.
3. Load user data into the Directory Server software.

Directory Server Documentation

Here are links to related Directory Server documentation:

• Sun Java System Directory Server Enterprise Edition 6.0 documentation collection
• Sun Java System Directory Server Enterprise Edition 6.0 Installation Guide
• Useful blog entry about installing Sun Java System Directory Server Enterprise Edition 6.0

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:

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:

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

# 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.

For More Information

Here are additional resources:

• Downloads:
  • Sun Java System Directory Server Enterprise Edition
  • Solaris 10 OS
• Sun training courses at http://www.sun.com/training/:
  • Sun Java System Directory Server Enterprise Edition 6.x: Analysis and Planning (DIR-2217)
  • Sun Java System Directory Server Enterprise Edition 6.x: Maintenance and Operations (DIR-2337D)
  • Sun Java System Directory Server Enterprise Edition: LDAP Concepts (WMT-DIR-1344)
  • Using LDAP as a Naming Service (IN-351)
  • LDAP Design and Deployment (WI-3501)
• Open source resources:
  • OpenSolaris software
  • OpenDS, an open directory service
  • Other open source resources
• Developer forums:
  • Sun Java System Directory Server forum
  • Sun Java Enterprise System forums
  • Solaris OS forums
• Documents at http://docs.sun.com:
  • System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)
  • Solaris 10 System Administrator Collection
• Wikis:
  • Sun Java System wiki
  • BigAdmin wiki
• Related sites and articles:
  • BigAdmin Sun Java Enterprise System hub
  • BigAdmin Solaris information center
  • Sun Java System Directory Server Enterprise Edition FAQ
• Events:
  • Worldwide Developer Events: Sun Tech Days
  • Other current events

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.