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