Thursday Jul 24, 2008

Installing OpenDS on my MacBook Pro in a cinch

Installing OpenDS on my MacBook Pro in a cinch


After downloading the OpenDS zip file, I unzipped the file and exeucte setup in command line mode (not the graphical interface).  This utility can be used to setup the Directory Server. Here are the global setup options:


Usage:  setup  {options}

        where {options} include:


-i, --cli

    Use the command line install. If not specified the graphical interface will     be launched.  The rest of the options (excluding help and version) will  only be taken into account if this option is specified

-b, --baseDN {baseDN}

    Base DN for user information in the Directory Server.  Multiple base DNs  may be provided by using this option multiple times

-a, --addBaseEntry

    Indicates whether to create the base entry in the Directory Server database

-l, --ldifFile {ldifFile}

    Path to an LDIF file containing data that should be added to the Directory   Server database. Multiple LDIF files may be provided by using this option   multiple times

-R, --rejectFile {rejectFile}

    Write rejected entries to the specified file

--skipFile {skipFile}

    Write skipped entries to the specified file

-d, --sampleData {numEntries}

    Specifies that the database should be populated with the specified number  of sample entries

-p, --ldapPort {port}

    Port on which the Directory Server should listen for LDAP communication

-x, --jmxPort {jmxPort}

    Port on which the Directory Server should listen for JMX communication

-S, --skipPortCheck

    Skip the check to determine whether the specified ports are usable

-D, --rootUserDN {rootUserDN}

    DN for the initial root user for the Directory Server

-w, --rootUserPassword {rootUserPassword}

    Password for the initial root user for the Directory Server

-j, --rootUserPasswordFile {rootUserPasswordFile}

    Path to a file containing the password for the initial root user for the   Directory Server

-O, --doNotStart

    Do not start the server when the configuration is completed

-q, --enableStartTLS

    Enable StartTLS to allow secure communication with the server using the

    LDAP port

-Z, --ldapsPort {port}

    Port on which the Directory Server should listen for LDAPS communication.   The LDAPS port will be configured and SSL will be enabled only if this  argument is explicitly specified


    Generate a self-signed certificate that the server should use when accepting SSL-based connections or performing StartTLS negotiation


    Use a certificate in a PKCS#11 token that the server should use when accepting SSL-based connections or performing StartTLS negotiation

--useJavaKeystore {keyStorePath}

    Path of a Java Key Store (JKS) containing a certificate to be used as the  server certificate

--usePkcs12keyStore {keyStorePath}

    Path of a PKCS#12 key store containing the certificate that the server  should use when accepting SSL-based connections or performing StartTLS   negotiation

-W, --keyStorePassword {keyStorePassword}

    Certificate key store PIN.  A PIN is required when you specify to use an  existing certificate (JKS, PKCS#12 or PKCS#11) as server certificate

-u, --keyStorePasswordFile {keyStorePasswordFile}

    Certificate key store PIN file.  A PIN is required when you specify to use  an existing certificate (JKS, PKCS#12 or PKCS#11) as server certificate

-N, --certNickname {nickname}

    Nickname of the certificate that the server should use when accepting   SSL-based connections or performing StartTLS negotiation


Utility Input/Output Options


-n, --no-prompt

    Perform an installation in non-interactive mode.  If some data in the  command is missing the user will not be prompted and the tool will fail

-Q, --quiet

    Run setup in quiet mode.  Quiet mode will not output progress information  to standard output

-v, --verbose

    Use verbose mode

--propertiesFilePath {propertiesFilePath}

    Path to the file containing default property values used for command line  arguments


    No properties file will be used to get default command line argument values


General Options


-V, --version

    Display Directory Server version information

-?, -H, --help

    Display this usage information


Since my install is a development environment I selected the following options:


-i – command line mode

-b – base DN of "dc=example,dc=com"

-a  - create the baseDN

-d  500 – five hundred sample users

-p 1389 – insecure port 1389

-D  "cn=directory manager" – directory administrator user

-w password – directory administrator password

-q -Z 1390  - secure port 1390

-v – verbose output


Herewith the installation session:


pcp002880pcs:~/opends/OpenDS-1.0.0 /$ ./setup -i -b "dc=example,dc=com" -a  -d  500 -p 1389 -D "cn=directory manager" -w password -q -Z 1390 -v


OpenDS Directory Server 1.0.0

Please wait while the setup program initializes...

Certificate server options:


    1)  Generate self-signed certificate (recommended for testing purposes


    2)  Use an existing certificate located on a Java Key Store (JKS)

    3)  Use an existing certificate located on a PKCS#12 key store

    4)  Use an existing certificate on a PKCS#11 token


Enter choice [1]:


Do you want to start the server when the configuration is completed? (yes /

no) [yes]:



Setup Summary


LDAP Listener Port: 1389

LDAP Secure Access: Enable StartTLS

                    Enable SSL on LDAP Port 1390

                    Create a new Self-Signed Certificate

Root User DN:       cn=directory manager

Directory Data:     Create New Base DN dc=example,dc=com.

Base DN Data: Import Automatically-Generated Data (500 Entries)



Start Server when the configuration is completed



