Re: Object Class Violation

On Tue, 2 Aug 2005, Manuel Amador (Rudd-O) wrote:

> When the host attribute is added to the person structure, the object
> class list is updated to include the problematic objectclass you
> mentioned a few e-mails ago.  This was done by me like that because,
> back in the golden days, that was the only way to add a host attribute
> without disabling OC checking.

When I started setting my LDAP schema up in OpenLDAP 2.0, I found I needed to 
add a reference to the ldapns.schema file to my slapd.conf to get things 
working.

This schema, by Luke Howard of PADL.com, did the trick:

# $Id: ldapns.schema,v 1.3 2003/05/29 12:57:29 lukeh Exp $
# LDAP Name Service Additional Schema
# http://www.iana.org/assignments/gssapi-service-names

attributetype ( 1.3.6.1.4.1.5322.17.2.1 NAME 'authorizedService'
         DESC 'IANA GSS-API authorized service name'
         EQUALITY caseIgnoreMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

objectclass ( 1.3.6.1.4.1.5322.17.1.1 NAME 'authorizedServiceObject'
         DESC 'Auxiliary object class for adding authorizedService attribute'
         SUP top
         AUXILIARY
         MAY authorizedService )

objectclass ( 1.3.6.1.4.1.5322.17.1.2 NAME 'hostObject'
         DESC 'Auxiliary object class for adding host attribute'
         SUP top
         AUXILIARY
         MAY host )

This schema is distributed with the nss_ldap RPM that comes with Red Hat 
Enterprise Linux 4. It was not distributed with the RHEL 3 RPM for nss_ldap, 
oddly enough.

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

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.


-- 
  Richard Bullington-McGuire, Managing Partner, PKR Internet, LLC
  Email: [email protected]  Web: http://pkrinternet.com/
  Phone: +1 (703) 271 0607  Fax: +1 (703) 271 0580
  PGP key IDs:  RSA: 0x9386230  DH/DSS: 0xDAC3028E