Re: Errors in diradmin-1.6.0

Mike Jackson <[email protected]> writes:

> Dieter Kluenter wrote:
>
>> A revised version, complying to ldapv3 and samba3 would be
>> great. It's
>> about a year ago, I suggested to replace object class account with
>> extensibleObject in order to overcome the objectclass violation.As the
>> attribute 'host' would be the only attribute used of object class
>> account, it would make sense to replace this object class.
>
> The LDAPv3 is working now with 1.6.0.
>
> RE your suggestion:
>
> The problem with the "account" objectclass is that it is the only
> standard objectclass which provides the "host" attribute, which
> pam_ldap relies on to do host-based access control, and that it is
> defined as structural. This is a mistake IMHO, but it would probably
> be impossible to get the RFC changed. Newer versions of OpenLDAP
> actually enforce structural integrity, e.g. only allowing one
> structural objectclass per object. This conflicts with "person", IIRC,
> which is also structural.

This is only partially correct. RFC 2252 requires that only one
structural objectclass is declared, but you may use all attributes
that are part of the class chain. An example, if you declare an entry
belonging to evolutionPerson objectclass, one may use attributes of
inetOrgPerson and Person as well but you don't have to declare this
entry belonging to this object classes.The object class chain is

top -> person -> pilotPerson -> inetOrgPerson -> evolutionPerson
 
> If we were to do this right, we would have a "pam_ldap.schema" or
> something. In order to use pam_ldap host access control, and to comply
> with structural integrity, we must add new schema to the server, but I
> don't really like that. I wonder if this has been discussed on the
> pam_ldap mailing list already.

I'm quite aware of the enheritage problem with structural object
classes. There are two solutions to this, either design a new subclass
and include a host attribute, or use the extensibleObject object class
and apply the host attribute (RFC 2252). I personally quite often make
use of the class extensibleObject.
An other approach would be a complete redesign with no hard coding of
any attributes, but read available attributes from the subschema
subentry, (ldapsearch -b "cn=subschema" -s base +) or (ldapsearch -b
"cn=subschema -s base attributeTypes objectClasses).

-Dieter

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



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt