OpenLDAP installation and configuration: Difference between revisions
m (using an external editor) |
m (using an external editor) |
||
Line 84: | Line 84: | ||
Bascially, if you use client software such as an LDAP browser, it will access this information. | Bascially, if you use client software such as an LDAP browser, it will access this information. | ||
=== Importing an LDIF file === | === Importing / exporting an LDIF file === | ||
To import an LDIF file: | To import an LDIF file: | ||
/opt/sfw/sbin/slapadd -v -l your-ldif-file.ldif | /opt/sfw/sbin/slapadd -v -l your-ldif-file.ldif | ||
Warning: When exported, '''modified the structure''', then imported ldifs again I noticed that I had to kill all (well some at least) attributes added by the server ! | To export an LDIF file: | ||
/opt/sfw/sbin/slapcat > file_name.ldif | |||
Warning: When I exported, then '''modified the structure''' (e.g. put people inside a ou), then imported ldifs again I noticed that I had to kill all (well some at least) attributes added by the server ! | |||
E.g. | E.g. | ||
entryUUID: .... | entryUUID: .... | ||
entryCSN: .... | entryCSN: .... | ||
If I didn't kill these, I could find anything anymore. | If I didn't kill these, I could find anything anymore. Maybe an import/export option I didn't get ... | ||
=== Testing with a client === | === Testing with a client === |
Revision as of 19:57, 10 September 2008
This article or section is currently under construction
In principle, someone is working on it and there should be a better version in a not so distant future.
If you want to modify this page, please discuss it with the person working on it (see the "history")
Introduction
OpenLDAP is the most popular free LDAP server. Documentation is not obvious for beginners, i.e. it takes some time learn how to install and configure a production server.
OpenLDAP 2.x software implements version 3 of LDAP (RFC 4510)
Configuration notes for solaris 10
There is an OpenLDAP version included in a typical installation. You can find it here:
/opt/sfw /opt/sfw/sbin - links to binaries /opt/sfw/libexec - binaries /opt/sfw/etc/openldap - configuration files /opt/sfw/var/openldap-data - default data /opt/sfw/var/run - PID of the server
- Binaires in /opt/sfw/sbin
slapadd -> ../libexec/slapd slapcat -> ../libexec/slapd slapdn -> ../libexec/slapd slapindex -> ../libexec/slapd slappasswd -> ../libexec/slapd slaptest -> ../libexec/slapd slapcat -> ../libexec/slapd slapdn -> ../libexec/slapd slapindex -> ../libexec/slapd slappasswd -> ../libexec/slapd slaptest -> ../libexec/slapd
The configuration file
Location:
/opt/sfw/etc/openldap/sladpd.conf
You will have to define
- What schemas to load in
- Where datafiles and pidfile etc. go
- What users are allowed to do
Here is a fictional example (comments taken away from the original):
include /opt/sfw/etc/openldap/schema/core.schema include /opt/sfw/etc/openldap/schema/cosine.schema include /opt/sfw/etc/openldap/schema/inetorgperson.schema include /opt/sfw/etc/openldap/schema/nis.schema # Add your own include /opt/sfw/etc/openldap/schema/tecfa.schema pidfile /opt/sfw/var/run/slapd.pid argsfile /opt/sfw/var/run/slapd.args security ssf=1 update_ssf=112 simple_bind=64 # Access contol (this is too minimalistic) access to attr=userpassword by self write by anonymous auth access to * by self write by users read database bdb # Suffix and root dn, adjust to your own organization suffix "dc=tecfa, dc=unige, dc=ch" # Note: The root uid does not need to be in the LDAP database rootdn "uid=xxxx, dc=tecfa, dc=unige, dc=ch" rootpw secret directory /opt/sfw/var/openldap-data index objectClass eq
You may want to put the data and schema files in some other place than the default, since you may by mistake kill them after an upgrade of the system. e.g. I used /var/openldap instead of /open/sfw/var/
The Root DSE
(more needed, still a mystery for me)
The LDAP protocol assumes there are one or more servers that jointly provide access to a Directory Information Tree (DIT). At the root of the DIT is a DSA-specific Entry (DSE) and it is not part of any naming context. The root DSE (DSA-specific Entry) data can be retrieved from an LDAPv3 server by doing a base-level search with a null BaseDN and with filter ObjectClass=*. The root DSE publishes information about the LDAP server including which LDAP versions it supports, any supported SASL mechanisms, supported controls as well as the DN for its subschemaSubentry. In addition to server information, operational attributes may be exposed that allow for extended administration functionality.
Bascially, if you use client software such as an LDAP browser, it will access this information.
Importing / exporting an LDIF file
To import an LDIF file:
/opt/sfw/sbin/slapadd -v -l your-ldif-file.ldif
To export an LDIF file:
/opt/sfw/sbin/slapcat > file_name.ldif
Warning: When I exported, then modified the structure (e.g. put people inside a ou), then imported ldifs again I noticed that I had to kill all (well some at least) attributes added by the server ! E.g.
entryUUID: .... entryCSN: ....
If I didn't kill these, I could find anything anymore. Maybe an import/export option I didn't get ...
Testing with a client
You can test your LDAP through an LDPA client like Apache Directory Studio. To connect to your LDAP server, make sure that the port is open both on your client machine and the server machine. By default LDAP uses port 389.
We suggest to install "Apache Directory Studio". To configure a connection to an LDAP server: Menu->LDAP->New connection
In the Authentication tab enter:
Bind DN or user: <the root dn you defined above>
Else, you may have the command line ldapsearch installed. More difficult, but a better bet for debugging.
Syntax for connecting as LDAP administrator:
ldapsearch -b <starting point> -D <user dn for connecting> -w - filter
Example: The following will display all attributes of the object uid=joemiller
ldapsearch -b "o=tecfa.unige.ch" -D "uid=root,o=tecfa.unige.ch" -w - "uid=joemiller"
Example: The following will search for "Daniel" in givenname(s) and display what it can to an anonymous bind (user).
ldapsearch -b "o=tecfa.unige.ch" -v "givenname=Daniel"
- "b <starting point>" refers to the top of the tree you want to search. It must be a distinguished name, e.g. "ou=people,dc=example,dc=com". Starting points can be very different from server to server.
- "-w -" will have it prompt for a password.
- "-h host" allows to specify a host, by default it is localhost
- "-v will make verbose output (diagnostics).
The startup script
To start/stop automatically the server you can write a script like this, put it in /etc/init.d and then make links from /etc/rc3.d, /etc/rc0.d etc.
#!/bin/sh STARTCMD="/opt/sfw/libexec/slapd" LISTENPORTS="ldap:/// ldaps:///" STOPCMD="kill -INT `cat /var/openldap/run/slapd.pid`" # These are some string we reuse to give feedback. DESC="OpenLDAP standalone Deamon (slapd)" ERRORMSG="!!!! ERROR:" # This is used to see if slapd is running. Contains null if it doesn't # or a process description if it does. ISRUNNING=`cat /var/openldap/run/slapd.pid` # Now we check for the argument given on command line # and act unpon its value case "$1" in 'start') # We test if the server is not already running if [ -z "$ISRUNNING" ] ; then # We test if the server is effectively started when the command is issued. if $STARTCMD -h "$LISTENPORTS" ; then echo "$DESC started" ; else echo "$ERRORMSG $DESC could not be started" exit ; fi else echo "$ERRORMSG $DESC is already running" ; fi ;; 'stop') # We test if the server is already running if [ ! -z "$ISRUNNING" ] ; then # We test if the server is effectively stopped when the command is issued. if $STOPCMD ; then echo "$DESC stopped" ; else echo "$ERROR $DESC could not be stopped" ; fi else echo "$ERRORMSG $DESC is not running" exit ; fi ;; 'restart') # We test if the server is already running if [ ! -z "$ISRUNNING" ] ; then # We test if the server is effectively stopped when the command is issued. if $STOPCMD ; then # We test if the server is effectively started when the command is issued. if $STARTCMD -h "$LISTENPORTS" ; then echo "$DESC restarted" ; else echo "$ERRORMSG $DESC stopped but not restarted" exit ; fi else echo "$ERRORMSG $DESC could not be stopped (and hence not restarted)" exit ; fi else echo "$DESC is not running: Starting" ; if $STARTCMD -h "$LISTENPORTS" ; then echo "$DESC started" ; else echo "$ERRORMSG $DESC could not be started" exit ; fi fi ;; 'debug') # We test if the server is already running if [ ! -z "$ISRUNNING" ] ; then echo "Server was running: stopping" if $STOPCMD ; then echo "STOPPED" ; else echo "$ERRORMSG $DESC could not be stopped" exit ; fi fi # we look if a second argument is given for debug level if [ -z "$2" ] then LOGLEVEL="4095" ; else LOGLEVEL="$2" ; fi echo "attempting to start $DESC" echo "in debug mode with loglevel $LOGLEVEL" echo echo "terminal will remain open if it succeeds" echo "exit with CTRL-C" # Starting the server in debug mode if $STARTCMD -d $LOGLEVEL -h "$LISTENPORTS" ; then # this is a little tricky because the message outputs only # when Ctrl-C is issued. echo "$DESC STOPPED..." ; else echo echo echo "!!!!!!!!!!!!!!!!!!!!!!!!!!" echo "$ERRORMSG $DESC could not be started in debug mode" echo "$ERRORMSG or has exited abnormaly" echo "!!!!!!!!!!!!!!!!!!!!!!!!!!" echo "Check for error messages in the debug trace" echo exit ; fi ;; *) # We show how to use that script if the given argument is not recognized. echo "**************************************************************************" echo "* Usage : /etc/init.d/openldap.server {start|stop|restart [debug_level]} *" echo "**************************************************************************" ;; esac
See also on the Internet, e.g. OpenLDAP Start/stop script from LinAgora.org.
Notes for Ubuntu 4.1
OpenLDAP is distributed through the Synaptic Package Manager.
- The installer will ask the rootdn password.
- It also will automatically launch the LDAP server (use Menu System->Administration->Services to stop it again)
Configuration files are in:
/etc/ldap/
Operational attributes
There exist so-called operational attributes like "modifyTimestamp". They are not returned unless you specifically request it. You must also have the appropriate permission to view the attribute.
In OpenLDAP, you can ask for "+" to fetch all the operational attributes for an entry. That would look something like this:
ldapsearch -LLL -W -D "cn=Manager,dc=example,dc=com" -b "cn=Christoph,ou=People,dc=dexample,dc=com" "(objectClass=*)" '+'
Or just ask for the "modifyTimestamp" attribute by name. The "+" is similar in concept to the "*" which returns all the non-operational attributes.
An example ldif
This start of an ldif file shows the following:
- The base naming context is dc=tecfa, dc=unige, dc=ch
- All people go inside a single organizational unit: dn: ou=people, dc=tecfa, dc=unige, dc=ch. Else if you distinguis between students, teachers and so forth, you will have to move entries once persons change status (see also "Flat is Good").
- In other words, each person has a dn like this:
dn: uid=xxxx, ou=people, dc=tecfa, dc=unige, dc=ch
dn: dc=tecfa, dc=unige, dc=ch dc: tecfa objectClass: dcObject objectClass: organization o: TECFA dn: ou=people, dc=tecfa, dc=unige, dc=ch objectClass: top objectClass: organizationalUnit ou: people description: All people in the LDAP structuralObjectClass: organizationalUnit dn: uid=dksuid, ou=people, dc=tecfa, dc=unige, dc=ch objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: tdsTecfaPerson givenName: Daniel sn: Schneider cn: Daniel Schneider uid: schneide description: Maitre d'enseignement et de recherche structuralObjectClass: tdsTecfaPerson tdsMemberCategory: TECFA bureau tdsMemberCategory: TECFA member tdsMemberCategory: TECFA teacher personalTitle: Dr. .... some entries deleted ....
Access control (ACL)
(not really complete)
OpenLDAP 2.0 contains two methods for specifying access control. The first is static, i.e. you define the rights in configuration files. wo other advantages of this method is that it should be more efficient in most cases and that the rules, being static, cannot be changed by external means using LDAP so it should be more secure. From an operational point of view, the problem of this method is that needs a server restart at every Access contol (ACL) change. (From the FAQ, Configuration / SLAPD Configuration)
The second method for access control inserts access control information inside the directory itself. Unfortunately, the standard for doing this in a way that is interoperable between servers of different vendors (this did not matter in the static config case) has not been finished and exists only as an Internet Draft (i.e. no RFC has been published and the specification might not even get enough consensus for an RFC to be published ever). (From the FAQ)
Via the old method (static)
access to <what> [ by <who> <access> [ <control> ] ]+
- Read 5.2 Securing the Directory (from the "Rocket scientist" manual).
- Read through the subcategories of More information about Access Control (scroll down the page and don't miss any links or examples ...)
Firstly you need to know about two principles:
- The general rule is: write special access rules first, generic access rules last.
- Never write more than a single rule about something. E.g. you can't have two rules rules that define acces to *.
Let's have a look at a few ACL patterns:
By default, anyone and everyone can read anything but but only the rootdn can make any updates (need to verify this). This implicit rule could be made explicit like this:
access to * by * read
First rule you may concerns the user passwords. Users can update but not read their password and anonymous users can authenticate (else no user can log in).
access to attrs=userpassword by self =xw by anonymous auth
"self" refers to the user.
The following rule means that the owners have full access to their entry and users can read everything. This is something you probably don't want, i.e. you might want to show some information (e.g. homepages or email addresses to a public at large (anonymous readers)
access to * by anonymous none by self write by users read
The following allows anonymous users to read
Via the new method (inside the LDAP)
olcAccess: to <what> [ by <who> <accesslevel> <control> ]+
is a different way of doing it. You should read these olcAccess statements as ldif notation of an LDAP attribute.
- Read the Access Control Chapter of the manual.
- Type man slapd.access
Links
- OpenLDAP Software 2.0 - 2.4 Administrator's Guides
- tip: Use the 1HTML version to search through the page...
- Configuring slapd (version 2.3 on Feb 2008).
- LDAP Tutorial - Exercise with OpenLDAP v2.0.11 on Linux by P. Gietz and N. Klasen (2001)
- LDAP01, Sam Hart's classnotes