Re: openldapRootDSE and solaris clients

[Igor Brezac <igor@ipass.net>]

On Tue, 11 May 2004, Pierangelo Masarati wrote:

>
> > In the past (version 2.1.22) I have been able to:
> >
> > sidhean openldap # ldapsearch -xLLLs base -b ""
> > dn:
> > objectClass: top
> > objectClass: OpenLDAProotDSE
> > structuralObjectClass: OpenLDAProotDSE
> > namingContexts: dc=my,dc=base
> > supportedControl: 1.2.826.0.1.334810.2.3
> > supportedControl: 1.3.6.1.4.1.4203.1.10.1
> > supportedControl: 1.3.6.1.4.1.4203.1.10.2
> > supportedControl: 2.16.840.1.113730.3.4.2
> > supportedControl: 2.16.840.1.113730.3.4.18
> > supportedExtension: 1.3.6.1.4.1.1466.20037
> > supportedExtension: 1.3.6.1.4.1.4203.1.11.1
> > supportedExtension: 1.3.6.1.4.1.4203.1.11.3
> > supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
> > supportedFeatures: 1.3.6.1.4.1.4203.1.5.2
> > supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
> > supportedFeatures: 1.3.6.1.4.1.4203.1.5.4
> > supportedFeatures: 1.3.6.1.4.1.4203.1.5.5
> > supportedLDAPVersion: 2
> > supportedLDAPVersion: 3
> > supportedSASLMechanisms: DIGEST-MD5
> > supportedSASLMechanisms: CRAM-MD5
> >
> > However, on a recent build (2.1.25) i find:
> >
> > budbase scripts # ldapsearch -xLLLs base -b ""
> > dn:
> > objectClass: top
> > objectClass: OpenLDAProotDSE
> >
> > Unfortunately this breaks the Solaris client configurator ldapclient(1)
> > because it cannot find the naming context. Adding a '+' to the above
> > search shows that the required attribute is there just not returned.
> >
> > I have seen a reference to this from Jan 2001 in the mailing list. why
> > does the 2.1.22 work and the 2.1.25 not? is it a configure option that I
> > missed? Anyone seen this problem with sol client? workaound?
>
> slapd behaves as intended since 2.0, as far as I remember.  If your client
> needs the attribute namingContexts it should require it explicitly.  I
> don't see any reason to expect a value if it's not asked for.  If it
> doesn't, the bug is in the client, not in the server.  In case, I suggest
> you patch the client (or ask your vendor to fix it, if you don't have
> access to the source code, since in that case I suppose you paid for it,
> and thus deserve support).

Ando,

This is a lost cause (fixing it via vendor route - Sun).  ;-( Apparently,
iplanet returns namingContexts without explicitly requesting them.  This
has been a problem since they introduced ldap client in Solaris 8.  It is
still broken in Solaris 9, but at least you can do manual configuration.

-- 
Igor