Netmojo Systems

How To Install and Configure Solaris 9 for Authentication with OpenLDAP 2.1


Table of Contents

  1. Introduction
  2. Objectives
  3. What You Need
  4. Building the Software
  5. Prepare the System
  6. Create OpenSSL Certificates
  7. Setup the slapd.conf File
  8. Setup the ldap.conf Files
  9. Start the Server and Populate It
  10. Last Step!
  11. Trouble Shooting

<!-- Note:

The instructions on this page haven't been updated since Nov 24, 2003. The software may have changed since then, as new versions have been released.

For a much easier experience with Solaris and LDAP, I encourage you to consider Sun's LDAP server, iPlanet/SunONE/Java-something-or-other, which now ships with Solaris. OpenLDAP clients can easily connect to it.

end note -->

Introduction

UNIX systems traditionally have relied on NIS for distributed user authentication. However, NIS suffers from the major disadvantage of sending password hashes over the network in clear text. Sun invented NIS+ to address the security problems with NIS, but almost anyone who has setup and managed NIS+ will tell you that it is a monster. It is overly complex, not very stable, and difficult to manage. Even Sun has abandoned it. The world is moving to LDAP, Lightweight Directory Access Protocol, which can provide a secure, easy to manage, and -- once you come to understand directory services -- simpler solution to distributed account management and user authentication.


Objectives

This will be a step-by-step walk through on setting up OpenLDAP to handle user account storage and authentication on Sun Solaris. There are numerous ways to configure LDAP; this HOWTO will cover one of them. The instructions are probably portable to other UNIX or UNIX-like systems that support name service switching.

OpenLDAP will be configured to work over SSL using StartTLS, so nothing will go over the network in the clear. Note that StartTLS sets up a kind of opportunistic SSL-encrypted tunnel on the regular ldap port, 389, which isn't the same as connecting with ldaps, on port 636.

Although I'm including the building and linking of SASL in these instructions, I won't be setting up LDAP authentication using SASL mechanisms -- OpenLDAP will be configured to use the "PLAIN" or "simple" mechanism, and will store passwords in encrypted form in the directory. When users type in their passwords at a password prompt, it will reach ldap in cleartext, although it will be over an SSL-encrypted tunnel. However, I may switch to SASL mechanisms at a later date, so I want to be prepared.


What You Need


