Skip to content

OpenSolaris / OpenDS / OpenSolaris client LDAP – the missing pieces

December 10, 2008


There is a great article on the Sun Developer Network that explains how to set up OpenDS as a naming service for OpenSolaris.

 I found a few glitches when going through the process, and have documented my "fixes" here.  Use these at your own risk!

SSL and Certificate Madness

Setting up certificates is always an excercise in frustration.  I elected to install OpenDS and let it generate it’s own self signed cert. This is somewhat different than the SDN article where they generate the cert and import it into OpenDS.  Note that self signed certs are fine for development, but for production you should always use a real certificate.

 In order for a Solaris LDAP client to authenticate using LDAPS, it is necessary to import the self signed cert from the server into the clients local keystore. For Solaris, the keystore is in the old Netscape format (nss) in the /var/ldap directory.

The first thing we need to do is to export the OpenDS cert. By default OpenDS uses JKS database (Java Keystore).  The OpenDS Wiki has instructions on how to change the default keystore. The following keytool script exports the cert into a PEM format file that we can import on the client:

# Export the opends self signed cert from the keystore to a PEM format that we can import into the LDAP client
# Note when prompted for a password just enter return - you will get a warning but it will work
keytool -keystore /opt/opends/config/keystore -export -alias server-cert -rfc -file /tmp/opends.pem

You should now see a cert in /tmp/opends.pem

 Next we need to import this cert on the OpenSolaris ldap client. In theory "pktool" supports creating and managing nss format databases, but I found it would not work (I always got SSL errors).   Certutil seems to do the trick. By default it is not installed on OpenSolaris 2008.11.

pkg install is your friend:

pkg install SUNWtlsu

The following commands (on the client!) will initialize the nss store and import the certificate that you previously exported from the OpenDS server (copy it to the client first).

cd /var/ldap
certutil -N -d .
certutil -A -n defaultCert -i /tmp/opends.pem  -t CT -d .
# The key files need to be world readable
chmod a+r *.db

You can now test LDAPS from the client to make sure SSL is working. You might want to tail your opends access log to watch for the incoming connection.   The following script will test the connection:

ldapsearch -h $host -p 636 -P $nssdb  -D "cn=Directory Manager" -b "" -s base "" vendorVersion

Updating OpenDS ACIs


I found I needed to add a few ACIs to make the ldap client search work. I used the following script:

[Note: Watch the cut n paste on the script. The ACI formatting/escaping is tricky. All ACIs should be on a single line]

 more setaci
# Sample script to modify OpenDS for Solaris LDAP clients
# Modify as required for your environment
# Note that ACIs are all on one line. If you cut n paste make sure to fix this
# You need to put the Director Manager password in the file /tmp/.dmp  (e..g echo "password" > /tmp/.dmp)
# ldap server hostname
# admin port
# dsconfig command
# proxy dn used by ldap clients
# LDAP Server Sort Result extension
$dsc -h $host -p $port --trustAll \
-D "cn=directory manager" -j /tmp/.dmp -n \
set-access-control-handler-prop \
--add global-aci:"(targetcontrol=\"1.2.840.113556.1.4.473\")(version 3.0; acl \"LDAP Administrator Server Sort\"; allow (all) us
erdn = \"ldap:///$dn\";)"
# VLV extension
$dsc -h $host -p $port --trustAll \
-D "cn=directory manager" -j /tmp/.dmp -n \
set-access-control-handler-prop \
--add global-aci:'(targetcontrol=" || 2.16.840.1.113730.3.4.9" ) (version 3.0; acl "Allow Account Statu
s and VLV controls for Proxy"; allow(read, proxy) userdn="ldap:///'$dn'";)'

Configuring the LDAP client

Now you are ready to configure the LDAP client.  I used the following script (adjust to your environment as required):

ldapclient -v manual \
-a domainName=localdomain \
-a credentialLevel=proxy \
-a defaultSearchBase=dc=sundemo,dc=net \
-a proxyDN=cn=solaris,ou=LDAPauth,dc=sundemo,dc=net \
-a defaultServerList= \
-a authenticationMethod=tls:simple \
-a proxyPassword=SolarisRulz

At this point you also may want to fix up your /etc/nsswitch.conf and use files/dns for host resolution (instead of ldap). If you get wierdness running simple commands (e.g. ping opensolaris) it is probably because host name resolution is trying to use ldap.

 The ldaplist command can be used to test the client setup:

# ldaplist passwd
dn: uid=test01,ou=People,dc=sundemo,dc=net

You now should have a fully functioning ldap client!

A client profile can be generated for import into ldap. This makes installing subsequent clients easier. Instead of using the manual install, you run the ldapclient init variant. This configures the client to pull it’s configuration from the directory. The added bonus is that changes to the configuration will be dynamically pulled by the client’s ldap_cachemgr.

The following command will generate LDIF which you can import into the directory:

ldapclient genprofile \
-a profileName=opensolarisclient \
-a defaultSearchBase=dc=sundemo,dc=net \
-a credentialLevel=proxy \
-a defaultServerList= \
-a authenticationMethod=tls:simple \

Sample Output:

# ./ dn: cn=opensolarisclient,ou=profile,dc=sundemo,dc=net ObjectClass: top ObjectClass: DUAConfigProfile defaultServerList: defaultSearchBase: dc=sundemo,dc=net authenticationMethod: tls:simple cn: opensolarisclient credentialLevel: proxy

You can configure more attributes using an LDAP editor. See  LDAP Client Profiles for more information.

 And yes, this process is harder than it needs to be!    OpenDS will be in the IPS repository very soon – and hopefully some of the ldap configuration steps will be taken care of.

  1. December 11, 2008 1:56 am

    Thanks for posting this. Your method for dealing with the OpenDS self signed certificate is definitely simpler, which works well for evaluation and developers.
    However in a real deployment scenario, I would strongly recommend to use real certificates.

  2. December 12, 2008 9:31 am

    Thanks Ludo – I have updated the article to suggest using real certs for production.

Comments are closed.

%d bloggers like this: