LDAP Linux HOWTO Luiz Ernesto Pinheiro Malere, malere@yahoo.com v1.01, 15 February 2000 Information about installing, configuring, running and maintaining a LDAP (Lightweight Directory Access Protocol) Server on a Linux machine is presented on this document. There are also details about how to create LDAP databases, how to update and delete information on the database, how to implement roaming access and how to use Netscape Address Book. This document is mostly based on the University of Michigan LDAP information pages. ______________________________________________________________________ Table of Contents 1. Introduction 1.1 What's LDAP ? 1.2 What's a Directory Service ? 1.3 How does LDAP work ? 1.4 LDAP backends, objects and attributes 1.5 New Versions of this Document 1.6 Opinions and Sugestions 1.7 Acknowledgments 1.8 Copyright and Disclaimer 2. Installing the LDAP Server 2.1 Downloading the package 2.2 Unpacking the server 2.3 Configuring the software 2.4 Building the server 3. Configuring the LDAP Server 3.1 Configuration File Format 3.2 Global Options 3.3 General Backend Options 3.4 LDBM Backend-Specific Options 3.5 Access Control Examples 4. Running the LDAP Server 4.1 Command Line Options 4.2 Running slapd as a Stand Alone Daemon 4.3 Running slapd from inetd 5. Database Creation and Maintenance 5.1 Creating a Database online 5.2 Creating a Database offline 5.3 More on the LDIF format 5.4 The ldapsearch, ldapdelete and ldapmodify utilities 6. Aditional Informations and Features 6.1 Roaming Access 6.2 Netscape Address Book 6.3 LDAP Migration Tools 6.4 Authentication using LDAP 6.5 Graphical LDAP tools 6.6 Killing the LDAP server 6.7 Logs 7. References 7.1 URLs 7.2 Books 7.3 RFCs ______________________________________________________________________ 1. Introduction The main purpose of this document is to setup 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 run a slapd which provides directory service for your local domain only, without replication, so without slurpd. This is a simple configuration for the server, good for starting but easy to upgrade to another configuration later if you want. The information presented on this document represents a nice initialization on using the LDAP protocol. Possibly after reading this document you would feel encouraged to expand the capabilities of your server and even write your own clients, using the already avaiable C, C++ and Java Development Kits. 1.1. What's LDAP ? LDAP is a client-server protocol for accessing a directory service. It was initially used as a front-end to X.500, but can also be used with stand-alone and other kinds of directory servers. 1.2. What's a Directory Service ? A directory is like 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. As a consequence, directories don't usually implement the complicated transaction or roll-back schemes that regular databases use for doing high-volume complex updates. Directory updates are typically simple all-or-nothing changes, if they are allowed at all. 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.3. 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 which 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.4. LDAP backends, objects and attributes Slapd comes with three different backend databases you can choose from. They are LDBM, a high-performance disk-based database; SHELL, a database interface to arbitrary UNIX commands or shell scripts; and PASSWD, a simple password file database. In this document I assume that you choose the LDBM database. The LDBM database works by assigning a compact four-byte unique identifier to each entry in the database. It uses this identifier to refer to entries in indexes. The database consists of one main index file, called id2entry, which maps from an entry's unique identifier (EID) to a text representation of the entry itself. Other index files are maintained as well. 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. An 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 LDBM 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. 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: o Groups in the directory, including unordered lists of individual objects or groups of objects. o Locations, such as the country name and description. o Organizations in the directory. o 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 (its 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 : o bin binary o ces case exact string (case must match during comparisons) o cis case ignore string (case is ignored during comparisons) o tel telephone number string (like cis but blanks and dashes `- ' are ignored during comparisons) o dn distinguished name Go to the first paragraph of ``section 3'' to know where the objectclass and attribute definitions lay on your system. 1.5. 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://dutedin.et.tudelft.nl/~malere/LDAP-Linux-HOWTO.html for new versions of this HOWTO. 1.6. 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 If you have commentaries and/or sugestions, please let me know too ! 1.7. 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. 1.8. Copyright and Disclaimer The LDAP Linux HOWTO is Copyrighted 1999 by Luiz Ernesto Pinheiro Malere. It can be distributed freely. It cannot be modified. If you have any kind of sugestion, please send me an email (I will update the document if the sugestion proceeds). If you want a translation, for example to Portuguese, you can send me an email about it too. No liability for the contents of this document can be accepted. I have no responsability about the consequences of following the steps provided in this document. If you have questions, please contact, the Linux HOWTO coordinator, at linux-howto@metalab.unc.edu 2. Installing the LDAP Server Four steps are necessary to install the server : Download the package, Unpack the software, Configure the Makefiles and Build the server. 2.1. 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 aditional documentation avaiable for it. This document supposes that you are using the OpenLDAP server. It's latest tar gziped version is avaiable on the following address : 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 To write this document, I used the OpenLDAP latest stable version and OpenLDAP 1.2.8 on a Slackware Linux machine with kernel 2.2.6. On the OpenLDAP site you can 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-990918.tgz, also available through the link openldap-stable.tgz. The latest development version was openldap-1_2_8.tgz. 2.2. Unpacking the server Now that you have the tar gziped package on your local machine you can unpack it. First copy the package to a desirable directory, for example /usr/local. Then use the following command : tar xvzf openldap-stable.tgz You can use this command too, as well : gunzip openldap-stable.tgz | tar xvf - 2.3. Configuring the software There are several options that you should like to customize so you can build the best software to your site. To configure the software you just need 2 steps : o Edit the file ldapconfig.h.edit, located on the subdirectory include beneath the directory where you unpacked the software. o Run the configure script (if you are a tough guy, you can also edit the Make-common file instead of running the configure script :^) In the file include/ldapconfig.h.edit you can set options like the location of the slapd and slurpd daemons. The file itself is well commented and it's default settings also reflect the most common administrator choices so, if you are in a hurry you can skip this step, and run directly: vi include/ldapconfig.h.edit The OpenLDAP server sources are distributed with a configuration script for setting options like instalation 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 prepar to build things on the default common location. So just type : ./configure And watch the output to see if all went well 2.4. Building the server After configuring the software you can start building it. First build the dependencies, using the command : make depend After build the server, 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 check the platform specific hints, they are located in the path doc/install/hints under the directory you unpacked the software. Now install the binaries and man pages. You may need to be superuser to do this (depending on where you are installing things): su make install That's all, now you have the binary of the server and the binaries of several other utilities. Go to the ``next'' section to see how to con- figure the operation of your LDAP server. If before learning how to configure your LDAP server you would like to test the recently built binaries, the latest versions of the OpenLDAP server come with a test script. When this document was updated the test script was not 100% stable for all diagnostics that it performed. Anyway you can try to run it and, if anything goes wrong with the script you can just abort it hitting Ctrl-C. In my case before the script stopped working I could see some successfull messages about the results of the most common diagnostics. To run the test script, go to the subdirectory /test beneath the path where you unpacked the software and type : make 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. In this directory you will also find the files slapd.oc.conf and slapd.at.conf which are included on the slad.conf file (see include option on ``section 3.2'') and that hold respectively the objectclasses and attributes definitions for the LDAP database backend. Next comes a description of the general format of the config file, followed by a detailed description of each config file option. 3.1. Configuration File Format The slapd.conf file consists of a series of global configuration options that apply to slapd as a whole (including all database backends), followed by zero or more database backend definitions that contain information specific to a backend instance. Global options can be overridden in a backend (for options that appear more than once, the last appearance in the slapd.conf file is used). 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. The general format of slapd.conf is as follows: # comment - these options apply to every database # first database definition & config options database # second database definition & config options database # subsequent database definitions & config options ... Configuration line arguments 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 `\', (e.g. `\\d').. The distribution contains an example configuration file that will be installed in the configuration prefix directory. Also provided are slapd.at.conf, which contains many commonly used attribute definitions, and slapd.oc.conf, which contains many commonly used object class definitions. 3.2. Global Options Options described in this section apply to all backends, unless specifically overridden in a backend definition. Option arguments that should be replaced by actual text are shown in brackets <>. access to [ by ]+ This option grants access (specified by ) to a set of entries and/or attributes (specified by ) by one or more requesters (specified by ). See the Access Control Examples for more details. attribute [] { bin | ces | cis | tel | dn } This option associates a syntax with an attribute name. By default, an attribute is assumed to have syntax cis. An optional alternate name can be given for an attribute. The possible syntaxes and their meanings are : bin : binary ces : case exact string (case must match during comparisons) cis : case ignore string (case is ignored during comparisons) tel : telephone number string (like cis but blanks and dashes `-' are ignored during comparisons) dn : distinguished name defaultaccess { none | compare | search | read | write } This option specifies the default access to grant requesters not matched by any other access line (take a look on Access Control examples down). Note that an access level implies all lesser access levels (e.g., write access implies read, search and compare). Default: defaultaccess read include This option 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. You can use this option to include the files that contain the objectclass and attribute definitions of your backend database. The LDAP software package comes with the files slapd.oc.conf and slapd.at.conf Note: You should be careful when using this option - there is no small limit on the number of nested include options, and no loop detection is done. loglevel This option specifies the level at which debugging statements and operation statistics should be syslogged (currently logged to the syslogd(8) LOCAL4 facility). You must have compiled slapd with - DLDAP_DEBUG for this to work (except for the two stats levels, which are always enabled). Log levels are additive. To display what numbers correspond to what kind of debugging, invoke slapd with the - ? flag or consult the table below. The possible values for are: 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 This will cause lots and lots of debugging information to be syslogged. Default: loglevel 256 objectclass [ requires ] [ allows ] This option defines the schema rules for the given object class. Used in conjunction with the schemacheck option. referral This option specifies the referral to pass back when slapd cannot find a local database to handle a request. Example: referral ldap://ldap.itd.umich.edu This will refer non-local queries to the LDAP server at the University of Michigan. 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. schemacheck { on | off } This option turns schema checking on or off. If schema checking is on, entries added or modified will be checked to ensure they obey the schema rules implied by their object class(es) as defined by the corresponding objectclass option(s). If schema checking is off this check is not done. Default: schemacheck off sizelimit This option specifies the maximum number of entries to return from a search operation. Default: sizelimit 500 srvtab This option specifies the srvtab file in which slapd can find the kerberos keys necessary for authenticating clients using kerberos. This option is only meaningful if you are using kerberos authentication, which must be enabled at compile time by including the appropriate definitions in the Make-common file. Default: srvtab /etc/srvtab timelimit This option 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 Options Options in this section only apply to the backend in which they are defined. They are supported by every type of backend. database This option marks the beginning of a new database instance definition. should be one of ldbm, shell, or passwd, depending on which backend will serve the database. Example: database ldbm This marks the beginning of a new LDBM backend database instance definition. lastmod { on | off } This option controls whether slapd will automatically maintain the modifiersName, modifyTimestamp, creatorsName, and createTimestamp attributes for entries. Default: lastmod off readonly { on | off } This option puts the database into "read-only" mode. Any attempts to modify the database will return an "unwilling to perform" error. Default: readonly off replica host=[:] "binddn=" bindmethod={ simple | kerberos } [credentials=] [srvtab=] This option specifies a replication site for this database. The host= parameter specifies 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 . If is not given, the standard LDAP port number (389) is used. 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, typically given as a "rootdn" in the slave's config file. It must also match the updatedn option in the slave slapd's config file. Since DNs are likely to contain embedded spaces, the entire "binddn=" string should be enclosed in quotes. bindmethod is either simple or kerberos, depending on whether simple password-based authentication or kerberos authentication is to be used when connecting to the slave slapd. Simple authentication requires a valid password be given. Kerberos authentication requires a valid srvtab file. The credentials= parameter, which is only required if using simple authentication, gives the password for binddn on the slave slapd. The srvtab= parameter, which is only required if using kerberos, specifies the filename which holds the kerberos key for the slave slapd. If omitted, /etc/srvtab is used. replogfile This option 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 option 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. rootdn This option specifies the DN of an entry that is not subject to access control or administrative limit restrictions for operations on this database. Example: rootdn "cn=Manager, o=U of M, c=US" rootkrbname This option specifies a kerberos name for the DN given above that will always work, regardless of whether an entry with the given DN exists or has a krbName attribute. This option is usefull when creating a database and also when using slurpd to provide replication service. Example: rootkrbname admin@umich.edu rootpw This option specifies a password for the DN given above that will always work, regardless of whether an entry with the given DN exists or has a password. This option is usefull when creating a database and also when using slurpd to provide replication service. Avoid having cleartext password on this option. At least provide an crypto (you can use an entry of Unix /etc/passwd file) password. Slapd supports other types of encryption methods too. Example: rootpw secret rootpw {crypto}encrypted_password_here suffix This option 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 "o=University of Michigan, c=US" Queries with a DN ending in "o=University of Michigan, c=US" 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. updatedn This option is only applicable in a slave slapd. It specifies the DN allowed to make changes to the replica (typically, this is the DN slurpd binds as when making changes to the replica). 3.4. LDBM Backend-Specific Options Options 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" line. cachesize This option specifies the size in entries of the in-memory cache maintained by the LDBM backend database instance. Default: cachesize 1000 dbcachesize This option 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 option 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 directory This option specifies the directory where the LDBM files containing the database and associated indexes live. Default: directory /usr/tmp index { | default} [pres,eq,approx,sub,none] This option specifies the indexes to maintain for the given attribute. If only an is given, all possible indexes are maintained. Example: index cn index sn,uid eq,sub,approx index default none This example causes all indexes to be maintained for the cn attribute; equality, substring, and approximate indexes for the sn and uid attributes; and no indexes for all other attributes. mode This option specifies the file protection mode that newly created database index files should have. Default: mode 0600 3.5. Access Control Examples The access control facility presented on ``section 3.2'' is quite powerful. This section shows some examples of its use. First, some simple examples: access to * by * read This access directive grants read access to everyone. If it appears alone it is the same as the following defaultaccess line. defaultaccess read 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=University of Michigan, c=US" subtree, to which search access is granted. 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. The next example again shows the importance of ordering, both of the access directives and the "by" clauses. It also shows the use of an attribute selector to grant access to a specific attribute and various selectors. access to dn=".*, o=U of M, c=US" attr=homePhone by self write by dn=".*, o=U of M, c=US" search by domain=.*\.umich\.edu read by * compare access to dn=".*, o=U of M, c=US" by self write by dn=".*, o=U of M, c=US" search by * none This example applies to entries in the "o=U of M, c=US" subtree. To all attributes except homePhone, the entry itself can write them, other U-M entries can search by them, anybody else has no access. The homePhone attribute is writable by the entry, searchable by other U-M entries, readable by clients connecting from somewhere in the umich.edu domain, and comparable by everybody else. Sometimes it is usefull 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 too 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 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. Note that the attr=member construct in the clause is a shorthand for the clause "dn=* attr=member" (i.e., it matches the member attribute in all entries). 4. Running the LDAP Server Slapd can be run in two different modes, stand-alone or from inetd(8). Stand-alone operation is recommended, especially if you are using the LDBM backend. This allows the backend to take advantage of caching and avoids concurrency problems with the LDBM index files. If you are running only a PASSWD or SHELL backend, running from inetd is an option. 4.1. Command Line Options Slapd supports the following command-line options. -d | ? This option sets the slapd debug level to . 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 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 65535 enable all debugging Debugging levels are additive. That is, if you want to trace function calls and watch the config file being processed, you would set level to the sum of those two levels (in this case, 65). Consult the file for more details. Note that slapd must have been compiled with -DLDAP_DEBUG defined for any debugging information beyond the two stats levels to be available. -f This option specifies an alternate configuration file for slapd. -i This option tells slapd that it is running from inetd instead of as a stand-alone server. On the following section about running slapd from inetd you will find more details. -p This option specifies an alternate TCP port on which slapd should listen for connections. The default port is 389. 4.2. Running slapd as a Stand Alone Daemon In general, slapd is run like this: $(ETCDIR)/slapd [