Building the Software

  1. Setup the build environment.
    Since I have different compilers and versions of libraries on my system, I want to ensure that my build environment includes the libraries and uses the compiler that I want. I'll be using gcc 3.3 (in /opt/bin) as my compiler, and Sun's linker in /usr/ccs/bin. OpenSSL is installed in /opt/ssl on my system. I'm running the bash shell, so I set environment variables by executing:

    export CC=/opt/bin/gcc
    export LDFLAGS="-L/opt/lib -L/opt/ssl/lib"
    export CPPFLAGS="-I/opt/include -I/opt/ssl/include"
    export PATH=/opt/bin:/opt/sbin:/usr/bin:/usr/sbin:/usr/ucb:/usr/ccs/bin
    I recommend that you unpack, configure, and build the source code for the various packages as a normal user. Switch to a priveleged user only before issuing 'make install'.

  2. Compile and install Berkeley DB
    Unpack the Berkeley DB sources somewhere, and enter its directory. By default, it installs to /opt/BerkeleyDB.4.1; if you want it elsewhere, use "--prefix=/path" as an argument to configure.

    If you would like to configure a database that is optimally resistent to data corruption in the event of a system crash, I suggest you read this document, about Berkeley DB's data integrity features as they relate to file and operating systems, and physical disks. This page discusses BDB's compile-time page size settings and the impacts that they could have on performance, and this post to an OpenLDAP mailing list mentions how to set BDB's page size at compile time. There are other things to consider though, such as the ratio of disk space consumed to performance gained when various pagesizes are enforced.

    Even if you go with the defaults, the worst-case scenario for data recovery isn't so bad with Berkeley DB anyways, and if you have replica servers, they may be a sufficient backup for your needs, in the event of a system failure and subsequent database corruption. I would be interested to find out if anyone has weighed all of these factors, done some tests, and reached some conclusions about the best filesystem blocksizes and BDB page sizes to use for optimal performance and reliability. Chances are that OpenLDAP itself picks good general defaults in its use of BDB, but I'm sure there is still room for optimization based on your specific hardware/software setup.

    To build BDB with all the default settings:

    cd build_unix ; ../dist/configure ; make ; su -c make install
    Now that Berkeley DB is installed, we should update our build environment so that it is included in our library path:
    export LDFLAGS="-L/opt/lib -L/opt/ssl/lib -L/opt/BerkeleyDB.4.1/lib"

  3. Compile and install Cyrus SASL
    We want to link OpenLDAP to the SASL libraries, but we also want to link SASL to the OpenLDAP libraries. So we'll install SASL now, then compile and install OpenLDAP (linking it to SASL), then re-compile and install SASL, linking to the new OpenLDAP libraries.

    Unpack the Cyrus SASL sources, and change into its directory. Run the configure script to see what options are available:

    ./configure --help
    I won't be using kerberos5 (gssapi) or kerberos4, and I'm going to use "plain" authentication (I will probably come back and revise this, since I've discovered that referalls don't get automatically followed when using plain), so my configure arguments are:
    ./configure --prefix=/opt --with-dbpath=/var/db/sasldb2 --with-dblib=berkeley --with-bdb-libdir=/opt/BerkeleyDB.4.1/lib --with-bdb-incdir=/opt/BerkeleyDB.4.1/include --with-saslauthd=/var/db/saslauthd --with-openssl=/opt/ssl --enable-plain --with-plugindir=/opt/lib/sasl2 --disable-krb4 --disable-gssapi --with-devrandom=/dev/random --enable-digest --disable-cram

    make ; su -c make install
    Now that SASL is installed, we should update our build environment to include it in our library path:
    export LDFLAGS="-L/opt/lib -L/opt/ssl/lib -L/opt/BerkeleyDB.4.1/lib -L/opt/lib/sasl2"
    export CPPFLAGS="-I /opt/lib -I/opt/ssl/include -I/opt/include/sasl -I/opt/BerkeleyDB.4.1/include"

  4. Compile and install OpenLDAP
    Add this additional environment variable, to ensure that sasl libraries get linked in:

    export LIBS="-lcrypto -lssl -lsasl2"
    Unpack the sources, and change into its directory. Run the configure script to see what options are available:
    ./configure --help
    It is important that you do not install OpenLDAP over the native solaris LDAP tools, so in case you're having a momentary lapse of sanity, don't use --prefix=/usr (you should never install 3rd-party stuff in /usr anyways, but especially not now). My configuration is:
    ./configure --prefix=/opt --enable-bdb --enable-ldbm --enable-crypt --enable-spasswd --with-threads --with-tls --with-cyrus-sasl --without-kerberos --disable-ipv6

    make depend ; make ; su -c make install

  5. Recompile and reinstall Cyrus SASL
    Now to rebuild SASL, linking against OpenLDAP. Change back into your SASL source directory, and execute "make clean". Then reconfigure, including the --with-ldap argument:

    ./configure --prefix=/opt --with-dbpath=/var/db/sasldb2 --with-dblib=berkeley --with-bdb-libdir=/opt/BerkeleyDB.4.1/lib --with-bdb-incdir=/opt/BerkeleyDB.4.1/include --with-saslauthd=/var/db/saslauthd --with-openssl=/opt/ssl --enable-plain --with-plugindir=/opt/lib/sasl2 --disable-krb4 --disable-gssapi --with-devrandom=/dev/random --enable-digest --disable-cram --with-ldap=/opt

    make ; su -c make install
    It is recommended in the SASL documentation that you add a symlink from your SASL2 installation directory to /usr/lib/sasl2:
    ln -s /opt/lib/sasl2 /usr/lib/sasl2

  6. Compile and install PADL pam_ldap and nss_ldap modules
    Unfortunately, PADL Software has tied their configuration scripts to specific versions of aclocal, part of automake. If you don't have version 1.6 of automake installed, you will have to download it and install it. It will peacefully coexist with other versions on your system. Autoconf 2.57 was required by automake1.6, and GNU m4 was required by autoconf. You can get them all from the same place.

    Make sure that you are using the real Sun linker (/usr/ccs/bin/ld), or the build will fail with a message about not understanding the solaris.exports file. I also found it necessary to add another environment variable for nss_ldap; the existing ones weren't enough for ld to find the openssl libraries:

    export LD_LIBRARY_PATH=/opt/ssl/lib
    For pam_ldap, the module is built only in the 'make install' target, so after switching to root to do the install, you'll have to update your environment with the ssl path again.

    Unpack the pam_ldap and nss_ldap source from PADL Software. Both of these modules use the same configuration parameters. Run "./configure --help" to see the options. I used:
    ./configure --prefix=/opt --with-ldap-lib=openldap --with-ldap-dir=/opt --with-ldap-conf-file=/opt/etc/ldap.conf --with-ldap-secret-file=/etc/ldap.secret

    make ; su -c make install
    I recommend using /etc/ldap.secret, since another peice of software also looks here. ldap.secret will contain a password in cleartext that gives access to your entire directory. This is a dissappointing hack, but if you think about it, it is no different than the /etc/shadow file, which contains password hashes on disk. This ldap.secret files provides the means to access similar password hashes in your LDAP directory. We will cover how this works below. As far as I know, there is no way around this requirement.

