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

Re: Adding Objectclass account gives object class violation



I tried adding my own auxiliary objectclass as below but I get this error, I'm definately not doing it right. apologies for the lack of schema knowledge, could you please correct me?

sudo ldapmodify -x -D cn=admin,cn=config -W -f hostobject.ldif
Enter LDAP Password:
modifying entry "olcDatabase={0}config,cn=config"
ldap_modify: Object class violation (65)
        additional info: attribute 'olcObjectClasses' not allowed

hostobject.ldif:
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcObjectClasses
olcObjectClasses: ( 1.3.6.1.4.1.6921.1.24 NAME 'hostobj'DESC 'Combine Samba and account' SUP top MUST $ account AUXILIARY )


On Wed, Apr 14, 2010 at 3:52 PM, Adam Tauno Williams <awilliam@opengroupware.us> wrote:
On Wed, 2010-04-14 at 14:28 +0530, Shamika Joshi wrote:
> I'm using samba-openldap on Ubuntu 9.10 Server. I have created
> following user:rick using smbldap-tools which use default
> samba.schema.eg shown below.
> Now I also want to use "Host based authentication" using pam_filter
> where I need to mention host entry which has to be present in that
> user record.
> pam_filter |(host=cms2)(host=cms3)
> However "host" attribute appears only if I add "objectclass:account".
> If I go ahead to add that here for user:rick it gives me objectclass
> violation. What could be the way out of it? Any inputs would be highly
> appreciated

You are violating the structural objectclass chain.

> cn: rick
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: shadowAccount
> objectClass: sambaSamAccount

You 'deepest' structural objectclass is an inetOrgPerson;  a person is
not an account.  [Yea, that part is pretty dumb - account should be
abstract.]  posixAccount, sambaSamAccount, and shadowAccount are all
abstract classes.  For some [historical?] reason account is a structural
objectclass.   So to have an inetOrgPerson that is also an account you
need to have an objectclass that seals the breach in the structural
objectclass chain.

We use:

 objectclass ( 1.3.6.1.4.1.6921.1.12
 NAME 'mHybridPerson'
 DESC 'Combine several objectclasses to support multiple MUAs'
 SUP ( inetOrgPerson $ officePerson $ evolutionPerson )
 STRUCTURAL )

 objectclass ( 1.3.6.1.4.1.6921.1.24
 NAME 'mHybridUserAccount'
 DESC 'Combine mHybridPerson and account'
 SUP ( mHybridPerson $ account )
 STRUCTURAL )

Or you can find, or define, an abstract objectclass that
permits/requires the host attribute.  [Although isn't it more elegant to
use groups anyway?]