#2

OpenLDAP BootCampInstallation & Configuration

Doc. v. 0.1 - 08/03/09

Wildan Maulanawildan.m@openthinklabs.com

http://workshop.openthinklabs.com/

The Topics

● Installing binary OpenLDAP packages

● Configuring the LDAP server with the slapd.conf file

● Verifying the slapd.conf configuration with slaptest

● Starting and stopping server

● Configuring client tools with the ldap.conf file

● Fetching the root DSE entry from the directory with ldapsearch

Refresh your Memory

● As the 1st presentation, the OpenLDAP suite includes the following classes of tools :

● Daemons (slapd and slurpd)● Libraries (notably libldap)● Client Applications (ldapsearch, ldapadd,

ldapmodify)● Supporting utilities (slapcat, slapauth, and others)

Install OpenLDAP Binary

We will be using the Ubuntu Distribution

Dependencies

● The Barkeley Database (BDB)

● The OpenSSL libraries : These provides SSL and TSL security. SSL and TLS provide encryption for network connections to the directory

● The Cyrus SASL library : This provides support for secure authentication

● The Perl programming language

● iODBC database connectivity layer – to connect to the RDBMS

Installing OpenLDAP

● Run the following command to install server and it's clients :

$sudo apt-get install libldap-2.4-2 slapd ldap-utils

● SLAPD sometimes called the OpenLDAP server, handles client request and directory management

Configuring the SLAPD Server● SLAPD has one main configuration file, called

slapd.conf,located at /etc/ldap and any number of auxiliary configuration files

# slapd.conf - Configuration file for LDAP SLAPD########### Basics ###########include /etc/ldap/schema/core.schemainclude /etc/ldap/schema/cosine.schemainclude /etc/ldap/schema/inetorgperson.schemapidfile /var/run/slapd/slapd.pidargsfile /var/run/slapd/slapd.argsloglevel nonemodulepath /usr/lib/ldap# modulepath /usr/local/libexec/openldapmoduleload back_hdb########################### Database Configuration ###########################

database hdbsuffix "dc=example,dc=com"rootdn "cn=Manager,dc=example,dc=com"rootpw secretdirectory /var/lib/ldap# directory /usr/local/var/openldap-dataindex objectClass,cn eq######### ACLs #########access to attrs=userPassword by anonymous auth by self write by * noneaccess to * by self write by * none

Directive

● Include directive can be used to load any configuration files besides schema, including the ACL

● Schema provide definitions of the the different object classes and attribute types that OpenLDAP should support, using this OpenLDAP can determine what entries it is allowed to store, wheter any given entry is valid, and how entries should optimally be stored

– core.schema → contains all attributes and object class definition from LDAP v.3 spesification

– cosine.schema and inteorgperson.schema → contains schema definitions for commonly used standardized extensions (see RFCs 1274 and 2798 → Homework @_@)

More Directives

● pidfileThe process ID for the SLAPD server process

● argsfileThe arguments that were passed into the slapd command at startup

● loglevel Specifies how much information SLAPD should send to the system log (any, none, trace and so on)

● modulepath and moduleload for loading OpenLDAP modules

Database Configuration

● OpenLDAP is not limited to one database. More than one database can be used per server, where each database stores its own directory tree (or subtree) and one database can also have multiple trees.

● For ex. a single OpenLDAP instance can serve a directory tree whose base is o=My Company,c=US

from one database, and a directory tree whose root is dc=example,dc=com from a second database.

Review :

o = Organization c = Country dc = Domain Componentcn = Common Name

About HDB

● HDB is the new generation storage mechanism for OpenLDAP. Like its predecessor, the BDB backend, HDB uses the Oracle Berkeley DB database for storage, but HDB stores entries hierarchically, a perfect fit for LDAP's tree strucutre. The old BDB backend is still supported, and you can use it by specificing bdb instead of hdb in the database directive.

More Directives

● suffix indicates which parts of the directory tree this database will hold. On our example, it indicates that this database's will be the entry with the Distinguished Name (DN) specified in the suffix directive (dc=example,dc=com)

More Directives

● The rootdn directive specifies the DN that will be considered the administrator of this directory

rootdn = cn=Manager,dc=example,dc=com.

● The rootpw is used to assign a password for the directory manager

● The directory manager is a special user with special privileges. The manager's requests are not filtered through ACLs—the manager's access cannot be restricted.

● Furthermore, the manager has write access to all records in the directory under the specified suffix or suffixes. For that reason, the manager DN should be used for administrative tasks only and not for anything else.

More Directives

● The directory directive indicates which directory on the file system should hold the database files.

directory /var/lib/ldap

● The index directive is composed of a list of attributes that should be indexed, followed by the type of matching that the index will be used for.