Prepare the system

  1. Create ldap system account & group
    Like most system services, we should avoid running them as the root user, where possible. OpenLDAP makes it easy to do so. Create a system account and group called "ldap", or something similar. The account should not have a working shell, and its home directory should be empty. OpenLDAP's files will be owned and accessible by this user, and the server will run as this user.

    mkdir -m 0555 /var/empty
    groupadd -g 30 ldap
    useradd -u 30 -g ldap -d /var/empty -s /bin/false -c "LDAP User" ldap

  2. Replace native nss_ldap
    Move the Sun nss_ldap out of the way, and create a symlink to the PADL version:

    mv /usr/lib/nss_ldap.so.1 /usr/lib/nss_ldap.so.1-sun
    ln -s /opt/lib/nss_ldap.so.1 /usr/lib/nss_ldap.so.1

  3. Setup ldap database directory
    Create a directory where the ldap datafiles will be stored, and set permissions on it:

    mkdir -m 0700 /var/db/ldap
    chown ldap:ldap /var/db/ldap

  4. Create a directory for the slapd pid file
    Since slapd will be running as the "ldap" user, it needs a writable directory for its pid file:

    mkdir -m 0755 /var/run/slapd
    chown ldap:ldap /var/run/slapd

Create OpenSSL Certificates

  1. Create the Certificate Authority
    Unless you're planning to offer some sort of public LDAP service, despite what many people say, I see no reason to pay a so-called official certificate authority, like Verisign, to sign your SSL certs. You can be your own CA, since you can configure your own clients to trust your CA.

    I am going to set up a master LDAP server that replicates to client servers, so I'm going to use the CA file (that I'm about to create) on my master LDAP server to sign all of the certificates for my client hosts.

    Find your "openssl.cnf" file, and edit it. The relevant fields to change and/or add are in the "[ req_distinguished_name ]" section. The field names ending in "_default" should be changed to suit your site, and those fields that don't already have defaults, add them. For example, I added:

    commonName_default = myhost.mydomain.com
    It is essential for OpenLDAP that the Common Name (CN) field on the client certificate & key to be identical to the fully qualified DNS domain name of the host on which it will reside. OpenLDAP will not work if you don't use the FQDN in the CN field. If you don't fill in the defaults for the other fields, such as Organization, Locality, etc., then you will have to re-type the information with every certificate you create.

    Use the CA.pl script that ships with OpenSSL. You may want to edit it, since some settings within it (strangely) override settings in the openssl.cnf file, such as where to put the new CA cert (it defaults to "demoCA" - I changed mine to "CA").

    Create the CA file on your master LDAP server:
    cd /opt/ssl/certs
    /opt/ssl/misc/CA.pl -newca
    Answer the questions accordingly, putting your master server's FQDN in the CN field, and use a password that you won't forget. This will generate some files under ./demoCA (or in my case ./CA), the one we are interested in is the "cacert.pem" file.

  2. Create the Client Certificates
    For each host that you intend to include in your LDAP-authenticating network, you need to make a client certificate and key. Each one must have the FQDN of the host on which it will be used, in the CN field. Starting with the master server, use the CA.pl script to create a certificate and key, entering the master server's FQDN in the CommonName field:

    /opt/ssl/misc/CA.pl -newreq
    /opt/ssl/misc/CA.pl -signreq
    This will produce "newreq.pem", which is the key, and "newcert.pem", which is the certificate. I find it practical to name them according to the host on which they'll be used:
    mv newreq.pem myhost.slapd-key.pem
    mv newcert.pem myhost.slapd-cert.pem
    The key file is encrypted using the password that you entered during it's creation. Unless you want to enter that password every time slapd starts up, you will need to decrypt the key, and protect it with file permissions:
    openssl rsa -in myhost.slapd-key.pem -out myhost.slapd-key.pem
    chmod 0400 myhost.slapd-key.pem
    Repeat this process for each host that will be part of your LDAP network, using their respective FQDNs in the CN field, and renaming the files so that they can be easily identified. Note that we use only one (the same) cacert.pem file for all hosts.

  3. Install the Certificates
    I'm going to put my SSL certs in /opt/etc/openldap/certs:

    mkdir -m 0755 /opt/etc/openldap/certs
    cp CA/cacert.pem /opt/etc/openldap/certs/
    cp myhost.slapd-cert.pem /opt/etc/openldap/certs/
    cp myhost.slapd-key.pem /opt/etc/openldap/certs/
    chown -R ldap:ldap /opt/etc/openldap/certs
    The client hosts need a copy of the cacert.pem, plus their own respective cert/key pair, so copy them to the other hosts accordingly.