What would you like to do?


    1)  Setup the server with the parameters above

    2)  Provide the setup parameters again

    3)  Cancel the setup


Enter choice [1]:


Configuring Directory Server ..... Done.

Configuring Certificates ..... Done.




Importing Automatically-Generated Data (500 Entries):

[24/Jul/2008:10:01:28 -0700] category=JEB severity=NOTICE msgID=8847544 msg=Available buffer memory 4479254 bytes is below the minimum value of 10485760 bytes. Setting available buffer memory to the minimum

[24/Jul/2008:10:01:28 -0700] category=JEB severity=NOTICE msgID=8847545 msg=Setting DB cache to 26875526 bytes and internal buffer to 10485760 bytes

[24/Jul/2008:10:01:29 -0700] category=JEB severity=NOTICE msgID=8847533 msg=OpenDS Directory Server 1.0.0 starting import (build 20080610152800Z, R4337)

[24/Jul/2008:10:01:29 -0700] category=JEB severity=NOTICE msgID=8847449 msg=Import Thread Count: 8 threads

[24/Jul/2008:10:01:29 -0700] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381713 msg=JVM Information: 1.5.0_13-b05-241 by Apple Computer, Inc., 32-bit architecture, 66650112 bytes heap size

[24/Jul/2008:10:01:29 -0700] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381714 msg=JVM Host:, running Mac OS X 10.4.11 i386, 4294967296 bytes physical memory size, number of processors available 2

[24/Jul/2008:10:01:29 -0700] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381715 msg=JVM Arguments: "-Dorg.opends.server.scriptName=setup"

[24/Jul/2008:10:01:29 -0700] category=JEB severity=NOTICE msgID=8847518 msg=Processing LDIF

[24/Jul/2008:10:01:30 -0700] category=JEB severity=NOTICE msgID=8847519 msg=End of LDIF reached

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847537 msg=Begin substring buffer flush of 15913 elements. Buffer total access: 30458  buffer hits: 14545

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847538 msg=Substring buffer flush completed in 1 seconds

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847539 msg=Begin final cleaner run

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847541 msg=Cleaner run took 0 seconds 0 logs removed

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847454 msg=Processed 502 entries, imported 502, skipped 0, rejected 0 and migrated 0 in 1 seconds (average rate 255.1/sec)

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847455 msg=Number of index values that exceeded the entry limit: 0

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847536 msg=Import LDIF environment close took 0 seconds




Starting Directory Server:

[24/Jul/2008:10:01:33 -0700] category=CORE severity=INFORMATION msgID=132 msg=The Directory Server is beginning the configuration bootstrapping process

[24/Jul/2008:10:01:35 -0700] category=CORE severity=NOTICE msgID=458886 msg=OpenDS Directory Server 1.0.0 (build 20080610152800Z, R4337) starting up

[24/Jul/2008:10:01:35 -0700] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381713 msg=JVM Information: 1.5.0_13-b05-241 by Apple Computer, Inc., 32-bit architecture, 132775936 bytes heap size

[24/Jul/2008:10:01:35 -0700] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381714 msg=JVM Host:, running Mac OS X 10.4.11 i386, 4294967296 bytes physical memory size, number of processors available 2

[24/Jul/2008:10:01:35 -0700] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381715 msg=JVM Arguments: "-Xserver", "-Dorg.opends.server.scriptName=start-ds"

[24/Jul/2008:10:01:39 -0700] category=ACCESS_CONTROL severity=INFORMATION msgID=12582978 msg=Added 8 Global Access Control Instruction (ACI) attribute types to the access control evaluation engine

[24/Jul/2008:10:01:41 -0700] category=JEB severity=NOTICE msgID=8847402 msg=The database backend userRoot containing 502 entries has started

[24/Jul/2008:10:01:41 -0700] category=PROTOCOL severity=MILD_WARNING msgID=2163134 msg=The directory /Users/jgershater/Documents/Work/ISO images/opends/OpenDS-1.0.0/config/auto-process-ldif referenced by the LDIF connection handler defined in configuration entry cn=LDIF Connection Handler,cn=Connection Handlers,cn=config does not exist.  The LDIF connection handler will start, but will not be able to process any changes until this directory is created

[24/Jul/2008:10:01:42 -0700] category=PROTOCOL severity=MILD_ERROR msgID=2294036 msg=Started listening for new connections on LDAP Connection Handler port 1390

[24/Jul/2008:10:01:42 -0700] category=PROTOCOL severity=MILD_ERROR msgID=2294036 msg=Started listening for new connections on LDAP Connection Handler port 1389

[24/Jul/2008:10:01:42 -0700] category=CORE severity=NOTICE msgID=458887 msg=The Directory Server has started successfully

[24/Jul/2008:10:01:42 -0700] category=CORE severity=NOTICE msgID=458891 msg=The Directory Server has sent an alert notification generated by class org.opends.server.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted, alert ID 458887):  The Directory Server has started successfully


See /tmp/opends-setup-11588.log for a detailed log of this operation.


To see basic server configuration status and configuration you can launch /opends/OpenDS-1.0.0/bin/status


