[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP Access controls

Hi again,

On 08/07/2009 15:24, Darryl Moore wrote:
Thanks again, I think I figured it out. I made some edits to the
olcDatabase={1}bdb.ldif file in the slapd.d, and was able to write to
the database. (It sure does help when you read the right set of

Unfortunately I somehow seem to have corrupted the database too. Now
when I restart the server I get the following in syslog.


  Jul  8 08:27:30 bison slapd[11407]: @(#) $OpenLDAP: slapd 2.4.15 (Mar
19 2009 10:08:25) $
Jul  8 08:27:30 bison slapd[11408]: bdb_db_open: database
"dc=moores,dc=ca" cannot be opened, err 13. Restore from backup!
Jul  8 08:27:30 bison slapd[11408]: bdb(dc=moores,dc=ca): txn_checkpoint
interface requires an environment configured for the transaction subsystem
Jul  8 08:27:30 bison slapd[11408]: bdb_db_close: database
"dc=moores,dc=ca": txn_checkpoint failed: Invalid argument (22).
Jul  8 08:27:30 bison slapd[11408]: backend_startup_one: bi_db_open
failed! (13)
Jul  8 08:27:30 bison slapd[11408]: bdb_db_close: database
"dc=moores,dc=ca": alock_close failed
Jul  8 08:27:30 bison slapd[11408]: slapd stopped.


Interestingly if I run slapd from the commandline instead of in the
background it still works. (Though possibly in read only mode I'm not
sure) Why does it not work when run from /etc/init.d too?

Sounds like a permissions problem. Often, distributions choose to run slapd as a specific user (ldap, for example). Thus, the files in your database must belong to that user. Try chown-ing /var/lib/ldap/*.

I came across this post WRT how to fix the database:


and it suggesting running a utility called slapd_db_recover. There is no
such utility on my system nor in any of the Ubuntu repos that I can see.
Is this something that is suppose to come with openLdap?

No, it a BerkeleyDB tool, and comes with BerkeleyDB. On Ubuntu, the packages are named db4.X-utils, where 4.X is the version of BerkeleyDB you're using (4.2, 4.4, 4.5, 4.6 or 4.7). The utilities are then named db4.X_recover, for example. Install the version matching the libdb4.X packet that your slapd depends on.

However, since version 2.3 of OpenLDAP, a database recover is done automatically on startup, so this won't solve your problem here.

P.S. It is too bad this list is configured as it is. I got several
replies to my initial query but most came back as private emails. One of
the benefits of email lists is that others can gain insight simply by
following a conversation without having to participate, but if the
default reply is to the sender rather than the list then most of the
time the list subscribers will never see them.

Agreed. Good habits and good email software should encourage replying to the list... Maybe setting a default reply-to would help with that.


Jonathan Clarke wrote:

On 07/07/2009 17:13, Darryl Moore wrote:
Hi all,

I've installed a LDAP server on my network against which all my users
can authenticate. They can even change their passwords via GUI or CLI
without any issue.

What I am trying to do now is allow each one of them to have an
address book in their subtree.

I created a subtree in each authentication relm that looks like this


Their is no problem with the rootdn adding entries below this, but I
am unable to get the user to be able to. In fact I can't seem to
allow the user to write anywhere. Even with the lone access rule:

access to * by * write

in the /etc/ldap/ldap.conf file (and yes I restart slapd everytime I
  change this file)

I presume you mean slapd.conf file, not ldap.conf.

When testing this, make sure to put this rule as the *first* access rule
in the slapd.conf file.

Order is important in ACLs, since the first matching rule will apply. So
if your "access to * by * write" is not the first, it probably is never

I beleive the correct access rule for what I want is: access to
dn.children="ou=People,dc=domain,dc=ca" by self write

A quick excerpt from the admin guide:
To add or delete an entry, the subject must have write access to the
entry's entry attribute AND must have write access to the entry's
parent's children attribute.

Be careful of "self" as well, it only represents the current user's
entry, not it's children/etc.

Hope this helps,

Jonathan Clarke - jonathan@phillipoux.net
Ldap Synchronization Connector (LSC) - http://lsc-project.org