Setup the slapd.conf file

The slapd.conf file holds the configuration information for the main ldap server process, slapd.
  1. Secure the config file
    My slapd.conf is here: /opt/etc/openldap/slapd.conf. We will be storing in this file a password hash of the directory administrator's password - the ldap equivalent of the root user account. So it is important that its file permissions does not allow ordinary users to read it.

    chown root:ldap /opt/etc/openldap/slapd.conf
    chmod 640 /opt/etc/openldap/slapd.conf
    While you're setting things up, you may actually want to make this file owned by you, to avoid having to work as the root user -- just remember to change it back!

  2. Edit the config file
    Open slapd.conf with your favorite text editor. I will proceed through the file by sections, with the config file's contents indented and in courier font. Note that my configuration may not meet to your site's requirements so please read the official documentation and decide for yourself what you need.

    The schema files

    include /opt/etc/openldap/schema/core.schema
    include /opt/etc/openldap/schema/cosine.schema
    include /opt/etc/openldap/schema/solaris-nis.schema
    include /opt/etc/openldap/schema/solaris.schema
    include /opt/etc/openldap/schema/inetorgperson.schema
    include /opt/etc/openldap/schema/misc.schema
    You may need to edit some of these files if you have special requirements for object class definitions.

    Logging and misc settings
    # Logging & Misc
    loglevel 296
    pidfile /var/run/slapd/slapd.pid
    argsfile /opt/etc/openldap/slapd.args
    defaultsearchbase dc=myorg,dc=com
    threads 400
    password-hash {CRYPT}
    OpenLDAP Logging levels are specified by adding integers from the following table (this info is in the slapd.conf(5) man page):


    1 trace function calls
    2 debug packet handling
    4 heavy trace debugging
    8 connection management
    16 print out packets sent and received
    32 search filter processing
    64 configuration file processing
    128 access control list processing
    256 stats log connections/operations/results
    512 stats log entries sent
    1024 print communication with shell backends


    So I choose 8 + 32 + 256 = 296, to log connections, search filter processing, and results, for now. Once you're up and running, you may want to disable logging altogether by setting loglevel to 0, which would improve performance, but leave you with no audit trail. OpenLDAP logs to the local4 syslog facility. You should set up logging ldap to a separate logfile by adding this to your /etc/syslog.conf:
    local4.debug /var/log/ldap
    Create the file, and restart syslogd.
    touch /var/log/ldap
    chmod 0600 /var/log/ldap
    pkill -HUP syslogd
    Using an argsfile directive will make slapd write the arguments with which it was started to a file on startup. This file is not to specify the arguments with which slapd should start -- you must specify those when you start slapd. Note that the ldap user will need write access to this file.

    The defaultsearchbase directive specifies the search base to use if one isn't specified when searches are performed. I choose the top of my directory tree as the default.

    The threads directive specifies the maximum number of threads to fork -- the default is only 16. One search will consume one thread, so if you set this too low, your system may become pretty sluggish. Solaris does a great job of threading, so we should take advantage of it.

    The password-hash directive sets the default cipher to be used when people change their passwords. I choose {CRYPT}, since I will be importing users from NIS+, and possibly interoperating with NIS and/or NIS+ hosts, which use CRYPT. If you have no such requirements, I recommend using {MD5} or {SHA} instead.

    TLS/SSL settings
    Specify where your SSL certificates are, and the crypto-strengths to use:
    # SSL/TLS
    TLSCipherSuite HIGH:+TLSv1:+SSLv2:+SSLv3
    TLSCACertificateFile /opt/etc/openldap/certs/cacert.pem
    TLSCertificateFile /opt/etc/openldap/certs/myhost.slapd-cert.pem
    TLSCertificateKeyFile /opt/etc/openldap/certs/myhost.slapd-key.pem
    security ssf=1 update_ssf=128 simple_bind=128 update_tls=128 tls=128
    The TLSCipherSuite directive specifies the strength of ciphers, or the specific ciphers to use. The options available here are in the ciphers(1) man page that comes with OpenSSL. "HIGH" specifies those ciphers suites with key lengths greater than 128bits.

    The TLS CA, Certificate and CertificateKey Files should point to the files that we installed in the previous section.

    The security parameter specifies the minimum encryption key lengths required to perform various tasks such as binding and updating. As always, there is more information available in the slapd.conf(5) man page. You may want to comment out this line while you're setting things up, since it will prevent ldap clients such as pam_ldap and openldap tools from connecting, if they don't have the client-side TLS options configured properly.

    While you are first setting up, you should probably comment out the "security" line, until ldap is working without TLS. Then uncomment it to enforce the use of TLS for all binds.

    Define Access Controls
    I'm going to allow authenticated users read/write access to all fields of their own record, and allow read access to all authenticated users to all fields of other users except the password field. By default, no access will be granted, so that a successfull ldap bind will have to happen before any access is granted.
    # Global access permissions
    access to attrs=userPassword
          by self write
          by * auth
    access to *
          by users read
    #       by * read
    You might want to use 'access to * by * read', to allow anonymous binds while you're setting things up. Change it to 'users' once you're confident everything else is OK, and you want to have pam_ldap and other tools use a specified system account for binding, instead of binding anonymously.

    Set up the Database Definition
    You will have to store the directory administrator's password in two locations, one in the slapd.conf file in a crypted hash form, and another in cleartext, in /etc/ldap.secret. You can create the password hash using a utility that comes with openldap called slappasswd, which installs into $PREFIX/sbin.
    /opt/sbin/slappasswd -h {MD5}
    Copy & paste the password hash into your database definition. Here's mine:
    # Myorg.com's database definition
    database bdb
    suffix "dc=myorg,dc=com"
    rootdn "cn=Manager,dc=myorg,dc=com"
    rootpw {MD5}rL0Y20zC+Fzt72VPzMSk2A==
    directory /var/db/ldap
    mode 0600
    index objectClass eq
    index uid,uidNumber,gidNumber,shadowExpire,shadowLastChange,
       loginShell,mail,host,homeDirectory eq
    index cn pres,eq
    cachesize 5000
    #dbcachesize 50000000
    defaultaccess none
    The cachesize parameter defines the number of entries that will be cached in memory. It defaults to 1000 entries. The dbcachesize parameter specifies how much memory to reserve for caching records. Some people have suggested that the ideal amount would be enough to cache all of your records, so set cachesize equal to the number of records that are in your directory -- but only if your system has enough memory to support it.


