[Evolution] Adding entries to LDAP addressbook

Luke St.Clair run_faster@hotmail.com
Sat, 09 Apr 2005 22:01:24 -0400


I'm attempting to create an LDAP addressbook that authorized users can write 
to.

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.

Here is my slapd.conf file - i know it is completely unsecure, which is 
fine, since it contains only junk data.  I also think it's worth noting that 
ldapadd -x -f file works just fine - anonymous adding works, etc., from 
ldapadd

Any thoughts on what could be causing this?





# Allow LDAPv2 binds
allow bind_v2

# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.

#######################################################################
# Global Directives:

# Features to permit
allow bind_v2
allow update_anon

# 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

# 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
loglevel        0

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

#######################################################################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend         bdb


#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend                <other>

#######################################################################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database        bdb

# The base of your directory in database #1
suffix          "dc=mydomain,dc=net"

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

# Indexing options for database #1
index           objectClass 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

# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attribute=userPassword
        by dn="cn=admin,dc=mydomain,dc=net" write
        by anonymous auth
        by self write
        by * none

# 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
# The admin dn has full write access, everyone else
# can read everything.
access to *
        by dn="cn=admin,dc=mydomain,dc=net" write
        by * write

# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=".*,ou=Roaming,o=morsnet"
#        by dn="cn=admin,dc=mydomain,dc=net" write
#        by dnattr=owner write

#######################################################################
# Specific Directives for database #2, of type 'other' (can be bdb too):
# Database specific directives apply to this databasse until another
# 'database' directive occurs
#database        <other>

# The base of your directory for database #2
#suffix         "dc=debian,dc=org"







This is a result of an ldapsearch:
# extended LDIF
#
# LDAPv3
# base <dc=mydomain,dc=net> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#

# mydomain.net
dn: dc=mydomain,dc=net
objectClass: top
objectClass: dcObject
objectClass: organization
o: mydomain.net
dc: mydomain

# admin, mydomain.net
dn: cn=admin,dc=mydomain,dc=net
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# addressbook, mydomain.net
dn: ou=addressbook,dc=mydomain,dc=net
ou: addressbook
objectClass: top
objectClass: organizationalUnit

# Fake Name, addressbook, mydomain.net
dn: cn=Fake Name,ou=addressbook,dc=mydomain,dc=net
cn: Fake Name
givenName: Fake
sn: Name
postalCode: 0000
pager: 5555 1111
homePhone: 5555 5555
telephoneNumber: 5555 5555
objectClass: top
objectClass: inetOrgPerson