I now view the status of the server, per the final line of the installation session:


pcp002880pcs:~/opends/OpenDS-1.0.0/$ cd bin



>>>> Specify OpenDS LDAP connection parameters

How do you want to connect?


    1)  LDAP

    2)  LDAP with SSL

    3)  LDAP with StartTLS


Enter choice [1]:


Administrator user bind DN [cn=Directory Manager]:


Password for user 'cn=Directory Manager':


          --- Server Status ---

Server Run Status:    Started

Open Connections:     1


          --- Server Details ---

Host Name:  

Administrative Users: cn=directory manager

Installation Path:    /opends/OpenDS-1.0.0

OpenDS Version:       OpenDS Directory Server 1.0.0

Java Version:         1.5.0_13-121


          --- Connection Handlers ---

Address:Port : Protocol : State

-------------:----------:--------- : LDAP     : Enabled : LDAPS    : Enabled  : SNMP     : Disabled : JMX      : Disabled


          --- Data Sources ---

Base DN:     dc=example,dc=com

Backend ID:  userRoot

Entries:     502

Replication: Disabled


And here is a graphical screenshot of the DIT (Directory Information Tree), using jxplorer


Total installation time, about two minutes!


Kudos to Ludo's team and the OpenDS community.






Monday Jul 21, 2008

A useful script for troubleshooting UNIX processes and TCP ports

A useful script for troubleshooting UNIX processes and TCP ports

I found a really useful script that will show what UNIX processes are using particular TCP ports, and vice-versa. I found this useful for troubleshooting Identity Synchronization for Windows connectors. The Directory Server connector runs as a java process listening on a particular TCP port. The ISW plugin in the Sun Directory Server connects to the connector over that port number.

The script can be downloaded here

In this example, the Directory Server connector is listening on port 7890 and the corresponding Sun Directory Server is connected to the connector on port 7890

# sh pcp -p 7890

PID Process Name and Port


7493 /usr/java/bin/java 7890 DS Connector

sockname: AF_INET port: 7890

sockname: AF_INET port: 7890

sockname: AF_INET port: 7890


7766 /opt/SUNWdsee/ds6/lib/64/ns-slapd 7890 Directory Server

peername: AF_INET port: 7890


Thursday Jun 26, 2008

Sun Directory Server 6.x and SSL - once and for all! :)

Sun Directory Server 6 and SSL

I have seen several postings requesting help for communicating with Sun Directory Server over SSL.

This posting serves to clarify confusion and provide tools and tips for testing SSL communication between Sun Directory Server and clients. This blog posting assumes basic SSL knowledge.Links to background information is provided in the references below.

For purposes of this blog posting assume:

Sun Directory Server commands: /opt/SUNWdsee/ds6/bin

Sun Directory Server instance: /var/opt/SUNWdsee/dsins1

Consequently, the Sun Directory Server certificate directory is : /var/opt/SUNWdsee/dsins1/alias

The following files are in the certificate directory:

cert8.db key3.db slapd-cert8.db

certmap.conf secmod.db slapd-key3.db

This blog posting uses

  • The Sun Directory commands located in /opt/SUNWdsee/ds6/bin

  • Certutil located in /usr/sfw/bin on Solaris 10. If certutil is not on your server, download the Sun Directory Resource kit

# unzip

# java DSRK

You can install the resource kit into any directory you choose. The following notes assume that the installation location is: the /opt/dsrk directory. Add /opt/dsrk/lib to your LD_LIBRARY_PATH environment variable.

Server configuration

List certificates in the database

Using dsadm:

# ./dsadm list-certs -i /var/opt/SUNWdsee/dsins1

Alias Valid from Expires on Self-signed? Issued by Issued to

----------- ---------------- ---------------- ------------ ------------------------------------------------------------------- -------------------------------------------------------------------------------------

defaultCert 2008/01/22 19:15 2008/04/22 19:15 y CN=myserver,CN=636,CN=Directory Server,O=Sun Microsystems Same as issuer

Using certutil

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

defaultCert CTu,u,u

The certificate listed above, defaultCert, is the self-signed certificate, valid for 90 days, that is installed with the Directory Server.

View certificates

View the certificates in the certificate database as follows

Using dsadm

In humanly readable format

# cd /opt/SUNWdsee/ds6/bin

# ./dsadm show-cert -F readable /var/opt/SUNWdsee/dsins1 defaultCert

click here to view the certificate

In ASCII format

# ./dsadm show-cert -i -F ascii /var/opt/SUNWdsee/dsins1 defaultCert















(note that der format, ./dsadm show-cert -i -F der /var/opt/SUNWdsee/dsins1 defaultCert, the output is not humanly readable and thus not demonstrated here.)

Using Certutil

The CertUtil utility will also display the certificates

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

Request and install certs from your Certificate Authority

This procedure describes how you request and install digial certificates from a Certificate Authority.

Certificate request

To install certificates from a certificate authority, proceed as follows:

Generate the certificate request. The format of the request, der or ascii, may depend on your certificate authority. The example below is in der format which is not humanly readable. The request is PKCS 10 format.