index objectClass,cn ew

● We can also use multiple index directive :

index objectClass eq

index cn eq,sub

an equality (eq) index is maintained for objectClass attributes, while the cn attribute is indexed for equality matches (eq) and substring matches (sub).

ACLs – Access Control List

######### ACLs #########access to attrs=userPassword by anonymous auth by self write by * none

access to * by self write by * none

The purpose of this access control is to keep a user's password protected. Specifically, it allows anonymous users to request that the server perform an authentication comparison (during the process of logging on) on a password. Additionally, it grantsa user permission to change his or her own password. Finally,it denies everyone else any access to the password.

access to [resources] by [who] [type of access granted] by [who] [type of access granted] by [who] [type of access granted]

For any object and all its attributes (to *), if the currently connected DN is the DN of this object,it can write to the object (by self write). Otherwise, the currently connected DN has no access whatsoever (by * none).

Verifying a Configuration File

● To testing the slapd.conf configuration files, we can use slaptest :

$ sudo slaptest -v -f /etc/ldap/slapd.conf

or we can also use the slapd directly :

$ slapd -T dest -f /etc/ldap/slapd.conf

● You can read more about configuration options at the manual (man)

$man slapd.conf

Starting and Stopping the Server

● Using the init script : $sudo invoke-rc.d slapd start $sudo invoke-rc.d slapd stop $sudo invoke-rc.d slapd restart

● The init scripts set up default parameters and pass in many system options. Some of these are stored in a separate configuration file located at /etc/default/slapd

● The OpenLDAP server must start as root, in order to bind to the correct TCP/IP port (389 or 636 by default). Then it will switch and use user account and grup specified in the file located at /etc/default/slapd

Starting and Stopping the Server

● Running SLAPD directly :

$ sudo slapd or $ sudo slapd -d config (for debugging purpose)

● The server will write its process ID to the location specified in the pidfile directive in slapd.conf. In our case, this is /var/run/slapd/slapd

● To stop server we can use :

$ sudo kill `cat /var/run/slapd/slapd.pid`$ sudo kill `pgrep slapd`

Configuring the LDAP Clients

● Fortunately all of the OpenLDAP client programs share one common configuration file, ldap.conf, which is located in Ubuntu at /etc/ldap/ldap.conf

● The purpose of the ldap.conf is two-fold :

1. It provided a place to define certain aspects of client behavior, such as how they treat SSL/TLS certificates or whether they follow alias entries.

2. It provides the OpenLDAP clients with useful defaults. By specifying some defaults, we can reduce the number of parameters we have to pass to the OpenLDAP clients when we run them from the command line.

Configuring the LDAP Clients

● The ldap.conf file has three different kinds of directive:

● General settings, which specify things such as the default server and DN to use

● SASL-specific settings, which determine how the OpenLDAP clients will try to authenticate when using SASL (Simple Authentication and Security Layer) authentication mechanisms

● TLS-specific settings, which specify how OpenLDAP will handle connections that use SSL (Secure Sockets Layer) and TLS encryption

The ldap.conf

● ldap.conf file is located in the same directory as slapd.conf—/etc/ldap/

● Basic ldap.conf file :

# LDAP Client SettingsURI ldap://localhostBASE dc=example,dc=comBINDDN cn=Manager,dc=example,dc=comSIZELIMIT 0TIMELIMIT 0

Don't use this on a production environtment

About DSE

● Although We haven't actually put any entries in our database, SLAPD does provide directory-based access to certain information, including currently-loaded schemas and subschemas, configuration information, and a special record called the root DSE. The root DSE (DSA-Specific Entry, where DSA stands for Directory Service Agent—the technical term for an LDAP server) is a special entry that provides information about the server itself

● Please Read RFC 4512 for more information about this.

Testing the Server

● -x: This tells the server to use simple authentication (instead of the more complicated, but more secure, SASL authentication).

● -W: This tells the client to prompt us for an interactive password. The client will give the following prompt:

Enter LDAP Password:

● -D 'cn=Manager,dc=example,dc=com': This specifies the DN that we want to use to connect to the directory. In this case, we are using the directory manager account.

● -b "": This sets the base DN for the search. In the ldap.conf file we set the default base to be dc=example,dc=com. But to get the root DSE, which is not under dc=example,dc=com, we need to specify an empty search base.

● -s base: This indicates that we want to search for just one (base) entry—the entry with the DN specified in the -b parameter (the empty DN of the root DSE).

$ ldapsearch -x -W -D 'cn=Manager,dc=example,dc=com' -b "" -s base

Testing the Server

Q&A

Rererence

● Matt Butcher, Mastering OpenLDAP, PACKT Publishing