Re: (ITS#6439) rootDSE access method question

[j@gropefruit.com]

ldapclient is also used to initialize system-wide configuration of a =
solaris box involving LDAP.  You pass it the basic parameters needed to =
perform LDAP lookups of users, groups, etc., and it generates the system =
configuration.  This is the message me and my associates have gathered =
after all the reading we have done. (Note: This is also "similar" to the =
way RedHat's LDAP configuration tool (system-config-authentication) =
works, in that parameters are passed from the command line, into a =
parser, which then edits files and then initialized the configuration.)

Solaris 10's system, even when explicitly told to BIND WITH A PROXY USER =
and NOT ANONYMOUSLY, it insists on binding anonymously.

--> Our OpenLDAP system does not permit anonymous binds. This is by =
design and I will not budge on this.  <--

When we try to initialize ldapclient using the automatic config, it =
tries to download a profile (which we have ready and waiting in our DIT) =
to configure the local system - unfortunately, since its binding =
anonymously, this fails.

So our remaining option is to use the ldapclient utility with the MANUAL =
config option, where we DON'T use a profile, rather we pass the needed =
parameters to it manually, on the command line .

When we configure this manually and execute the configuration changes, =
we see in our slapd logs an attempt to talk to our system looking for =
the supportedControl and supportedSASLMechanisms attributes -- which are =
only available in the rootDSE.  Unfortunately, this process uses every =
scope EXCEPT base, which is the only scope that allows rootDSE to be =
queried.

Furthermore, I got them to admit that the very act of looking for SASL =
entries when doing a SIMPLE BIND config is retarded.  They agreed.

So we have a few issues on Solaris' side:

  * Superfluous SASL queries, even in SIMPLE config.
  * Lack of base scope makes rootDSE query impossible
  * Client insists on binding anonymously, even when told NOT to

They have offered to fix these things, I'm waiting on them now ...

The important thing is that our slapd config is not to blame, as =
everything else in our infrastructure that uses the DS system I built is =
working nicely.

J



Solaris 10's system implicitly tries to perform=20

On Jan 5, 2010, at 15:05 , Howard Chu wrote:

> j@gropefruit.com wrote:
>> Full_Name: J
>> Version: 2.4.20
>> OS: Debian-Lenny/amd64
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (68.15.14.98)
>>=20
>>=20
>> Certain clients (for example, a Solaris 10 host) need to query the =
rootDSE of
>> our OpenLDAP server. Unfortunately, due to the way their client =
software is
>> written, the Solaris 10 client will only be able to attempt to view =
the rootDSE
>> using a scope of ONELEVEL or SUBTREE - it does not support BASELEVEL =
searches of
>> the rootDSE.
>>=20
>> Solaris 10's 'ldapsearch' allows manual querying of our rootDSE for
>> testing-purposes, so I know otherwise things should work (ACL-wise, =
etc).  It
>> just seems to be a problem in the system-config, as the man page =
clearly states
>> that only the two aforementioned scopes are allowed.
>>=20
>> Options?  Is there a way I can alias a DN-less object? If so, is this =
even
>> advisable?=20
>>=20
>> Or, perhaps is there a way to store an alternate copy of the rootDSE =
somewhere
>> that is more "conventionally" accessible?
>>=20
>> At this point, I'll consider any alternative.  I reviewed the manpage =
for
>> slapd.conf, however the rootDSE parameter in slapd.conf seems to be =
only used
>> for "additions" or supplemental changes to an existing rootDSE.
>=20
> Since you quoted the ldapclient docs, I have to ask what exactly =
you're trying
> to accomplish. Solaris ldapclient is only used to configure NSS, and =
there are
> no NSS tables that serve anything that could be extracted from an LDAP
> server's rootDSE. What are you really trying to do?
>=20
> --=20
>  -- Howard Chu
>  CTO, Symas Corp.           http://www.symas.com
>  Director, Highland Sun     http://highlandsun.com/hyc/
>  Chief Architect, OpenLDAP  http://www.openldap.org/project/