/opt/SUNWdsee/ds6/bin/dsadm request-cert --city "My City" --country "US" -F der --name myserver --org "my org" -o /tmp/CertReq --state CA /var/opt/SUNWdsee/dsins1

The above request is in “DER” format (-F der) which is not humanly readable. If the request above was in ascii format (-F ascii) then the output file would read as follows:

# more /tmp/CertReq

Certificate request generated by Sun-Java(tm)-System-Directory/6.2

Common Name: myserver

Email: (not specified)

Phone: (not specified)

Organization:my organization

State: CA

Country: US





Send the above to your certificate authority (CA)

The CA will then send a digital certificate for you to install in your Directory Server. This certificate allows clients to communicate with your server over SSL.

You should also request the signing certificate from your CA. This allows clients to trust the server certificate requested above. You may need multiple signing certificates, the rootCA certificate and any intermediary signing certificates, depending on the configuration of your CA.

Install CA certificates

To install the server and CA signing certificates proceed as follows

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

Upload these to the Directory Server as /tmp/CACert

Installing the server certificate:

Using certutil

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

Using dsadm:

#/opt/SUNWdsee/ds6/bin/dsadm add-cert /var/opt/sun/dsins1 server-cert /tmp/CertFile

Setting the default certificate

Set the above server certificate as the default server certificate. This is required so that when the client communicates with the server, the server will present the CA certificate to the client. The client can then authenticate the certificate presented:

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


Installing the CA signing certificates:

 Using dsadm

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


Using certutil

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

View the certificates :

Using certutil

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

defaultCert                                                  Ctu,u,u – default self signed certificate installed with Directory Server

ServerCert                                                     u,u,u – server certificate provided by your Certificate Authority

Root CA                                                 CT,, - RootCA signiing certificate

Using dsadm

# /opt/SUNWdsee/ds6/bin/dsadm list-certs /var/opt/SUNWdsee/dsins1

Restart Directory Server

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


Now, you need to install the server and rootCA certificates on each client that wishes to communicate with the server over SSL

Create the certificate database.

Execute these commands as root to create the database in the directory: /var/ldap.

/opt/dsrk/lib/nss/bin/certutil -N -d /var/ldap

Set permissions to be readable by all.

chmod 644 /var/ldap/\*.db

Note that Solaris 8 & 9 use certificate databases in cert7.db format. The certutil utility that ships with the Solaris 9 OS in /usr/sfw/bin creates a cert8.db database. To create a cert7.db database, you must use the certutil utility in the Sun Directory Resource Kit. See introduction to this blog posting.

Retrieve the certificates from your Directory server as follows:

Export the server certificate and CA signing certificate.

./dsadm export-cert -o /tmp/ServerCert /var/opt/SUNWdsee/dsins1 myserver

Choose the PKCS#12 file password:

Confirm the PKCS#12 file password:

Copy the certificates to each client

Copy the from the file /tmp/ServerCert from the Directory server to the client.

Also copy the RootCA certificate you received from your CA above to the client

Import the certificates into the databases created above

Import both the Directory Server SSL certificate and the CA signing certificate into the certificate database created above. The example’s certificates are in ASCII PEM format.

certutil -A -a –i /tmp/RootCert -n “RootCA” -t “CT” -d /var/ldap

certutil -A -n "ServerCertificate" -i /var/tmp/ServerCert-a -t “CT” -d /var/ldap

List the newly imported certificates

To List the certificates you have stored in the key database:

# /usr/sfw/bin/certutil -L -d /var/ldap

RootCA CT,,

ServerCertificate CT,,

Test SSL connectivity

Using openSSL

Use the openSSL utility to test connectivity, where is the name of your Directory Server. This command verifies connnectivity and displays all certificates, as I have highlighed in red font.

# /usr/sfw/bin/openssl s_client -host -port 636 -showcerts -verify 3

verify depth is 3


depth=2 /C=US/ organization/CN=Root CA

verify error:num=19:self signed certificate in certificate chain

verify return:1

depth=2 /C=US/ organization/CN=Root CA

verify return:1

depth=1 /C=US/ organization/CN=servercert

verify return:1

depth=0 /L=my City/ST=CA/C=US/ organization/

verify return:1


Certificate chain

0 s:/L=my City/ST=CA/C=US/ organization/

i:/C=US/ organization/CN=servercert
























1 s:/C=US/ organization/CN=servercert

i:/C=US/ organization/CN=Root CA

























2 s:/C=US/ organization/CN=Root CA

i:/C=US/ organization/CN=Root CA


























Server certificate

subject=/L=my City/ST=CA/C=US/ organization/

issuer=/C=US/ organization/CN=servercert


Acceptable client certificate CA names

/C=US/ organization/CN=servercert – CA signed server certificate received with our request

/C=US/ organization/CN=Root CA – root CA signing certificate

/O=Sun Microsystems/CN=Directory Server/CN=636/CN=myserver – default self signed certificate


SSL handshake has read 3554 bytes and written 334 bytes


New, TLSv1/SSLv3, Cipher is AES256-SHA

Server public key is 1024 bit

Compression: NONE

Expansion: NONE


Protocol : TLSv1

Cipher : AES256-SHA