Setup the ldap.conf files


There are two ldap.conf files, one for PADL's modules (pam_ldap & nss_ldap) and one for OpenLDAP's clients (ldapsearch, ldapadd, etc). I'll start with PADL's /opt/etc/ldap.conf file:
  1. Secure the config file
    By default, pam_ldap will do anonymous binds to search for the user's DN based on their username. I prefer to set up a special account for pam_ldap to bind with, since I don't want to allow anonymous binds. As such, I'll be including the password in this file, and thus need to set its permissions appropriately:

    chown root:root /opt/etc/ldap.conf
    chmod 0600 /opt/etc/ldap.conf
    pam/nss_ldap runs with root priveleges, so we don't need to worry about the file only being readable by the root user.

  2. Edit the file
    As I did for the slapd.conf section, I'll put parts of the file in blockquote and courier font. The comments in the file should make most things self-explanatory:

    # Host to connect to
    host 127.0.0.1

    # The port.
    port 389

    # The distinguished name of the search base.
    base dc=myorg,dc=com

    # The LDAP version to use (defaults to 3
    # if supported by client library)
    ldap_version 3

    # The distinguished name to bind to the server with.
    # Optional: default is to bind anonymously.
    binddn cn=NonAnon,dc=myorg,dc=com

    # The credentials to bind with.
    # Optional: default is no credential.
    bindpw SeCrEt

    # The distinguished name to bind to the server with
    # if the effective user ID is root. Password is
    # stored in /etc/ldap.secret (mode 600)
    rootbinddn cn=Manager,dc=myorg,dc=com

    # The search scope.
    scope sub

    # Search timelimit
    timelimit 30

    # Bind timelimit
    bind_timelimit 30

    # Idle timelimit; client will close connections
    # (nss_ldap only) if the server has not been contacted
    # for the number of seconds specified below.
    idle_timelimit 3600

    # Filter to AND with uid=%s
    pam_filter objectclass=posixAccount

    # The user ID attribute (defaults to uid)
    pam_login_attribute uid

    # Search the root DSE for the password policy (works
    # with Netscape Directory Server)
    pam_lookup_policy no

    # Check the 'host' attribute for access control
    # Default is no; if set to yes, and user has no
    # value for the host attribute, and pam_ldap is
    # configured for account management (authorization)
    # then the user will not be allowed to login.
    pam_check_host_attr yes
    The pam_check_host_attr allows you to add "host" fields to your ldap records to specify the hosts to which the user may login. i.e., in the user's account record would be lines like:
    host myhost.mydomain.com
    host myhost2.mydomain.com
    host myhost5.mydomain.com
    This is a very useful feature for a large network, but if you want to allow all users to login to all of your hosts, set this parameter to 'no'.
    # Check the 'authorizedService' attribute for access
    # control
    pam_check_service_attr no

    # Group to enforce membership of
    #pam_groupdn cn=PAM,ou=Groups,dc=myorg,dc=com

    # Group member attribute
    #pam_member_attribute uniquemember

    # Specify a minium or maximum UID number allowed
    pam_min_uid 1000

    # Template login attribute, default template user
    #pam_login_attribute userPrincipalName
    #pam_template_login_attribute uid
    #pam_template_login nobody

    # Do not hash the password at all; presume
    # the directory server will do it, if
    # necessary. This is the default.
    pam_password clear

    # RFC2307bis naming contexts
    # Syntax:
    # nss_base_XXX base?scope?filter
    # where scope is {base,one,sub}
    # and filter is a filter to be &'d with the
    # default filter.
    # You can omit the suffix eg:
    # nss_base_passwd ou=People,
    # to append the default base DN but this
    # may incur a small performance impact.
    nss_base_passwd ou=People,dc=myorg,dc=com?sub
    nss_base_shadow ou=People,dc=myorg,dc=com?sub
    nss_base_group ou=Group,dc=myorg,dc=com?sub
    nss_base_hosts ou=Hosts,dc=myorg,dc=com?sub
    #nss_base_services ou=Services,dc=myorg,dc=com?one
    #nss_base_networks ou=Networks,dc=myorg,dc=com?one
    #nss_base_protocols ou=Protocols,dc=myorg,dc=com?one
    #nss_base_rpc ou=Rpc,dc=myorg,dc=com?one
    #nss_base_ethers ou=Ethers,dc=myorg,dc=com?one
    #nss_base_netmasks ou=Networks,dc=myorg,dc=com?ne
    #nss_base_bootparams ou=Ethers,dc=myorg,dc=com?one
    #nss_base_aliases ou=Aliases,dc=myorg,dc=com?one
    #nss_base_netgroup ou=Netgroup,dc=myorg,dc=com?one

    # OpenLDAP SSL mechanism
    # start_tls mechanism uses the normal LDAP port,
    # LDAPS typically 636
    ssl start_tls
    #ssl on

    # CA certificates for server certificate verification
    # At least one of these are required if tls_checkpeer is "yes"
    tls_cacertfile /opt/etc/openldap/certs/cacert.pem
    #tls_cacertdir /etc/ssl/certs

    # SSL cipher suite
    # See man ciphers for syntax
    #tls_ciphers TLSv1
    tls_ciphers HIGH

    # Client certificate and key
    # Use these, if your server requires client authentication.
    #tls_cert
    #tls_key
    The OpenLDAP ldap.conf file is considerably more simple.
    /opt/etc/openldap/ldap.conf:
    # $OpenLDAP: pkg/ldap/libraries/libldap/ldap.conf,v 1.9 2000/09/04 19:57:01 kurt Exp $
    #
    # LDAP Defaults
    #

    # See ldap.conf(5) for details
    # This file should be world readable but not world
    writable.

    BASE dc=myorg,dc=com
    HOST 127.0.0.1
    URI ldap://127.0.0.1:389

    #SIZELIMIT 12
    #TIMELIMIT 15
    #DEREF never

    TLS_REQCERT never
    TLS_CACERT /opt/etc/openldap/certs/cacert.pem

    I think that the requirement for 'TLS_REQCERT never' parameter may be a solaris idiosyncrasy. There were some remarks on the pam_ldap mailing list from solaris admins who couldn't get the openldap tools to successfully bind without it, and neither could I.


