Re: Net::LDAP::schema brokenness

[Clif H. <cl...@di...>]

> 
> I think the schema method of the Net::LDAP class is fairly broken. It isn't
> documented, either :-)

I agreed it is not documented, we can fix that.

> 
> Here's my take on the existing behaviour:
> 
> schema ( [ dn => DN ] )
> 
> DN is an optional distinguished name. If not present, the method will use a
> random DN from the Root DSE's subschemaSubentry attribute. If this
> attribute is not present, the method will try <cn=schema>.
> 
> It then tries to do a base object search of that DN with a filter of
> (objectClass=*).
> 
> However, this is useless if you specify the DN, because the schema object
> can only be constructed if the search requests some operational attributes.
> 
> This is also useless if you don't specify the DN and there is a
> subschemaSubentry attribute in the root DSE, because the filter is wrong
> (see RFC 2251 section 3.2.2, last para.)
> 
> It's probably also useless in the <cn=schema> case, though that case seems
> to be a band-aid for broken versions of a particular server (Netscape?) and
> so all bets are probably off on that one's behaviour ;-)

I am going to have to take issue with the above paragraph, I am using
.22.

I have used this on my x.500 servers, thru the ldap interface, works fine.
I have used this on my Netscape LDAP servers, works fine. 

I am 99% sure that I have used this on my Exchange servers and that it
worked fine.  This is one gross schema! 

I know I have tried this on a MS Active Directory but I do not remember if
it worked correctly.

IMO if cn=schema is broken, it has the strange habit of returning correct 
data.


> 
> So the code's kind of trying to do two different things (reading a subentry
> and reading an entry) and failing at both.
> 
> Here's what I think this code should do.
> 
> schema ( [ dn => DN ] )
> 
> 	If a DN is passed, return a Net::LDAP::Schema object using the subschema
> retrieved from the objectClasses and attributeTypes operational attributes
> from that entry (specifically entry, *not* subentry.)
> 
> 	If a DN is not specified, return a Net::LDAP::Schema object using the
> objectClasses and attributeTypes held in the subentry (again, specifically
> subentry, *not* entry) referenced by one of the values from the Root DSE's
> subschemaSubentry attribute. If the Root DSE doesn't contain a
> subschemaSubentry attribute, try using the DN of <cn=schema> for
> compatibility with some broken directory servers.
> 


I believe the RFC states MAY contain a subschemaSubentry attribute.



> I'm attaching some diffs against Net::LDAP 0.20 which implements this
> behaviour. The line offsets are probably a bit out too because I've been
> experimenting with some other local changes. Sigh. Anyway, sorry it isn't
> against a clean 0.22, but the guts of the change are:
> 
> In schema() add a $filter variable and set it depending on the existence of
> $arg{'dn'};
> 
> In schema() set the attrs array when reading the subschema to include the
> necessary operational attributes;
> 
> In root_dse() set the attrs array when reading the Root DSE to include all
> the standard (RFC 2251) operational attributes.
> 
> I suppose I must get around to installing 0.22 at some point :-)
> 
> Cheers,
> 
> Chris


Later,

Clif Harden        c-h...@ti...