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

Re: ACL Help Please



Hi Andrew -

I added the ACL's you suggested. First I tried...
 access to "ou=addressbook,dc=Company,dc=com"
        by users write
        by * read

 access to *
        by * read

When I used ldapadd I received this error...

ldapadd -D "cn=Elliott Smith,ou=addressbook,dc=Company,dc=com" -f
contact.ldif2
Enter bind password: 
adding new entry cn=Nick Drake,ou=addressbook,dc=Company,dc=com
Enter bind password: 
ldap_simple_bind: Invalid credentials

I then tried is using "ou=users" like this...

ldapadd -D "cn=Elliott Smith,ou=users,dc=Company,dc=com" -f contact.ldif2
Enter bind password: 
adding new entry cn=Nick Drake,ou=addressbook,dc=Company,dc=com
ldap_add: Insufficient access
ldap_add: additional info: no write access to parent

Slapd and the initial LDIF are below in all of their glory...

# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral       ldap://root.openldap.org

pidfile         /usr/local/var/run/slapd.pid
argsfile        /usr/local/var/run/slapd.args

# Load dynamic backend modules:
# modulepath    /usr/local/libexec/openldap
# moduleload    back_bdb.la
# moduleload    back_ldap.la
# moduleload    back_ldbm.la
# moduleload    back_passwd.la
# moduleload    back_shell.la

# Sample security restrictions
#       Require integrity protection (prevent hijacking)
#       Require 112-bit (3DES or better) encryption for updates
#       Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
#       Root DSE: allow anyone to read it
#       Subschema (sub)entry DSE: allow anyone to read it
#       Other DSEs:
#               Allow self write access
#               Allow authenticated users read access
#               Allow anonymous users to authenticate
#       Directives needed to implement policy:
#
#

 access to "ou=addressbook,dc=Company,dc=com"
        by users write
        by * read

 access to *
        by * read

# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

#######################################################################
# BDB database definitions
#######################################################################

database        bdb
suffix          "dc=Company,dc=com"
rootdn          "cn=root,dc=Company,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw          secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory       /usr/local/var/openldap-data
# Indices to maintain
index   objectClass     eq




# Initialize the suffix entry defined in slapd.conf
#
dn: dc=company,dc=com
objectclass: top
objectclass: dcObject
objectclass: organization
dc: company
o: corporate

#
# Initialize the AddressBooks heirarchy
#
dn: ou=addressbook,dc=company,dc=com
objectclass: top
objectclass: organizationalUnit
ou: addressbook

#
# Define individual address books
#
dn: o=hr,ou=addressbook,dc=company,dc=com
objectclass: top
objectclass: organization
o: hr

#
# Initialize the Users heirarchy
#
dn: ou=users,dc=company,dc=com
objectclass: top
objectclass: organizationalUnit
ou: users

#
# Define individual users
#
dn: cn=Elliott Smith,ou=users,dc=company,dc=com
objectclass: top
objectclass: person
cn: Elliott Smith
sn: Smith
userPassword: mysecret
uid: esmith


--On Tuesday, July 1, 2008 9:15 AM +0100 Andrew Findlay
<andrew.findlay@skills-1st.co.uk> wrote:

> On Mon, Jun 30, 2008 at 04:09:07PM -0700, david stackis wrote:
> 
>> My goal is to have each one of my user able to read/write to their own
>> personal address book.
> 
>> ldapadd -D "cn=Elliott Smith,ou=users,dc=Company,dc=com" -f contact.ldif
>> Enter bind password: 
>> adding new entry cn=Nick Drake,ou=addressbook,dc=Company,dc=com
>> ldap_add: Insufficient access
>> ldap_add: additional info: no write access to parent
> 
>>  access to dn.regex="(.+,)?(uid=[^,]+,o=isc)$"
>>         by dn.exact,expand="$2" write
>>         by anonymous auth
> 
> It looks as if you have part of an ACL taken from some other system.
> It will not help you here, I suggest you remove it.
> 
> You need to provide 'write' access to the whole subtree under
> ou=addressbook,dc=Company,dc=com
> so I suggest starting with this:
> 
> access to ou=addressbook,dc=Company,dc=com
> 	by users write
> 	by * read
> 
> access to *
> 	by * read
> 
> That will allow *any* authenticated user to do *anything* in your
> addressbooks tree. You can then refine it, perhaps by limiting
> which users can write:
> 
> access to ou=addressbook,dc=Company,dc=com
> 	by dn.subtree=ou=users,dc=Company,dc=com write
> 	by * read
> 
> access to *
> 	by * read
> 
> 
> Andrew
> -- 
> -----------------------------------------------------------------------
>|                 From Andrew Findlay, Skills 1st Ltd                 |
>| Consultant in large-scale systems, networks, and directory services |
>|     http://www.skills-1st.co.uk/                +44 1628 782565     |
> -----------------------------------------------------------------------



-------------------
david stackis
uc santa barbara
phone: 805-893-8286
http://isc.ucsb.edu