boosten.org

Creating my own LDAP Directory – part 1

Introduction

My home network is not that big, but sometimes it gets quite complicated. I have two web servers, one internal and one external (I could combine those, but it gives me a reason to keep the other server around), and both use authentication on some directories. All my family members have their own mailbox, which is accessed through IMAP.

These already add up to three different authentication schemes. To get rid of these, I started thinking about LDAP.

And since I’m at it, I easily could migrate other services as well.

For instance: my MTA, postfix, uses MySQL as backend for mail routing. Bind (DNS) uses flat files, and so does my DHCP server.

Let’s start big:

I started to think about the services that could use LDAP. While not all are possible (I suspect MySQL won’t be able to authenticate to LDAP), I started drawing the services.

In the next couple of articles I will describe my configurations, and in this article I will describe my LDAP configuration (so far, because it probably will grow during the next stages) and even some meaningful usage for it.

Creating the Data Information Tree

The first thing to think about is the design of your tree (actually the Data Information Tree, or DIT). There’s actually no wrong way to create this, just create what works for you.

Since my domain name is boosten.org, I chose a similar structure of my DIT.

The top level consists actually of two levels, ‘org’ and ‘boosten’. I could have gone for one level (for instance an ‘organization’ called ‘boosten’, but the first approach seems to be best practice.

Again, you could choose whatever works for you. I already created to Organizational Units (short: ou, called ‘people’ for holding my user accounts, and ‘groups’ for holding groups, hence the name. Also one user account is in my DIT, ‘cn’ is ‘common name’, the name the object is known by. All these object have their own attributes, I will come to that later.

Installing OpenLDAP

The next task is to install OpenLDAP, which is piece of cake if you’re using FreeBSD. I decided to install from the ports (which is really the smartest way to install anything on FreeBSD).

cd /usr/ports/net/openldap24-servermake all install clean

wait a bit and the LDAP server is ready to rumble. Before you can start OpenLDAP, you have to configure it first. FreeBSD keeps configuration files of ports in /usr/local/etc, so that’s our starting point. The file we’re looking for is actually in /usr/local/etc/openldap, and it’s called slapd.conf.

My file looks like this:

## See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema
include         /usr/local/etc/openldap/schema/nis.schema
include         /usr/local/etc/openldap/schema/qmail.schema
pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

# Load dynamic backend modules:
modulepath      /usr/local/libexec/openldap
moduleload      back_bdb

#######################################################################
# BDB database definitions
#######################################################################

database        bdbsuffix          "dc=boosten,dc=org"
rootdn          "cn=root,dc=boosten,dc=org"
# Cleartext passwords, especially for the rootdn, should
# be avoid.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw          verysecret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory       /var/db/openldap-data
# Indices to maintain
index   objectClass             eq
index   cn,sn,mail,uid,givenName        eq,pres,approx,sub

The configuration starts with some include statements, which load the needed schema files. This is just the beginning, since I think we’re going to need some more in future. ‘core’ and ‘cosine’ are loaded by default, I added ‘internetorgperson’ and ‘qmail’ (this one you have to download, I downloaded mine from zytrax. ‘nis’ is needed by ‘internetorgperson’ and ‘qmail’.These schemes give you enough attributes to start with (you cannot use attributes in your DIT that are not described in schemes).

The next important part of the configuration is the database configuration. Nowadays OpenLDAP uses the bdb (Berkeley DB) backend, so therefore ‘database bdb’.

Now comes the real stuff: the layout of the root of your DIT and who’s able to administrate:

suffix          "dc=boosten,dc=org"
rootdn          "cn=root,dc=boosten,dc=org"
rootpw          verysecret

The ‘suffix’ is the same as in the picture above, this should reflect your configuration.

‘rootdn’ is the user account that has all the mighty powers: this account is able to create the rest of your DIT. I named mine ‘root’, but you can call it ‘administrator’ if you like. LDAP is hierarchical, and therefore root is only known in the DIT by its Distinguished Name (dn): cn=root,dc=boosten,dc=org.

Root’s password is described by ‘rootpw’. In this example I chose a clear text password, just to show the password, but in reality this is bad practice. You should create an encrypted password and replace the ‘verysecret’ (or any other clear text password) with that encrypted one. The tool to create such an encrypted password is ‘slappasswd’.

% slappasswd
New password:
Re-enter new password:

And the result should look like this:

{SSHA}X8s4mgL/Qtjo9xqsfi2LfNNkWv7anT5x

Copy the above string into slapd.conf and the password is still ‘verysecret’, but no one can read it.

Once the slapd.conf is acceptable, you can start the ldap daemon (slapd). For this you have to modify /etc/rc.conf and put slapd_enable=”YES” in it. after that:

/usr/local/etc/rc.d/slapd start

and slapd should start (you can check with ps).

Adding data

Now that slapd is running, we can start filling it with some useful information. I started with the structure. To do this, create a text file with your favorite editor, and call it ‘structure.ldif’. The extension ldif is not really needed, but it shows the purpose of the file (LDAP Data Interchange Format). Mine looks like this:

dn: dc=boosten, dc=org
objectclass: domain
dc: boosten

dn: ou=groups, dc=boosten, dc=org
objectclass: top
objectclass: organizationalUnit
ou: groups

dn: ou=people, dc=boosten, dc=org
objectclass: top
objectclass: organizationalUnit
ou: people

Remember that ‘dn’ is Distinguished Name, the (unique) name the object is known by in the DIT. There cannot be two objects in the DIT with the same dn. Every object belongs to one or more objectclasses, so each object has at least one objectclass. You can already see the structure of my DIT: a domain (dc=boosten,dc=org) and underneath two organizational units, called ‘people’ and ‘groups’.

Once you created such a file, you can import it into LDAP with the command ldapadd:

ldapadd -x -D "cn=root,dc=boosten,dc=org" -W -f structure.ldif

This command will ask the password you configured in slapd.conf (of course you should modify the command above to reflect your situation, between the quotes should be the rootdn entry from your slapd.conf). ldapadd will tell you if you made some typos.

The next step is to add one or more user objects. You can add as many as you want, put them in one file or each in a separate ldif, whatever is convenient for you. If you put more than one user (object) in one file, make sure you separate them by one blank line.

Let’s create one (user.ldif):

dn: cn=Peter Boosten, ou=people, dc=boosten, dc=org
cn: Peter Boosten
sn: Boosten
givenName: Peter
objectclass: top
objectclass: person
objectclass: inetOrgPerson
objectclass: organizationalPerson
uid: peter
userpassword: {SSHA}X8s4mgL/Qtjo9xqsfi2LfNNkWv7anT5x
mail: peter@boosten.org

and add it:

ldapadd -x -D "cn=root,dc=boosten,dc=org" -W -f user.ldif

The user.ldif is straight forward: it contains a Distinguished Name, a Common Name (cn), a Surname (sn), Given name, several objectclasses, a user id, the password for the user, and a mail address. These are all called attributes. There are other attributes you can add, for instance: ‘l’ (lowercase L – locality or city), ‘mobile’ for your mobile phone, ‘street’ for your address.

The objectclasses decide on which attributes are mandatory, and which are optional. Common Name is mandatory for a person object, for instance, but the user password isn’t. The beauty of LDAP is that several attributes can be used to authenticate (I’m jumping ahead, I’ll get to that in detail). For instance: I could use the cn to match the password, or I could use the uid or email address. I chose the uid, btw, because that looks nicer in my apache log files.

Use the data

At this moment we can use this LDAP already as address book in your mail client (if of course it knows how to speak to an LDAP server). I use Mozilla Thunderbird.

This window can be accessed through ‘tools’, ‘options’ in the menu bar, then choose ‘Composition’ and ‘Addressing’, there you can add your newly created LDAP server.

After done that, click the ‘Address Book’ button, choose your LDAP server (it shows by the ‘Name’ you gave it in the ‘Directory Server Properties’ – see above) and type a piece of the name of the user you created in user.ldif (one character probably is enough). And there it is. If you created the extra attributes ‘street’ and so on, they will show up in the address book as well.

This concludes part 1. In the next article I will describe how to configure Apache to use LDAP as authentication.

This entry was posted on Thursday, November 20th, 2008 at 6:14 pm and is filed under freebsd. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.