Filling an OpenLDAP database

Creating your first Organizational Units

On the offchance that you haven't installed LAM, and thus haven't created the organizational units people, groups, hosts and domains, here's how to create them manually. Create a file containing the following information:

dn: ou=people,dc=saruman,dc=biz
ou: people
objectClass: top
objectClass: organizationalUnit

dn: ou=groups,dc=saruman,dc=biz
ou: groups
objectClass: top
objectClass: organizationalUnit

dn: ou=hosts,dc=saruman,dc=biz
ou: hosts
objectClass: top
objectClass: organizationalUnit

dn: ou=domains,dc=saruman,dc=biz
ou: domains
objectClass: top
objectClass: organizationalUnit

Let's suppose this file is named orgunits.ldif. Now from the directory that contains this file, feed the information into your OpenLDAP using the following commands:

sudo invoke-rc.d slapd stop
sudo slapadd -c -v -l orgunits.ldif
sudo invoke-rc.d slapd start

This effectively stops the server, writes the information directly into the database, and then starts the server again.

Another way to do (almost) the same thing, would be to add the information with the ldapadd command:

ldapadd -c -x -D cn=admin,dc=saruman,dc=biz -W -f orgunits.ldif

This binds to the OpenLDAP server (which must be running) using the admin account. This in turn causes the command to request the admin password, and then feed the contents from the orgunits.ldif file into the database. However, adding data to a live database precludes you from adding system controlled attributes, as structuralObjectClass is. So for live addition, remove those four particular lines from the orgunits.ldif file.

Explanation of this difference: slapadd is meant as a restore tool, so it must (and can) create system controlled attributes. ldapadd is a modification tool, so it shouldn't need to (and can't) create these attributes.

Migrating User, Password and Group entries to an LDAP server

It's nice to have an LDAP, but it's much nicer if it is filled with information. We'll try to enter all existing users and groups from the host server into LDAP, using the available migration tools.

Creating new users

If we need new users (e.g. when the server you're setting up is spankin' new) then we can create them in several ways. Let's discuss two of them:

Adding a user with an LDIF file

To add a user with the LDAP command line utilities, we first need to create an LDIF file. This file is a simple text file, created with a text editor like vi. The file could look something like the text below. In that file, we create a posix group "networkusers", and a user "sixpacjo" that's a member of this posix group. However, first we need to generate a password for our user, e.g. "raQaMad3", then hash it:

slappasswd -u -h {SSHA} -s raQaMad3
{SSHA}OcAQWgcTCzpu6v8n4yUUthiKPM6rlODq

Now with this hashed password, and all other information on user sixpacjo and group networkusers, we can create the actual LDIF file

# Create the user group
dn: cn=networkusers,ou=groups,dc=saruman,dc=biz
objectClass: posixGroup
gidNumber: 10001
cn: networkusers
description: Internal network users 

# Create a new user:
dn: uid=sixpacjo,ou=people,dc=saruman,dc=biz
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
cn: Joe Sixpack
description: Your Average Network User
givenName: Joe
sn: Sixpack
mail: joe.sixpack@saruman.biz
mail: j.sixpack@saruman.biz
# The Unix login-name for the user:
uid: sixpacjo
# The group and user IDs:
gidNumber: 10001
uidNumber: 10001
# The Unix account data:
homeDirectory: /home/sixpacjo
loginShell: /bin/bash
# The encrypted password for the user:
userPassword: {SSHA}OcAQWgcTCzpu6v8n4yUUthiKPM6rlODq

For a line-by-line explanation of this LDIF file, go here; we also explain the password hashing there. If you need to create more users, you can put them all in the same LDIF file, as long as you leave empty lines between each user.

To put the information from this file into our LDAP server, we have two options:

1. Shut down the OpenLDAP server, put the information straight into the database using slapadd, and then starting the server again. This would be the recommended way to enter information if we hadn't just typed it in ourselves, but previously made a backup of some sorts from the LDAP server using slapcat.
2. Keep the OpenLDAP running, and use the ldapadd utility to read the data into the live LDAP database. This makes use of the credentials of some user that has the right to write in the database, at least at the places where your LDIF file wants to store information (in the above example: in the groups and people OU's).

The ldapadd method works like this: after creating the file, e.g. sixpack.ldif in a certain place, e.g. our home directory, we run the following command:

ldapadd -v -x -D cn=admin.dc=saruman.dc=biz -W -f ~/sixpack.ldif

The meaning of the options is as follows:

• -v the everamusing "verbose" for extra diagnostic messages.
• -x use "simple bind" and not a TLS-encrypted connection.
• -D cn=admin.dc=saruman.dc=biz is the Distinguished Name with which to bind to the LDAP server.
• -W prompt for the password of the -D credential. Alternatively, use -w <password>, but ofcourse then the password winds up in your Bash history file et cetera.
• -f ~/sixpack.ldif read the LDIF information from this particular file, instead of the StdIn

The output of such an action could look like this:

ldapadd -v -x -D cn=admin,dc=saruman,dc=biz -W -f sixpack.ldif
ldap_initialize( <DEFAULT> )
Enter LDAP Password:
add objectClass:
        posixGroup
add gidNumber:
        10001
add cn:
        networkusers
add description:
        Internal network users
adding new entry "cn=networkusers,ou=groups,dc=saruman,dc=biz"
modify complete

add objectClass:
        posixAccount
        shadowAccount
        inetOrgPerson
add cn:
        Joe Sixpack
add description:
        Your Average Network User
....
(et cetera et cetera)
....
adding new entry "uid=sixpacjo,ou=people,dc=saruman,dc=biz"
modify complete

There, wasn't that fun? We now have Joe Sixpack in our LDAP server with all data necessary for a valid account - even though he as yet can't do anything yet on our server! To change that, we'll have to instruct our server to give user sixpacjo shell access.

Adding a user with LAM

To add a user with LAM is not exactly challenging. Log into LAM with an admin account; in the top menu, click Users; at the left bottom, you'll find a button "New user". Click it.

You'll find yourself in a browser screen with four "tabs": Personal, Unix, Shadow, and Samba3. Incidentally, if the system complains about "No Samba3 domains found in LDAP": ignore that for now.

In the first tab Personal, we find a (large) number of attributes that we can fill; the mandatory attributes are marked with an asterisk. At a minimum, fill in those required attributes. Then switch to the next tab, Unix. Here we fill in the required attributes, taking care to select a unique UID number, selecting the right primary group (that you've made beforehand, naturally, e.g. with the LDIF file mentioned previously), and setting a password. We don't need to add anything to the 3rd and 4th tab, so we can finish by clicking save at the left top hand. LAM should respond with "LDAP operation succesfull".

The next phase: shell access

For the next phase, we want to start using LDAP for two separate goals: authentication and authentication for Linux shell access, and authentication for SSH access. For these two steps, go here.