Actually, there are different objectClass that might be extended: person, inetOrgPerson, organizationalPerson and residentialPerson. Considering that inetOrgPerson, organizationalPerson and residentialPerson are designed for specific purposes, I think that extending the person objectClass would be the best guess, what do you think ?
No need to extend existing classes - use another auxiliary class and add it to the object. inetOrgPerson - is a common way to store addressbook data, it is handled by Thunderbird/Outlook/TheBat/whatever.
You may try such schema: olcAttributeTypes: ( 2.999.1.1 NAME 'myData' DESC 'My string' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) olcObjectClasses: ( 2.999.2.1 NAME 'myObject' SUP top AUXILIARY MUST myData MAY info)
Then create your addressbook entry: dn: cn=entry1,ou=addressbook,dc=babelouest,dc=org objectClass: inetOrgPerson objectClass: myObject sn: ... gn: ... mail: ... myData: ...
You need also unique OID for your schema (2.999 - is reserved for examples and documentation). See http://www.oid-info.com/faq.htm#10 http://quick-oid.org/
I would like to add another branch to allow users to add their own addressbook entries, these entries would be in read/write mode only for the owner, no one else but him should have access.
The new directory would look like this: dc=babelouest,dc=org | |-ou=addressbook (global, read-only for all users) | | | |-cn=Address1 | |-cn=Address2 | |-[...] | |-ou=users | | | |-uid=user1 | |-uid=user2 | |[...] | |-ou=personnalAddressbooks (personnal addressbook entries) | | | |-uid=user1 | | | | | |-cn=Address1 | | |-cn=Address2 | | |-cn=Address3 | | | |-uid=user2 | | | | | |-cn=Address1 | | |-cn=Address2
Better place personal addressbook entries under common addressbook - this can be configured then on the clients as a single connection (with a single base=ou=addressbook,dc=babelouest,dc=org). Also this gives an opportunity to share personal entries - just change the ACL.
dc=babelouest,dc=org | |-ou=addressbook (global, read-only for all users) | | | |-cn=Address1 | |-cn=Address2 | |-[...] | |-uid=user1 | | | | | |-cn=Address1 | | |-cn=Address2 | | |-cn=Address3 | | | |-uid=user2 | | | | | |-cn=Address1 | | |-cn=Address2
For ACL you may use olcAccess with regexes and backreferences.
olcAccess: to dn.regex="^uid=(.+),ou=addressbook,dc=babelouest,dc=org$" by dn="^uid=$2,ou=users,dc=babelouest,dc=org$" write by * none
Notice that $1 is replaced with the whole matched string, and $2 replacement is for the first (.+) backref. "write" privilege also implies "read" and "search".