Session-ID: 5DBEF47FCD5B642D41F4974690EA4A8FA1B7964242C39898E86AA3492496C6BB


Master-Key: 75B8E8BA280D6794F7177416679C3170B7F1A45F21EF1461D230221872E157EF5F1822C28E5FFF327244E8B818FAAB7C

Key-Arg : None

Start Time: 1214502072

Timeout : 300 (sec)

Verify return code: 19 (self signed certificate in certificate chain)


Using secure LDAP search

  • Solaris 8 default ldapsearch does not have SSL capability, unless you have the the ldapclient patch 108993

  • Solaris 9 default ldapsearch does not have SSL capability, but the iplanet ldapseach does in /usr/iplanet/ds5/shared/bin/ldapsearch

  • Solaris 10 default ldapsearch does have SSL support .

/usr/bin/ldapsearch -v -h -p 636 -Z -P /var/ldap/cert8.db -b "dc=example,dc=com"  -D "cn=directory manager" -w <password> "objectclass=\*"



PKI reference guide



Can contain all of private keys (RSA and DSA), public keys (RSA and DSA) and (x509) certificates. It stores data Base64 encoded DER format, surrounded by ascii headers, so is suitable for text mode transfers between systems.


Can contain all of private keys, public keys and certificates. It stored according to the ASN1 DER format. It is headerless - PEM is text header wrapped DER. It is the default format for most browsers.


Also known as PFX files. Can contain all of private keys, public keys and certificates. It stores in a binary format.

Monday Jun 16, 2008

Anonymous access and Solaris native-ldap clients

Anonymous Access and Solaris native-ldap clients

Since anonymous access to an entire Directory tree can be a security risk, this blog posting clarifies exactly what anonymous access is required by Solaris native-ldap clients.

When Solaris native-ldap clients are initialized they require anonymous access to the Sun Java Directory Server's baseDN and ou=profile container. The following acis configure the appropriate access.

