Re: Object Class Violation

El mar, 02-08-2005 a las 09:38 -0400, Richard Bullington-McGuire
escribió:

> I don't have a solution of the account vs. organizationalPerson dilemma. 
> It seems to do it the old way with OpenLDAP 2.2+, you have to disable 
> schema checking. How about having an account object with a person object 
> as a child object, or the other way around?

thing is conceptually neither person is a child of account nor vice
versa.  if you picture object classes as sets of usefully related
attributes or "profiles" that are available to be applied to every
object, then account vs. organizationalPerson should not be a problem at
all.  But practice tells us that there is a conflict, and this conflict
is very, very stupid, because it's a problem with the implementation of
the object classes themselves: they conflict with one another, when
there is actually no solid reason or ground for them to conflict.

The way I see it, objects in LDAP directories are data-rich
representations of conceptual or physical entities in the real world.
This conclusion, taken to its logical next step, together with best
practices and common sense, dictates that it's only logical and atomic
to keep organizationalPerson and account attributes stored together in a
single object.

In my mind, I always ask myself this: who the hell thought:

   "naaahh, no company employee will ever have a UNIX account"

?

> 
> In any case, DA should be able to manage an account-based user without the 
> organizationalPerson information. If you try doing that now, it won't 
> edit any information, complaining about missing objectClasses.
> 
> 
-- 
                Rudd-O          <[email protected]>
                http://www.amautacorp.com/staff/Rudd-O/