Start the Server and Populate It

  1. Start the server in debug mode
    As root, run the server in debug mode, so you can see what is happening as we begin to populate it:

    /opt/libexec/slapd -u ldap -g ldap -d 296

  2. Create the directory structure
    Type out your directory structure in LDIF format, and save it to a file, like "toplevel.ldif":

    dn: dc=myorg,dc=com
    objectclass: top
    objectclass: dcObject
    objectclass: nisDomainObject
    objectclass: organization
    dc: myorg
    o: My Organization
    nisDomain: myorg.com

    dn: cn=Manager,dc=myorg,dc=com
    objectclass: organizationalRole
    cn: Manager
    description: Directory Manager

    dn: cn=NonAnon,dc=myorg,dc=com
    objectclass: account
    objectclass: posixAccount
    description: Non-anonymous ldap binds
    cn: NonAnon
    uid: nonanon
    uidnumber: 1005
    gidnumber: 105
    homeDirectory: /var/empty
    userPassword: {CRYPT}jzbATAcaox.
    loginshell: /bin/false
    host: myldaphost.myorg.com

    dn: ou=People,dc=myorg,dc=com
    objectclass: organizationalUnit
    ou: People
    description: User Accounts

    dn: ou=Group,dc=myorg,dc=com
    objectclass: organizationalUnit
    ou: Group
    description: System Groups

    dn: ou=Hosts,dc=myorg,dc=com
    objectclass: organizationalUnit
    ou: Hosts
    description: Hosts
    Now add it to the server using ldapadd. Note that in Solaris 9, /usr/bin/ldapadd is probably in your path before openldap's version, so you may want to either adjust your PATH variable, or prepend the commands with their full pathnames.
    /opt/bin/ldapadd -Z -x -W -D "cn=Manager,dc=myorg,dc=com" -v -f toplevel.ldif

  3. Create and add a user account
    Again, create an ldif file, tailored to your needs.

    dn: uid=testuser,ou=People,dc=myorg,dc=com
    objectclass: account
    objectclass: posixAccount
    objectclass: shadowAccount
    objectclass: inetLocalMailRecipient
    cn: Test User
    uid: testuser
    userPassword: {crypt}s58TNiuL/tcM.
    loginShell: /usr/bin/bash
    uidnumber: 1001
    gidnumber: 500
    homeDirectory: /home/admin/testuser
    mailLocalAddress: testuser@myorg.com
    mailRoutingAddress: testuser@mailhost.myorg.com
    host: somehost.myorg.com
    host: someotherhost.myorg.com
    host: anotherhost.myorg.com
    shadowLastChange:12193
    shadowMin:0
    shadowMax:99999
    shadowWarning: 7
    shadowInactive: 1
    shadowExpire: 12999
    gecos: Test User
    I choose to use the {crypt} cipher since I'll be importing a large number of accounts from NIS+ tables, which are in crypt format already. {MD5} is probably a better choice if you're starting fresh. Add the data the same way:
    /opt/bin/ldapadd -Z -x -W -D "cn=Manager,dc=myorg,dc=com" -v -f person.ldif

  4. Test the new account
    Ensure that you can bind to and search the directory using the new account.

    /opt/bin/ldapsearch -Z -x -W -D "uid=testuser,ou=People,dc=myorg,dc=com" "(objectclass=*)"


