OpenLDAP 2.4.11

From SaruWiki
Revision as of 20:45, 12 April 2011 by Saruman! (talk | contribs) (moved OpenLDAP to OpenLDAP 2.4.11: new ldap version)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

OpenLDAP installation

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"<ref>Should you see a third, empty, domain component (dc=) then this is caused by a trailing dot in your particular DNS name: the DNS root. You might have specified your domain as "amber.lan.". You should change your domain name to a name without the DNS root, and you must regenerate your LDAP directory.</ref>.

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 (see further down for the difference between BDB and HDB).
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/HDB) 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.

<references/>

OpenLDAP configuration

To finetune the OpenLDAP configuration, we make some changes to the main configuration file for the OpenLDAP server, /etc/ldap/slapd.conf. Note: make SURE that the permissions on this file are rw-r----- (640) and the owner is root:openldap, so that OpenLDAP can read the configuration, but only you can change it.

When changing the configuration of your LDAP server, keep in mind that everything above the first backend hdb (or backend <something>) should contain only global directives, and everything under it only backend directives that will apply to all databases that you're going to run under that backend type. In our examples, we're only going to run a single database of a single backend type, so all backend directives will apply to our single database. Nevertheless, you should put your global directives above the backend declaration, and the rest below.

global directives

We check to be certain all necessary schemas are included: in the beginning of the file we should see 

include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema

If any line got missing, we need to (re)enter it in order to be able to create the LDAP entries that we want.

We find the line beginning with loglevel and change it from none to 256. This value means connections/operations/results wil be logged to the syslogd daemon. There, it will be logged to the LOG_LOCAL4 facility.

The default hash algorithm for encrypting user passwords is {SSHA}, which is the SHA-1 algorithm (FIPS160-1) wit a seed number. However, OpenLDAP can understand more hashes, even multiple at the same time. To specify which hash or hashes, we can specify something like 

password-hash {SSHA}
password-hash {MD5}

Valid hashes are {SHA}, {SSHA} (the default), {MD5}, {SMD5}, {CRYPT} and {CLEARTEXT}. We usually don't need to change the default, but if you do, put in the directive and restart your LDAP server. More information: "man 5 slapd.conf".

backend directives

We find the line beginning with index, and add one or more lines under it, containing the attributes that we would like to be indexed. For starters, we would advise you to index not only objectClass, but also uid and memberUid. This will make the section look like this: 

index           objectClass  eq
index           uid          eq
index           memberUid    eq

The purpose of this change is to make the OpenLDAP server create another index, on LDAP attribute uid, and another one on LDAP attribute memberUid. The uid index is important, because under some circumstances you might not receive any result on a valid query unless the searched entries are indexed. This entry makes sure all objects with a uid attribute are indexed, and thus can be found when queried. The memberUid index is not so important, but creating it will prevent a lot of informational messages in our syslog that go like 

Nov  9 10:24:40 dworkin slapd[13998]: <= bdb_equality_candidates: (memberUid) not indexed

After these little refinements, we must stop, reindex, and restart the OpenLDAP server. This can be done with the following sequence of commands: 

sudo invoke-rc.d slapd stop
sudo -u openldap slapindex
sudo invoke-rc.d slapd start

Note: you need to have your sudo configured to allow you to su to user openldap in order to run the second command.

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.

Where to go from here

This completes the setup of the LDAP server.

  • To fill it with relevant data, go to the next section.
  • To set your system to accept LDAP users logging in to the machine, go here.
Retrieved from "https://www.saruman.biz/saruwiki/index.php?title=OpenLDAP_2.4.11&oldid=2673"