Note: This is a preliminary posting of this article, and I may update it over time as I have the chance to do more testing and research into the details of my functional setup.

Overview

This article discusses what is involved in building an authentication server running on Solaris 10, using all Sun software for the back-end. It even covers what is needed to prepare it for client machines to authenticate. The actual client configuration will be covered in another article.

I’ll try to cover many of the caveats I discovered along the way, since none of the official documentation covers everything you need to know in a single source. I will, however, refer to official documentation where appropriate. Bear in mind, however, that the contents of this article are an ex post facto reconstruction of what I think I did when setting things up. So if I left something out, or got something wrong, please
let me know so I can fix it.

Setting up the authentication server

Thankfully Sun provides excellent documentation for parts of this step. The difficulty comes into play when you need to do the extra bits of configuration to support client authentication. Also, I discovered that you need to read the release notes, or ns-slapd will core dump.

This part of the process consists of the following major steps:

• Installing Sun JSDS
• Configuring JSDS to use SSL
• Setting up your Kerberos KDC, and configuring JSDS to use it
• Fixing JSDS’s startup scripts so it doesn’t crash
• Configuring the SMF so JSDS will run on system startup
• Prepare JSDS to be usable as an LDAP user/network directory

Installing Sun JSDS

The installation process is fairly straightforward, and there is no need for me to discuss the details. You download the software, run the installer, remember any username/password pairs you have to set, and that’s pretty much it.

The specific software I used when doing all this is as follows:

• Solaris 10 (SPARC), up-to-date on patches as of sometime in December 2005
• Sun Java(TM) System Directory Server 5.2 2005Q4
  • Described here
  • Downloaded here
  • Documented here

I think the default installation directory is “/var/Sun/mps”. However, since “/var” isn’t typically a place I want to be installing software, I installed JSDS in “/opt/Sun/mps” instead. So for the sake of this article, whenever appropriate, assume that I installed JSDS in “/opt/Sun/mps”.

Configuring JSDS to use SSL

The details of this procedure are described fairly well in the first half of this Sun document. I think I followed this procedure, or some logical variant thereof. For your SSL CA, you can use anything you want (including your own fake CA). While I don’t want to pay for a gazillion SSL certificates for my personal tinkerings, I still don’t personally like the idea of making a gazillion fake “Snake Oil CA” keys. As such, I use CAcert as the CA for all of my SSL certificates.

Setting up your Kerberos KDC, and configuring JSDS to use it

Surprisingly, Sun’s JSDS docs cover it again for this step. As such, I don’t even need to bother writing a section on how to setup your Kerberos KDC. Once more, you need to look at this document, and search for the section that is titled “Configuring Kerberos Authentication using GSSAPI with SASL: Example procedure”.

Fixing JSDS’s startup scripts

Once you have the GSSAPI pieces of Sun JSDS configured, you need to do one more thing before starting it back up. If you forget this step, ns-slapd *will* core dump the moment you try to do anything. This tip is actually copied from Sun’s release notes, and while it does imply a pre-release build of Solaris 10, the problem still definitely occurs on the release version of Solaris 10 complete with up-to-date patches:

GSSAPI Crashes on Solaris 10 When Using Kerberos (6184559)

When Directory Server is configured for use with SASL authentication on Solaris 10 build 69, when you perform an authentication by using Kerberos through GSSAPI the directory core is dumped.

Workaround
For 64-bit servers on Solaris 10 machines, pre-load the smartheap library when you start the slapd daemon. To pre-load the smartheap library, modify the start-slapd script under an ldap instance, as follows:

For example:

Configuring the SMF so JSDS will run on system startup

Create the file “/var/svc/manifest/site/jsds.xml” with the following contents:
(Note: I have JSDS installed in “/opt/Sun/mps”, and my instance name is “neutronium”, after the name of my auth server. Please replace these two items in the below text as appropriate for your system)

< ?xml version="1.0"?>
< !DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type='manifest' name='site:jsds'>

<service name='site/jsds'
        type='service'
        version='1'>

        <create_default_instance enabled='false' />

        <single_instance />

        <dependency name='required_services'
                grouping='require_all'
                restart_on='none'
                type='service'>
                        <service_fmri value='svc:/network/dns/client' />
                        <service_fmri value='svc:/network/security/krb5kdc' />
        </dependency>

        <dependency name='network'
                grouping='require_any'
                restart_on='error'
                type='service'>
                        <service_fmri value='svc:/network/service' />
        </dependency>

        <dependent name='jsds_multi-user'
                grouping='optional_all'
                restart_on='none'>
                        <service_fmri value='svc:/milestone/multi-user' />
        </dependent>

        <exec_method type='method'
                name='start'
                exec='/opt/Sun/mps/slapd-neutronium/start-slapd'
                timeout_seconds='60'/>

        <exec_method type='method'
                name='stop'
                exec='/opt/Sun/mps/slapd-neutronium/stop-slapd'
                timeout_seconds='60' />

        <exec_method type='method'
                name='restart'
                exec='/opt/Sun/mps/slapd-neutronium/restart-slapd'
                timeout_seconds='120' />

        <stability value='Unstable' />

        <template>
                <common_name>
                        <loctext xml:lang='C'>
                        Sun Java System Directory Server
                        </loctext>
                </common_name>
                <documentation>
                </documentation>
        </template>

</service>

</service_bundle>

Install this service manifest with the following command:

svccfg import /var/svc/manifest/site/jsds.xml

Enable this service with the following command:

svcadm enable site/jsds

Keep in mind that this doesn’t start the back-end for the administration console by default. If you want to start that, use this command:

/opt/Sun/mps/start-admin

Then you can start the admin console itself (a Java GUI application) with:

/opt/Sun/mps/startconsole

Prepare JSDS to be usable as an LDAP user/network directory

This is the final step, which is completely omitted from Sun’s JSDS documentation. However, it is required to create the necessary LDAP entries for everything (that I’ll describe in the other articles) to work properly. Thankfully, Sun does describe a bit of the procedure here, within the Solaris 10 documentation.

Essentially, you run “/usr/lib/ldap/idsconfig” and follow the prompts. Besides setting up all the necessary LDAP structure and inital entries, this process also creates a new LDAP user called “proxyagent”. This user is used in client setup configuration, so it is also important.