Last Step!

  1. Start Name Service Caching Deamon
    The nscd is basically a necessity when using backend databases like LDAP or NIS for holding user data. If its not already running, start it:

    /etc/init.d/nscd start

  2. Modify PAM configuration
    It is always a good idea to keep a root shell open when changing /etc/pam.conf (or on some systems /etc/pam.d/*). Here is a /etc/pam.conf from solaris 9 (with the verbose comments removed):

    login auth requisite pam_authtok_get.so.1
    login auth required pam_dhkeys.so.1
    login auth sufficient pam_unix_auth.so.1
    login auth required /opt/lib/security/pam_ldap.so.1 try_first_pass
    login auth required pam_dial_auth.so.1
    #
    ## OpenSSH
    sshd auth sufficient pam_unix.so.1
    sshd auth required /opt/lib/security/pam_ldap.so.1 try_first_pass
    #
    # Default definitions for Authentication management
    # Used when service name is not explicitly mentioned for authenctication
    #
    other auth requisite pam_authtok_get.so.1
    other auth required pam_dhkeys.so.1
    other auth sufficient pam_unix_auth.so.1
    other auth required /opt/lib/security/pam_ldap.so.1 try_first_pass
    #
    # passwd command (explicit because of a different authentication module)
    #
    passwd auth required pam_passwd_auth.so.1
    passwd auth sufficient pam_unix_auth.so.1
    #
    # cron service (explicit because of non-usage of pam_roles.so.1)
    #
    cron account required pam_projects.so.1
    cron account required pam_unix_account.so.1
    #
    ## OpenSSH
    sshd account sufficient pam_unix.so.1
    sshd account required /opt/lib/security/pam_ldap.so.1 try_first_pass
    # # Default definition for Account management
    # Used when service name is not explicitly mentioned for account management
    #
    other account requisite pam_roles.so.1
    other account required pam_projects.so.1
    other account sufficient pam_unix_account.so.1
    other account required /opt/lib/security/pam_ldap.so.1 try_first_pass
    #
    # Default definition for Session management
    # Used when service name is not explicitly mentioned for session management
    #
    other session required pam_unix_session.so.1
    #
    # Default definition for Password management
    # Used when service name is not explicitly mentioned for password management
    #
    other password required pam_dhkeys.so.1
    other password requisite pam_authtok_get.so.1
    other password requisite pam_authtok_check.so.1
    other password required pam_authtok_store.so.1
    other password sufficient pam_unix.so.1
    other password required /opt/lib/security/pam_ldap.so try_first_pass

  3. Add ldap to /etc/nsswitch.conf
    Be sure to keep "files" in front of ldap in /etc/nsswitch.conf:

    passwd: files ldap
    group: files ldap

  4. Test, test, test -- that should be all.

Trouble Shooting

This section will be coming later.
  1. Directives in /opt/etc/openldap/ldap.conf seem to be ignored.
    Make sure the permissions are set so that the user executing the command (i.e., ldapsearch) can read it. Mode 0644 is fine for that file. For /opt/etc/ldap.conf, I use 0600, owned by user "ldap".





Contact Me My PGP Key


© Copyright 2003 Netmojo Systems