Re: [Evolution] Adding entries to LDAP addressbook



On Sat, 2005-04-09 at 22:01 -0400, Luke St.Clair wrote:
I'm attempting to create an LDAP addressbook that authorized users can write 
to.

I just did that last week, so I guess I can help you.

By the way, LDAP addressbook with Evolution is wonderful. With IMAP
mail, server-side filtering (maildrop) and now server-side addressbook,
my mail setup is now free of client-side data. With documents in
Subversion on top of that, I can sit down at any bare workstation and
feel at home in seconds. That's very nice, especially since I absolutely
hate laptops. Next step on the horizon : the calendar... But that's
another story...

I've succeeded in getting an addressbook that evo can read, but not write 
to.  When I try to create a new contact, and select the ldap server as the 
location for the new contact, all fields are greyed out.

Did you look at your slapd logs ? Set log debug level mask to 128 and
you'll have the ACL logs. They are useful in detecting permission
problems.

Here is my slapd.conf file - i know it is completely unsecure

Mine is not the most secure in the world either (read for everyone,
including anonymous users...), but since it is restricted to local
access only (I always use it though a SSH tunnel) and there is only a
handful of users it is acceptable enough for now although I'll
reconsider our architecture sometime in the not too distant future in
order to make it secure enough (TLS, rigorous ACL, no anonymous read
access).

Any thoughts on what could be causing this?

Check you logs ! Debugging without logs will not get you very far.

Be aware that ordering matters in the slapd ACL. Understanding that when
I started would have saved me quite a bit of time.

Be aware that there is more than more way to do it. In fact there seems
to be as many ways as there are LDAP installations. And that's not only
more than one architecture, but more than one way to implement each
thing. I have yet to see best practices emerge, or something even
remotely looking like a standard LDAP setup. This makes most of the
documentation specific to whatever setup it's documenting. Now I am
beginning to make sense of what I read, but beginning LDAP
administration is a very confusing experience.

Take a look at
http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl?LDAP01/Access_Control
 an easily understandable introduction to LDAP ACL. I found it helped
make the concepts clearer to me.

While you are at it, don't forget to
include /etc/ldap/schema/evolutionperson.schema (you'll find it on a
Debian Evolution setup
in /usr/share/evolution-data-server-1.0/evolutionperson.schema). This
schema enables the LDAP storage of Evolution specific items.

And once everything works, make sure that the contacts you are copying
conform to the schema, otherwise slapd will not take them if schemacheck
is enabled. I enabled it - it is a bit of a pain but I really wanted to
enforce data quality, especially since this LDAP addressbook is going to
be my central repository for various synchronized devices (viva
Multisync !).

Finally, I recommend Phpldapadmin the best PHP LDAP client I have ever
used :
http://phpldapadmin.sourceforge.net/. I also use GQ and I like it, but
it has been unmaintained for a while and I am considering alternatives.



Now here is an abbreviated version of my slapd.conf
###############################################################

# Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/misc.schema
include         /etc/ldap/schema/evolutionperson.schema

# Schema check allows for forcing entries to
# match schemas for their objectClasses's
schemacheck     on

# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile         /var/run/slapd/slapd.pid

# List of arguments that were passed to the server
argsfile        /var/run/slapd.args

# Read slapd.conf(5) for possible values
# 128 for ACL debugging
#loglevel 128
loglevel 0

# Where the dynamically loaded modules are stored
modulepath      /usr/lib/ldap
moduleload      back_ldbm

# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend         ldbm

# Database specific directives apply to this databasse until another
# 'database' directive occurs
database        ldbm

# The base of your directory in database #1
suffix          "dc=grabeuh,dc=com"

# Where the database file are physically stored for database #1
directory       "/var/lib/ldap"

# Indexing options for database #1
index objectClass                                                eq
index uid,cn
pres,eq,sub
index mailRoutingAddress,mailLocalAddress    pres,eq

# Save the time that the entry gets modified, for database #1
lastmod         on

# Where to store the replica logs for database #1
replogfile      /var/lib/ldap/replog

# Set the entry cache size. This value is separate from the
set_cachesize value
# set in the DB_CONFIG  file  under  the bdb directory.  That value
should be
# set as well to optimize database caching for the Berkeley DB
subsystem.
#
cachesize       5000


# Ensure read access to the base for things like
# supportedSASLMechanisms.  Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
access to dn.base=""
        by * read

# Let everyone read the password hashes. This is meant for
# authentication purposes.
access to attribute=userPassword
        by * read
#
# And since you are asking... Yes, everyone can read the hash.
# Refer to the installation story to understand the tradeoffs we made.
# There is a better way, but it is more complicated. Now that we
# begin to understand LDAP we will think about it.

# Each Kivu owner has write rights on his own record.
access to dn.one="ou=admin,ou=people,dc=grabeuh,dc=com"
        by self write
        by dn="cn=admin,dc=grabeuh,dc=com" write
        by * read

# Each Kivu owner has write rights on the branch containing his users.
# This could be expressed in just one declaration using regex and
variable expansion
# but for now I prefer to stick to something I actually understand...
access to dn.subtree="ou=jim,ou=people,dc=grabeuh,dc=com"
        by dn="uid=jim,ou=admin,ou=people,dc=grabeuh,dc=com" write
        by dn="cn=admin,dc=grabeuh,dc=com" write
        by * read

# We wont let non-owner users modify their own record until we can do it
# safely. We need to keep the non-owner users from modifying unsafe
attributes.
# Since not much would be left writable it will probably not be worth
the
# hassle to bother opening anything to them.

# Each addressbook user has write rights on his own addressbook
# Addressbook entries are private, so others have no read rights
access to dn.subtree="ou=jim,ou=addressbook,dc=grabeuh,dc=com"
        by dn="uid=jim,ou=admin,ou=people,dc=grabeuh,dc=com" write

# If no access to directive matches or no by <who> clause, access is
denied.
# That is, every access to directive ends with an implicit by * none
clause and
# every access list ends with an implicit access to * by * none
directive.

#
# And now here is our default ACL so it must be the last one !
#
access to *
        by dn="cn=admin,dc=grabeuh,dc=com" write
        by * read
# The admin dn has full write access
# Everyone else can read everything
# This is a lax default, but quite adequate
# in a small group such as ours.
# Could be likened to the default group read umask.

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]