Ludo's sketches: Ludovic Poitou's blog

Some people seem to be in love with our Directory Server Enterprise Edition product and are showing it ! I wonder when we will start seeing OpenDS license plates ;-)

Photo courtesy of Kent Spaulding, CTO at Skyworth TTG.

Technorati Tags: directory-server, ldap

Directory Server 6.0 introduced many changes in its administration tools: a new GUI, new CLIs such as dsconf and dsadm.

dsadm has a set of commands to do certificate management for directory server instances, such as requesting new certificates, listing certificates, adding certificates. This feature has been added in Directory Server 6, because certutil, the utility available with the NSS library is not officially supported.

The dsadm utility does the work in most of the cases but there are some known limitations such as no support for the subjectAltName extension. For those advance use cases, the workaround is to use certutil (at your own risks).

One big difference between dsadm and certutil is the certificate store password. By default, the password is unknown to the administrators, and managed through a file. Certutil does require the password to be known.

To change the default password and be able to use certutil, you need to launch the following command as root or the owner of the directory server instance:

>  /opt/SUNWdsee/ds6/bin/dsadm set-flags /local/demo/dstest cert-pwd-prompt=on
Choose the new certificate database password:
Confirm the new certificate database password:
Certificate database password successfully updated.

From them, you will be able to run "certutil -d /local/demo/dstest/alias -P slapd- ..." with the appropriate options.

When you're done, you can store the password again in a text file for use by dsadm or Directory Server at restart with the following command:

>  /opt/SUNWdsee/ds6/bin/dsadm set-flags /local/demo/dstest cert-pwd-prompt=off
Enter the certificate database password:
Certificate database password has been successfully stored.

Directory Service Control Center (DSCC) is the new graphical user interface to manage a complete directory service deployment. Below is a screen-shot of the main panel when starting DSCC.

DSCC is relying on the Solaris WebConsole, which is available by default on Solaris but has been ported to the other supported platforms (HP-UX, Linux, Windows).

If you want to get a better understanding of the Web Console, want to change its default configuration or need to troubleshoot it, please refer to this document: http://docs.sun.com/app/docs/doc/817-1985/6mhm8o5ke?a=view.

Last week I was invited to a meeting with one of our customers, a wireless telecom operator happily  user of Sun Directory Server 5.2 (patch3) with a few tens of million entries.

With the convergence of voice and data, the telcos are looking for ways to reduce the number of databases they have and consolidate the data in a single repository such as LDAP-based directory services.
The discussion went on the subject of the data models, the differences between the LDAP model and the relational model, drifting to which model would be the most appropriate in consideration with the Generic User Profile recommendation from the IMS specifications. Clearly the discussion was reaching the limits of my expertise (while I'm quite confident in the LDAP area, IMS is not something that I've followed), but it was very informative.

The one thing that I really found interesting in this discussion: at no time, the consideration of performances was mentioned. It seemed obvious for all parties that LDAP directory services (and probably more specifically our Directory Server) do have the capability of keeping with the high throughput and low response time requirements of the network equipments.

And in fact, they really do. We will have some evidence of this with Directory Server Enterprise Edition 6.0 very soon.