Warning Livedoc is no longer being updated and will be deprecated shortly. Please refer to https://documentation.tjhsst.edu.

Sun Java System Directory Server

From Livedoc - The Documentation Repository
Revision as of 12:36, 13 August 2008 by William Yang (talk | contribs) (Intranet: Completed section.)
Jump to: navigation, search

Currently, this article applies to version 6 of Sun Java System Directory Server, Sun's implemention of an LDAP server. It is sometimes referred to as Sun Directory Server, Directory Server Enterprise Edition, or DSEE.


  • Currently we use the Java Enterprise System (JES) or native packages installers. Note that the native package installer for version 6.3 is really the JES installer for 6.0 + Solaris patch.
  • To use Identity Synchronization for Windows (ISW), you may need to download the ZIP distribution of DSEE. Note that you should still install the native packages distribution for DSEE, only using the ZIP distribution to get ISW.
  • When installing DSEE, choose "Configure Later". After installation completes, run the following sequence of commands to use the DSCC (not a typo) web management interface:
/opt/SUNWdsee/dscc6/bin/dsccsetup initialize
cacaoadm enable
cacaoadm start
smcwebserver enable
smcwebserver start

Configuration Notes

Any configuration steps listed below that are server-specific must be run on each LDAP instance!

  • The databases are currently stored using ZFS, located at /store/ds/{subdir}.
  • We use the wildcard SSL certificate from ipsCA rather than a self-signed one for LDAP because we have it and it works. It needs to be imported in PKCS12 format (the password for which cannot be null). A PKCS12 version of the currently valid certificate is located at TJcerts/main_ipsca/tjhsst.pkcs12 on the Sun administrative volume. As last attempted, this process seems to be a little more involved than it should:
    • Import the certificate
    • Restart the Directory Server instance
    • Now switch to the new certificate
    • Restart again
  • To change the manager password, run ldapmodify with the appropriate arguments against this:
dn: cn=config
changetype: modify
replace: nsslapd-rootpw
nsslapd-rootpw: newpassword
  • To enable starting the server at boot time using SMF, run
/opt/SUNWdsee/ds6/bin/dsadm enable-service -T SMF /path/to/directory

DSCC's LDAP server is located at /var/opt/SUNWdsee/dscc6/dcc/ads, while we locate the data-containing LDAP servers at /store/ds/{subdir}. Also run svccfg -s application/sun/ds setprop start/timeout_seconds=600 in the event that a recovery needs to take a long time, otherwise SMF will kill and restart the LDAP server if a recovery operation takes longer than the default timeout (which means the directory server may not ever automatically restart after a system crash). Finally run svcadm enable on the new SMF entries created for the Directory Servers. sun/ds:default doesn't start anything so you don't need to enable that.

  • If using ISW: using DSCC, select the LDAP server instance, go to Server Configuration -> Plugins, select the "referential integrity postoperation" plugin. Set Argument 1 to "2". This should make mass modifications and deletions faster.[1] This plugin is enabled by ISW, so if you change the setting before installing ISW, the plugin may still be disabled.
  • When importing data from OpenLDAP, you may have structuralObjectClass attributes on objects. Sun Directory Server doesn't seem to like this, so just change structuralObjectClass to plain objectClass.
  • The default DN of the manager account (basically a root account in LDAP) for Sun Directory Server is "cn=Directory Manager".


See also NSS LDAP.

  • NSS LDAP databases are stored in /store/ds/nss.
  • Currently ports 388 (non-SSL) and 635 (SSL) are used for NSS LDAP, but that is not a requirement. It is used because NSS LDAP used to coexist with another LDAP instance at the same IP address that used the normal 389/636 ports. While that is no longer the case, the port numbers were kept to reduce impact on already configured client systems.
  • Verify that the following 4 acis exist on the root dn entry dc=csl,dc=tjhsst,dc=edu (easily done by reading a backup LDIF dump):
