OpenLDAP 2.4.11

OpenLDAP installation and configuration

Note: we're going to install OpenLDAP on our server as the local directory service, without replication, referrals or other advanced features.

Installing OpenLDAP on your Debian server is ridiculously simple. Just make sure your server is up-to-date (sudo apt-get update followed by sudo apt-get upgrade), and then install the two main components for your OpenLDAP server:

sudo apt-get install slapd ldap-utils

The Debian configuration script will ask you for only one single thing: an administrator password. As always: generate a strong password! When you've provided the password, the LDAP database is created with the administrator name "admin" and as a base directory path, something based on your DNS name. Suppose your internal domain is "amber.lan.", then the script will generate suffix "dc=amber,dc=lan,dc=". The last, empty, domain component (dc) is caused by the trailing dot in your DNS name: the DNS root.

Since this might not always be the most convenient configuration, we recommend that you run the configuration again using dpkg-reconfigure slapd. Interestingly enough, this reconfiguration asks you many more questions. The answers could look like this:

omit OpenLDAP config:  no
DNS domain name:       saruman.biz
Organization name:     Saruman
Administrator passwd:  wEt3udes
Database backend:      HDB
DB remove after purge: no
Move old DB:           yes
Allow LDAPv2:          no

As you can see, the reconfiguration yields much more configuration options than plain installation - although really you'll probably answer most questions with their default values anyway, with the exception of the database backend, which by default is BDB.
Anyway, the above method of configuring yields you an LDAP database with only two objects in it:

• a single Organization (o="Saruman") with Distinguished Name dn="dc=saruman,dc=biz"
• a single administrator with Common Name cn="admin", and dn="cn=admin,dc=saruman,dc=biz"

The database that your OpenLDAP server uses is a standard Berkeley DB (BDB) database. Now we most likely will require some other databases as well in our server setup, something modern like PostgreSQL or MySQL - so why don't we configure our OpenLDAP to use this same database as well? For the answer, see here - in short, the LDAP tree structure does not lend itself very well to inclusion in a modern relational database. Thus, we advise to stick with the Berkeley database provided with OpenLDAP.
Now, for the database backend, we have the choice between two almost identical flavours: the bdb backend is the recommended primary backend for a normal slapd database. It uses the Oracle Berkeley DB package, referred to as BDB, to store data. It makes extensive use of indexing and caching to speed data access. hdb is a variant of the bdb backend that uses a hierarchical database layout which supports subtree renames. It is otherwise identical to the bdb behavior, and all the same configuration options apply.

Installing and configuring an LDAP Account Manager

It's perfectly normal to manipulate your LDAP from the command line using LDAP utilities like ldapsearch, ldapadd, ldapdelete and ldapmodify, as well as slapcat, slappasswd etcetera. However, many people find a GUI for LDAP indispensible. If you are amongst those, then for you, my friend, the question becomes: which graphic tool do you want to use? Many people speak highly of gq, luma and phpldapadmin. We go for lam (LDAP acount Manager).
To install lam, first ensure that you have installed Apache2 and PHP5. Then we can use apt-get install ldap-account-manager. After installation, we can right away surf to http://<server-IP>/lam, where we can log in. However, note that in the upper right, there's a link LAM configuration. We'll go there first.

Under the LAM configuration page, there are two links to areas, where settings can be specified. The first one is "Edit general settings", and clicking it prompts you for a master password - by default this is "lam". Behind that password is a simple settings page, that can be filled with values like this (bold values deviate from the default):

