Thanks Kurt;
1) However, the client was not previously hacked.
2) The client (and all other Solaris clients) will authenticate just
fine against the other LDAP server.
It is just this server specifically that I'm having this problem
with.

-Ric

Kurt D. Zeilenga wrote:

Seems to me that the client requested, without authenticating
first, the return of the root DSE. It got what it asked for:
the root DSE. However, I note that the client did not ask the
return of any operational attributes and, hence, none were provided.
However, if one look at your original post, the client was complaining
about not being able to locate any naming contexts (values of the
namingContext (operational) attribute in the root DSE). The client
appears to be broken in that it expects the return of operational
attributes which it didn't ask to be returned.

Since you said this occurred only after upgrading OpenLDAP Software,
i surmise that you were running a hacked version of OpenLDAP Software
previously to work around this client problem. If you haven't
yet fixed (through the maintainer of this client) the problem, you
might try applying a similar hack to the later version of OpenLDAP
Software.

I don't remember for sure. It was a couple of months ago.
This is all on a development server, so there was no rush.
Now I need to start building the production server, so it has become important.
I'll be sure to add the patch to the full production version, once I get this one debugged.

It should have been a relatively routine upgrade.
It's important to note that my AIX, and Linux clients are still able to
authenticate without problem.
It's only the Solaris clients that this affected.

Hm, that is odd. Did you patch any of your solaris systems recently?

I've done several things. But nothing that would effect this.
And I've tried several systems.

The primary system I'm using as a test client, was recently re-installed. It is still able to attach, and authenticate to the other LDAP server (we also have a Sun One Directory Server. There is no problem attaching to that.

When I did the upgrade, because I was changing the database, I exported
the whole thing first with "slapcat". Then after installing the new s/w,
I ran slapadd to put it all back.
It seems to have dropped something.

I've never had slapadd "drop" anything... It just loads what is in the LDIF output. Did you run slapadd with the '-c' option? If you did, and it had output, that would indicate you had errors in your LDIF as compared to your schema, which it would then skip past.

I was being a bit tongue in cheek about that.
I didn't run slapad with -c. If it had encountered errors, I would have prefered it stopped.
It completed with no errors.

The logs haven't been much help.
Setting the loglevel to 128, shows the interaction with the ACLs, and I'm
not seeing where anything is being denied.
Below is an example run:

That log output isn't particularly useful. If possible, I suggest having an isolated machine you can query with a Solaris system, and run slapd with the '-d -1' flag, and dump that output to a file as a connection is made. It will give you all relevant information.

Okay, I did this, and got no rejects.
So it is not rejecting the connection. It did come up with some errors about: