Also:
The one place where I could see using this is if one is using OpenLDAP as
the backend to a Kerberos KDC. It's considered best practice right now to
always encrypt the KDC database at rest on disk, and some sites even
require an administrator be present with a USB key to unlock the database
whenever a KDC has to be rebooted. Given the increasing interest in using
LDAP[?] as a backend store for the KDC, this may be a simpler method for
providing equivalent KDC security without encrypting various bits of data
individually
Taking this all into account, what is needed is simply adding to your
slapd.conf file:
CODE:
cryptkey testing
Note: there is also a cryptfile option to store the password in a seperate file.
If you already have a directory setup, then exporting your data and importing it again is needed to encrypt the files. A basic slapd.conf file needed would be:
CODE:
include /usr/local/etc/openldap/schema/core.schema
pidfile ./slapd.pid
argsfile ./slapd.args
modulepath /usr/local/libexec/openldap
moduleload back_bdb.la
database bdb
suffix "dc=suretecsystems,dc=com"
rootdn "cn=admin,dc=suretecsystems,dc=com"
rootpw secret
directory ./openldap-data
cryptkey testing
index objectClass eq
Then import your data with slapadd and test with the bdb tools:
CODE:
[ghenry@suretec openldap-data]$ /usr/local/BerkeleyDB.4.7/bin/db_dump objectClass.bdb
db_verify: Encrypted environment: no encryption key supplied
[ghenry@suretec openldap-data]$ /usr/local/BerkeleyDB.4.7/bin/db_dump -P "test" objectClass.bdb
db_verify: Invalid password
[ghenry@suretec openldap-data]$ /usr/local/BerkeleyDB.4.7/bin/db_dump -P "testing" objectClass.bdb
VERSION=3
format=bytevalue
type=btree
chksum=1
duplicates=1
dupsort=1
db_pagesize=4096
HEADER=END
0096defd
00000001
21d9e0af
00000001
62c4d55f
00000001
DATA=END
Things to note:
You need the bdb version that supports encryption, i.e. not the one that has
NC in the package name and that the
only encrypted parts of a database environment are its databases and its log files. Specifically, the shared memory regions supporting the database environment are not encrypted. For this reason, it may be possible for an attacker to read some or all of an encrypted database by reading the on-disk files that back these shared memory regions.
For more information see the
slapd-bdb man page.
Thanks,
Gavin.
If you have an entry for our "OpenLDAP Quick Tips" series, why not e-mail your tip to us.
P.S. For direct access to this section, you can click
OpenLDAP Quick Tips.