• Security settings
  • Session timeout: 15 (the amount of minutes of inactivity that's allowed before a user is logged off)
  • Allowed hosts: 192.168.67.* (the range of IP numbers from which LAM accepts connections; empty would mean "all" so we recommend limiting the scope to your internal network, or even less if possible. Multiple hosts or network ranges can be inserted below each other)
• Password policy (in this section you can specify lower limits on your LDAP passwords - tho currently it's not clear to us what you're limiting. We suspect it's the creation of all LDAP passwords from within LAM).
  • Minimum password length: 6
  • Minimum lowercase characters: 0
  • Minimum uppercase characters: 0
  • Minimum numeric characters: 0
  • Minimum symbolic characters: 0
  • Minimum character classes: 3 (The character classes are: lowercase, uppercase, numeric and symbols)
• Logging
  • Log level: notice (this is the most detailed level; "warning" logs less information, "error" less still)
  • Log destination: syslog (outputs all LAM messages to the syslogger; alternatively specify "no logging" or a file name & location)
• Change master password
  • New master password: ***** (this is the password that'll replace "lam" to log into the LAM configuration; it is NOT the password of your rootdn, and if anywhere possible, you should avoid using that particular password here - for safety. Generate yet another strong password.)
  • Reenter new master password: *****

After entering the above settings, we at least know LAM is operational, and coarsely secured (it's not using SSL yet). Click OK to save, or back to login if you change your mind and just want to go back.

The second link from the LAM configuration page, "Edit server profiles" will again prompt you. However, this password prompt page contains an extra pulldown option, currently filled with the word "lam". This is because there is only one server profile, named "lam", and filled with some default values for your LDAP server. And under those two boxes, there's a link "manage server profiles".
Now first we'll rename that profile to something more descriptive. Click the "manage server profiles" link, in the "profile management page" check the radio button next to [lam] Rename profile, put in the new name (e.g. "sarumanbiz"), fill in the shiny new master LAM password — it should no longer be the default "lam" since you've changed it, in line with the paragraph above :-) — and then click OK. Presto! The server profile is renamed.
When you now enter your password to edit the server preferences for profile "sarumanbiz", you get to a page with a lot of settings; the only ones we're currently interested in are:

• Server settings
  • Server address: ldap://localhost:389 (verify that it's either localhost, if both the LDAP server and your LAM Apache2 are on the same machine, or a correct IP address or DNS name if that's not the case)
  • Tree Suffix: dc=saruman,dc=biz (the same suffix you've installed your LDAP server with)
• Account types
  • Edit Account types
    • Users
      • LDAP Suffix: ou=people,dc=saruman,dc=biz (You'll have to designate an OU in which to store user accounts; it does not have to exist yet (LAM can create it for you any time you log in) but the base has to be accessible; in our example: saruman.biz. Any name will do, but since we're storing identities, and not specifically users, we're calling the OU "people")
    • Groups
      • LDAP Suffix: ou=groups,dc=saruman,dc=biz (This is the OU where groups will be stored)
    • Hosts
      • LDAP Suffix: ou=hosts,dc=saruman,dc=biz (This is where machines, i.e. hosts, will be stored)
    • Samba domains
      • LDAP Suffix: ou=domains,dc=saruman,dc=biz (This is where all Windows workgroups/domains will wind up)
• Security settings
  • List of valid users: cn=admin,dc=saruman,dc=biz (or whatever you've designated your root DN)
  • New password: leave empty (because this is to change the master password to edit this server profile; when this remains empty, the "master master password" for LAM remains in effect)
  • Reenter password: (make this the same as the new password, i.e. empty)

Now click OK, and your LAM should be ready to go.

When you first log into the LAM profile you've just created, LAM will ask you if it should create the four OU's you've designated for people/groups/machines/domains. This is a nice test: if LAM cannot create those OU's, then you've misconfigured it (or the LDAP tree itself). If it can, then you'll be able to click tree view and browse the LDAP tree. At least the administrator (e.g. cn=admin) and the four OU's (e.g. domains/groups/hosts/people) should be present under the root (e.g. dc=saruman,dc=biz).
Incidentally, the configuration you've just entered into LAM as profile "sarumanbiz" can also be found at /usr/share/ldap-account-manager/config/sarumanbiz.conf, so if need be, you can edit the profile by hand.

Securing LAM communications with SSL

Until just now, all communications with LAM have taken place over unencrypted connections - not a nice way to work in a production environment. We really need to use SSL to secure the LAM environment. Fortunately, that is as easy as enabling SSL on the underlying Apache2 webserver.

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, that could look something like this:

# Create a new user:
dn: cn=Joe Sixpack,ou=people,dc=saruman,dc=biz
objectclass: top
objectclass: inetOrgPerson
objectclass: PosixAccount
objectclass: ShadowAccount
cn: Joe Sixpack
sn: Sixpack
# The Unix login-name for the user:
uid: sixpacjo
# The group and user IDs:
gidNumber: 1000
uidNumber: 1000
# The home directory for the user:
homeDirectory: /home/sixpacjo
# The encrypted password for the user:
userPassword: {crypt}$1$qs70ynbk$UBuewN7ZdIvqavIxkxdmX0

AHA! you'll say. But how do I get to this encrypted password? It's simple. Try this:

openssl passwd -crypt "secret"

The argument -crypt makes openssl generate a password using the standard Unix password algorithm; this is also the default setting. An alternative would be to use -1 instead of -crypt, which'll give you an MD5 encrypted password. Ofcourse, using an MD5 encrypted password means you have to change the last line of the LDIF file to

userPassword: {MD5}$1$yCuyTf63$NoAjuX/dYBmE29hXrsDb41

Note that prefixing the used encryption method is totally fine with OpenLDAP, but it actually is not according to the LDAP standard; this LDIF file can be understood by OpenLDAP, but not by every other piece of LDAP software out there...

Back to the LDIF file.