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.
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.
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
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'.
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
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"
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
Now that SASL is installed, we should update our build environment
to include it in our library path:
make ; su -c make install
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"
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
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
It is recommended in the SASL documentation that you add a symlink from your SASL2
installation directory to /usr/lib/sasl2:
make ; su -c make install
ln -s /opt/lib/sasl2 /usr/lib/sasl2
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
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.
make ; su -c make install
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
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
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
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 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
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.
/opt/ssl/misc/CA.pl -newca
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
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:
/opt/ssl/misc/CA.pl -signreq
mv newreq.pem myhost.slapd-key.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:
mv newcert.pem myhost.slapd-cert.pem
openssl rsa -in myhost.slapd-key.pem -out 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.
chmod 0400 myhost.slapd-key.pem
Install the Certificates
I'm going to put my SSL certs in /opt/etc/openldap/certs:
mkdir -m 0755 /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.
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
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
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!
chmod 640 /opt/etc/openldap/slapd.conf
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
You may need to edit some of these files if you have
special requirements for object class definitions.
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
Logging and misc settings
# Logging & Misc
OpenLDAP Logging levels are specified by adding integers
from the following table (this info is in the
slapd.conf(5) man page):
loglevel 296
pidfile /var/run/slapd/slapd.pid
argsfile /opt/etc/openldap/slapd.args
defaultsearchbase dc=myorg,dc=com
threads 400
password-hash {CRYPT}
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
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.
chmod 0600 /var/log/ldap
pkill -HUP syslogd
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
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.
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 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
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.
access to attrs=userPassword
by self write
by * auth
access to *
by users read
# by * read
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
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.
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
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
pam/nss_ldap runs with root priveleges, so we don't need to
worry about the file only being readable by the root user.
chmod 0600 /opt/etc/ldap.conf
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
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 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
host myhost.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'.
host myhost2.mydomain.com
host myhost5.mydomain.com
# Check the 'authorizedService' attribute for access
The OpenLDAP ldap.conf file is considerably more simple.
# 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
/opt/etc/openldap/ldap.conf:
# $OpenLDAP: pkg/ldap/libraries/libldap/ldap.conf,v 1.9 2000/09/04 19:57:01 kurt Exp $
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.
#
# 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
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
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
Create and add a user account
Again, create an ldif file, tailored to your needs.
dn: uid=testuser,ou=People,dc=myorg,dc=com
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:
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
/opt/bin/ldapadd -Z -x -W -D "cn=Manager,dc=myorg,dc=com" -v -f person.ldif
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=*)"
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
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
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
Test, test, test -- that should be all.
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 |
|