Re: Object Class Violation

"Manuel Amador (Rudd-O)" <[email protected]> writes:

> 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.

You are getting mixed up here. A person may *have* an account, but a
person *is* not an account. An account may be valid *for* a host, the
persons data may reside on a host. To describe this host, you may
include the object class iphost, this object class is auxiliary and
uses the attribute 'comon name' (cn) to define this host. In order to
distinguish the users cn and the hosts cn, you may add a tag 'x-' to
this attribute, that is cn;x-host: 

-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6