LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/guide/docbook/Linux-Networking/LDAP.xml

4398 lines
227 KiB
XML
Raw Blame History

<sect1 id="LDAP">
<title>LDAP</title>
Information about installing, configuring, running and maintaining a LDAP
(Lightweight Directory Access Protocol) Server on a Linux machine is
presented on this section. This section also presents details about how to
create LDAP databases, how to add, how to update and how to delete
information on the directory. This paper is mostly based on the University of
Michigan LDAP information pages and on the OpenLDAP Administrator's Guide.
-----------------------------------------------------------------------------
Chapter 1. Introduction
The main purpose of this document is to set up and use a LDAP Directory
Server on your Linux machine.You will learn how to install, configure, run
and maintain the LDAP server. After you also learn how you can store,
retrieve and update information on your Directory using the LDAP clients and
utilities. The daemon for the LDAP directory server is called slapd and it
runs on many different UNIX platforms.
There is another daemon that cares for replication between LDAP servers. It's
called slurpd and for the moment you don't need to worry about it. In this
document you will run a slapd which provides directory service for your local
domain only, without replication, so without slurpd. Complete information
about replication is available at: OpenLDAP Administrator's Guide
The local domain setup represents a simple choice for configuring your
server, good for starting and easy to upgrade to another configuration later
if you want. The information presented on this document represents a nice
initialization on using the LDAP server. Possibly after reading this document
you will feel encouraged to expand the capabilities of your server and even
write your own clients, using the already available C, C++ and Java
Development Kits.
-----------------------------------------------------------------------------
1.1. What's LDAP ?
LDAP stands for Lightweight Directory Access Protocol. As the name suggests,
it is a lightweight client-server protocol for accessing directory services,
specifically X.500-based directory services. LDAP runs over TCP/IP or other
connection oriented transfer services. LDAP is defined in [ftp://ftp.isi.edu/
in-notes/rfc2251.txt] RFC2251 "The Lightweight Directory Access Protocol
(v3).
A directory is similar to a database, but tends to contain more descriptive,
attribute-based information. The information in a directory is generally read
much more often than it is written. Directories are tuned to give
quick-response to high-volume lookup or search operations. They may have the
ability to replicate information widely in order to increase availability and
reliability, while reducing response time. When directory information is
replicated, temporary inconsistencies between the replicas may be OK, as long
as they get in sync eventually.
There are many different ways to provide a directory service. Different
methods allow different kinds of information to be stored in the directory,
place different requirements on how that information can be referenced,
queried and updated, how it is protected from unauthorized access, etc. Some
directory services are local, providing service to a restricted context
(e.g., the finger service on a single machine). Other services are global,
providing service to a much broader context.
-----------------------------------------------------------------------------
1.2. How does LDAP work ?
LDAP directory service is based on a client-server model. One or more LDAP
servers contain the data making up the LDAP directory tree or LDAP backend
database. An LDAP client connects to an LDAP server and asks it a question.
The server responds with the answer, or with a pointer to where the client
can get more information (typically, another LDAP server). No matter what
LDAP server a client connects to, it sees the same view of the directory; a
name presented to one LDAP server references the same entry it would at
another LDAP server. This is an important feature of a global directory
service, like LDAP.
-----------------------------------------------------------------------------
1.3. LDAP backends, objects and attributes
The LDAP server daemon is called Slapd. Slapd supports a variety of different
database backends which you can use.
They include the primary choice BDB, a high-performance transactional
database backend; LDBM, a lightweight DBM based backend; SHELL, a backend
interface to arbitrary shell scripts and PASSWD, a simple backend interface
to the passwd(5) file.
BDB utilizes [http://www.sleepycat.com/] Sleepycat Berkeley DB 4. LDBM
utilizes either [http://www.sleepycat.com/] Berkeley DB or [http://
www.gnu.org/software/gdbm/] GDBM.
BDB transactional backend is suited for multi-user read/write database
access, with any mix of read and write operations. BDB is used in
applications that require:
<EFBFBD><EFBFBD>*<2A>Transactions, including making multiple changes to the database
atomically and rolling back uncommitted changes when necessary.
<EFBFBD><EFBFBD>*<2A>Ability to recover from systems crashes and hardware failures without
losing any committed transactions.
In this document I assume that you choose the BDB database.
To import and export directory information between LDAP-based directory
servers, or to describe a set of changes which are to be applied to a
directory, the file format known as LDIF, for LDAP Data Interchange Format,
is typically used. A LDIF file stores information in object-oriented
hierarchies of entries. The LDAP software package you're going to get comes
with an utility to convert LDIF files to the BDB format
A common LDIF file looks like this:
dn: o=TUDelft, c=NL
o: TUDelft
objectclass: organization
dn: cn=Luiz Malere, o=TUDelft, c=NL
cn: Luiz Malere
sn: Malere
mail: malere@yahoo.com
objectclass: person
As you can see each entry is uniquely identified by a distinguished name, or
DN. The DN consists of the name of the entry plus a path of names tracing the
entry back to the top of the directory hierarchy (just like a tree).
In LDAP, an object class defines the collection of attributes that can be
used to define an entry. The LDAP standard provides these basic types of
object classes:
<EFBFBD><EFBFBD>*<2A>Groups in the directory, including unordered lists of individual objects
or groups of objects.
<EFBFBD><EFBFBD>*<2A>Locations, such as the country name and description.
<EFBFBD><EFBFBD>*<2A>Organizations in the directory.
<EFBFBD><EFBFBD>*<2A>People in the directory.
An entry can belong to more than one object class. For example, the entry for
a person is defined by the person object class, but may also be defined by
attributes in the inetOrgPerson, groupOfNames, and organization
objectclasses. The server's object class structure (it's schema) determines
the total list of required and allowed attributes for a particular entry.
Directory data is represented as attribute-value pairs. Any specific piece of
information is associated with a descriptive attribute.
For instance, the commonName, or cn, attribute is used to store a person's
name . A person named Jonas Salk can be represented in the directory as
cn: Jonas Salk
Each person entered in the directory is defined by the collection of
attributes in the person object class. Other attributes used to define this
entry could include:
givenname: Jonas
surname: Salk
mail: jonass@airius.com
Required attributes include the attributes that must be present in entries
using the object class. All entries require the objectClass attribute, which
lists the object classes to which an entry belongs.
Allowed attributes include the attributes that may be present in entries
using the object class. For example, in the person object class, the cn and
sn attributes are required. The description, telephoneNumber, seeAlso, and
userpassword attributes are allowed but are not required.
Each attribute has a corresponding syntax definition. The syntax definition
describes the type of information provided by the attribute, for instance:
<EFBFBD><EFBFBD>*<2A>bin binary.
<EFBFBD><EFBFBD>*<2A>ces case exact string (case must match during comparisons).
<EFBFBD><EFBFBD>*<2A>cis case ignore string (case is ignored during comparisons).
<EFBFBD><EFBFBD>*<2A>tel telephone number string (like cis but blanks and dashes `- ' are
ignored during comparisons).
<EFBFBD><EFBFBD>*<2A>dn distinguished name.
Note: Usually objectclass and attribute definitions reside on schema files,
on the subdirectory schema under the OpenLDAP installation home.
-----------------------------------------------------------------------------
1.4. New versions of this document
This document may receive corrections and updates based on the feedback
received by the readers. You should look at:
[http://www.tldp.org/HOWTO/LDAP-HOWTO.html] http://www.tldp.org/HOWTO/
LDAP-HOWTO.html
for new versions of this HOWTO.
-----------------------------------------------------------------------------
1.5. Opinions and Sugestions
If you have any kind of doubt about some information avaiable on this
document, please contact me on the following email address:
[malere@yahoo.com] malere@yahoo.com
If you have commentaries and/or sugestions, please let me know too!
-----------------------------------------------------------------------------
1.6. Acknowledgments
This Howto was result of an internship made by me on the TUDelft University -
Netherlands. I would like to thank the persons that encouraged me to write
this document: Rene van Leuken and Wim Tiwon. Thank you very much. They are
also Linux fans, just like me.
I would like to thank also Thomas Bendler, author of the German Ldap-Howto,
for his contributions to my document and Joshua Go, great volunteer on the
LDP project.
Karl Lattimer deserves a prize, for his great contribution on SASL related
issues.
And thanks my Lord!
-----------------------------------------------------------------------------
1.7. Copyright and Disclaimer
Copyright (c) 1999 Luiz Ernesto Pinheiro Mal<61>re. Permission is granted to
copy, distribute and/or modify this document under the terms of the GNU Free
Documentation License, Version 1.1 or any later version published by the Free
Software Foundation; with no Invariant Sections, with no Front-Cover Texts
and with no Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
If you have questions, please visit the following url: [http://www.gnu.org/
licenses/fdl.txt] http://www.gnu.org/licenses/fdl.txt and contact the Linux
HOWTO coordinator, at: [guylhem@metalab.unc.edu] guylhem@metalab.unc.edu
-----------------------------------------------------------------------------
Chapter 2. Installing the LDAP Server
Five steps are necessary to install the server:
<EFBFBD><EFBFBD>*<2A>Install the pre-required packages (if not already installed).
<EFBFBD><EFBFBD>*<2A>Download the server.
<EFBFBD><EFBFBD>*<2A>Unpack the software.
<EFBFBD><EFBFBD>*<2A>Configure the Makefiles.
<EFBFBD><EFBFBD>*<2A>Build the server.
-----------------------------------------------------------------------------
2.1. Pre-Requirements
To be fully LDAPv3 compliant, OpenLDAP clients and servers require
installation of some additional packages. For writing this document, I've
used a Mandrake 9.0 box with a 2.4.20 Kernel, manually installing the
Berkeley BDB package and SASL libraries.
OpenSSL TLS Libraries
The OpenSSL TLS libraries are normally part of the base system or compose an
optional software component. The official OpenSSL url is: [http://
www.openssl.org] http://www.openssl.org
Kerberos Authentication Services
OpenLDAP clients and servers support Kerberos-based authentication services.
In particular, OpenLDAP supports SASL/GSSAPI authentication mechanism using
either Heimdal or MIT Kerberos V packages. If you desire to use
Kerberos-based SASL/GSSAPI authentication, you should install either Heimdal
or MIT Kerberos V. Heimdal Kerberos is available from [http://www.pdc.kth.se/
heimdal] http://www.pdc.kth.se/heimdal MIT Kerberos is available from [http:/
/web.mit.edu/kerberos/www] http://web.mit.edu/kerberos/www
The use of strong authentication services, such as those provided by
Kerberos, is highly recommended.
Cyrus's Simple Authentication and Security Layer Libraries
Cyrus's SASL libraries are normally part of the base system or compose an
optional software component. Cyrus SASL is available from [http://
asg.web.cmu.edu/sasl/sasl-library.html] http://asg.web.cmu.edu/sasl/
sasl-library.html. Cyrus SASL will make use of OpenSSL and Kerberos/GSSAPI
libraries if preinstalled. By the time of this writing, I've used Cyrus SASL
2.1.17.
Database Software
Slapd's primary database backend, BDB, requires [http://www.sleepycat.com]
Sleepycat Software Berkeley DB, version 4. If not available at configure
time, you will not be able to build slapd with primary database backend.
Your operating system may provide Berkeley DB, version 4, in the base system
or as an optional software component. If not, there are several versions
available at [http://www.sleepycat.com/download.html] Sleepycat. At the time
of this writing, the latest release, version 4.2.52, is recommended.
OpenLDAP's slapd LDBM backend supports a variety of database managers, like
Berkeley DB (version 3) and GDBM. GDBM is available from [http://www.fsf.org
/] FSF's download site [ftp://ftp.gnu.org/pub/gnu/gdbm/] ftp://ftp.gnu.org/
pub/gnu/gdbm/.
Threads
Threads support are almost guaranteed to be part of your base Linux system.
OpenLDAP is designed to take advantage of threads. OpenLDAP supports POSIX
pthreads, Mach CThreads, and a number of other varieties. The configure
script will complain if it cannot find a suitable thread subsystem. If this
occurs, please consult the Software - Installation - Platform Hints section
of the OpenLDAP FAQ: [http://www.openldap.org/faq/] http://www.openldap.org/
faq/.
TCP Wrappers
Slapd supports TCP wrappers (IP level access control filters) if
preinstalled. Use of TCP wrappers or other IP-level access filters (such as
those provided by an IP-level firewall) is recommended for servers containing
non-public information.
-----------------------------------------------------------------------------
2.2. Downloading the Package
There are two free distributed LDAP servers: University of Michigan LDAP
server and OpenLDAP server. There's also the Netscape Directory Server, which
is free only under some conditions (educational institutions get it free, for
example). The OpenLDAP server is based on the latest version of the
University of Michigan Server and there are mailing lists and additional
documentation available for it. This document assumes that you are using the
OpenLDAP server.
It's latest tar gzipped version is avaiable on the following address:
[http://www.openldap.org] http://www.openldap.org
If you want to get the latest version of University of Michigan Server, go to
this address:
[ftp://terminator.rs.itd.umich.edu/ldap] ftp://terminator.rs.itd.umich.edu/
ldap
To write this document, I used the 2.2.5 version of the OpenLDAP package. My
operating system is a Mandrake Linux 9.0 with kernel 2.4.20.
On the OpenLDAP site you can always find the latest development and stable
versions of the OpenLDAP server. By the time this document was updated, the
latest stable version was openldap-stable-20031217.tgz (version 2.1.25). The
latest development version was also openldap-2.2.5.tgz.
-----------------------------------------------------------------------------
2.3. Unpacking the Software
Now that you have the tar gzipped package on your local machine, you can
unpack it.
First copy the package to a desirable directory, for example /usr/local. Next
use the following command:
tar xvzf openldap-2.2.5.tgz
You can use this command too, as well:
gunzip openldap-2.2.5.tgz | tar xvf -
-----------------------------------------------------------------------------
2.4. Configuring the Software
The OpenLDAP server sources are distributed with a configuration script for
setting options like installation directories, compiler and linker flags.
Type the following command on the directory where you unpacked the software:
./configure --help
This will print all options that you can customize with the configure script
before you build the software. Some usefull options are --prefix=pref ,
--exec-prefix=eprefix and --bindir=dir, for setting instalation directories.
Normally if you run configure without options, it will auto-detect the
appropriate settings and prepare to build things on the default common
location. So just type:
./configure
And watch the output to see if all went well
Tip: Sometimes you need to pass specific options to your configure script,
like for example --with-tls (for enabling slapd to use a secure channel:
LDAPS://). In this case, you might have your SSL/TLS libraries residing on a
non-standard directory of your system. You can make the configure script
aware of the libraries location changing you environment with the env
command. Example: suppose you've installed the openssl package under /usr/
local/openssl. The following command will build slapd with SSL/TLS support:
env CPPFLAGS=-I/usr/local/openssl/include \
LDFLAGS=-L/usr/local/openssl/lib \
configure --with-tls ...
You can specify the following environment variables with the env command
before the configure script:
<EFBFBD><EFBFBD>*<2A>CC: Specify alternative C Compiler.
<EFBFBD><EFBFBD>*<2A>CFLAGS: Specify additional compiler flags.
<EFBFBD><EFBFBD>*<2A>CPPFLAGS: Specify C Preprocessor flags.
<EFBFBD><EFBFBD>*<2A>LDFLAGS: Specify linker flags.
<EFBFBD><EFBFBD>*<2A>LIBS: Specify additional libraries.
-----------------------------------------------------------------------------
2.5. Building the Server
After configuring the software you can start building it. First build the
dependencies, using the command:
make depend
Build the server after that, using the command:
make
If all goes well, the server will build as configured. If not, return to the
previous step to review the configuration settings. You should read the
INSTALL and README files located in the directory where you unpacked the
software. Also, check the configure script specific hints, they are located
in the path doc/install/configure under the directory you unpacked the
software.
To ensure a correct build, you should run the test suite (it only takes a few
minutes):
make test
Tests which apply to your configuration will run and they should pass. Some
tests, such as the replication test, may be skipped.
Now install the binaries and man pages. You may need to be superuser to do
this (depending on where you are installing things):
su root -c 'make install'
That's all, now you have the binary of the server and the binaries of several
other utilities. Go to the Chapter 3 section to see how to configure the
operation of your LDAP server.
-----------------------------------------------------------------------------
Chapter 3. Configuring the LDAP Server
Once the software has been installed and built, you are ready to configure it
for use at your site. All slapd runtime configuration is accomplished through
the slapd.conf file, installed in the prefix directory you specified in the
configuration script or by default in /usr/local/etc/openldap.
This section details the commonly used configuration directives in
slapd.conf. For a complete list, see the slapd.conf(5) manual page. The
configuration file directives are separated into global, backend specific and
database specific. Here you will find descriptions of directives, together
with their default values (if any) and examples of use.
-----------------------------------------------------------------------------
3.1. Configuration File Format
The slapd.conf file consists of three types of configuration information:
global, backend specific, and database specific. Global information is
specified first, followed by information associated with a particular backend
type, which is then followed by information associated with a particular
database instance.
Global directives can be overridden in a backend and/or database directives,
backend directives can be overridden by database directives.
Blank lines and comment lines beginning with a '#' character are ignored. If
a line begins with white space, it is considered a continuation of the
previous line (even if the previous line is a comment). The general format of
slapd.conf is as follows:
# global configuration directives
<global config directives>
# backend definition
backend <typeA>
<backend-specific directives>
# first database definition & config directives
database <typeA>
<database-specific directives>
# second database definition & config directives
database <typeB>
<database-specific directives>
# second "typeA" database definition & config directives
database <typeA>
<database-specific directives>
# subsequent backend & database definitions & config directives
...
A configuration directive may take arguments. If so, they are separated by
white space. If an argument contains white space, the argument should be
enclosed in double quotes "like this". If an argument contains a double quote
or a backslash character `\', the character should be preceded by a backslash
character `\'.
The distribution contains an example configuration file that will be
installed in the /usr/local/etc/openldap directory. A number of files
containing schema definitions (attribute types and object classes) are also
provided in the /usr/local/etc/openldap/schema directory.
-----------------------------------------------------------------------------
3.2. Global Directives
Directives described in this section apply to all backends and databases
unless specifically overridden in a backend or database definition. Arguments
that should be replaced by actual text are shown in brackets <>.
access to <what> [ by <who> <accesslevel> <control> ]+
This directive grants access (specified by <accesslevel>) to a set of entries
and/or attributes (specified by <what>) by one or more requesters (specified
by <who>). See the Section 3.7 examples for more details.
Important: If no access directives are specified, the default access control
policy, access to * by * read, allows all both authenticated and anonymous
users read access.
attributetype <RFC2252 Attribute Type Description>
This directive defines an attribute type. Check the following URL for more
details: [http://www.openldap.org/doc/admin22/schema.html] Schema
Specification
idletimeout <integer>
Specify the number of seconds to wait before forcibly closing an idle client
connection. An idletimeout of 0, the default, disables this feature.
include <filename>
This directive specifies that slapd should read additional configuration
information from the given file before continuing with the next line of the
current file. The included file should follow the normal slapd config file
format. The file is commonly used to include files containing schema
specifications.
Note:You should be careful when using this directive - there is no small
limit on the number of nested include directives, and no loop detection is
done.
loglevel <integer>
This directive specifies the level at which debugging statements and
operation statistics should be syslogged (currently logged to the syslogd(8)
LOCAL4 facility). You must have configured OpenLDAP --enable-debug (the
default) for this to work (except for the two statistics levels, which are
always enabled). Log levels are additive. To display what numbers correspond
to what kind of debugging, invoke slapd with -? or consult the table below.
The possible values for <integer> are:
Table 3-1. Debugging Levels
+-----+-----------------------------------------+
|Level|Description |
+-----+-----------------------------------------+
|-1 |enable all debugging |
+-----+-----------------------------------------+
|0 |no debugging |
+-----+-----------------------------------------+
|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 |
+-----+-----------------------------------------+
|2048 |print entry parsing debugging |
+-----+-----------------------------------------+
Example:
loglevel 255 or loglevel -1
This will cause lots and lots of debugging information to be syslogged.
Default:
loglevel 256
objectclass <RFC2252 Object Class Description>
This directive defines an object class. Check the following URL for more
details: [http://www.openldap.org/doc/admin22/schema.html] Schema
Specification
referral <URI>
This directive specifies the referral to pass back when slapd cannot find a
local database to handle a request.
Example:
referral ldap://root.openldap.org
This will refer non-local queries to the global root LDAP server at the
OpenLDAP Project. Smart LDAP clients can re-ask their query at that server,
but note that most of these clients are only going to know how to handle
simple LDAP URLs that contain a host part and optionally a distinguished name
part.
sizelimit <integer>
This directive specifies the maximum number of entries to return from a
search operation.
Default:
sizelimit 500
timelimit <integer>
This directive specifies the maximum number of seconds (in real time) slapd
will spend answering a search request. If a request is not finished in this
time, a result indicating an exceeded timelimit will be returned.
Default:
timelimit 3600
-----------------------------------------------------------------------------
3.3. General Backend Directives
Directives in this section apply only to the backend in which they are
defined. They are supported by every type of backend. Backend directives
apply to all databases instances of the same type and, depending on the
directive, may be overridden by database directives.
backend <type>
This directive marks the beginning of a backend definition. <type> should be
one of bdb or one of other supported backend types listed below:
Table 3-2. Database Backends
+-------+------------------------------------------------------+
|Type |Description |
+-------+------------------------------------------------------+
|bdb |Berkeley DB transactional backend |
+-------+------------------------------------------------------+
|dnssrv |DNS SRV backend |
+-------+------------------------------------------------------+
|ldbm |Lightweight DBM backend |
+-------+------------------------------------------------------+
|ldap |Lightweight Directory Access Protocol (Proxy) backend |
+-------+------------------------------------------------------+
|meta |Meta Directory backend |
+-------+------------------------------------------------------+
|monitor|Monitor backend |
+-------+------------------------------------------------------+
|passwd |Provides read-only access to passwd(5) |
+-------+------------------------------------------------------+
|perl |Perl programmable backend |
+-------+------------------------------------------------------+
|shell |Shell (external program) backend |
+-------+------------------------------------------------------+
|sql |SQL programmable backend |
+-------+------------------------------------------------------+
Example:
backend bdb
This marks the beginning of a new BDB backend definition
-----------------------------------------------------------------------------
3.4. General Database Directives
Directives in this section apply only to the database in which they are
defined. They are supported by every type of database.
database <type>
This directive marks the beginning of a new database instance definition. <
type> should be one of the backend types listed on the previous item.
Example:
database bdb
This marks the beginning of a new BDB backend database instance definition.
readonly { on | off }
This directive puts the database into "read-only" mode. Any attempts to
modify the database will return an "unwilling to perform" error.
Default:
readonly off
replica uri=ldap[s]://<hostname>[:<port>] | host=<hostname>[:<port>]
[bindmethod={simple|kerberos|sasl}]
["binddn=<DN>"]
[saslmech=<mech>]
[authcid=<identity>]
[authzid=<identity>]
[credentials=<password>]
[srvtab=<filename>]
This directive specifies a replication site for this database. The uri=
parameter specifies a scheme, a host and optionally a port where the slave
slapd instance can be found. Either a domain name or IP address may be used
for <hostname>. If <port> is not given, the standard LDAP port number (389 or
636) is used.
Note: host is deprecated in favor of the uri parameter.
uri allows the replica LDAP server to be specified as an LDAP URI such as
ldap://slave.example.com:389 or ldaps://slave.example.com:636
The binddn= parameter gives the DN to bind as for updates to the slave slapd.
It should be a DN which has read/write access to the slave slapd's database.
It must also match the updatedn directive in the slave slapd's config file.
Generally, this DN should not be the same as the rootdn of the master
database. Since DNs are likely to contain embedded spaces, the entire "binddn
=<DN>" string should be enclosed in double quotes.
The bindmethod is simple or kerberos or sasl, depending on whether simple
password-based authentication or Kerberos authentication or SASL
authentication is to be used when connecting to the slave slapd.
Simple authentication should not be used unless adequate integrity and
privacy protections are in place (e.g. TLS or IPSEC). Simple authentication
requires specification of binddn and credentials parameters.
Kerberos authentication is deprecated in favor of SASL authentication
mechanisms, in particular the KERBEROS_V4 and GSSAPI mechanisms. Kerberos
authentication requires binddn and srvtab parameters.
SASL authentication is generally recommended. SASL authentication requires
specification of a mechanism using the saslmech parameter. Depending on the
mechanism, an authentication identity and/or credentials can be specified
using authcid and credentials respectively. The authzid parameter may be used
to specify an authorization identity.
Check this URL for additional details: [http://www.openldap.org/doc/admin22/
replication.html] Replication with Slurpd.
replogfile <filename>
This directive specifies the name of the replication log file to which slapd
will log changes. The replication log is typically written by slapd and read
by slurpd. Normally, this directive is only used if slurpd is being used to
replicate the database. However, you can also use it to generate a
transaction log, if slurpd is not running. In this case, you will need to
periodically truncate the file, since it will grow indefinitely otherwise.
Check this URL for additional details: [http://www.openldap.org/doc/admin22/
replication.html] Replication with Slurpd.
rootdn <dn>
This directive specifies the DN that is not subject to access control or
administrative limit restrictions for operations on this database. The DN
need not refer to an entry in the directory. The DN may refer to a SASL
identity.
Entry-based Example:
rootdn "cn=Manager, dc=example, dc=com"
SASL-based Example:
rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
rootpw <password>
This directive can be used to specify a password for the rootdn (when the
rootdn is set to a DN within the database).
Example:
rootpw secret
It is also permissible to provide hash of the password in RFC 2307 form.
slappasswd may be used to generate the password hash.
Example:
rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
The hash was generated using the command slappasswd -s secret.
suffix <dn suffix>
This directive specifies the DN suffix of queries that will be passed to this
backend database. Multiple suffix lines can be given, and at least one is
required for each database definition.
Example:
suffix "dc=example, dc=com"
Queries with a DN ending in "dc=example, dc=com" will be passed to this
backend.
Note: When the backend to pass a query to is selected, slapd looks at the
suffix line(s) in each database definition in the order they appear in the
file. Thus, if one database suffix is a prefix of another, it must appear
after it in the config file.
syncrepl
This directive is used to keep a replicated database synchronized with the
master database, so that the replicated database content will be kept up to
date with the master content.
This document doesn't cover in details this directive, because we're
configuring a single LDAP Server. For more informations about this directive,
please visit : [http://www.openldap.org/doc/admin22/syncrepl.html] LDAP Sync
Replication.
updatedn <dn>
This directive is only applicable in a slave slapd. It specifies the DN
allowed to make changes to the replica. This may be the DN slurpd binds as
when making changes to the replica or the DN associated with a SASL identity.
Entry-based Example:
updatedn "cn=Update Daemon, dc=example, dc=com"
SASL-based Example:
updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
Check this URL for additional details: [http://www.openldap.org/doc/admin22/
replication.html] Replication with Slurpd.
updateref <URL>
This directive is only applicable in a slave slapd. It specifies the URL to
return to clients which submit update requests upon the replica. If specified
multiple times, each URL is provided.
Example:
updateref ldap://master.example.net
-----------------------------------------------------------------------------
3.5. BDB Database Directives
Directives in this category only apply a BDB database. That is, they must
follow a "database bdb" line and come before any subsequent "backend" or
"database" line. For a complete reference of BDB configuration directives,
see the slapd-bdb manpages (man slapd-bdb).
directory <directory>
This directive specifies the directory where the BDB files containing the
database and associated indexes reside.
Default:
directory /usr/local/var/openldap-data
sessionlog <sid> <limit>
This directive specifies a session log store in the syncrepl replication
provider server which contains information on the entries that have been
scoped out of the replication content identified by <sid>. The first syncrepl
search request having the same <sid> value in the cookie establishes the
session log store in the provider server. The number of the entries in the
session log store is limited by <limit>. Excessive entries are removed from
the store in the FIFO order. Both <sid> and <limit> are non-negative
integers. <sid> has no more than three decimal digits.
The LDAP Content Synchronization operation that falls into a pre-existing
session can use the session log store in order to reduce the amount of
synchronization traffic. If the replica is not so outdated that it can be
made up-to-date by the information in the session store, the provider slapd
will send the consumer slapd the identities of the scoped-out entries
together with the in-scope entries added to or modified within the
replication content. If the replica status is outdated too much and beyond
the coverage of the history store, then the provider slapd will send the
identities of the unchanged in-scope entries along with the changed in-scope
entries. The consumer slapd will then remove those entries in the replica
which are not identified as present in the provider content.
For more informations about syncrepl, please visit : [http://www.openldap.org
/doc/admin22/syncrepl.html] LDAP Sync Replication.
-----------------------------------------------------------------------------
3.6. LDBM Database Directives
Directives in this category only apply to the LDBM backend database. That is,
they must follow a "database ldbm" line and come before any other "database"
or "backend" line. For a complete reference of LDBM configuration directives,
see the slapd-ldbm manpages (man slapd-ldbm).
cachesize <integer>
This directive specifies the size in entries of the in-memory cache
maintained by the LDBM backend database instance.
Default:
cachesize 1000
dbcachesize <integer>
This directive specifies the size in bytes of the in-memory cache associated
with each open index file. If not supported by the underlying database
method, this directive is ignored without comment. Increasing this number
uses more memory but can cause a dramatic performance increase, especially
during modifies or when building indexes.
Default:
dbcachesize 100000
dbnolocking
This option, if present, disables database locking. Enabling this option may
improve performance at the expense of data security.
dbnosync
This option causes on-disk database contents not to be immediately
synchronized with in memory changes upon change. Enabling this option may
improve performance at the expense of data security.
directory <directory>
This directive specifies the directory where the LDBM files containing the
database and associated indexes live.
Default:
directory /usr/local/var/openldap-data
index {<attrlist> | default} [pres,eq,approx,sub,none]
This directive specifies the indexes to maintain for the given attribute. If
only an <attrlist> is given, the default indexes are maintained.
Example:
index default pres,eq
index uid
index cn,sn pres,eq,sub
index objectClass eq
The first line sets the default set of indexes to maintain to present and
equality. The second line causes the default (pres,eq) set of indices to be
maintained for the uid attribute type. The third line causes present,
equality and substring indices to be maintained for cn and sn attribute
types. The fourth line causes an equality index for the objectClass attribute
type.
By default, no indices are maintained. It is generally advised that minimally
an equality index upon objectClass be maintained.
index objectClass eq
mode <integer>
This directive specifies the file protection mode that newly created database
index files should have.
Default:
mode 0600
-----------------------------------------------------------------------------
3.7. Access Control Examples
The access control facility provided by the access directive is quite
powerful. This section shows some examples of it's use. First, some simple
examples:
access to * by * read
This access directive grants read access to everyone.
The following example shows the use of a regular expression to select the
entries by DN in two access directives where ordering is significant.
access to dn=".*, o=U of M, c=US"
by * search
access to dn=".*, c=US"
by * read
Read access is granted to entries under the c=US subtree, except for those
entries under the "o=U of M, c=US" subtree, to which search access is
granted. No access is granted to c=US as neither access directive matches
this DN.If the order of these access directives was reversed, the
U-M-specific directive would never be matched, since all U-M entries are also
c=US entries.
Another way to implement the same access controls is:
access to dn.children="dc=example,dc=com"
by * search
access to dn.children="dc=com"
by * read
Read access is granted to entries under the dc=com subtree, except for those
entries under the dc=example,dc=com subtree, to which search access is
granted. No access is granted to dc=com as neither access directive matches
this DN. If the order of these access directives was reversed, the trailing
directive would never be reached, since all entries under dc=example,dc=com
are also under dc=com entries.
Note: Also note that if no access to directive or no "by <who>" clause
matches, access is denied. That is, every access to directive ends with an
implicit by * none clause and every access list ends with an implicit access
to * by * none directive.
The next example again shows the importance of ordering, both of the access
directives and the "by <who>" clauses. It also shows the use of an attribute
selector to grant access to a specific attribute and various <who> selectors.
access to dn.subtree="dc=example,dc=com" attr=homePhone
by self write
by dn.children=dc=example,dc=com" search
by peername=IP:10\..+ read
access to dn.subtree="dc=example,dc=com"
by self write
by dn.children="dc=example,dc=com" search
by anonymous auth
This example applies to entries in the "dc=example,dc=com" subtree. To all
attributes except homePhone, an entry can write to itself, entries under
example.com entries can search by them, anybody else has no access (implicit
by * none) excepting for authentication/authorization (which is always done
anonymously). The homePhone attribute is writable by the entry, searchable by
entries under example.com, readable by clients connecting from network 10,
and otherwise not readable (implicit by * none). All other access is denied
by the implicit access to * by * none.
Sometimes it is useful to permit a particular DN to add or remove itself from
an attribute. For example, if you would like to create a group and allow
people to add and remove only their own DN from the member attribute, you
could accomplish it with an access directive like this:
access to attr=member,entry
by dnattr=member selfwrite
The dnattr <who> selector says that the access applies to entries listed in
the member attribute. The selfwrite access selector says that such members
can only add or delete their own DN from the attribute, not other values. The
addition of the entry attribute is required because access to the entry is
required to access any of the entry's attributes.
There's plenty of information about Access Control on the OpenLDAP
Administrator's Guide. Take a look at: [http://www.openldap.org/doc/admin22/
slapdconfig.html#Access Control] Access Control for more information about
this subject.
-----------------------------------------------------------------------------
3.8. Configuration File Example
The following is an example configuration file, interspersed with explanatory
text. It defines two databases to handle different parts of the X.500 tree;
both are BDB database instances. The line numbers shown are provided for
reference only and are not included in the actual file. First, the global
configuration section:
1. # example config file - global configuration section
2. include /usr/local/etc/schema/core.schema
3. referral ldap://root.openldap.org
4. access to * by * read
Line 1 is a comment. Line 2 includes another config file which contains core
schema definitions. The referral directive on line 3 means that queries not
local to one of the databases defined below will be referred to the LDAP
server running on the standard port (389) at the host root.openldap.org.
Line 4 is a global access control. It applies to all entries (after any
applicable database-specific access controls).
The next section of the configuration file defines a BDB backend that will
handle queries for things in the "dc=example,dc=com" portion of the tree. The
database is to be replicated to two slave slapds, one on truelies, the other
on judgmentday. Indexes are to be maintained for several attributes, and the
userPassword attribute is to be protected from unauthorized access.
5. # BDB definition for the example.com
6. database bdb
7. suffix "dc=example,dc=com"
8. directory /usr/local/var/openldap-data
9. rootdn "cn=Manager,dc=example,dc=com"
10. rootpw secret
11. # replication directives
12. replogfile /usr/local/var/openldap/slapd.replog
13. replica uri=ldap://slave1.example.com:389
14. binddn="cn=Replicator,dc=example,dc=com"
15. bindmethod=simple credentials=secret
16. replica uri=ldaps://slave2.example.com:636
17. binddn="cn=Replicator,dc=example,dc=com"
18. bindmethod=simple credentials=secret
19. # indexed attribute definitions
20. index uid pres,eq
21. index cn,sn,uid pres,eq,sub
22. index objectClass eq
23. # database access control definitions
24. access to attr=userPassword
25. by self write
26. by anonymous auth
27. by dn.base="cn=Admin,dc=example,dc=com" write
28. by * none
29. access to *
30. by self write
31. by dn.base="cn=Admin,dc=example,dc=com" write
32. by * read
Line 5 is a comment. The start of the database definition is marked by the
database keyword on line 6. Line 7 specifies the DN suffix for queries to
pass to this database. Line 8 specifies the directory in which the database
files will live.
Lines 9 and 10 identify the database "super user" entry and associated
password. This entry is not subject to access control or size or time limit
restrictions. Please remeber to encrypt the rootpw using slappasswd.
Example: rootpw {SSHA}Jq4xhhkGa7weT/0xKmaecT4HEXsdqiYA
Lines 11 through 18 are for replication. See the [http://www.openldap.org/doc
/admin22/replication.html] Replication link for more information on these
directives.
Lines 20 through 22 indicate the indexes to maintain for various attributes.
Lines 24 through 32 specify access control for entries in the this database.
As this is the first database, the controls also apply to entries not held in
any database (such as the Root DSE). For all applicable entries, the
userPassword attribute is writable by the entry itself and by the "admin"
entry. It may be used for authentication/authorization purposes, but is
otherwise not readable. All other attributes are writable by the entry and
the "admin" entry, but may be read by all users (authenticated or not).
The next section of the example configuration file defines another BDB
database. This one handles queries involving the dc=example,dc=net subtree
but is managed by the same entity as the first database. Note that without
line 39, the read access would be allowed due to the global access rule at
line 4.
33. # BDB definition for example.net
34. database bdb
35. suffix "dc=example,dc=net"
36. directory /usr/local/var/openldap-data-net
37. rootdn "cn=Manager,dc=example,dc=com"
38. index objectClass eq
39. access to * by users read
-----------------------------------------------------------------------------
Chapter 4. Running the LDAP Server
The LDAP daemon slapd is designed to be run as a stand-alone server. This
allows the server to take advantage of caching, manage concurrency issues
with underlying databases, and conserve system resources. Running from inetd
(8) is not an option.
-----------------------------------------------------------------------------
4.1. Command Line Options
Slapd supports a number of command-line options as detailed in the manual
page. This section details a few commonly used options:
-f <filename>
This option specifies an alternate configuration file for slapd. The default
is normally /usr/local/etc/openldap/slapd.conf.
-h <URLs>
This option specifies alternative listener configurations. The default is
ldap:/// which implies LDAP over TCP on all interfaces on the default LDAP
port 389. You can specify specific host-port pairs or other protocol schemes
(such as ldaps:// or ldapi://). For example, -h "ldaps:// ldap://127.0.0.1:
667" will create two listeners: one for LDAP over SSL on all interfaces on
the default LDAP/SSL port 636, and one for LDAP over TCP on the localhost
(loopback) interface on port 667. Hosts may be specified using IPv4
dotted-decimal form or using host names. Port values must be numeric.
-n <service-name>
This option specifies the service name used for logging and other purposes.
The default service name is slapd.
-l <syslog-local-user>
This option specifies the local user for the syslog(8) facility. Values can
be LOCAL0, LOCAL1, LOCAL2, ..., and LOCAL7. The default is LOCAL4. This
option may not be supported on all systems. See the Section 6.5 for more
details.
-u user -g group
These options specify the user and group, respectively, to run slapd as. user
can be either a user name or uid. group can be either a group name or gid.
-r directory
This option specifies a run-time directory. slapd will chroot(2) to this
directory after opening listeners but before reading any configuration files
or initializing any backends.
-d <level> | ?
This option sets the slapd debug level to <level>. When level is a `?'
character, the various debugging levels are printed and slapd exits,
regardless of any other options you give it. Current debugging levels are:
Table 4-1. Debugging Levels
+-----+-----------------------------------------+
|Level|Description |
+-----+-----------------------------------------+
|-1 |enable all debugging |
+-----+-----------------------------------------+
|0 |no debugging |
+-----+-----------------------------------------+
|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 |
+-----+-----------------------------------------+
|2048 |print entry parsing debugging |
+-----+-----------------------------------------+
You may enable multiple levels by specifying the debug option once for each
desired level. Or, since debugging levels are additive, you can do the math
yourself. That is, if you want to trace function calls and watch the config
file being processed, you could set level to the sum of those two levels (in
this case, -d 65). Or, you can let slapd do the math, (e.g. -d 1 -d 64).
Consult <ldap.h> for more details.
Note: slapd must have been compiled with -DLDAP_DEBUG defined for any
debugging information beyond the two stats levels to be available.
-----------------------------------------------------------------------------
4.2. Starting the LDAP Server
In general, slapd is run like this:
/usr/local/etc/libexec/slapd [<option>]*
Where /usr/local/etc/libexec is determined by configure and <option> is one
of the options described above (or in slapd(8)). Unless you have specified a
debugging level (including level 0), slapd will automatically fork and detach
itself from its controlling terminal and run in the background.
-----------------------------------------------------------------------------
4.3. Killing the LDAP Server
To kill off slapd safely, you should give a command like this:
kill -INT `cat $(ETCDIR)/slapd.pid`
Killing slapd by a more drastic method may cause it's databases to be
corrupted, as it may need to flush various buffers before it exits. Note that
slapd writes its pid to a file called slapd.pid in the directory you
configured in slapd.conf file, for example: /usr/local/var/slapd.pid
Slapd will also write its arguments to a file called slapd.args in the
directory you configured in slapd.conf file, for example /usr/local/var/
slapd.args
-----------------------------------------------------------------------------
Chapter 5. Database Creation and Maintenance
This section tells you how to create a slapd database from scratch. There are
two ways to create a database. First, you can create the database on-line
using LDAP. With this method, you simply start up slapd and add entries using
the LDAP client of your choice. This method is fine for relatively small
databases (a few hundred or thousand entries, depending on your
requirements). This method works for database types which support updates.
The second method of database creation is to do it off-line using special
utilities provided with slapd. This method is best if you have many thousands
of entries to create, which would take an unacceptably long time using the
LDAP method, or if you want to ensure the database is not accessed while it
is being created. Note that not all database types support these utilitites.
-----------------------------------------------------------------------------
5.1. Creating a Database online
The OpenLDAP software package comes with an utility called ldapadd, used to
add entries while the LDAP server is running. If you choose to create the
Database online, you can use the ldapadd tool to add entries (you can also
use other clients provided outside the OpenLDAP package to add entries, like
the [http://www.iit.edu/~gawojar/ldap/] Ldap Browser). After adding the first
entries, you can still use ldapadd to add more entries. You should be sure to
set the following configuration options on your sladp.conf file before
starting slapd:
suffix <dn>
As described in the Section 3.4, this option says what entries are to be held
by this database. You should set this to the DN of the root of the subtree
you are trying to create. For example:
suffix "o=TUDelft, c=NL"
You should be sure to specify a directory where the index files should be
created:
directory /usr/local/tudelft
You need to create this directory with appropriate permissions so that slapd
can write to it.
You need to configure slapd so that you can connect to it as a directory user
with permission to add entries. You can configure the directory to support a
special super-user or root user just for this purpose. This is done through
the following two options in the database definition:
rootdn <dn>
rootpw <passwd> /* Remember to use a SHA password here !!! */
These options specify a DN and password that can be used to authenticate as
the "superuser" entry of the database (i.e., the entry allowed to do
anything). The DN and password specified here will always work, regardless of
whether the entry named actually exists or has the password given. This
solves the chicken-and-egg problem of how to authenticate and add entries
before any entries yet exist.
Slapd natively understands if you use a SHA-1 encrypted password on the
rootpw directive. I use a Java class that generates SHA-1 passwords, but it's
possible to use the command slappasswd to generate the passwords:
slappasswd -h {SHA}
rootpw "{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ="
For example:
rootdn "cn=Manager,dc=example,dc=com"
rootpw "{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ="
The default output for slappasswd is to generate Secure Hash passwords
{SSHA}, in this case you don't need to pass the -h parameter, just call
slappasswd directly.
If you are using SASL as a mechanism to authenticate against LDAP, the rootpw
line may be discarded. Take a look on the Section 3.4 and on the Section 6.2
for more details.
Finally, you should make sure that the database definition contains the index
definitions you want:
index {<attrlist> | default} [pres,eq,sub,none]
For example, to index the cn, sn, uid and objectclass attributes, the
following index configuration lines could be used.
index cn,sn,uid pres,eq,sub
index objectClass pres,eq
Note: Note that not all index types are available with all attribute types.
Take a look on the Section 3.6 for examples.
Once you have configured things to your liking, start up slapd, connect with
your LDAP client, and start adding entries. For example, to add the TUDelft
entry followed by a Postmaster entry using the ldapadd tool, you could create
a file called /tmp/newentry with the contents:
o=TUDelft, c=NL
objectClass=organization
description=Technical University of Delft Netherlands
cn=Postmaster, o=TUDelft, c=NL
objectClass=organizationalRole
cn=Postmaster
description= TUDelft postmaster - postmaster@tudelft.nl
and then use a command like this to actually create the entry:
ldapadd -f /tmp/newentry -x -D "cn=Manager, o=TUDelft, c=NL" -w secret
The above command assumes that you have set rootdn to "cn=Manager, o=TUDelft,
c=NL" and rootpw to "secret" (maybe SHA-1 encrypted in slapd.conf). If you
don't want to type the password on the command line, use the -W option for
the ldapadd command instead of -w "password". You will be prompted to enter
the password:
ldapadd -f /tmp/newentry -x -D "cn=Manager, o=TUDelft, c=NL" -W
Enter LDAP Password:
-----------------------------------------------------------------------------
5.2. Creating a Database offline
The second method of database creation is to do it off-line, using the slapd
database tools described below. This method is best if you have many
thousands of entries to create, which would take an unacceptably long time
using the LDAP method described above. These tools read the slapd
configuration file and an input LDIF file containing a text representation of
the entries to add. For database types which support the tools, they produce
the database files directly (otherwise you must use the on-line method
above). There are several important configuration options you will want to be
sure and set in the config file database definition first:
suffix <dn>
As described in the preceding section, this option says which entries are to
be held by this database. You should set this to the DN of the root of the
subtree you are trying to create. For example:
suffix "o=TUDelft, c=NL"
You should be sure to specify a directory where the index files should be
created:
directory /usr/local/tudelft
Finally, you need to specify which indexes you want to build. This is done by
one or more index options.
index {<attrlist> | default } [pres,eq,approx,sub,none]
For example:
index cn,sn,uid pres,eq,sub
index objectClass eq
This would create presence, equality and substring indexes for the cn, sn,
and uid attributes and an equality index for the objectClass attribute. See
the configuration file section for more information on this option.
Once you've configured things to your liking, you create the primary database
and associated indexes by running the slapadd(8) program:
slapadd -l <inputfile> -f <slapdconfigfile> [-d <debuglevel>]
[-n <integer>|-b <suffix>]
The arguments have the following meanings:
-l <inputfile>
Specifies the LDIF input file containing the entries to add in text form
(Take a look on the next section).
-f <slapdconfigfile>
Specifies the slapd configuration file that tells where to create the
indexes, what indexes to create, etc.
-d <debuglevel>
Turn on debugging, as specified by <debuglevel>. The debug levels are the
same as for slapd. See the Section 4.1 for more details.
-n <databasenumber>
An optional argument that specifies which database to modify. The first
database listed in the configuration file is 1, the second 2, etc. By
default, the first database in the configuration file is used. Should not be
used in conjunction with -b.
-b <suffix>
An optional argument that specifies which database to modify. The provided
suffix is matched against a database suffix directive to determine the
database number. Should not be used in conjunction with -n.
Sometimes it may be necessary to regenerate indices (such as after modifying
slapd.conf(5)). This is possible using the slapindex(8) program. slapindex is
invoked like this:
slapindex -f <slapdconfigfile> [-d <debuglevel>] [-n <databasenumber>|-b <suffix>]
Where the -f, -d, -n and -b options are the same as for the slapadd(1)
program. slapindex rebuilds all indices based upon the current database
contents.
The slapcat program is used to dump the database to an LDIF file. This can be
useful when you want to make a human-readable backup of your database or when
you want to edit your database off-line. The program is invoked like this:
slapcat -l <filename> -f <slapdconfigfile> [-d <debuglevel>] [-n <databasenumber>|-b <suffix>]
where -n or -b is used to select the database in the slapd.conf(5) specified
using -f. The corresponding LDIF output is written to standard output or to
the file specified using the -l option.
-----------------------------------------------------------------------------
5.3. More on the LDIF Format
The LDAP Data Interchange Format (LDIF) is used to represent LDAP entries in
a simple text format. The basic form of an entry is:
#comment
dn: <distinguished name>
<attrdesc>: <attrvalue>
<attrdesc>: <attrvalue>
...
Lines starting with a '#' character are comments. An attribute description
(attrdesc) may be a simple attribute type like cn or objectClass or 1.2.3 (an
OID associated with an attribute type) or may include options such as cn;
lang_en_US or userCertificate;binary.
A line may be continued by starting the next line with a single space or tab
character. For example:
dn: cn=Barbara J Jensen, dc=example, dc=
com
cn: Barbara J
Jensen
is equivalent to:
dn: cn=Barbara J Jensen, dc=example, dc=com
cn: Barbara J Jensen
Multiple attribute values are specified on separate lines. e.g.,
cn: Barbara J Jensen
cn: Babs Jensen
If an <attrvalue> contains non-printing characters or begins with a space, a
double colon (':'), or a less than ('<'), the <attrdesc> is followed by a
double colon and the base64 encoding of the value. For example, the value "
begins with a space" would be encoded like this:
cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=
You can also specify a URL containing the attribute value. For example, the
following specifies the jpegPhoto value should be obtained from the file /
path/to/file.jpeg.
cn:< file://path/to/file.jpeg
Multiple entries within the same LDIF file are separated by blank lines.
Here's an example of an LDIF file containing three entries.
# Barbara's Entry
dn: cn=Barbara J Jensen, dc=example, dc=com
cn: Barbara J Jensen
cn: Babs Jensen
objectClass: person
sn: Jensen
# Bjorn's Entry
dn: cn=Bjorn J Jensen, dc=example, dc=com
cn: Bjorn J Jensen
cn: Bjorn Jensen
objectClass: person
sn: Jensen
# Base64 encoded JPEG photo
jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD
A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ
ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG
# Jennifer's Entry
dn: cn=Jennifer J Jensen, dc=example, dc=com
cn: Jennifer J Jensen
cn: Jennifer Jensen
objectClass: person
sn: Jensen
# JPEG photo from file
jpegPhoto:< file://path/to/file.jpeg
Notice that the jpegPhoto in Bjorn's entry is base 64 encoded and the
jpegPhoto in Jennifer's entry is obtained from the location indicated by the
URL.
Trailing spaces are not trimmed from values in an LDIF file. Nor are multiple
internal spaces compressed. If you don't want them in your data, don't put
them there.
-----------------------------------------------------------------------------
5.4. The ldapsearch, ldapdelete and ldapmodify utilities
ldapsearch - ldapsearch is a shell accessible interface to the ldap_search(3)
library call. Use this utility to search for entries on your LDAP database
backend.
The synopsis to call ldapsearch is the following (take a look at the
ldapsearch man page to see what each option means):
ldapsearch [-n] [-u] [-v] [-k]
[-K] [-t] [-A] [-B] [-L]
[-R] [-d debuglevel] [-F sep] [-f file]
[-x] [-D binddn] [-W] [-w bindpasswd]
[-h ldaphost] [-p ldapport] [-b searchbase]
[-s base|one|sub]
[-a never|always|search|find] [-l timelimit]
[-z sizelimit] filter [attrs...]
ldapsearch opens a connection to an LDAP server, binds, and performs a search
using the filter filter. The filter should conform to the string
representation for LDAP filters as defined in RFC 1558. If ldapsearch finds
one or more entries, the attributes specified by attrs are retrieved and the
entries and values are printed to standard output. If no attrs are listed,
all attributes are returned.
ldapsearch -x -b 'o=TUDelft,c=NL' 'objectclass=*'
ldapsearch -b 'o=TUDelft,c=NL' 'cn=Rene van Leuken'
ldasearch -u -b 'o=TUDelft,c=NL' 'cn=Luiz Malere' sn mail
The -b option stands for searchbase (initial search point), the -u option
stands for userfriendly output information and the -x option is used to
specify simple authentication.
ldapdelete - ldapdelete is a shell accessible interface to the ldap_delete(3)
library call. Use this utility to delete entries on our LDAP database
backend.
The synopsis to call ldapdelete is the following (take a look at the
ldapdelete man page to see what each option means):
ldapdelete [-n] [-v] [-k] [-K]
[-c] [-d debuglevel] [-f file] [-D binddn]
[-W] [-w passwd] [-h ldaphost] [-p ldapport]
[dn]...
ldapdelete opens a connection to an LDAP server, binds, and deletes one or
more entries. If one or more dn arguments are provided, entries with those
Distinguished Names are deleted. Each dn should be a string-represented DN as
defined in RFC 1779. If no dn arguments are provided, a list of DNs is read
from standard input (or from file if the -f flag is used).
Here are some examples of the use of ldapdelete:
ldapdelete 'cn=Luiz Malere,o=TUDelft,c=NL'
ldapdelete -v 'cn=Rene van Leuken,o=TUDelft,c=NL' -D 'cn=Luiz Malere,o=TUDelft,c=NL' -W
The -v option stands for verbose mode, the -D option stands for Binddn (the
dn to authenticate against) and the -W option stands for password prompt.
ldapmodify - ldapmodify is a shell accessible interface to the ldap_modify(3)
and ldap_add(3) library calls. Use this utility to modify entries on our LDAP
database backend.
The synopsis to call ldapmodify is the following (take a look at the
ldapmodify man page to see what each option mean):
ldapmodify [-a] [-b] [-c] [-r]
[-n] [-v] [-k] [-d debuglevel]
[-D binddn] [-W] [-w passwd]
[-h ldaphost] [-p ldapport] [-f file]
ldapadd [-b] [-c] [-r] [-n]
[-v] [-k] [-K] [-d debuglevel]
[-D binddn] [-w passwd] [-h ldaphost]
[-p ldapport] [-f file]
ldapadd is implemented as a hard link to the ldapmodify tool. When invoked as
ldapadd the -a (add new entry) flag of ldapmodify is turned on automatically.
ldapmodify opens a connection to an LDAP server, binds, and modifies or adds
entries. The entry information is read from standard input or from file
through the use of the -f option.
Here are some examples of the use of ldapmodify:
Assuming that the file /tmp/entrymods exists and has the contents:
dn: cn=Modify Me, o=University of Michigan, c=US
changetype: modify
replace: mail
mail: modme@terminator.rs.itd.umich.edu
-
add: title
title: Grand Poobah
-
add: jpegPhoto
jpegPhoto: /tmp/modme.jpeg
-
delete: description
-
The command:
ldapmodify -b -r -f /tmp/entrymods
will replace the contents of the "Modify Me" entry's mail attribute with the
value "modme@terminator.rs.itd.umich.edu", add a title of "Grand Poobah", and
the contents of the file /tmp/modme.jpeg as a jpegPhoto, and completely
remove the description attribute.
The same modifications as above can be performed using the older ldapmodify
input format:
cn=Modify Me, o=University of Michigan, c=US
mail=modme@terminator.rs.itd.umich.edu
+title=Grand Poobah
+jpegPhoto=/tmp/modme.jpeg
-description
And plus the command bellow:
ldapmodify -b -r -f /tmp/entrymods
Assuming that the file /tmp/newentry exists and has the contents:
dn: cn=Barbara Jensen, o=University of Michigan, c=US
objectClass: person
cn: Barbara Jensen
cn: Babs Jensen
sn: Jensen
title: the world's most famous manager
mail: bjensen@terminator.rs.itd.umich.edu
uid: bjensen
The command:
ldapadd -f /tmp/entrymods
will add the entry with dn: cn=Barbara Jensen, o=University of Michigan, c=US
if it's not already present. If an entry with this dn already exists, the
command will point out the error and will not overwrite the entry.
Assuming that the file /tmp/newentry exists and has the contents:
dn: cn=Barbara Jensen, o=University of Michigan, c=US
changetype: delete
The command:
ldapmodify -f /tmp/entrymods
will remove Babs Jensen's entry.
The -f option stands for file (read the modification information from a file
instead of standard input), the -b option stands for binary (any values
starting with a '/' on the input file are interpreted as binaries), the -r
stands for replace (replace existing values by default).
-----------------------------------------------------------------------------
Chapter 6. Additional Information and Features
In this section you will find additional information and useful references
for topics like authentication, logs and LDAP clients. At the end of the
section there are also some very nice generic URL's and book recomendations
about the subject LDAP.
-----------------------------------------------------------------------------
6.1. LDAP Migration Tools
The LDAP Migration Tools are a collection of Perl scripts provided by PADL
Software Ltd. They are used to convert configuration files to the LDIF
format. I recommend reading the license terms before using them, even being
free. If you plan to use your LDAP server to authenticate users, this tools
may be very useful. Use the Migration Tools to convert your NIS or password
archives to the LDIF format, making these files compatible with your LDAP
Server. Also apply these Perl scripts to migrate users, groups, aliases,
hosts, netgroups, networks, protocols, RPCs and services from existing
nameservices (NIS, flat files and NetInfo) to the LDIF format.
To download the LDAP Migration Tools and get more information, go to the
following address: [http://www.padl.com/tools.html] http://www.padl.com/
tools.html .
The package comes with a README file and the name of the script files are
intuitive. Take a first look on the README file and then start applying the
scripts.
Another recommended URL with migration tools is:
[http://dataconv.org/apps_ldap.html] http://dataconv.org/apps_ldap.html
-----------------------------------------------------------------------------
6.2. Authentication using LDAP
To access the LDAP service, the LDAP client first must authenticate itself to
the service. That is, it must tell the LDAP server who is going to be
accessing the data so that the server can decide what the client is allowed
to see and do. If the client authenticates successfully to the LDAP server,
then when the server subsequently receives a request from the client, it will
check whether the client is allowed to perform the request. This process is
called access control.
In LDAP, authentication is supplied in the "bind" operation. Ldapv3 supports
three types of authentication: anonymous, simple and SASL authentication. A
client that sends a LDAP request without doing a "bind" is treated as an
anonymous client. Simple authentication consists of sending the LDAP server
the fully qualified DN of the client (user) and the client's clear-text
password. This mechanism has security problems because the password can be
read from the network. To avoid exposing the password in this way, you can
use the simple authentication mechanism within an encrypted channel (such as
SSL), provided that this is supported by the LDAP server.
Finally, SASL is the Simple Authentication and Security Layer (RFC 2222). It
specifies a challenge-response protocol in which data is exchanged between
the client and the server for the purposes of authentication and
establishment of a security layer on which to carry out subsequent
communication. By using SASL, LDAP can support any type of authentication
agreed upon by the LDAP client and server. The Cyrus-SASL package is
available at the following URL: [http://asg.web.cmu.edu/sasl/
sasl-library.html] http://asg.web.cmu.edu/sasl/sasl-library.html.
Further on authenticating users to access information from your Directory
Tree, your LDAP server can authenticate users from other services too
(Sendmail, Login, Ftp, etc.). This is accomplished migrating specific user
information to your LDAP server and using a mechanism called PAM (Pluggable
Authentication Module). The authentication module for LDAP is available as a
tar ball on the following address: [http://www.padl.com/OSS/pam_ldap.html]
http://www.padl.com/OSS/pam_ldap.html
-----------------------------------------------------------------------------
6.3. SASL Configuration: Digest-MD5
I've got LDAP-SASL authentication running using the DIGEST-MD5 mechanism. To
accomplish that, I've followed strictly the steps listed bellow:
<EFBFBD><EFBFBD>*<EFBFBD>Downloaded SleepyCat 4.2.52, compiling and building manually. After
downloading, I've just followed the instructions listed on the file docs/
index.html under the directory where I've unpacked the .tar.gz bundle.
After unpacking you can run the suggested:
root@rdnt03:/usr/local/BerkeleyDB.4.2/build_unix#../dist/configure
root@rdnt03:/usr/local/BerkeleyDB.4.2/build_unix#make
root@rdnt03:/usr/local/BerkeleyDB.4.2/build_unix#make install
<EFBFBD><EFBFBD>*<EFBFBD>Downloaded Cyrus SASL 2.1.17, unpacking and following the instructions
listed on the document doc/install.html, under the directory where I've
unpacked the .tar.gz file. Here there's a point of attention, you need to
run the configure script using some env parameters:
root@rdnt03:/usr/local/cyrus-sasl-2.1.17#env CPPFLAGS="-I/usr/local/BerkeleyDB.4.2/include"
LDFLAGS="-L/usr/local/BerkeleyDB.4.2/lib" ./configure
The CPPFLAGS and LDFLAGS environment parameters should point to the
respective include and lib directories where Berkeley BDB was installed.
After that you can run the suggested:
root@rdnt03:/usr/local/cyrus-sasl-2.1.17#make
root@rdnt03:/usr/local/cyrus-sasl-2.1.17#make install
root@rdnt03:/usr/local/cyrus-sasl-2.1.17#ln -s /usr/local/lib/sasl2 /usr/lib/sasl2
<EFBFBD><EFBFBD>*<EFBFBD>Finally, I've installed OpenLDAP 2.2.5 using the same directions listed
on this document, just running the configure script the same way as
SASL's configure:
root@rdnt03:/usr/local/openldap-2.2.5#env CPPFLAGS="-I/usr/local/BerkeleyDB.4.2/include"
LDFLAGS="-L/usr/local/BerkeleyDB.4.2/lib" ./configure
After that, I've run the suggested:
root@rdnt03:/usr/local/openldap-2.2.5#make depend
root@rdnt03:/usr/local/openldap-2.2.5#make
root@rdnt03:/usr/local/openldap-2.2.5#make install
<EFBFBD><EFBFBD>*<EFBFBD>Next, I've created the sasl user database:
root@rdnt03:~# saslpasswd2 -c admin
You'll be prompted for a password. Remember that the username should not
be a DN (distinguished name). Also remember to use the same password as
your admin entry on the directory tree.
<EFBFBD><EFBFBD>*<EFBFBD>Now, you should set the sasl-regexp directive in the slapd.conf file
before starting the slapd daemon and testing the authentication. My
slapd.conf file resides at /usr/local/etc/openldap:
sasl-regexp uid=(.*),cn=rdnt03,cn=DIGEST-MD5,cn=auth uid=$1,ou=People,o=Ever
This parameter is in the format of:
uid=<username>,cn=<realm>,cn=<mech>,cn=auth
The username is taken from sasl and inserted into the ldap search string
in the place of $1.Your realm is supposed to be your FQDN (fully
qualified domain name), but in some cases it isn't, like mine. To find
out what your realm is do:
root@rdnt03:~# sasldblistusers2
admin@rdnt03: userPassword
admin@rdnt03: cmusaslsecretOTP
In my case, rdnt03 is indicated as the realm. If it is your FQDN you
shouldn't have any problems. I use the following LDIF file:
dn: o=Ever
o: Ever
description: Organization Root
objectClass: top
objectClass: organization
dn: ou=Staff, o=Ever
ou: Staff
description: These are privileged users that can interact with Organization products
objectClass: top
objectClass: organizationalUnit
dn: ou=People, o=Ever
ou: People
objectClass: top
objectClass: organizationalUnit
dn: uid=admin, ou=Staff, o=Ever
uid: admin
cn: LDAP Adminstrator
sn: admin
userPassword: {SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=
objectClass: Top
objectClass: Person
objectClass: Organizationalperson
objectClass: Inetorgperson
dn: uid=admin,ou=People,o=Ever
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
userPassword: {SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=
displayName: admin
mail: admin@eversystems.com.br
uid: admin
cn: Administrator
sn: admin
Add the entries to your LDAP directory using the following command:
slapadd -c -l Ever.ldif -f slapd.conf -v -d 256
<EFBFBD><EFBFBD>*<2A>Now, start the slapd daemon and run a query using the ldapsearch command:
root@rdnt03:~# ldapsearch -U admin@rdnt03 -b 'o=Ever' '(objectclass=*)'
SASL/DIGEST-MD5 authentication started
Please enter your password:
SASL username: admin@rdnt03
SASL SSF: 128
SASL installing layers
...
Entries
...
That's it ! If you prefer to use SASL with Kerberos V or GSSAPI, there's a
useful link at [http://www.openldap.org/doc/admin22/sasl.html] http://
www.openldap.org/doc/admin22/sasl.html. This link assumes you've already
managed to install and configure the SASL library. The mailing lists will
help you get going with this matter: [http://asg.web.cmu.edu/sasl/index.html#
mailinglists] http://asg.web.cmu.edu/sasl/index.html#mailinglists
-----------------------------------------------------------------------------
6.4. Graphical LDAP tools
Kldap is a graphical LDAP client written for KDE. Kldap has a nice interface
and is able to show all the information tree stored on your Directory. You
can check some screenshots of the application and download it at: [http://
www.mountpoint.ch/oliver/kldap/] http://www.mountpoint.ch/oliver/kldap/
KDirAdm is a LDAP Directory management tool written for the KDE Desktop
Environment version 2 or later. It aims to provide all of the functionality
of most commercial directory management tools: [http://www.carillonis.com/
kdiradm/] http://www.carillonis.com/kdiradm/
Directory Administrator is the most widely used GNOME application for
managing UNIX users and groups on LDAP directory servers. Directory
administrator allows you to create and delete users and groups, and manage
your users associated address book information, per-server access controls
and Sendmail mail routing: [http://diradmin.open-it.org/index.php] http://
diradmin.open-it.org/index.php
GQ is another graphical LDAP client with a simpler interface. It was written
for GNOME. It also runs under KDE, the same way Kldap runs under GNOME. The
address for downloading and getting more information is: [http://biot.com/gq
/] http://biot.com/gq/
LDAP Browser/Editor: This tool is fantastic, it has complete administrative
and browsing funcionalities. Check it out: [http://www.iit.edu/~gawojar/ldap
/] Ldap Browser.
-----------------------------------------------------------------------------
6.5. Logs
Slapd uses the syslog(8) facility to generate logs. The default user of the
syslog(8) facility is LOCAL4, but values from LOCAL0, LOCAL1, up to LOCAL7
are allowed.
In order to enable the generation of logs you have to edit your syslog.conf
file, usually located in the /etc directory.
Create a line like this:
local4.* /usr/adm/ldaplog
This will use the default user LOCAL4 for the syslog facility. If you are not
familiar with the syntax of this line, take a look at the man pages of
syslog, syslog.conf and syslogd. If you want to specify the level of the logs
generated or to change the default user, you have the following options while
starting slapd:
-s syslog-level
This option tells slapd at what level debugging statements should be logged
to the syslog(8) facility. The level describes the severity of the message,
and is a keyword from the following ordered list (higher to lower): emerg,
alert, crit, err, warning, notice, info, and debug. Ex: slapd -f myslapd.conf
-s debug
-l syslog-local-user
Selects the local user of the syslog(8) facility. Values can be LOCAL0,
LOCAL1, and so on, up to LOCAL7. The default is LOCAL4. However, this option
is only permitted on systems that support local users with the syslog(8)
facility.
Now take a look at the logs generated (/usr/adm/ldaplog in the example). They
can help you tremendously in solving problems with queries, updates, binding,
etc.
-----------------------------------------------------------------------------
Chapter 7. References
On this section you will find additional documentation about LDAP: useful
URLs, cool books and definition RFCs.
-----------------------------------------------------------------------------
7.1. URL's
Here are the URLs that contain very useful information about LDAP. From these
URLs, this HOWTO was made, so if after reading this document you need more
specific information, you probably will find here:
<EFBFBD><EFBFBD>*<2A>University of Michigan LDAP Page: [http://www.umich.edu/~dirsvcs/ldap/]
http://www.umich.edu/~dirsvcs/ldap/
<EFBFBD><EFBFBD>*<2A>University of Michigan LDAP Documentation Page: [http://www.umich.edu/
~dirsvcs/ldap/doc/] http://www.umich.edu/~dirsvcs/ldap/doc/
<EFBFBD><EFBFBD>*<2A>OpenLDAP Administrator's Guide (brother document): [http://
www.openldap.org/doc/admin] http://www.openldap.org/doc/admin
<EFBFBD><EFBFBD>*<2A>Linux Directory Service: [http://www.rage.net/ldap/] http://www.rage.net/
ldap/
<EFBFBD><EFBFBD>*<2A>Red Hat and LDAP: [http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/
ref-guide/ch-ldap.html] http://www.redhat.com/docs/manuals/linux/
RHL-9-Manual/ref-guide/ch-ldap.html
<EFBFBD><EFBFBD>*<2A>Mandrake Linux - Using OpenLDAP for Authentication: [http://
www.mandrakesecure.net/en/docs/ldap-auth.php] http://
www.mandrakesecure.net/en/docs/ldap-auth.php
<EFBFBD><EFBFBD>*<2A>Integrating OpenLDAP with other Open Source projects: [ftp://
kalamazoolinux.org/pub/pdf/ldapv3.pdf] ftp://kalamazoolinux.org/pub/pdf/
ldapv3.pdf
-----------------------------------------------------------------------------
7.2. Books
These are the most popular and useful books about LDAP:
<EFBFBD><EFBFBD>*<2A>Implementing LDAP by Mark Wilcox
<EFBFBD><EFBFBD>*<2A>LDAP: Programming Directory-Enabled Applications with Lightweight
Directory Access Protocol by Howes and Smith
<EFBFBD><EFBFBD>*<2A>Understanding and Deploying LDAP Directory Servers by Howes, Smith, and
Good
-----------------------------------------------------------------------------
7.3. RFC's
The [http://www.rfc-editor.org/rfc/] RFCs that support the LDAP development
efforts:
<EFBFBD><EFBFBD>*<2A>RFC 1558: A String Representation of LDAP Search Filters
<EFBFBD><EFBFBD>*<2A>RFC 1777: Lightweight Directory Access Protocol
<EFBFBD><EFBFBD>*<2A>RFC 1778: The String Representation of Standard Attribute Syntaxes
<EFBFBD><EFBFBD>*<2A>RFC 1779: A String Representation of Distinguished Names
<EFBFBD><EFBFBD>*<2A>RFC 1781: Using the OSI Directory to Achieve User Friendly Naming
<EFBFBD><EFBFBD>*<2A>RFC 1798: Connectionless LDAP
<EFBFBD><EFBFBD>*<2A>RFC 1823: The LDAP Application Programming Interface
<EFBFBD><EFBFBD>*<2A>RFC 1959: An LDAP URL Format
<EFBFBD><EFBFBD>*<2A>RFC 1960: A String Representation of LDAP Search Filters
<EFBFBD><EFBFBD>*<2A>RFC 2251: Lightweight Directory Access Protocol (v3)
<EFBFBD><EFBFBD>*<2A>RFC 2307: LDAP as a Network Information Service
LDAP Implementation HOWTO
Roel van Meer
[http://www.linvision.com] Linvision BV
r.vanmeer@linvision.com
Giuseppe Lo Biondo
[http://www.mi.infn.it] INFN MI
giuseppe.lobiondo@mi.infn.it
v0.5, 2001-03-30
Revision History
Revision 0.5 2001-03-30 Revised by: rvm
Cleanup, fixes, overview rewritten.
Revision 0.4 2001-02-01 Revised by: rvm
Added dns section.
Revision 0.3 2001-01-18 Revised by: rvm
Added MTA sections.
Revision 0.2 2000-11-12 Revised by: glb
Improved section on nss. Added sections about certificates and wrappers.
This document describes the technical aspects of storing application data in
an ldap server. It focuses on the configuration of various applications to
make them ldap-aware. Some applications that assist in handling ldap data are
also discussed.
-----------------------------------------------------------------------------
Table of Contents
1. Overview
1.1. Why this howto?
1.2. What is it about?
1.3. What is it NOT about?
1.4. Acknowledgements
1.5. Disclaimer
1.6. Copyright and license
2. LDAP authentication using pam_ldap and nss_ldap
2.1. The components of the framework
2.1.1. Authentication: PAM and pam_ldap.so
2.1.2. The Name Service Switch and nss_ldap.so
2.1.3. The Lightweight Directory Access Protocol
2.1.4. The Name Service Caching Daemon
2.1.5. The Secure Socket Layer
2.2. Building the authentication system
2.2.1. Server side
2.2.1.1. Installing and configuring OpenLDAP
2.2.2. Client side
2.2.2.1. PAM LDAP Installation and Configuration
2.2.2.2. NSS LDAP installation and configuration
2.2.2.3. NSCD configuration
2.2.2.4. LDAP client configuration file
2.3. Starting up
2.4. Accounts maintenance
2.5. Known limits
2.6. File permissions
3. Radius authentication using LDAP
3.1. FreeRadius Radiusd configuration
3.2. Testing Radius Authentication
3.3. Sample CISCO IOS Configuration
4. Samba
5. DNS
5.1. Using nss
5.1.1. Configuration
5.1.2. Schema
5.2. Using bind
5.2.1. Bind patch
5.2.2. ldap2dns
5.2.3. ispman
6. Mail Transfer Agents
6.1. Sendmail
6.1.1. Ldap support in sendmail
6.1.2. System layout.
6.1.3. Sendmail configuration file
6.1.4. Schema
6.1.5. More information.
6.2. Postfix
6.2.1. Support
6.2.2. Configuration
6.2.3. Example setup
6.3. Qmail
7. Address books
8. Netscape roaming access
9. Publishing digital certificates with LDAP
9.1. LDAP Server configuration
9.2. Certificate Publishing
9.3. LDAP Aware Clients
10. SSL/TLS and SSL/TLS wrappers for LDAP
10.1. A Brief description of SSL
10.2. SSL/TLS availability for OpenLDAP
10.3. How to use stunnel to provide SSL/TLS to an LDAP V2 server
10.4. How to use stunnel to provide SSL to LDAP clients
10.5. How to use stunnel to provide SSL for slurpd replication
11. Ldap schema's
12. Example files
12.1. The schema file
12.2. Example base ldif
-----------------------------------------------------------------------------
1. Overview
1.1. Why this howto?
I started learning about ldap when my company felt the need for a centralized
storage of user account information, and wanted to use ldap for this. I soon
found that there were bits and pieces of documantation everywhere, but that
there was no document that put it all together. This has been the reason to
start it.
Furthermore, Ldap is becoming more widely used every day. I think it is
useful that when people are considering to use Ldap, they can get a full
overview of which applications are Ldap aware. This might help them to choose
their system setup carefully, without throwing everything about every time
they want to change something or add functionality.
It started out as a project roadmap on how we wanted to implement Ldap for
our own uses. But thanks to my employer, [http://www.linvision.com]
Linvision, who gave me the opportunity to do some research on things that
weren't really useful to our own cause, it changed from a roadmap to a
technical overview of applications that are ldap aware.
-----------------------------------------------------------------------------
1.2. What is it about?
Most of the common services can be authenticated through PAM, Pluggable
Authentication Modules. With the pam_ldap and nss_ldap modules, all pamified
programs can get their information from LDAP. More information about PAM in
general can be found on [http://www.kernel.org/pub/linux/libs/pam/] the
Linux-PAM site. Information about pam_ldap and nss_ldap can be found on the
[http://www.padl.com] padl software site.
For Samba, things are a little difficult at this moment. The current stable
Samba versions do not have Ldap support. Ldap support can be found in the
HEAD and TNG branch, and probably also in the combined tree. The problem is
that samba has it's own usernames and passwords. It does have usage for PAM,
in fact, but that is not sufficient to do all the authentication and
retrieval of user information. Because the implementation of LDAP in samba is
not fully finished yet, there are a few limitations to the use of ldap with
samba. From my experiences, the HEAD is at this time (early June 2000) not
stable enough, and the performance is unsatisfying. However, when the ldap
support is fully functional in the new releases, samba too can be configured
to get all of it's user information from ldap.
Another thing that can be stored into an ldap database is DNS. When the
amount of machines connected to your network increases, it is no longer
feasable to edit the DNS files by hand. When machine accounts are stored into
ldap, two simple DNS entries (one for the lookup, and one for the reverse
lookup) can easily be added at the same time. This too provides a
simplification of system management. Although the storage of DNS entries in
an ldap database may not be neccesary for most systems, it may prove useful
to some people.
Since sendmail version 8.9 (see [http://www.sendmail.net/] sendmail.net for
more details), sendmail has Ldap support. Postfix and QMail are ldap-aware
too. When setting up an email system which has multiple mailhosts and or
fallback hosts, it is convenient to store all the information in one place.
Normally, every system needs to be configured separately, with the same
information. When using ldap, this can be avoided.
Roaming access can also be used with LDAP. Netscape versions 4.5 and up have
the possibility to store user data like bookmarks and such via an HTML or
LDAP server. This gives users their good old preferences, wherever they log
in and use Netscape.
Microsoft's office programs can import address books. Thay can also use an
Active Directory service to automagically match emailaddresses to user names
or nicknames. With Ldap this can be done on a Linux system, without the need
for Microsoft Exchange Server or something the like.
-----------------------------------------------------------------------------
1.3. What is it NOT about?
First thing: I will try not to talk too much about the actual setup and
administration of Ldap itself. There is an excellent Ldap HOWTO available at
the Linux Documentation Project that discusses this.
Secondly, I will not discuss things regarding the applications itself, when
they have nothing to do with Ldap.
Lastly, in most cases, I cannot tell you if it is wise to use Ldap. I don't
have that kind of experience. I can tell you how to do it, if you want, but i
cannot tell you if you should. There is plenty documentaion available that
discusses the useability of Ldap in general.
-----------------------------------------------------------------------------
1.4. Acknowledgements
At first, I would like to thank my employer, [http://www.linvision.com]
Linvision, for giving me the opportunity to work on this document in their
time.
Furthermore, I would like to thank the following people, who have contributed
to this document in some way (in no particular order): Giuseppe Lo Biondo.
-----------------------------------------------------------------------------
1.5. Disclaimer
This document is provided as is and should be considered as a work in
progress. Several sections are as yet unfinished, and probably a lot of
things that should be in here, aren't. I would greatly appreciate any
comments on this document, of whatever nature they may be.
In any case, think before you go messing around with your system and don't
come to me if it breaks.
-----------------------------------------------------------------------------
1.6. Copyright and license
Copyright (c) by Roel van Meer, Giuseppe Lo Biondo. This document may be
distributed only subject to the terms and conditions set forth in the LDP
License at the [http://www.linuxdoc.org/COPYRIGHT.html] Linux Documentation
Project.
-----------------------------------------------------------------------------
2. LDAP authentication using pam_ldap and nss_ldap
This section focuses on how to use LDAP as a NIS substitute for user accounts
management. Having a lot of user accounts on several hosts often causes
misalignments in the accounts configuration. LDAP can be used to build a
centralized authentication system thus avoiding data replication and
increasing data consistency.
At the moment the most used method to distribute users account data and other
information through a network is the Network Information Service (NIS). Like
LDAP, NIS is a distributed service that allows to have a central server where
configuration files such as passwd, shadow, groups, services, hosts etc. are
kept. The NIS server is queried by NIS clients to retrieve this information.
LDAP can offer the same functionality of NIS, moreover there are several
advantages on using LDAP:
<EFBFBD><EFBFBD>*<2A>Information on the LDAP server can be easily used for several purposes.
As outlined in this HOWTO, the same users entries on the LDAP database
can be used for other applications like phone directories, mail routing,
staff databases etc., thus avoiding data replication and inconsistency.
<EFBFBD><EFBFBD>*<2A>LDAP allows complex access control lists to be applied on the database.
This allows for a fine grain tuning of permissions on the database
entries.
<EFBFBD><EFBFBD>*<2A>A secure transmission channel between the LDAP server and the clients can
be implemented through the Secure Socket Layer (SSL).
<EFBFBD><EFBFBD>*<2A>A fault tolerant service can be implemented using slapd replication [1]
and DNS round robin queries (this is not covered in this document).
<EFBFBD><EFBFBD>*<2A>Having a single instance of users on the network helps to maintain users
on many hosts from a single management point (i.e. you can create and
delete accounts in the LDAP server and this changes are available
immediately to LDAP clients).
Herein I'll focus on how an LDAP server can be used for authentication and
authorization on systems providing the Pluggable Authentication Module (PAM)
and the Name Service Switch (NSS) technologies, in particular I'll refer to
the Linux operating system even if this instructions can be applied to other
operating systems.
The environment proposed consists of an LDAP server where users account data
is stored in a convenient format and a set of Un*x clients using this
information to authenticate and authorize users on resources in a standard Un
*x fashion.
A secure channel is also required in client/server communications since
critical information such as user account data, should not be sent in clear
over the network, this channel will be provided by the Secure Socket Layer.
On the client side a caching mechanism, needed for performance issues, can be
provided by the Name Service Caching Daemon.
All (almost) the software used to build this system is Open Source.
-----------------------------------------------------------------------------
2.1. The components of the framework
This section outlines the various components that are used to build the
authentication system. For each component is given a brief description.
-----------------------------------------------------------------------------
2.1.1. Authentication: PAM and pam_ldap.so
The Pluggable Authentication Module allows integration of various
authentication technologies such as standard UNIX, RSA, DCE, LDAP etc. into
system services such as login, passwd, rlogin, su, ftp, ssh etc. without
changing any of these services.
First implemented by Sun Solaris, PAM is now the standard authentication
framework of many Linux distributions, including RedHat and Debian. It
provides an API through which authentication requests are mapped into
technology specific actions (implemented in the so called pam modules). This
mapping is done by PAM configuration files, in which, for each service are
basically given the authentication mechanisms to use.
In our case, the pam_ldap module, implemented in the shared library
pam_ldap.so, allows user and group authentication using an LDAP service.
Each service that needs an authentication facility, can be configured through
the PAM configuration files to use different authentication methods. This
means that it is possible, using the PAM configuration files, to write a
custom list of requirements that an user must satisfy to obtain access to a
resource.
-----------------------------------------------------------------------------
2.1.2. The Name Service Switch and nss_ldap.so
Once an user is authenticated, many applications still need access to user
information. This information is traditionally contained in text files (/etc/
passwd, /etc/shadow, and /etc/group) but can also be provided by other name
services.
As a new name service (such as LDAP) is introduced it can be implemented
either in the C library (as it was for NIS and DNS) or in the application
that wants to use the new nameservice.
Anyway, this can be avoided using a common, general purpose, name service API
and by demanding to a set of libraries the task of retrieving this
information performing technology based operations.
This solution was adopted in the GNU C Library that implements the Name
Service Switch, a method originated from the Sun C library that permits to
obtain information from various name services through a common API.
NSS uses a common API and a configuration file (/etc/nsswitch.conf) in which
the name service providers for every supported database are specified.
The databases currently supported by NSS [2] are:
<EFBFBD><EFBFBD>*<2A>aliases: Mail aliases.
<EFBFBD><EFBFBD>*<2A>ethers: Ethernet numbers.
<EFBFBD><EFBFBD>*<2A>group: Groups of users.
<EFBFBD><EFBFBD>*<2A>hosts: Host names and numbers.
<EFBFBD><EFBFBD>*<2A>netgroup: Network wide list of host and users.
<EFBFBD><EFBFBD>*<2A>network: Network names and numbers.
<EFBFBD><EFBFBD>*<2A>protocols: Network protocols.
<EFBFBD><EFBFBD>*<2A>passwd: User passwords.
<EFBFBD><EFBFBD>*<2A>rpc: Remote procedure call names and numbers.
<EFBFBD><EFBFBD>*<2A>services: Network services.
<EFBFBD><EFBFBD>*<2A>shadow: Shadow user passwords.
Using the nss_ldap shared library it is possible to implement the maps above
using LDAP, anyway here I'll focus only on the LDAP implementation of shadow,
passwd and group database tough all the maps above can be implemented. For
most of the other maps it is even unadvisable to store them in ldap, as they
tend not to change too often, so it is not a problem to have them locally as
files, and storing them in ldap would cause some minor performance loss.
-----------------------------------------------------------------------------
2.1.3. The Lightweight Directory Access Protocol
For our application LDAP is used to provide clients with information about
user accounts and user groups. The standard objectclasses that are used to
represent users and groups are: top, posixAccount, shadowAccount and
posixGroup.
Users entries on the database must belong at least[3] to the top,
posixAccount and shadowAccount objectclasses. Group entries must belong to
the top and posixGroup objectclasses.
The implementation of pam_ldap and nss_ldap that we use refers to this
objectclasses, that are described in RFC 2307.
Note: Actually LDAP NSS recognize other objectclasses
-----------------------------------------------------------------------------
2.1.4. The Name Service Caching Daemon
The Name Service Caching Daemon (NSCD) is used to cache name service lookups
and can improve performance with the services provided by the NSS.
It must be tuned with a large cache for passwd entries in order to have
acceptable performance on the client side.
It has some disadvantages however, like the introduction of cache
inconsistencies, so you would want to be sure you need this before you use
it. We have succesfully running some systems without it, and personally i
think that it isn't really neccesary on relatively small systems.
-----------------------------------------------------------------------------
2.1.5. The Secure Socket Layer
For details on SSL refer to Section 10.
SSL is needed in the communication between the LDAP server and the clients
libraries (pam_ldap.so and nss_ldap.so), since sensible data, such as
password entries, needs to be encrypted between the client and the server.
SLL also permits the client to uniquely identify the server, thus avoiding to
obtain authentication informations from an untrusted source.
Client authentication (the server identifies the client) is not supported in
the current implementation of pam_ldap and nss_ldap modules tough it may be
useful.
-----------------------------------------------------------------------------
2.2. Building the authentication system
This section describes the steps needed to build the authentication system
using the components described in the previous section.
Figure 1. PAM Layout
The relationships among the pieces of the authentication system from the PAM
point of view
Figure 2. NSS Layout
The relationships among the pieces of the authentication system from the NSS
perspective
Though this layout may seem quite complex to implement, most of the
components are already in place in a Linux system.
-----------------------------------------------------------------------------
2.2.1. Server side
On the server side an LDAP server must be installed and configured. The LDAP
server used is OpenLDAP, an open source LDAP toolkit including an LDAP server
(slapd), library and utilities.
At the moment OpenLDAP comes with two implementation of LDAP: a V2
implementation (OpenLDAP 1.2.x) ad a V3 (OpenLDAP 2.0.x) implementation
The V3 implementation provides native SSL, the V2 doesn't. Anyway it is
possible to use an SSL wrapper to add SSL capabilities to the server (see
Section 10).
-----------------------------------------------------------------------------
2.2.1.1. Installing and configuring OpenLDAP
You can refer to the LDAP-HOWTO for instruction on installation and
configuration of LDAP
Once slapd is properly configured we need to insert some data for the initial
creation of the database. Therefore an LDIF (LDAP Data interchange format)
file must be created. This is a text file that can be imported in the LDAP
database with the command:
#ldif2ldbm -i your_file.ldif
Note: ldif2ldbm is provided with the OpenLDAP 1.2.x package, if you use
OpenLDAP 2.0.x, you should use the ldapadd command (after the server is
started).
If you use OpenLDAP 2.0.x (LDAPv3) you can find the standard nis schema in
the file etc/openldap/schema/nis.schema, include it in your slapd.conf with
the include directive, to have schema enforcement.
Here is an example of a minimal LDIF file. Each entry is separated by a blank
line.
dn:dc=yourorg, dc=com
objectclass: top
objectclass: organizationalUnit
dn:ou=groups, dc=yourorg, dc=com
objectclass: top
objectclass: organizationalUnit
ou: groups
dn:ou=people, dc=yourorg, dc=com
objectclass: top
objectclass: organizationalUnit
ou: people
dn: cn=Giuseppe LoBiondo, ou=people, dc=yourorg, dc=com
cn: Giuseppe Lo Biondo
sn: Lo Biondo
objectclass: top
objectclass: person
objectclass: posixAccount
objectclass: shadowAccount
uid:giuseppe
userpassword:{crypt}$1$ss2ii(0$gbs*do&@=)eksd
uidnumber:104
gidnumber:100
gecos:Giuseppe Lo Biondo
loginShell:/bin/zsh
homeDirectory: /home/giuseppe
shadowLastChange:10877
shadowMin: 0
shadowMax: 999999
shadowWarning: 7
shadowInactive: -1
shadowExpire: -1
shadowFlag: 0
dn: cn=mygroup, ou=groups, dc=yourorg, dc=com
objectclass: top
objectclass: posixGroup
cn: mygroup
gidnumber: 100
memberuid: giuseppe
memberuid: anotheruser
Note: Note that lines that are too long are continued on the following
line started by a tab or a space, this in true too for LDIF format files
Here we defined the base DN for the orgazation dc=yourorg, dc=com under which
are contained two sub organizational units: people and groups. Then is
described a user that belongs to the people organizational unit and a group
(which the users belongs to) under the groups organizational unit.
Note: Useful tools to convert existing databases into ldif format are
provided by PADL and can be found at the address [ftp://ftp.padl.com/pub/
MigrationTools.tar.gz] ftp://ftp.padl.com/pub/MigrationTools.tar.gz.
The LDIF file must be imported in the server while it is not running since
the ldif2ldbm command builds the database directly, bypassing the LDAP
server. Once the LDIF file is imported into the database, the server can be
started.
-----------------------------------------------------------------------------
2.2.2. Client side
On the client side pam_ldap.so and nss_ldap.so are required and they must be
compiled using the Netscape LDAP Library (Mozilla) since it provides the
required LDAPS (LDAP over SSL) API. The library is distributed in a binary
package under Netscape One license and is not open source (it is public
domain anyway).
The package can be extracted, for example, in the directory /usr/local/
ldapsdk.
Client libraries must also have access to a certificate database containing
the LDAP (stunnel) server certificate and the CA certificate of the CA that
signed the server certificate (marked as trusted).
The certificate database must be in Netscape format since the Mozilla LDAP
API used to compile pam_ldap and nss_ldap uses certificate databases in
Netscape format.
To deal with such certificate databases it is convenient to use the certutil
utility found in the PKCS#11 package provided by Netscape [4].
The main configuration file for LDAP clients is /etc/ldap.conf.
Note that if you use nss_ldap, you don't strictly need to use pam_ldap.
You can use the pam_unix_auth module instead, since nss_ldap maps all getpw*
and getsh* calls into LDAP lookups and pam_unix_auth uses this calls to
authenticate users.
-----------------------------------------------------------------------------
2.2.2.1. PAM LDAP Installation and Configuration
To compile and install pam_ldap, do the following:
$ ./configure --with-ldap-lib=netscape4 \
--with-ldap-dir=/usr/local/ldapsdk
$ make
# make install
The configure switch --with-ldap-lib tells which LDAP library you are going
to use.
The switch --with-ldap-dir tells where you have installed your Netscape
ldapsdk toolkit.
This will install /lib/security/pam_ldap.so.1 and the various symlinks.
PAM has to be properly configured in order to access the new authentication
system. PAM configuration files are located in the directory /etc/pam.d and
are named after the service for which authentication is provided.
For example this is the PAM configuration file for the login service (in a
file named login).
#%PAM-1.0
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_nologin.so
auth sufficient /lib/security/pam_ldap.so
auth required /lib/security/pam_unix_auth.so use_first_pass
account sufficient /lib/security/pam_ldap.so
account required /lib/security/pam_unix_acct.so
password required /lib/security/pam_cracklib.so
password sufficient /lib/security/pam_ldap.so
password required /lib/security/pam_unix_passwd.so use_first_pass md5 shadow
session required /lib/security/pam_unix_session.so
Standard PAM configuration files for use with PAM can be found in the
pam_ldap source distribution, in the directory pam_ldap-version/pam.d.
This files can be copied in the /etc/pam.d directory. Caution must be given
when performing this operation, since if something goes wrong you probably
will not be able to login again. It is suggested to make a backup copy of /
etc/pam.d before installing new files there and to leave an open privileged
shell.
Note: In the example pam.d directory, a sshd file is not present, so
unless you create one, you will be unable to login via ssh, if it uses
pam (OpenSSH does use PAM).
-----------------------------------------------------------------------------
2.2.2.2. NSS LDAP installation and configuration
After you've unpacked the sources, check the makefile. For most
configurations, it doesn't need to be edited. Anyway, if you want to use SSL
you must link against an SSL aware LDAP library, such as the Netscape one.
Assuming that the ldap sdk is in /usr/local/ldapsdk you have to modify the
Makefile to enable SSL. Look for NSFLAGS in Makefile.linux.mozilla and
uncomment -DSSL.
Also check the LIBS definition to see if the ldapssl library specified in the
file is the same that you have installed (ldap_nss.so compiles with both
libldapssl40 and libldapssl30).
Then you can install the library:
$ make -f Makefile.linux.mozilla
# make -f Makefile.linux.mozilla install
#ldconfig
this installs /lib/libnss_ldap.so, which is the nss_ldap library, and a set
of example configuration files, /etc/nsswitch.ldap and /etc/ldap.conf, in
case they do not exist already.
Once you have installed it you must edit the NSS configuration file /etc/
nsswitch.conf. Tough LDAP can be used for all the services we use it only for
passwd, group and shadow therefore we should have something like:
passwd: files ldap
group: files ldap
shadow: files ldap
in the first lines of the configuration file. With this configuration,
entries are first looked in the system files and, if no value is returned,
the LDAP server is queried.
Note: Beware when using ldap as backup for your dns lookups. If dns
cannot resolve the hostname, we're in infinite recursion, because libldap
calls gethostbyname(). [ from the nsswitch.ldap]
-----------------------------------------------------------------------------
2.2.2.3. NSCD configuration
NSCD is already available in many Linux distributions, anyway it can be found
within the GNU C library package.
The NSCD configuration file is /etc/nscd.conf. Each line specifies either an
attribute and a value, or an attribute, cachename, and a value. Fields are
separated either by SPACE or TAB characters. cachename can be hosts, passwd,
or groups (in our case we won't cache hosts).
enable-cache passwd yes
positive-time-to-live passwd 600
negative-time-to-live passwd 20
suggested-size passwd 211
keep-hot-count passwd 20
check-files passwd yes
enable-cache group yes
positive-time-to-live group 3600
negative-time-to-live group 60
suggested-size group 211
keep-hot-count group 20
check-files group yes
Keep in mind that the nscd program caches passwd entries obtained from LDAP.
This means that when an user is modified on the ldap server, the nscd cache
remains valid. This is avoided when using flat unix files by the check-files
directive that invalidates the cache when the corresponding file is modified.
Such a mechanism should be generalized, at the moment anyway does not apply
to LDAP. A way to avoid possible misalignments between the LDAP server and
the cache is to invalidate the cache manually when updating passwd entries
with the command:
#nscd --invalidate=TABLE
Where TABLE can be passwd, groups or hosts.
To avoid confusion when testing, do not use nscd.
Moreover using nss and nscd will produce a lot of open filedescriptors, so is
easy to run out of available filedescriptors on the system (this can hang
your system).
You can increase the maximum number of filedescriptors in a Linux box (Kernel
2.2.x) with something like:
#echo 16384 > /proc/sys/fs/file-max
The maximum number of filedescriptors suggested for a system depends anyway
from the configuration of your system.
-----------------------------------------------------------------------------
2.2.2.4. LDAP client configuration file
The LDAP client configuration file /etc/ldap.conf is read by pam_ldap and
nss_ldap as well as other LDAP clients. The following is an example of how it
should look like in our environment.
#
# $Id$
# This is the configuration file for the LDAP nameservice
# switch library and the LDAP PAM module.
# PADL Software
# http://www.padl.com
#
# If the host and base aren't here, then the DNS RR
# _ldap._tcp.[defaultdomain]. will be resolved. [defaultdomain]
# will be mapped to a distinguished name and the target host
# will be used as the server.
#
# Your LDAP server. Must be resolvable without using LDAP.
host 192.111.111.111
#
# The distinguished name of the search base.
base dc=yourorg, dc=com
#
# The LDAP version to use (defaults to 2,
# use 3 if you are using OpenLDAP 2.0.x or Netscape Directory Server)
# ldap_version 3
#
# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
# binddn cn=manager,dc=padl,dc=com
#
# The credentials to bind with.
# Optional: default is no credential.
#bindpw secret
#
# The port.
# Optional: default is 389. 636 is for ldaps
port 636
#
# The search scope.
#scope sub
#scope one
#scope base
#
# The following options are specific to nss_ldap.
#
# The hashing algorithm your libc uses.
# Optional: default is des
#crypt md5
#crypt sha
#crypt des
#
# The following options are specific to pam_ldap.
#
# 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 yes
#
# Group to enforce membership of
#
#pam_groupdn cn=PAM,ou=Groups,dc=padl,dc=com
#
# Group member attribute
pam_member_attribute memberuid
# Template login attribute, default template user
# (can be overridden by value of former attribute
# in user's entry)
#pam_login_attribute userPrincipalName
#pam_template_login_attribute uid
#pam_template_login nobody
#
# Hash password locally; required for University of
# Michigan LDAP server, and works with Netscape
# Directory Server if you're using the UNIX-Crypt
# hash mechanism and not using the NT Synchronization
# service.
pam_crypt local
#
# SSL Configuration
ssl yes
sslpath /usr/local/ssl/certs
#
Note: To avoid problems with the various applications that may read this
file it is suggested not to use tabs between parameters and values, only
a single space.
The pam_groupdn directive is useful when an LDAP server provides
authentication information to a pool of clients, but the user should be
authorized only on a set of clients. This directive can provide the same
functionality of NIS netgroups.
The SSL configuration directives are not documented in the package, but they
tell to enable SSL and where the file containing the LDAP server certificate
and the CA certificate is stored.
A Netscape certificate database named cert7.db is searched in sslpath. This
file must contain the server certificate and the CA certificate (unless the
server certificate is self signed). There are two ways to generate this file:
using the Netscape PKCS#11 tools or using the Netscape browser.
With the Netscape browser, after you have started slapd and stunnel on the
server you can use Netscape Navigator to connect to the URL https://
your.ldap.server:636/, you will be prompted to insert the server certificate
in your database. Also the CA certificate (provided by your CA) must be
loaded in the database (unless you are using a self signed certificate). At
this point you can copy the $HOME/.netscape/cert7.db in sslpath. It is
preferred that you use a scratch account with a default cert7.db file since
other server certificates, that may be present in your personal certificate
database, will be considered by your LDAP client as trusted authentication
servers. Once the browser has imported the server certificate it can be used
to debug SSL since it will behave like the pam and nss libraries.
-----------------------------------------------------------------------------
2.3. Starting up
On the server side you have to start slapd (the LDAP daemon process) with a
command like:
# slapd
If you use stunnel, it has to be started on the LDAPS port 636:
# /usr/local/sbin/stunnel -r ldap -d 636 \
-p /usr/local/ssl/certs/stunnel.pem
If you use OpenLDAP 2.0.x, compiled with TLS (OpenSSL), you can start the
server using the command
# slapd -h "ldap:/// ldaps:///"
On the client nscd can be started with the a startup script, usually found in
many Linux distributions:
# /etc/rc.d/init.d/nscd start
If PAM and NSS are correctly configured this should be enough.
-----------------------------------------------------------------------------
2.4. Accounts maintenance
At this point account creation and maintenance should be done using LDAP
client tools.
Unfortunately these general purpose tools are not intended for Un*x accounts
maintenance. The one that seems to be enough versatile is the LDAP Browser/
Editor ([http://www-unix.mcs.anl.gov/~gawor/ldap] http://www-unix.mcs.anl.gov
/~gawor/ldap) that allows to set passwords in various formats and can use SSL
to connect to the server.
-----------------------------------------------------------------------------
2.5. Known limits
As it is for NIS with a single master server (no slave servers), LDAP without
a replication mechanism represents a single point of failure for the
authentication system. For authentication purposes it is rather important to
implement LDAP replication. The server that cames with OpenLDAP (slapd)
provides replication capabilities.
-----------------------------------------------------------------------------
2.6. File permissions
The following are the file permissions that should be applied to some of the
files used by the authentication system.
-rw-r--r-- root.root /etc/ldap.conf
-rw------- root.root /usr/local/etc/openldap/slapd.conf
-rwxr-xr-x root.root /lib/security/pam_ldap.so.1
-rw-r--r-- root.root /lib/libnss_ldap-2.1.2.so
-rw-r--r-- root.root /usr/local/ssl/certs/cert7.db
-rw------- root.root /usr/local/ssl/certs/stunnel.pem
-----------------------------------------------------------------------------
3. Radius authentication using LDAP
A Radius Server, is a daemon for un*x operating systems which allows one to
set up (guess what!) a radius protocol server, which is usually used for
authentication and accounting of dial-up users. To use server, you also need
a correctly setup client which will talk to it, usually a terminal server or
a PC with appropriate which emulates it (PortSlave, radiusclient etc). [From
the freeradius FAQ]
Radius has its own database of users, anyway, since this information is
already contained in LDAP, it will be more convenient to use it!
There are several freeware Radius servers, the one that has good support for
LDAP is the FreeRadius server ([http://www.freeradius.org] http://
www.freeradius.org), it is still a development version, anyway the LDAP
module works fine.
-----------------------------------------------------------------------------
3.1. FreeRadius Radiusd configuration
Once you have installed the server you have to configure it using the
configuration files, that are located under /etc/raddb (or /usr/local/etc/
raddb)
In the radiusd.conf file edit :
[...omissis]
# Uncomment this if you want to use ldap (Auth-Type = LDAP)
# Also uncomment it in the authenticate{} block below
ldap {
server = ldap.yourorg.com
#login = "cn=admin,o=My Org,c=US"
#password = mypass
basedn = "ou=users,dc=yourorg,dc=com"
filter = "(posixAccount)(uid=%u))"
}
[...omissis]
# Authentication types, Auth-Type = System and PAM for now.
authenticate {
pam
unix
# sql
# sql2
# Uncomment this if you want to use ldap (Auth-Type = LDAP)
ldap
}
[...omissis]
Also edit the dictionary file:
[...omissis]
#
# Non-Protocol Integer Translations
#
VALUE Auth-Type Local 0
VALUE Auth-Type System 1
VALUE Auth-Type SecurID 2
VALUE Auth-Type Crypt-Local 3
VALUE Auth-Type Reject 4
VALUE Auth-Type ActivCard 4
VALUE Auth-Type LDAP 5
[...omissis]
And the users file to have a default authorization entry:
[...omissis]
DEFAULT Auth-Type := LDAP
Fall-Through = 1
[...omissis]
If you alreay set up an LDAP server for Un*x accounts management, this is
enough.
On the LDAP server ensure also that the radius server can read the all the
posixAccount attributes (expecially uid and userpassword).
-----------------------------------------------------------------------------
3.2. Testing Radius Authentication
To test everything server start radiusd in debugging mode:
/usr/local/sbin/radiusd -X -A
Then use the radtest program whith a syntax like
radtest username "password" radius.yourorg.com 1 testing123
If everything went fine you should receive an Acces-Accept packet from the
Radius server.
You can also use stunnel in client mode to provide SSL in the connection
between the Radius server and the LDAPS server. For details on SSL refer to
Section 10.
-----------------------------------------------------------------------------
3.3. Sample CISCO IOS Configuration
Just for completeness, here is a sample Cisco IOS configuration. Anyway, this
is outside the purpose of the HOWTO so it may not suit your needs.
[...omissis]
aaa new-model
aaa authentication login default radius enable
aaa authentication ppp default radius
aaa authorization network radius
[...omissis]
radius-server host 192.168.10.1
radius-server timeout 10
radius-server key cisco
[...omissis]
Note: Almost all NAS use port 1645 for radius, check it out and configure
the server appropriately.
-----------------------------------------------------------------------------
4. Samba
The current stable samba tree does not contain ldap support. The HEAD and TNG
branches should, but are still under heavy development. When stable version
are released I will document the implementation of samba in it here. Until
then, you might want to take a look a [http://www.unav.es/cti/ldap-smb/
ldap-smb-HEAD-howto.html] document written by Ignacio Coupeau, where he
describes the setup of Ldap for both of these branches.
Anyway, at this point, the smbpasswd file still has to be used. User account
information is already retrieved from ldap, though. (As this is done by
nsswitch, not samba.) When samba supports ldap, it should be possible to
store the information that is now contained in the smbpasswd and optionally
smbusers files in ldap. Whether it is possible for shares to be dynamically
defined in ldap, I don't know, but I suppose it is not.
-----------------------------------------------------------------------------
5. DNS
There are to ways of dns that can be configured via ldap, client side and
server side. The first, client side, is using the name server switch to
access the dns entries in the Ldap database. This means that only clients
that modify their /etc/nsswitch.conf file will see the dns entries from ldap.
The second way to do it is to use ldap as a backend for bind or tinydns.
There are some projects going on about this subject and i will describe them
below.
-----------------------------------------------------------------------------
5.1. Using nss
When using nss to access (additional) host entries, please take not that only
"friendly" machines (e.g. machines that you know of and whoes configuration
you can control) can use this service. It might be useful for intranet host
lookups that change often, but it cannot be used to distribute your
webservers virtual hostnames to the world. Note that also the nslookup
command bypasses both /etc/hosts and ldap, so it cannot be used to check if
your setup is working. Use something like host or ping instead, which does a
lookup with the internel gehostbyname() function.
-----------------------------------------------------------------------------
5.1.1. Configuration
To have the name server switch use ldap for dns lookups it must be configured
with nss_ldap. How to set up nss_ldap, you can find in Section 2. Here i will
assume you have a working nss_ldap configuration. The dns lookups of nss are
controlled with the hosts line in /etc/nsswitch.conf. It is very unlikely
that you do not already have a hosts line. Most probably it will contain the
files and dns entries. You should add ldap to it like this:
hosts: files, dns, ldap
Think well about the order in which you specify these! It is advised always
to put files as the first entry. Then, if you want ldap to override your
local dns server, you have to make sure that the ip of the ldap server can be
found in the /etc/hosts file. If not, you will have a nice recursive lookup
going. -- You want to look up a host, it's not in files, so we try to contact
the ldap server, whoes ip we don't know, so we try to look it up in files,
where we cannot find it, so we try to contact the ldap server -- get the
point? You could bypass this problem entirely by referring to your ldap
server with an ip number instead of a hostname (in /etc/ldap.conf, that is.)
-----------------------------------------------------------------------------
5.1.2. Schema
The schema used for this, and similar services, can be found in [http://
www.cis.ohio-state.edu/cgi-bin/rfc/rfc2307.html] RFC 2307. Entries used for
mapping names to ipnumbers are in an objectclass ipHost. The name part of the
mapping is given in the attribute cn, while the ip part lives in ipHostNumber
. A typical ldif entry would therefore look like this:
dn: cn=somehostname.mydomain.com,ou=Network,o=YourOrg,c=NL
objectclass: top
objectclass: ipHost
cn: somehostname.internal.example.com
ipHostNumber: 10.1.5.13
Of course, the usual restrictions and possibilities that come with dns apply.
-----------------------------------------------------------------------------
5.2. Using bind
There are a few possibilities with bind or tinydns nowadays, but imho none of
them is a "real" solution (yet). I must say, however, that i have no
experience with any of them. They are listed below.
-----------------------------------------------------------------------------
5.2.1. Bind patch
David Storey is working on a patch for Bind, which makes it get its data
directly from ldap. This means that every time a request is performed on the
bind daemon, it does a lookup in ldap. At this time, his future plans were:
(Taken from the source) to have at least two modes of operation: cached and
dynamic. Cached mode operates just like an rbtdb by loading the entire zone
into memory and reloading whenever the server is HUP'ed. Dynamic mode is much
like it is now: every request means an LDAP lookup. For up to date
information you should check out the [ftp://ftp.eyeo.com/bind/] sources.
-----------------------------------------------------------------------------
5.2.2. ldap2dns
Taken entirely from their website:
ldap2dns is a program to create DNS records directly from a LDAP directory.
It can and should be be used to replace the secondary name-server by a second
primary one. ldap2dns helps to reduce all kind of administration overhead. No
more flat file editing, no more zone file editing. After having installed
ldap2dns, the administrator only has to access the LDAP directory. If he
desires he can add access control for each zone, create a webbased GUI and
add all other kind of zone and resource record information without
interfering with the DNS server. ldap2dns is designed to write binary
data.cdb files used by tinydns, but also may be used to write .db-files used
by named.
The projects homepage is [http://ldap2dns.tiscover.com/] here.
-----------------------------------------------------------------------------
5.2.3. ispman
ispman is a perl-based isp management package. It uses an ldap database
backend for it's configuration. It can do lot's of things, so you might check
out what you need exactly. It's at [http://www.ispman.org] ispman.org.
-----------------------------------------------------------------------------
6. Mail Transfer Agents
i will describe three different MTA's in this section, Sendmail, Postfix and
Qmail. These are three MTA's that can be configured to use Ldap for the
retrieval of information. From personal experience, I must say that Postfix
is much easier to set up than sendmail, but this may change in the future, as
the ldap support in sendmail develops to a more mature state. I have not used
qmail myself.
-----------------------------------------------------------------------------
6.1. Sendmail
6.1.1. Ldap support in sendmail
Sendmail has support for ldap since somewhere around version 8.8.x using the
map type ldapx.From version 8.10 and up an ldap database type ldap is
supported. Please note that the ldap map support is not enabled per default
in the RedHat package. Debian versions 2.2 and later do have ldap support in
their sendmail, I am told. If you have to compile it yourself, please read
the file sendmail/README from the sendmail sources. It contains valuable
information about how to compile in the ldap support.
Both the old and the new ldap map type have the ability to look up entries in
an ldap database. There is one thing that must be noted however. When a
search is being done, only one result should be returned. If more results are
found, only the first is used. Additionally, is multiple return values for
that result are found, only the first is returned. Let's take a look at the
following example ldif file:
dn: cn=mailuser1,ou=mail,dc=company,dc=com
objectclass: top
objectclass: foo
cn: mailuser1
mail: mailuser1@company.com
mail: info@company.com
If a search is performed with a simple search filter like cn=mailuser1, and
the attribute that is asked for is mail, only mailuser1@company.com, is
returned. To get both results, they should we stored in a single-valued
attribute with comma-separated values, like this:
mail: mailuser1@company.com, info@company.com
An email message containing information related to this subject can be found
at the [alias_issues] LIH home.
-----------------------------------------------------------------------------
6.1.2. System layout.
When ldap maps are available, almost anything can be looked up in an ldap
database. What we would like to do is to simplify the configuration of the
following setup.
Let's say we have a medium-sized or large network where we recieve for many
domains. We have two mailhosts and two or three fallback hosts. This setup
will normally have four places where three types of information are stored.
<EFBFBD><EFBFBD>*<2A>The mailhosts both need a file , or traditionally sendmail.cw, to store
the domains for which they should recieve mail. The fallback hosts keep
the same information in the access file, but they use it to list the
domains for which they should relay any incoming mail.
<EFBFBD><EFBFBD>*<2A>The mailhosts both have a virtusers file, which maps multiple adresses
(or entire domains) to a single virtual or local user.
<EFBFBD><EFBFBD>*<2A>The mailhosts both have an aliases file, which maps virtual users to one
or more mail addresses or local users.
If this information is stored in a single database, each host will read its
configuration from that database, which improves both the manageability and
the scaleability of the network. One could even think of a single host which
carries all data, mapped to with nfs. In such a case it makes no difference
anymore to which host we are connecting. To a user, they appear to be all the
same.
-----------------------------------------------------------------------------
6.1.3. Sendmail configuration file
To understand how this information is read from an ldap database instead of
the regular files a little background knowledge of the sendmail.cf file is
neccesary. The information we're dealing with here is stored in two different
ways. The local-host-names file is read into a class (class w, to be exactly,
hence the old extension cw), while the virtusers file is used through a
simple map. The aliases file is also a map, but it is defined in a different
manner and used internally, instead of being referred to in rules.
When information is retrieved from a ldap database, it always ends up being
in a map. This is somewhat problematic with the information stored in the
local-host-names file, because this used to be a class. I have been unable to
fill the class with the information from the map or something alike. That
would be the easy way, but I think it's not possible. (If I'm incorrect about
this, please let me know). Therefore, I had to define a new map, and insert
rules in the sendmail configuration to make sure that (almost) every time
when a value is looked up in the class, the new map is searched for the value
too.
For the maps, the change of configuration is easy. A map is normally defined
with a name and database type, and some database-specific options, (like the
location of the file, for the normally used newdb database types). So for
maps, it suffices to change the definition of the map and voila, we're done.
Ldap maps have a few more options, some of which can be predefined. They are
explained in the following list (largely taken from Booker Bense's document):
Ldap-specific map options in sendmail.cf
-h
Defines a space-separated list with hostnames of ldap servers. All
machines will be queried in this order, until a result is found. This can
be configured globally.
-b
Defines the ldap search base, e.g. the ldap directory you are going to
search in. This can be configured globally.
-k
Defines the ldap search filter. It is a "sprintf" style string that
defines how the map takes it's input value and constructs an ldap search.
It has the form of an ordinary ldap search filter, with %s replaced by
the value that is searched for. To learn more about ldap search filters
please see [http://www.cis.ohio-state.edu/htbin/rfc/rfc2254.html] RFC
2254. The search filter and the search base used above should define a
search that returns at most one entry. The ldap map will only use the
first entry it recieves.
-v
Defines the ldap attribute of which the value will be returned by the map
lookup. Explained in detail later.
PLease note that all ldap options must be double-quoted and must immediately
follow the sendmail option. Here is an example:
Kldapexamplemap ldap -h"localhost ldap.myorg.com" -b"ou=mail,dc=myorg,dc=com" -k"(mailstuff)(uid=%s))" -v"mailaddress"
-----------------------------------------------------------------------------
6.1.4. Schema
For this particular setup I have defined a subtree mail in the ldap
directory, under which all mail-related information will be stored. I t would
have been possible to store some of the user-related mail-information in the
ou=Users subtree, but I have specificalle chosen not to do this. When using a
separate subtree, all information for sendmail is stored in a single place,
and, when having many users, searches may be faster, because not the entire
ou=Users subtree needs to be searched, but only the ou=mail subtree.
In this subtree two kinds of records will appear.
1. Entries that hold mappings from the virtuser file and aliases file, for a
single virtual user. I have chosen to store both mappings in a single
entry, because this clarifies the effect and configuration used. For this
I have defined an objectclass inetmailrecipient, and three attributes,
mailid, mailacceptinggeneralid and maildrop.
inetmailrecipient
This is a classification that tells us the entry is some form of
mapping from one or more real mail addresses and/or mail domains to
one or more real users.
mailid
This describes the mail addresses that this virtual user recieves
mail for. Can be in the form of normail addresses, like foo@myorg.com
, or complete domains like @my2nd.org. Multiple of these attributes
may be present, but they should all contain only one value. For each
of these id's mail is sent to mailacceptinggeneralid.
Here you'll put what you used to put at the left side in the
virtusers file.
mailacceptinggeneralid
Defines a virtual user. This is in fact the link between the
virtusers and aliases file. In each entry, one attribute of this type
must be present, but no more than one may be present, and the
attribute may contain only one value. This can either be a local
username, or a virtual user. In the second case, a maildrop attribute
must be present, in the first case, it does not.
Here you'll put what you used to put in the virtusers file, and at
the left side in the aliases file.
maildrop
Defines the addresses and/or users that mail received for should be
delivered to. Only one attribute of this type may be present, but it
may contain a comma-separated list of addresses and/or users. If the
value of mailacceptinggeneralid is a virtual user, this attribute
must be present. If the value is a real user, this entry may be
omitted.
Here you'll put what you used to put at the right side in the aliases
file.
In general, one could say that the mailid and mailacceptinggeneralid
together provide the functionality of the virtusers file, and
mailacceptinggeneralid and maildrop together provide the functionality of
the aliases file.
2. One or more entries that hold the domain names which would normally apear
in the sendmail.cw and access files. For this I have defined an
objectclass inetmaildomain, and three attributes, maildomain,
sendmailislokalkey and sendmailaccesskey.
inetmaildomain
This is a classification that tells us the entry lists mail domains
which belong to our system, and either should be delivered locally,
or be relayed to another host.
maildomain
Defines the mail domain. Multiple of these attributes may be
presentin a single entry. The value should be the domain without the
"@".
For each of the dmain entries in the local-host-names file, one of
these attributes should be present.
sendmailislocalkey
This defines a simple key that is used in the sendmail rules to
determine if a domain is local. It can be anything really, but is
must be the exact string you will use in your sendmail rules. For now
I have used <LDAPLOCAL>. One attribute of this type must be present,
and no more than one may be present in each entry.
sendmailaccesskey
This defines the key that is used in the sendmail rules to determine
what action needs t be taken for the specified domain. It can be one
of RELAY, OK, REJECT, DISCARD or an error indicator. (For detailed
information see the cf/README file from the sendmail sources.)
Note: PLease note that in this particular setup I will only be using
entire domains in the access file. That means that in this case I can
use the maildomain attribute for both the information used in the
access file and the information used in the local-host-names. If you
want a finer control over your access list, you should define a
separate entry to hold that information, instead of using the
maildomain attribute.
-----------------------------------------------------------------------------
6.1.5. More information.
Here are a few sources of information that might be useful:
<EFBFBD><EFBFBD>*<2A>Booker Bense has written a [http://www.stanford.edu/~bbense/ldap/
Inst.html] document about the usage of ldap with sendmail 8.9.3. He says
it's the wrong place to start when learning about using sendmail and
ldap, but it has been of great help to me.
<EFBFBD><EFBFBD>*<2A>[http://www.iconimaging.net/~jradford/sendmail/sendmail-ldap.html] A
short howto about how to setup sendmail with ldap, written by Jason
Christopher Radford
<EFBFBD><EFBFBD>*<2A>[http://ldapman.org/articles/index.html] New articles about ldap and
sendmail are being published on [http://www.sendmail.net] sendmail.net,
written by Michael Donnelly, originating from [http:///www.ldapmap.org]
ldapmap.org, which has also a lot of general interesting ldap-related
information.
-----------------------------------------------------------------------------
6.2. Postfix
6.2.1. Support
Postfix has native ldap support. A lot of options in postfix can be
configured using maps which can be of various types. One of those types is
ldap. For each ldap map a couple of options can be configured. (See Section
6.2.2.)
The process of having postfix look up certain data in an ldap database is
pretty straightforward. The most common use (so i think) is to have postfix
look up virtual users in the ldap database. Together with the above explaind
nss_ldap feature, this allows you to have all your email users in an ldap
database. But other things can be configured too, like the domains postfix is
allowed to relay mail for, or relay mail from, or for which is should act as
a backup mail server.
-----------------------------------------------------------------------------
6.2.2. Configuration
The description of the configuration options is completely taken from
LDAP_README in the postfix docs from version 20001217.
server_host
The name of the host running the LDAP server, e.g.
ldapsource_server_host = ldap.your.com
It should be possible with all the libraries mentioned above to specify
multiple servers separated by spaces, with the libraries trying them in
order should the first one fail. It should also be possible to give each
server in the list a different port, by naming them like "ldap.your.com:
1444".
server_port (389)
The port the LDAP server listens on, e.g.
ldapsource_server_port = 778
search_base (No default; you must configure this.)
The base at which to conduct the search, e.g.
ldapsource_search_base = dc=your, dc=com
timeout (10 seconds)
The number of seconds a search can take before timing out, e.g.
ldapsource_timeout = 5
query_filter (mailacceptinggeneralid=%s)
The RFC2254 filter used to search the directory, where %s is a substitute
for the address Postfix is trying to resolve, e.g.
ldapsource_query_filter = (%s)(paid_up=true))
domain (No default; you must configure this.)
This is a list of domain names, paths to files, or dictionaries. If
specified, only lookups ending in a domain on this list will be searched.
This can significantly reduce the query load on the LDAP server.
ldapsource_domain = postfix.org, hash:/etc/postfix/searchdomains
result_attribute (maildrop)
The attribute(s) Postfix will read from any directory entries returned by
the lookup, to be resolved to an email address.
ldapsource_result_attribute = mailbox,maildrop
special_result_attribute (No default)
The attribute(s) of directory entries that can contain DNs or URLs. If
found, a recursive subsequent search is done using their values.
ldapsource_special_result_attribute = member
scope (sub)
The LDAP search scope: sub, base, or one. These translate into
LDAP_SCOPE_SUBTREE, LDAP_SCOPE_BASE, and LDAP_SCOPE_ONELEVEL.
bind (yes)
Whether or not to bind to the LDAP server. Newer LDAP implementations
don't require clients to bind, which saves time. Example:
ldapsource_bind = no
If you do need to bind, you might consider configuring Postfix to connect
to the local machine on a port that's an SSL tunnel to your LDAP server.
If your LDAP server doesn't natively support SSL, put a tunnel (wrapper,
proxy, whatever you want to call it) on that system too. This should
prevent the password from traversing the network in the clear.
bind_dn ("")
If you do have to bind, do it with this distinguished name. Example:
ldapsource_bind_dn = uid=postfix, dc=your, dc=com
bind_pw ("")
The password for the distinguished name above. If you have to use this,
you probably want to make main.cf readable only by the Postfix user.
Example:
ldapsource_bind_pw = postfixpw
cache (no)
Whether to use a client-side cache for the LDAP connection. See
ldap_enable_cache(3). It's off by default.
cache_expiry (30 seconds)
If the client-side cache is enabled, cached results will expire after
this many seconds.
cache_size (32768 bytes)
If the client-side cache is enabled, this is its size in bytes.
dereference (0)
When to dereference LDAP aliases. (Note that this has nothing do with
Postfix aliases.) The permitted values are those legal for the OpenLDAP/
UM LDAP implementations:
0 never
1 when searching
2 when locating the base object for the search
3 always
-----------------------------------------------------------------------------
6.2.3. Example setup
If you want a virtual domain (say foo.virtualdomain.com) and you want to
store email addresses in Ldap for this domain, youwould need the following
piece in your main.cf.
virtual_maps = ldap:ldapvirtual
ldapvirtual_search_base = ou=mail,o=YourOrg,c=nl
ldapvirtual_query_filter = (mailacceptinggeneralid=%s)
ldapvirtual_domain = foo.virtualdomain.com
ldapvirtual_result_attribute = maildrop
ldapvirtual_bind = no
ldapvirtual_scope = one
With this setting, if postfix receives mail for a user with a domain part
"foo.virtualdomain.com", to do a search in the database for entries that have
an attribute mailacceptinggeneralid that matches
"user@foo.virtualdomain.com". If such an entry is found, the values of all
available maildrop attributes are returned, and to these values the mail is
delivered. If "user@foo.virtualdomain.com" is not found, another query is
performed, that tries to match the catchall user, "@foo.virtualdomain.com".
If this is again not found, the message will be bounced.
-----------------------------------------------------------------------------
6.3. Qmail
Qmail itself does not have any ldap support. However, there is a patch by
Andre Oppermann that provides ldap support. This package, including the
documentation for it, can be found at [http://www.nrg4u.com] his site.
-----------------------------------------------------------------------------
7. Address books
A very useful feature of an Ldap database on a linuxserver is that when you
have an internal network in your organization, you can have a single place to
store all your external contacts. You could even divide it in groups, or
departments. It is no longer neccesary to give each employee a seperate
address book. Apart from using Ldap, this could also be done with Microsoft
Exchange Server, Lotus Domino, and Netscape Active Directory.
To use Microsoft Address Book and programs that rely on it, such as Microsoft
Outlook, Microsoft Outlook Express and Microsoft Outlook 2000 there is no
need to change the basic ldap configuration. There are two things that need
to be modified though.
At first, you have to create a directory tree to store your addresses and
relevant data. In Section 11 will be shown which entries will be used in this
tree.
Second, you have to make sure that all hosts on your local network have read
access to this tree. This will be dealt with in the chapter 'security' which
is not finished yet.
All Microsoft Email programs can use the Ldap Directory Services. If you want
to search for people, you have to use the Address Book. When composing a new
email message, a name can be automatically matched to an email address. To do
this, the cn,sn,givenname and mail fields are searched. When you want to
configure your Microsoft email program to use an Ldap server as your address
book, or to look up email addresses, you need to do the following:
1. Start your favorite email program and open the address book. This can be
done by selecting Tools, Addressbook from within the program, or via the
start menu by selecting Start,Programs,Accessories,Address Book.
2. Click on Tools,Accounts to open the Internet Account window.
3. Click Add, now you get an Internet Connection Wizard window, type the ip
address or hostname of your Ldap server, and click OK.
4. On the next window, answer Yes to confirm you want to check your adresses
using this directory, or No if you don't want do not want that. Now click
Next and click Finish.
5. Now you're back at the Internet Account window. Select your newly-added
account and click Properties.
6. On the properties window, click the Advanced tab.
7. In the Search Base field, enter the base of the tree where your adresses
will be stored. An example could be ou=Addressbook,dc=yourorg,dc=com.
8. Press OK to close the window and click Close to close the Internet
Account window. You should have returned to the main Address Book window
now.
Now, when you enter a name in the to: field, the email address is looked up
in the Ldap Directory, and automagically filled in for you. If an entry is
not found, a window is presented, and any typos can be corrected, or a new
search can be done.
-----------------------------------------------------------------------------
8. Netscape roaming access
ToDo.
A good article on this subject can be found [http://www.linuxworld.com/
linuxworld/lw-1999-09/lw-09-ldap-netscape.html] here.
-----------------------------------------------------------------------------
9. Publishing digital certificates with LDAP
This section focuses on how to publish digital certificates into an ldap
server. You need to publish digital certificates if you run a Certificaton
Authority. Publishing to LDAP is a simple way to make this information
available in the network .Also many certificate aware software uses LDAP as a
preferred repository for user certificates.
This allows to keep users certificates with the rest of the user information
avoiding useless replication of data.
To deal with certificates you need a cryptographic toolkit, the one used here
is OpenSSL.
-----------------------------------------------------------------------------
9.1. LDAP Server configuration
The LDAP server used here is OpenLDAP 2.0.x.
Your LDAP server must support objectclasses that allows attributes to store
certificates. In particular you need to store in the LDAP server the
Certification Authority certificate, the Certificate Revocation List, the
Authority Revocation List and end users certificates.
The certificationAuthority objectclass implements the
authorityRevocationList, certificateRevocationList and cACertificate
attributes.
The inetOrgPerson objectclass supports the usercertificate (binary)
attribute.
You can also use the mix-in objectclass strongAuthenticationUser to add
certificates to non inetOrgPerson entries.
You can include required schemas to OpenLDAP including the following schemas
into your slapd.conf file.
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
-----------------------------------------------------------------------------
9.2. Certificate Publishing
Certificates are encoded using ASN.1 DER (Distingushed Encoding Rules). So it
must be published into the LDAP server as a binary piece of data (using BER
encoding).
You can convert a pem certificate into der format using openssl
openssl x509 -outform DER -in incert.pem -out outcert.der
Then an LDIF file can be created using the ldif utility provided with
OpenLDAP. The command:
ldif -b "usercertificate;binary" < outcert.der > cert.ldif
creates an usercertificate attribute encoded in BASE64. You can add this
certificate to an LDIF entry and then use ldapmodify to add the certificate
to an entry.
ldapmodify -x -W -D "cn=Manager,dc=yourorg,dc=com" -f cert.ldif
Where cert.ldif contains something like:
dn: cn=user,ou=people,dc=yourorg,dc=com
changetype: modify
add: usercertificate
usercertificate;binary:: MIIC2TCCAkKgAwIBAgIBADANBgkqhkiG9w0BAQQFADBGMQswCQYD
VQQGEwJJVDENMAsGA1UEChMESU5GTjESMBAGA1UECxMJQXV0aG9yaXR5MRQwEgYDVQQDEwtJTkZO
IENBICgyKTAeFw05OTA2MjMxMTE2MDdaFw0wMzA4MDExMTE2MDdaMEYxCzAJBgNVBAYTAklUMQ0w
CwYDVQQKEwRJTkZOMRIwEAYDVQQLEwlBdXRob3JpdHkxFDASBgNVBAMTC0lORk4gQ0EgKDIpMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrHdRKJsobcjXz/OsGjyq8v73DbggG3JCGrQZ9f1Vm
9RrIWJPwggczqgxwWL6JLPKglxbUjAtUxiZm3fw2kX7FGMUq5JaN/Pk2PT4ExA7bYLnbLGZ9jKJs
Dh4bNOKrGRIxRO9Ff+YwmH8EQdoVpSRFbBpNnoDIkHLc4DtzB+B4wwIDAQABo4HWMIHTMAwGA1Ud
EwQFMAMBAf8wHQYDVR0OBBYEFK3QjOXGc4j9LqYEYTn9WvSRAcusMG4GA1UdIwRnMGWAFK3QjOXG
c4j9LqYEYTn9WvSRAcusoUqkSDBGMQswCQYDVQQGEwJJVDENMAsGA1UEChMESU5GTjESMBAGA1UE
CxMJQXV0aG9yaXR5MRQwEgYDVQQDEwtJTkZOIENBICgyKYIBADALBgNVHQ8EBAMCAQYwEQYJYIZI
AYb4QgEBBAQDAgAHMAkGA1UdEQQCMAAwCQYDVR0SBAIwADANBgkqhkiG9w0BAQQFAAOBgQCDs5b1
jmbIYVq2epd5iDjQ109SJ/V7b6DFw2NIl8CWeDPOOjL1E5M8dnlmCDeTR2TlBxqUZaBBJZPqzFdv
xpxqsHC0HfkCXAnUe5MaefFNAH9WbxoB/A2pkXtT6WGWed+QsL5wyKJaO4oD9UD5T+x12aGsHcsD
Cy3EVEaGEOl+/A==
It is also possible to specify the certificate in the LDIF file as:
userCertificate;binary:< file:///path/to/cert.der
-----------------------------------------------------------------------------
9.3. LDAP Aware Clients
Once you stored certificates in the server you may wonder to retrieve them.
Among other clients, Netscape has supprt to retrieve certificates
automatically from an LDAP server. Using the Security Panel-->User
Certificates-->Search Directory; you can search for certificates in the LDAP
dierctory and have them automatically installed in your Netscape certificate
database.
Another client that has good support for certificates is web2ldap [http://
www.web2ldap.de/] www.web2ldap.de
-----------------------------------------------------------------------------
10. SSL/TLS and SSL/TLS wrappers for LDAP
10.1. A Brief description of SSL
The Secure Socket Layer (SSL) is an application layer protocol that provides
a secure transmission channel between parties. It stands between TCP/IP and
application level protocols, such as HTTP, LDAP, SMTP etc... It is based on
public key cryptography systems (various ciphers can be used) and on X.509
certificates.
SSL was initially a Netscape protocol, then it has gone trough a
standardization process and now is called TLS (Transmission Layer Security).
It is commonly referred as SSL/TLS.
The SSL/TLS protocol provides:
<EFBFBD><EFBFBD>*<2A>Data encryption: Client/server session is encrypted
<EFBFBD><EFBFBD>*<2A>Server authentication: Client can verify the server identity
<EFBFBD><EFBFBD>*<2A>Message integrity: Data is not modified during transmission; this
prevents "man in the middle" attacks.
<EFBFBD><EFBFBD>*<2A>Client authentication: Server can verify the client identity
-----------------------------------------------------------------------------
10.2. SSL/TLS availability for OpenLDAP
Since OpenLDAP 2.0.x, that is an LDAP V3 toolkit, SSL/TLS is provided by the
server. OpenLDAP 2.0.x needs to be compiled using the OpenSSL library to add
SSL/TLS. It also has Start-TLS support.
Note: Start-TLS allows to enable TLS if the client requests it. This way
it is possible to use only an LDAP port for both secure and insecure
connections.
OpenLDAP 1.2.x, instead, is an LDAP V2 protocol implementation and does not
provide SSL/TLS.
Valuable information on SSL/TLS on OpenLDAP 2.0.x can be found on the
OpenLDAP web site, here we will focus how to use an SSL tunnel to secure LDAP
parties that are not SSL/TLS aware
-----------------------------------------------------------------------------
10.3. How to use stunnel to provide SSL/TLS to an LDAP V2 server
If you use OpenLDAP 1.2.x you need a general purpose SSL wrapper to add SSL
capabilities to the server. Stunnel ([http://www.stunnel.org]
www.stunnel.org) has been found to be stable and suitable for this
application.
Installing it is quite simple, but first you have to install OpenSSL ([http:/
/www.OpenSSL.org] www.OpenSSL.org) to have the required library and tools.
OpenSSL, is an open source implementation of the SSL protocol that provides
the SSL library and a set of cryptography tools.
To install OpenSSL you have to type the following commands:
$ ./config
$ make
$ make test
# make install
usually, everything will be installed in /usr/local/ssl.
If OpenSSL is correctly installed the only command needed to compile and
install stunnel are:
$ ./configure
$ make
# make install
Stunnel uses a server certificate for SSL, this can be a self signed
certificate, or, better, a certificate signed by your own Certification
Authority (the SSL client has to trust the CA too).
A commonly used place used to store such certificate is:
/usr/local/ssl/certs/stunnel.pem
If having a Certification Authority is not a concern, a self signed
certificate can be produced using the tools provided by the OpenSSL suite.
In the stunnel directory (to use the configuration file stunnel.cnf) type the
following commands:
$ openssl req -new -x509 -days 365 -nodes -config stunnel.cnf \
-out stunnel.pem -keyout stunnel.pem
$ openssl gendh 512 >> stunnel.pem
This will produce a self signed certificate, valid for a year, in the file
stunnel.pem.
Once stunnel is installed, you can start up first the LDAP server on port 389
(the default LDAP port):
#/usr/local/libexec/slapd
Then stunnel on port 636 (the port used by LDAPS client):
# /usr/local/sbin/stunnel -r ldap -d 636 \
-p /usr/local/ssl/certs/stunnel.pem
For debugging you can start stunnel in foreground with the following syntax:
# /usr/local/sbin/stunnel -r ldap -d 636 \
-D 7 -f -p /usr/local/ssl/certs/stunnel.pem
-----------------------------------------------------------------------------
10.4. How to use stunnel to provide SSL to LDAP clients
Many LDAP client are not SSL aware, anyway, it is possible using stunnel in
client mode, to provide SSL to these clients.
This is quite simple. You can start stunnel on the client host, using the
LDAPS port, and forward requests to this port to the actual LDAP server:
# stunnel -c -d 636 -r ldapserver.yourorg.com:636
Now LDAP clients must be configured using localhost:636 as the LDAPS server
to use.
-----------------------------------------------------------------------------
10.5. How to use stunnel to provide SSL for slurpd replication
At the moment slurpd (slapd replication daemon) hasn't SSL capabilities,
anyway you can use stunnel in client mode to have this job done.
Using stunnel in client mode on the master, you can forward a local port to a
remote port:
# stunnel -c -d 9636 -r ldapreplica.yourorg.com:636
and have on the master LDAP server in slapd.conf
replica host=localhost:9636
-----------------------------------------------------------------------------
11. Ldap schema's
Warning: this section is terribly incomplete and outdated. I should be
updating it, adding the various rfc's or other authoritive sources of
schematic data.
This is a proposition of a schema that can be used to accommodate all the
data needed for the previously listed functions. It should under no
circumstances be regarded as authoritative. It is an example that should
serve it's purpose, but it is likely you have to adapt it to match your
specific needs.
Because it has been a lot of work (for me, maybe it's out there but I don't
know where?) to find out the specific meaning of each entry, and what
information it should contain, I'll try to do this as well. It should be
noted, however, that it doesn't fit together seamlessly. The Microsoft
Addressbook does not seem to use some of the fields it is presenting. I
suspect that for the "Title", "Nickname", "Home City", "Home State/Province",
"Home ZIP Code", "Home Country/Region" and "Home Web Page" entries no
information is requested. For the "Personal", "Netmeeting" and "Digital IDs"
I didn't yet bother to figure out how it should be put in the Ldap database.
Any information is welcome. The netscape address book has a similar problem.
When a record is copied from an LDap directory to a local address book, some
of the fields are lost. As the nature of an company-wide addressbook should
discourage users to copy addresses locally, this is not a big problem though.
But netscape address book has another little oddity though. In a normal
address record, the Ldap attribute associated with "Nickname" is
xmozillanickname. When searching for addresses however, the associated
attribute is simple nickname. That is the reason why the nickname entry shows
up twice in the schema.
This schema is known to work with Microsoft Outlook 2000, and Netscape 4.73.
If you find I'm wrong about a description, function, or neccessity of an
entry, please do let me know!
The schema file that represent this schema can be found in Section 12.1.
Table 1. Ldap attributes and objectclasses - quick description
+---------+--------------------+-----------------------------+--------------+-----------+
|Function |Objectclass |Attributes |Description |(Default) |
| | | | |value |
+---------+--------------------+-----------------------------+--------------+-----------+
|User |top |<7C> |default |<7C> |
|accounts | +-----------------------------+--------------+-----------+
| | |ou |Organizational|Users |
| | | |Unit | |
| +--------------------+-----------------------------+--------------+-----------+
| |person |<7C> |Owner is a |<7C> |
| | | |person | |
| | +-----------------------------+--------------+-----------+
| | |uid |unix login |foo |
| | | |name | |
| | +-----------------------------+--------------+-----------+
| | |cn |Common Name |Foo Bar |
| | +-----------------------------+--------------+-----------+
| | |sn |Surname |Bar |
| +--------------------+-----------------------------+--------------+-----------+
| |account |<7C> |Owner has an |<7C> |
| | | |account | |
| +--------------------+-----------------------------+--------------+-----------+
| |posixaccount |<7C> |Owner has a |<7C> |
| | | |Unix account | |
| | +-----------------------------+--------------+-----------+
| | |uidNumber |uid |513 |
| | +-----------------------------+--------------+-----------+
| | |gidNumber |gid |100 |
| | +-----------------------------+--------------+-----------+
| | |homedirectory |Home directory|/home/users|
| | | | |/foo |
| | +-----------------------------+--------------+-----------+
| | |userpassword |unix password |S3cr3t |
| +--------------------+-----------------------------+--------------+-----------+
| |sambaaccount |<7C> |Owner has a |<7C> |
| | | |samba account | |
| | +-----------------------------+--------------+-----------+
| | |ntuid |Unknown |uid |
| | +-----------------------------+--------------+-----------+
| | |rid |Unknown |uidnumber |
| | +-----------------------------+--------------+-----------+
| | |lmpassword |Lanman |Unused |
| | | |password hash | |
| | +-----------------------------+--------------+-----------+
| | |ntpasswd |NT password |Unused |
| | | |hash | |
| | +-----------------------------+--------------+-----------+
| | |loginshell |Users shell |/bin/ |
| | | | |pleurop |
+---------+--------------------+-----------------------------+--------------+-----------+
|Machine |top |<7C> |default |<7C> |
|accounts | +-----------------------------+--------------+-----------+
| | |ou |Organizational|Machines |
| | | |Unit | |
| +--------------------+-----------------------------+--------------+-----------+
| |posixaccount |<7C> |Owner has a |<7C> |
| | | |unix account | |
| | +-----------------------------+--------------+-----------+
| | |uid |login name |speed$ |
| | +-----------------------------+--------------+-----------+
| | |uidnumber |unix uid |514 |
| | +-----------------------------+--------------+-----------+
| | |gidnumber |gid |100 |
| | +-----------------------------+--------------+-----------+
| | |homedirectory |Home directory|Unused |
+---------+--------------------+-----------------------------+--------------+-----------+
|Microsoft|top |<7C> |default |<7C> |
|Address | +-----------------------------+--------------+-----------+
|Book | |ou |Organizational|Addressbook|
| | | |Unit | |
| +--------------------+-----------------------------+--------------+-----------+
| |microsoftaddressbook|<7C> |Owner has |<7C> |
| | | |Microsofts | |
| | | |Addressbook | |
| | | |properties | |
| | +-----------------------------+--------------+-----------+
| | |cn |Name |<7C> |
| | +-----------------------------+--------------+-----------+
| | |c |Business |<7C> |
| | | |country | |
| | +-----------------------------+--------------+-----------+
| | |department |Business |<7C> |
| | | |department | |
| | +-----------------------------+--------------+-----------+
| | |facsimiletelephonenumber |Business fax |<7C> |
| | | |number | |
| | +-----------------------------+--------------+-----------+
| | |givenname |First name |<7C> |
| | +-----------------------------+--------------+-----------+
| | |homephone |Home phone |<7C> |
| | | |number | |
| | +-----------------------------+--------------+-----------+
| | |homepostaladdress |Home postal |<7C> |
| | | |address | |
| | +-----------------------------+--------------+-----------+
| | |info |Notes |<7C> |
| | +-----------------------------+--------------+-----------+
| | |initials |Initials |<7C> |
| | +-----------------------------+--------------+-----------+
| | |l |Business city |<7C> |
| | +-----------------------------+--------------+-----------+
| | |mail |Email address |<7C> |
| | +-----------------------------+--------------+-----------+
| | |mobile |Home cellphone|<7C> |
| | | |number | |
| | +-----------------------------+--------------+-----------+
| | |organizationname |Company name |<7C> |
| | +-----------------------------+--------------+-----------+
| | |otherfacsimiletelephonenumber|Home fax |<7C> |
| | | |number | |
| | +-----------------------------+--------------+-----------+
| | |otherpager |Business pager|can be |
| | | |number |"pager" |
| | | | |too? |
| | +-----------------------------+--------------+-----------+
| | |physicaldeliveryofficename |Location of |<7C> |
| | | |office at work| |
| | +-----------------------------+--------------+-----------+
| | |postaladdress |Business |<7C> |
| | | |postal address| |
| | +-----------------------------+--------------+-----------+
| | |postalcode |Business |<7C> |
| | | |postal code | |
| | +-----------------------------+--------------+-----------+
| | |sn |Last Name |<7C> |
| | +-----------------------------+--------------+-----------+
| | |st |Business state|<7C> |
| | | |/province | |
| | +-----------------------------+--------------+-----------+
| | |telephonenumber |Business phone|<7C> |
| | | |number | |
| | +-----------------------------+--------------+-----------+
| | |title |Job title |<7C> |
| | +-----------------------------+--------------+-----------+
| | |url |Business web |<7C> |
| | | |page | |
+---------+--------------------+-----------------------------+--------------+-----------+
|Netscape |top |<7C> |default |<7C> |
|Address | +-----------------------------+--------------+-----------+
|Book | |ou |Organizational|Addressbook|
| | | |Unit | |
| +--------------------+-----------------------------+--------------+-----------+
| |netscapeaddressbook |<7C> |Owner has |<7C> |
| | | |Netscape's | |
| | | |properties | |
| | +-----------------------------+--------------+-----------+
| | |cn |Name |<7C> |
| | +-----------------------------+--------------+-----------+
| | |cellphone |Cellphone |<7C> |
| | | |number | |
| | +-----------------------------+--------------+-----------+
| | |countryname |Country |<7C> |
| | +-----------------------------+--------------+-----------+
| | |description |Description |<7C> |
| | +-----------------------------+--------------+-----------+
| | |facsimiletelephonenumber |Fax number |<7C> |
| | +-----------------------------+--------------+-----------+
| | |givenname |First Name |<7C> |
| | +-----------------------------+--------------+-----------+
| | |homephone |Home phone |<7C> |
| | | |number | |
| | +-----------------------------+--------------+-----------+
| | |homeurl |Personal web |<7C> |
| | | |page | |
| | +-----------------------------+--------------+-----------+
| | |locality |Home city |<7C> |
| | +-----------------------------+--------------+-----------+
| | |mail |Email address |<7C> |
| | +-----------------------------+--------------+-----------+
| | |nickname |Nickname |<7C> |
| | +-----------------------------+--------------+-----------+
| | |o |Company |<7C> |
| | +-----------------------------+--------------+-----------+
| | |ou |Department |<7C> |
| | +-----------------------------+--------------+-----------+
| | |pagerphone |Pager number |<7C> |
| | +-----------------------------+--------------+-----------+
| | |postalcode |Home postal |<7C> |
| | | |code | |
| | +-----------------------------+--------------+-----------+
| | |sn |Last name |<7C> |
| | +-----------------------------+--------------+-----------+
| | |st |State |<7C> |
| | +-----------------------------+--------------+-----------+
| | |streetaddress |Home postal |<7C> |
| | | |address | |
| | +-----------------------------+--------------+-----------+
| | |telephonenumber |Business phone|<7C> |
| | | |number | |
| | +-----------------------------+--------------+-----------+
| | |title |Title |<7C> |
| | +-----------------------------+--------------+-----------+
| | |xmozillaanyphone |Business phone|<7C> |
| | | |number | |
| | +-----------------------------+--------------+-----------+
| | |xmozillanickname |Nickname |Same as |
| | | | |nickname |
| | +-----------------------------+--------------+-----------+
| | |xmozillausehtmlmail |Client uses |TRUE |
| | | |html mail | |
+---------+--------------------+-----------------------------+--------------+-----------+
|Netscape |top |<7C> |default |<7C> |
|roaming | +-----------------------------+--------------+-----------+
|access | |ou |Organizational|Roaming |
| | | |Unit | |
+---------+--------------------+-----------------------------+--------------+-----------+
Note: Netscape and Microsoft use the addressbook entries in a slightly
different way. Netscape stores a postal address in the streetaddress
entry in a base64 encoded string, while Microsoft uses the postaladdress
entry. However, when a streetaddress entry is present, Microsoft uses
this instead of the postaladdress entry, but it's value is stored
plaintext, not base64 encoded. So you cannot use them at the same time.
More information about Ldap schema's in general can be found on [http://
ldap.hklc.com/] Linux Center. I found a document describing Microsoft
Addressbook's properties on the [http://msdn.microsoft.com/library/psdk/adsi/
gluser_4437.htm] Microsoft Developers Network.
Beware, the description given on the Microsoft page doesn't match the fields
where the content shows up in address book. Also, not all fields in address
book contain information, but if the listed keys don't work I wouldn't know
which keys do work.
-----------------------------------------------------------------------------
12. Example files
Here are the example files that can be used to setup an installation as I
described here.
-----------------------------------------------------------------------------
12.1. The schema file
# Unix related and default classes (Modified)
attribute userpassword ces
attribute telephonenumber tel
attribute facsimiletelephonenumber fax tel
attribute pagertelephonenumberpager tel
attribute homephone tel
attribute mobiletelephonenumber mobile tel
attribute member dn
attribute owner dn
attribute dn dn
objectclass top
requires
objectClass
objectclass organization
requires
objectClass,
o
allows
description
objectclass organizationalUnit
requires
objectClass,
ou
allows
description
objectclass person
requires
objectClass,
cn
allows
description
objectclass account
requires
objectClass,
uid
allows
description,
host,
o,
ou
# Samba related classes (Original)
objectclass sambaaccount
requires
objectclass,
uid,
uidnumber,
ntuid,
rid
allows
gidnumber,
grouprid,
nickname,
userpassword,
ou,
description,
lmpassword,
ntpassword,
pwdlastset,
smbhome,
homedrive,
script,
profile,
workstations,
acctflags,
pwdcanchange,
pwdmustchange
objectclass sambagroup
requires
cn,
rid
allows
ntuid,
member,
description
objectclass sambaconfig
requires
id
allows
nextrid
objectclass sambabuiltin
requires
cn,
sid
allows
ntuid,
rid,
member,
description
# Sendmail related class (new / modified)
objectclass inetmailrecipient
requires
objectclass
allows
mailid,
mailacceptinggeneralid,
maildrop
objectclass inetmaildomain
requires
objectclass,
sendmailislocalkey
allows
maildomain,
sendmailaccesskey
# Addressbook related classes
objectclass netscapeaddressbook
requires
objectclass,
cn
allows
cellphone,
countryname,
description,
facsimiletelephonenumber,
givenname,
homephone,
homeurl,
locality,
mail,
nickname,
o,
ou,
pagerphone,
postalcode,
sn,
st,
streetaddress,
telephonenumber,
title,
xmozillanickname,
xmozillausehtmlmail,
xmozillaanyphone
objectclass microsoftaddressbook
requires
objectclass,
cn
allows
c,
department,
facsimiletelephonenumber,
givenname,
homephone,
homepostaladdress,
info,
initials,
l,
mail,
mobile,
organizationname,
otherfacsimiletelephonenumber,
otherpager,
physicaldeliveryofficename,
postaladdress,
postalcode,
sn,
st,
telephonenumber,
title,
url
-----------------------------------------------------------------------------
12.2. Example base ldif
dn: dc=yourorg,dc=com
objectClass: top
objectClass: organization
o: YourOrg
description: This is our organizations base dn. Everything is stored beneath this
dn: ou=Users,dc=yourorg,dc=com
objectClass: top
objectClass: organizationalunit
ou: Users
description: This is the tree were user accounts are stored
dn: ou=Machines,dc=yourorg,dc=com
objectClass: top
objectClass: organizationalunit
ou: Machines
description: This is the tree were machine accounts are stored
dn: ou=Roaming,dc=yourorg,dc=com
objectClass: top
objectClass: organizationalunit
ou: Roaming
description: This is the tree were netscape roaming profiles are stored
dn: ou=Addressbook,dc=yourorg,dc=com
objectClass: top
objectClass: organizationalunit
ou: Addressbook
description: This is the tree were addressbook entries are stored
Notes
[1] A mechanism that permits LDAP database replication between servers.
[2] It is not a case that these are the maps provided by NIS.
[3] An entry can belong to several objectclasses.
[4] In a tricky way, it is also possible to use the Netscape Communicator
certificate database.
</sect1>
View Git Blame Copy Permalink