aci: (targetattr="dspswpassword")(version 3.0; acl "No read access to dspswpas
 sword"; deny(read, search, compare) userdn="ldap:///anyone";)
aci: (targetattr="dspswuserlink || dspswloop || dspswvalidate")(version 3.0; a
 cl "deny write access to dspswuserlink, dspswloop, dspswvalidate"; deny(writ
 e) userdn="ldap:///self";)
aci: (targetattr="*")(version 3.0; acl "Full rights for PSW Connector"; allow(
 all) userdn="ldap:///uid=PSWConnector,dc=csl,dc=tjhsst,dc=edu";)
aci: (target="ldap:///dc=csl,dc=tjhsst,dc=edu")(targetattr !="aci")(version 3.
 0;acl "anonymous, no acis"; allow (read, search, compare) userdn = "ldap:///
  • In order for NSS LDAP to fully work for Solaris clients, we need to set up VLV indexes (nowadays sometimes referred to as "browsing indexes". This must be done on EACH replica server, not just the master(s). Without these indexes, while the system will probably work fine, you won't be able to "dump" the NSS databases using getent passwd or getent group.
    • From the DSCC web interface, select the LDAP instance, then go to Entry Management -> Access Control
    • Edit the "VLV Request Control" entry to apply to ldap:///anyone instead of ldap:///all (anyone means anonymous access while all means any bound user)
    • On the command line, ldapadd the vlvindexes.ldif file (currently located in the ds folder on the Sun admin volume)
      • If you want to try and understand what we are adding, examine the /usr/lib/ldap/idsconfig script
    • Stop the directory instance
    • Generate the VLV indexes: dsadm reindex -l -b -t csl.tjhsst.edu.getpwent -t csl.tjhsst.edu.getgrent /store/ds/nss csl
  • We also want to supplement the default attribute indexes. After logging into the DSCC, go to Directory Servers -> Suffixes -> [choose the suffix] -> Indexes.
    • For "uid", enable Presence and Substring (Equality should already be enabled).
    • ldapadd the nssindexes.ldif file (same location as vlvindexes.ldif above) to add all the other indexes that we want.
    • Indexes shouldn't need to be regenerated since there shouldn't be any data in the directory server yet.
  • Adjust the default cache values. Select the LDAP instance, then go to Server Configuration.
    • On the LDAP subtab, set the Size Limit and Lookthrough Limit to Unlimited. The default 3600 second Time Limit and Unlimited Idle Timeout should be fine.
    • On the Performance subtab, change the following values:
      • Database Cache (Global): 256 MB (default 32 MB)
      • Initialization Cache (Global): 512 MB (default 64 MB)
      • Cache Size Limits: dc=csl,dc=tjhsst,dc=edu: 64 MB (default 10 MB)


See also Intranet2. While Intranet currently uses OpenLDAP, Sun Directory Server is being considered for Intranet use. The notes below reflect what has been found so far in that considering process; however, they should be considered out-of-date.

Since there isn't really an Intranet2 functional article, here's a short blurb on the role of LDAP: LDAP is used to store student information. In Intranet 1, MySQL was used exclusively for this purpose, but now LDAP is used for most static student information, including biographical information, class schedule, and contact information. Eighth period, Intranet groups, polls, and several other services are still managed through MySQL since it is better for things that are more likely to change. Access controls are also applied using LDAP and not using Intranet. In this way, by having the Intranet LDAP server run by a staff member, students are not necessarily able to easily access private student information even while retaining administrative privileges over other components of Intranet.

  • There is no Sun LDAP instance for testing use with I2 at this time. There was at one point, running DSEE 6.1 on chuku, prior to the "students can see other students private data?" debacle.
  • The manager DN for I2 LDAP is "cn=Manager,dc=tjhsst,dc=edu".
  • Most files referenced below are located in the ds directory on the Sun admin volume.
  • Anywhere below that it says "ldapadd this", the basic command to use is: ldapadd -h chuku -D "cn=manager,dc=tjhsst,dc=edu" -Wxc -f {filename}. The "-c" argument is recommended so ldapadd will continue trying to add the rest of the LDIF even if it encounters an error with one of the entries in the middle.



WARNING: ACIs haven't really been worked out yet; the acis.ldif file doesn't have everything that it should for Intranet.

  • Delete all of the default ACIs.
  • ldapadd the acis.ldif file.


  • ldapadd the indexes.ldif file
  • Indexes that are currently seen in the OpenLDAP slapd.conf that aren't in this LDIF are missing because they are defaults for Sun Directory Server.
  • If the indexes used have changed, the gen_indexldif.sh and indexes.in files can be used to easily generate a new indexes.ldif.
  • Sun docs for v6.0: http://docs.sun.com/app/docs/doc/819-0995/6n3cq3avo?a=view

Cache configuration

  • Use DSCC, select the LDAP instance, go to the Server Configuration -> Performance.
  • Set the following values:
    • Database Cache (Global): 512 MB (default 32 MB)
    • Initialization Cache (Global): 768 MB (default 64 MB)
    • Cache Size Limits: dc=tjhsst,dc=edu: 64 MB (default 10 MB)

Simple bind users

  • At time of writing this applies only to cn=authuser, but for all users that have a hashed password stored in LDAP (so those that would use a simple bind as opposed to a SASL/GSSAPI bind to access LDAP), reset the password manually after the user(s) have been loaded into LDAP from LDIF, unless you are able to successfully bind as that user without doing so.


Listed below are general ways to administer DSEE. See NSS LDAP for some special ways to administer its LDAP server.

Web interface

Access to the web interface is on the primary LDAP server only at this time. The Directory Service Control Center (DSCC) is accessed through the Sun Java Web Console, available at https://ldap1.sun.tjhsst.edu:6789/. This address is NOT open to the world; you will need to be on the TJ network to access it. To login to Web Console, use the root account and password. Once logged into the Web Console, you will need to launch the DSCC app. Login as "admin" with the DSCC admin password. DSCC makes it easy to manage multiple Sun Directory Server instances on any number of servers.

Details of how to use the console aren't provided here, but here is a short list of things you can do:

  • Manage replication
  • Restart LDAP servers
  • Modify performance parameters (indexing, caches, etc.)
  • Access logs
  • Manage entries (mostly users and groups)

Note that server-specific changes should be made to both servers; i.e. server configuration is not replicated. However, if setting up new LDAP servers, it may be easier to finish setting up one server before setting up its partner as many settings can be copied from an existing LDAP server by DSCC.

If the primary LDAP server (not just the service) is down, the console will also be unavailable as it runs there. There should be a way to replicate DSCC settings as well since it is just dependent on another smaller LDAP instance; however, we do not currently use it as the need doesn't seem to be there. Note that an LDAP server can only be registered in one DSCC at a time.

CLI tools

This just means you can use ldapadd, ldapmodify, ldapdelete, etc. to work on LDAP. Either Sun LDAP client tools or OpenLDAP tools may be used, just be aware that syntaxes may vary for command line options and binary or hashed contents in LDIFs. Note that when using Sun LDAP client tools, you should NOT pass the "-w -" option to prompt interactively for password. For whatever reason, if you do that, and the password contains special characters, it won't read successfully. If you don't pass "-w -", you will still be interactively prompted for a bind password, but this way it will be read successfully even if it contains special characters.

dsadm command on the LDAP servers is also used to manage the server instance itself. It is located in /opt/SUNWdsee/ds6/bin, which should already be in the PATH.

Everything that can be done through the web interface should also be doable using CLI tools, albeit not always as easily.

See Also