Re: Object Class Violation

Dieter Kluenter said:
> Hi,
>
> "Neil Schneider" <[email protected]> writes:
>
>> Manuel Amador (Rudd-O) said:
> [...]
>>> Feel free to deploy an alternative solution, but we need to get to
>>> a
>>> consensus and fast.  Many people are claiming DA is useless because
>>> of
>>> this problem.  Truth of the matter we should simply deploy new
>>> schemas
>>> and that is that.  But I would so very much like to preserve on
>>> persons
>>> as many useful object classes as possible, instead of reinventing
>>> the
>>> wheel.
>>
>> I have a suggestion, that you may take for what it's worth. I would
>> suggest making a configuration option where the user/administrator
>> can
>> configure from a list of object classes of their choosing, creating
>> a
>> "template, if you will for each account. My testing indicates that
>> for
>> my purposes I needed the following objectclasses.
>>
>> objectClass: top
>> objectClass: account
>> objectClass: posixAccount
>> objectClass: shadowAccount
>> objectClass: sambaSamAccount
>
> Never use object class account attributes to describe persons, you
> will get into trouble if you ever want to add attributes like mail or
> telephoneNumber. Object classes posixAccount and sambaSamAccount are
> somehow misleading as in fact these classes are describing persons and
> not an account.
> I would prefer person, or even better inetorgPerson, as structural
> object class.

This is a closed development environment. None of those attributes
will ever be required, because they are stored somewhere else, outside
this network. Only machines inside this newtwork use ldap and only for
authentication. The information can't leak out, because outbound
connections are forbidden by a firewall.

My primary objection to the way that DA works, is it makes assumption
what I require, without first asking me if it's true. If it asked,
during the setup or had a preference dialog, where I could make
choices about which attributes I require, that would be much better.

The problem seems to stem from a conflict between objectclass account
and objectclass inetOrganizationalPerson. They are both structural
classes, and as such cannot both be included.

Just my $.02

-- 
Neil Schneider                              pacneil_at_linuxgeek_dot_net
                                           http://www.paccomp.com
Key fingerprint = 67F0 E493 FCC0 0A8C 769B  8209 32D7 1DB1 8460 C47D
Secrecy, being an instrument of conspiracy, ought never to be the
system of a regular government.
- Jeremy Bentham, jurist and philosopher (1748-1832)