the baseDN - (target = ldap:///dc=example,dc=com) (targetscope = base) (targetattr="\*") (version 3.0; acl "anonymousBaseDN"; allow (read, compare, search) (userdn = "ldap:///anyone") ;) .

For super secure access, this aci could be modified thus to only allow access to the nisDomain attribute

(target = ldap:///dc=example,dc=com) (targetscope = base) (targetattr="nisdomain") (version 3.0; acl "anonymousBaseDN"; allow (read, compare, search) (userdn = "ldap:///anyone") ;) .

the profile container - (target = "ldap:///ou=profile,dc=example,dc=com") (targetscope = subtree) (targetattr="\*") (version 3.0; acl "anonymousProfile"; allow (read,compare,search) (userdn = "ldap:///anyone") ;)

For super secure access, this aci could be modified thus to only allow access to the proxyagent user object

(target = "ldap:///cn=proxyagent,ou=profile,dc=example,dc=com") (targetscope = subtree) (targetattr="\*") (version 3.0; acl "anonymousProfile"; allow (all) (userdn = "ldap:///anyone") ;)

When a native-ldap client is initialized, the access required is visible, per this session below:

  • In red font, the client is searching for, and found, the baseDN.

  • In blue font, the client is searching for the profile, and the prompt for the password indicates the profile was found, and read, successfully.

# ./


Parsing profileName=exampleprofile

Parsing proxyDN=cn=proxyagent,ou=profile,dc=example,dc=com

Arguments parsed:


proxyDN: cn=proxyagent,ou=profile,dc=example,dc=com

profileName: exampleprofile


Handling init option

About to configure machine by downloading a profile

findBaseDN: begins

findBaseDN: ldap not running

findBaseDN: calling __ns_ldap_default_config()

found 2 namingcontexts

findBaseDN: __ns_ldap_list(NULL, "(&(objectclass=nisDomainObject)("

rootDN[0] cn=changelog

NOTFOUND:Could not find the nisDomainObject for DN cn=changelog

findBaseDN: __ns_ldap_list(NULL, "(&(objectclass=nisDomainObject)("

rootDN[1] dc=example,dc=com

found baseDN dc=example,dc=com for domain

Proxy DN: cn=proxyagent,ou=profile,dc=example,dc=com

Proxy password: NULL

Credential level: 1

Authentication method: 3

credentialLevel requires proxyPassword

Proxy Bind Password:

About to modify this machines configuration by writing the files

Stopping network services

Stopping sendmail

Stopping nscd

Stopping autofs

ldap not running

nisd not running

nis_cache not running

nispasswd not running

nis(yp) not running

file_backup: stat(/etc/nsswitch.conf)=0

file_backup: (/etc/nsswitch.conf -> /var/ldap/restore/nsswitch.conf)

file_backup: stat(/etc/defaultdomain)=0

file_backup: (/etc/defaultdomain -> /var/ldap/restore/defaultdomain)

file_backup: stat(/var/nis/NIS_COLD_START)=-1

file_backup: No /var/nis/NIS_COLD_START file.

file_backup: nis domain is ""

file_backup: stat(/var/yp/binding/

file_backup: No /var/yp/binding/ directory.

file_backup: stat(/var/ldap/ldap_client_file)=-1

file_backup: No /var/ldap/ldap_client_file file.

Starting network services

start: /usr/bin/domainname success

start: /usr/lib/ldap/ldap_cachemgr... success

start: /etc/init.d/autofs start... success

start: /etc/init.d/nscd start... success

start: /etc/init.d/sendmail start... success

System successfully configured


Sun Directory Server and native-ldap clients

Setup LDAP client

ACIs - Access Control Instructions - Management

ACIs - Access Control Instruction - Reference

Tuesday May 13, 2008

Two Directory servers listening on ports 389/636, on one server

The following procedure outlines how to configure a two (or more instances) of Sun Java Directory Server, both listening on non-secure port 389 and secure port 636.

This is useful in application testing where all applications require port 389/636 but you need two distinct Directories to ensure that data and configurations do not collide.

This procedure requires that you add a second virtual network interface.

View the current network settings

# ifconfig -a

lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1

inet netmask ff000000

dmfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2

inet netmask ffffff00 broadcast

ether 0:3:ba:7a:bb:ed

Create the second virtual interface

# ifconfig dmfe0:1 plumb

Assign an ip address to it

# ifconfig dmfe0:1 up

Add the secondhostname to /etc/hosts(or DNS)

# Internet host table

# localhost firsthostname loghost secondhostname

Confirm the network interface is working

# ping is alive

# ping secondhostname

secondhostname is alive

Create an instance of DSEE.

  • Ensure that you specify the second host name with the -h parameter

  • Temporarily provide a secure and non-secure port that is not in use (otherwise the create command will fail since ports 389 and 636 are already in use)

#/opt/SUNWdsee/ds6/bin/dsadm create -h secondhostname -p 1389 -P 1636 /var/opt/SUNWdsee/dsins2

Edit the dse.ldif of the new instance

  • Add the two lines in blue below

  • Change the the port numbers to 389 and 636 respectively.

#vi /var/opt/SUNWdsee/dsins2/config/dse.ldif

dn: cn=config

cn: config




nsslapd-enquote-sup-oc: off

nsslapd-listenhost: secondhostname

nsslapd-securelistenhost: secondhostname

nsslapd-localhost: secondhostname

nsslapd-schemacheck: on

nsslapd-syntaxcheck: off

nsslapd-requires-bind-password: on

nsslapd-rewrite-rfc1274: off

nsslapd-return-exact-case: on

nsslapd-port: 389

nsslapd-localuser: root




nsslapd-security: on

nsslapd-secureport: 636

Start the second instance

#/opt/SUNWdsee/ds6/bin/dsadm start /var/opt/SUNWdsee/dsins2

# Waiting for server to start...

Server started: pid=9570


Directory Documentation Man Page

Friday May 02, 2008

Sun Java Identity Synchronization for Windows - bug fix!

If you are implementing Sun Java Identity Synchronization for Windows 6.0 and your user objects have auxiliary objects then you will likely hit bug 6691600. “Users with auxiliary objectclasses fail to link”

A fix is available, get it from Sun support

To implement the fix follow these steps

  1. stop the IMQ and ISW instances. (/etc/init.d/isw stop) & (/etc/init.d/imq stop)

  2. backup /opt/SUNWisw/lib/connector.jar

  3. Replace the connector.jar at the installation directory (/opt/SUNWisw/lib/connector.jar) with the one from support

  4. Repeat this procedure on all the hosts which has the Connectors installed.

  5. Start IMQ and ISW (/etc/init.d/imq start) & (/etc/init.d/isw start)

Java forums reference:

Monday Apr 07, 2008

PwdLastAuthTime and cn=proxyagent

You might be wondering what the cryptic title to this blog entry is, allow me to explain:.

  • Sun Directory Server 6 introduced a new attribute in password policies, PwdLastAuthTime, that stores the last time a user authenticated to the Directory.

  • ProxyAgent is the default user in the profile used by native-ldap clients configured for proxy authentication.

Thus suppose:

  1. You have two or more Sun Directory servers in a multi-master replication configuration.

  2. That the Directory servers are deployed as a naming service used by native-ldap clients ( for authentication etc.) configured for proxy-authentication

  3. That you have configured a user-defined password policy to store PwdLastAuthTime.

The proxyAgent user object will authenticate to the Directory quite frequently to update the client profile etc. This proxy authentication is recorded by the Directory and in a replicated environment, you may notice your replication changelog file grows very quickly consuming disk-space. The documentation explicitly states “ Using this feature can affect performance. When you configure Directory Server to save pwdLastAuthTime timestamps, the server must perform an internal modify operation for each successful bind.

The solution to the problem of rapidly growing replication changelog files, is to apply a special password policy to the proxyagent user, not to record PwdLastAuthTime. See sample below:

LDIF file to create a custom password policy that logs PwdLastAuthTime and is assigned to all users by default

dn: cn=DirectorypwdPolicy,ou=ExamplePasswordPolicy,dc=visa,dc=com

changetype: add

objectclass: pwdPolicy

objectclass: sunPwdPolicy

objectclass: ldapsubentry

objectclass: top

cn: Example Password Policy

description: Example Password Policy

pwdAttribute: userPassword

pwdAllowUserChange: true

pwdGraceAuthNLimit: 0

pwdMustChange: False

pwdCheckQuality: 0

pwdMinAge: 0

pwdMaxAge: 2592000

pwdExpireWarning: 432000

pwdInHistory: 0

pwdSafeModify: true

pwdMaxFailure: 5

pwdFailureCountInterval: 0

pwdLockout: true

pwdLockoutDuration: 0

pwdIsLockoutPrioritized: true

pwdKeepLastAuthTime: true

passwordRootdnMayBypassModsChecks: on

passwordStorageScheme: SSHA

LDIF file to create a custom password policy that does not log PwdLastAuthTime

dn: cn=DirectorypwdPolicyPxyAgent,ou=ExamplePasswordPolicy,dc=Example,dc=com

changetype: add

objectclass: pwdPolicy

objectclass: sunPwdPolicy

objectclass: ldapsubentry

objectclass: top

cn: ExamplePassword Policy PxyAgent

description: Example Password Policy PxyAgent

pwdAttribute: userPassword

pwdAllowUserChange: true

pwdGraceAuthNLimit: 0

pwdMustChange: False

pwdCheckQuality: 0

pwdMinAge: 0

pwdMaxAge: 2592000

pwdExpireWarning: 432000

pwdInHistory: 0

pwdSafeModify: true

pwdMaxFailure: 5

pwdFailureCountInterval: 0

pwdLockout: false

pwdLockoutDuration: 0

pwdIsLockoutPrioritized: true

pwdKeepLastAuthTime: false

passwordRootdnMayBypassModsChecks: on

passwordStorageScheme: SSHA

LDIF file to assign the above password policy to the proxyagent user:

dn: cn=proxyagent,ou=profile,dc=example,dc=com

changetype: modify

add: pwdPolicySubentry

pwdPolicySubentry: cn=DirectorypwdPolicyPxyAgent,ou=ExamplePasswordPolicy,dc=Example,dc=com

For this blog entry, I decided to list the references below, rather than creating hyperlinks in the text above and thus distracting myself from the main text. I hope the reader finds this easier to read as well.


Sun Directory Server 6 password policies

Applying password policies to an individual user


LDAP as a naming service

Proxy authentication – see “Using Proxy Credentials”

Monday Mar 31, 2008

two billion Directory entries - a misleading benchmark

Dave Kearns and Phil Hunt write about a two billion Directory entry benchmark recently published by Oracle. I wish to refute that benchmark as it does not simulate a real-world scenario for the following reasons:
  1. Entries are read sequentially rather than random. Sequential reads almost guarantee that reads come from (faster) memory rather than (slower) file systems. How often in the real world is an LDAP or relational database read sequentially? Coming from a leading database vendor this scenario is very surprising and not reflective of the real world.
  2. The changelog is disabled and password policy is ignored.
  3. Who would implement two billion entries on a single non-replicated server. Everyone knows that replication provides high availability and failover and as a consequence creates an extra load (slower response) from an LDAP (or database) server.
A more realistic benchmark would be most interesting. The benchmark published is more of academic than practical interest....

Tuesday Mar 04, 2008

Migration guideline from Sun Directory Server 5.2 to 6.2

Although Sun Directory Server 6.2 has been out for many months, some users are only starting to get their feet wet with the new commands and Graphical User Interface. This is an outline of tasks in Directory Server 5.2 and their equivalent in Directory 6.2 . First a table of equivalent commands in 5.2 and 6.2, below that screenshots of equivalent tasks in 5.2 and 6.2

Command line


Directory 5.2 command

Directory 6.2 command

Server management

Create server


dsadm create

Delete server


dsadm delete

Start server


dsadm start

Stop server


dsadm stop



dsadm restart




dsadm backup



dsadm restore



dsadm import



dsadm export


Generate request


dsamd request-cert

Import certificate


dsadm add-cert

Key database


Create agreeement


dsconf create-repl-agmt

Delete agreement


dsconf delete-repl-agmt

Enable replication


dsconf enable-repl

Replication status


dsconf show-repl-agmt-status




dsconf create-suffix



dsconf reindex



dsconf delete-suffix



dsconf export



dsconf import


Create index


dsconf create-index

Delete index


dsconf delete-index

Get index property


dsconf get-index-prop

Set index property


dsconf set-index-prop

List indexes


dsconf list-index



dsconf reindex


Manage properties


dsconf set-log-prop

Graphical User Interface

Create server – version 5.2

Create server – version 6.2

Start & stop server – version 5.2

Start & stop server – version 6.2

Backup & restore server – version 5.2

Backup & restore server – version 6.2

Replication – version 5.2

Replication – version 6.2

Suffix management – version 5.2

Suffix management – version 6.2

LDIF import/export – version 5.2

LDIF import/export – version 6.2

Manage certificates – version 5.2

Manage certificates – version 6.2

Configure logs – version 5.2

Configure logs- version 6.2

Sunday Nov 11, 2007

Sun Directory Server 6.2 upgrade process

This blog entry outlines the process of upgrading the Sun Directory Server from version 6.0 to version 6.2


This procedure assumes the following:

  1. The operating system is Solaris SPARC.

  2. The PKG version of Directory Server 6.0 has been installed.

  3. The DCC is deployed in the Sun Java Web Console (not as a .war file in a J2EE container).

  4. The services are managed in SMF.

  5. The patches are downloaded to a directory “RequiredPatches”. Note: installation of the first patch requires a reboot, therefore do NOT download the patches to /tmp or /var/tmp (some systems) otherwise the files will be lost after the reboot.

  6. The installation paths are as follows:











Patches required before upgrade

Inventory the patches on each server and establish what versions exist.

To inventory the patches, execute ‘showrev –p | grep “Patch: <patchnumber>”’


# showrev -p | grep "Patch: 119963"

Patch: 119963-05 Obsoletes: Requires: Incompatibles: Packages: SUNWlibC

Patch: 119963-08 Obsoletes: Requires: Incompatibles: Packages: SUNWlibC


The list of patches is in column one and is hyperlinked to enable download of the patch from

Patch to install










Patches required to perform 6.2 upgrade


Verify current version installed

Execute LDAPSEARCH to display the current version, substituting <PASSWORD> for the Directory Manager password.

# ldapsearch -h localhost -b cn=config -D "cn=directory manager" -w <PASSWORD> objectclass=nsslapdConfig nsslapd-versionstring

version: 1

dn: cn=config

nsslapd-versionstring: Sun-Java(tm)-System-Directory/6.0

Begin the upgrade process

Stop the processes

Disable DCC Directory server

# svcadm disable svc:/application/sun/ds:ds--var-opt-SUNWdsee-dscc6-dcc-ads

Disable LDAP instance

# svcadm disable svc:/application/sun/ds:ds--var-opt-SUNWdsee-dsins1

Disable CACAO

#svcadm disable svc:/application/management/common-agent-container-1:default

Disable Java Web Console

#svcadm disable svc:/application/management/wbem:default

#svcadm disable svc:/system/webconsole:console

Installation of patches

Before installing patch 118836 a workaround for a small defect is required.

(see note here)


#mkdir /var/tmp/118833-36.SUNWcslr

Click each of the following to view the output of the above patch installations

118833-36.txt see above workaround. Also, reboot after installing this patch.







Upgrade to Directory Server 6.2

Install patch 125276-05.txt

Restart Directory and Console services

Start cacaoagent

#svcadm enable svc:/application/management/common-agent-container-1:default

Start DCC

# svcadm enable svc:/application/sun/ds:ds--var-opt-SUNWdsee-dscc6-dcc-ads

Start LDAP instance

# svcadm enable svc:/application/sun/ds:ds--var-opt-SUNWdsee-dsins1

Start Java Web Console

#svcadm enable svc:/application/management/wbem:default

#svcadm enable svc:/system/webconsole:console

Verify that server was upgraded

Execute LDAPSEARCH to display the current version, substituting <PASSWORD> for the Directory Manager password.

#ldapsearch -h localhost -b cn=config -D "cn=directory manager" -w <PASSWORD> objectclass=nsslapdConfig nsslapd-versionstring

version: 1

dn: cn=config

nsslapd-versionstring: Sun-Java(tm)-System-Directory/6.2

View the Directory Server documentation here

Thursday Jul 26, 2007

F5 Load Balancers and Sun Directory Servers

An IP load balancer, is often used to load balance Directory Servers. (Although far better and feature rich load balancing can be achieved with Sun Java System Directory Proxy Server).
If you choose to use a load balancer such as a BIG-IP F5, then please configure the F5 as follows:
Create an LDAP monitor that will execute a bind against the Directory Server. This is preferable to a standard TCP health check because:
  1. A simple TCP health check does not perform as complete an LDAP operation as a BIND
  2. The LDAP server does not know how to handle the simple TCP health check properly and thus in your Sun Directory Server logs you will likely see 4164 or 4166 errors.

  3. Complete the simple F5 configuration web form with relevant details from your Directory Server.
    1. 'user name': enter an LDAP user that has no rights to important data in the Directory, ideally an ACI that only gives privileges to the use and nothing else. This ensures that if anyone compromises these credentials they cannot access other data. Sample ACI that only allows the F5 user to modify their own password.
      aci: (targetattr = "userPassword") ( version 3.0; acl "allow 
      userpassword self modification"; allow (write) userdn = "ldap:///self";)
    2. 'password': the password for the user
    3. 'Base': base DN
    4. 'Filter;: if your user is in it's own OU no need to filter anything
    5. 'Security': select yes if you wish to test LDAPS (LDAP over SSL)

Monday Mar 05, 2007

A few Sun Java Directory Server 6.0 screenshots

  • Firstly the Sun Java Web Console, which you can use to manage all your applications installed on the server. Click here and you will see, the new Sun Directory Server 6.0 web console is simply a link from the Sun Java Web Console.
  • Secondly, here is a screenshot of the Sun Directory Server 6.0 web management console. Look at all the tools at your disposal in one web form.
  • Finally, actions you can perform on a Directory server. Now isn't that cool, changing the function of a server using a few browser clicks.


Jonathan Gershater


« April 2014