Hello List -
Please forgive my ignorance regarding the ACL's in OpenLDAP. For Starters I'm using OpenLDAP Software 2.4, and I've obtained the software from sunfreeware.com. OpenLDAP is running on a Solaris 10 Sparc system.
My goal is to have each one of my user able to read/write to their own personal address book. I've added my initial LDIF file, and configured slapd as best I could understand. I can ldapadd using the root dn, and I can see all of the entries that I added using ldapsearch. However when I try to add to my personal entry, I receive this error.
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
Below are my LDIF and slapd. I want to express that I have read through as much of this list as I could regarding the "no write access to parent", and I've found many have similar issues. I feel that my setup is fairly straight forward.
Any help is much appreciated. Let me know if you need more information.
The LDIF I used to begin... # 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
The slapd I'm using... # 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 dn.regex="(.+,)?(uid=[^,]+,o=isc)$" by dn.exact,expand="$2" write by anonymous auth # 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
------------------- david stackis uc santa barbara
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
david stackis wrote:
My goal is to have each one of my user able to read/write to their own personal address book.
Maybe something like this?
http://www.openldap.org/faq/data/cache/1005.html
Ciao, Michael.
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
On Tue, Jul 01, 2008 at 02:05:00PM -0700, david stackis wrote:
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
Sorry - that first line should have specified dn.subtree:
access to dn.subtree="ou=addressbook,dc=Company,dc=com" by users write by * read
access to * by * read
You should keep the 'access' keyword hard against the left margin: leading white space indicates continuation lines.
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
No surprise there - you did not load anything called "cn=Elliott Smith,ou=addressbook,dc=Company,dc=com" so you cannot authenticate as it.
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
Fixed by new version above.
# # 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
That won't load, as uid is not in the person object class: you need inetOrgPerson for that.
Andrew
Great!!! it worked!!! I know I have this setup fairly simple...but it's a good start.
Thanks so much, Andrew Cheers~
--On Wednesday, July 2, 2008 10:08 AM +0100 Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
On Tue, Jul 01, 2008 at 02:05:00PM -0700, david stackis wrote:
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
Sorry - that first line should have specified dn.subtree:
access to dn.subtree="ou=addressbook,dc=Company,dc=com" by users write by * read
access to * by * read
You should keep the 'access' keyword hard against the left margin: leading white space indicates continuation lines.
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
No surprise there - you did not load anything called "cn=Elliott Smith,ou=addressbook,dc=Company,dc=com" so you cannot authenticate as it.
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
Fixed by new version above.
# # 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
That won't load, as uid is not in the person object class: you need inetOrgPerson for that.
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
openldap-software@openldap.org
-
Andrew Findlay -
david stackis -
Michael Ströder