On 4/13/2023 9:20 AM, Quanah Gibson-Mount wrote:

--On Tuesday, April 11, 2023 3:54 AM +0000 Jordan Brown openldap@jordan.maileater.net wrote:

...

How can I get detailed information about connection errors - host not found, timed out, connection refused, various TLS errors, et cetera?

Generally, use stats level logging and then parse the logs for them.

Sorry, to be clear:  I'm asking about how a *client* might diagnose these errors.

On 4/13/2023 9:28 AM, Quanah Gibson-Mount wrote:

--On Thursday, April 13, 2023 5:22 PM +0000 Jordan Brown openldap@jordan.maileater.net wrote:

...

How can I get detailed information about connection errors - host not found, timed out, connection refused, various TLS errors, et cetera?

https://ldap.com/ldap-result-code-reference/

I'm already dumping that.  But it is not very detailed.  I believe that's what ldapsearch is dumping; here's some sample output in various error cases:

No server running (connection refused):

$ ldapsearch -h myhost -b '' ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

No response, connection timed out:

$ ldapsearch -h 1.2.3.4 -b '' ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

TLS certificate not trusted:

$ ldapsearch -H ldaps://ldap.mycompany.com -b '' ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Host does not exist:

$ ldapsearch -h nonexist.example.com -b '' ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

On 4/13/2023 10:36 AM, Quanah Gibson-Mount wrote:

--On Thursday, April 13, 2023 6:33 PM +0000 Jordan Brown openldap@jordan.maileater.net wrote:

...

I'm already dumping that.  But it is not very detailed.  I believe that's what ldapsearch is dumping; here's some sample output in various error cases:

Those are the result codes that are provided to the client per RFC.  Feel free to write a new RFC expanding on the result codes.

OpenLDAP could have additional non-RFC features that would allow you to retrieve more error information.

There are dozens of OpenLDAP-specific options.  An OpenLDAP-specific option could retrieve additional error information.

There could be a variation on LDAP_OPT_CONNECT_CB - for discussion, call it LDAP_OPT_ERROR_CB - that calls back with error information on any failing connection.  (That would be more right than a "get error" option, because it would work when there's more than one server specified.)

So the first question is "does OpenLDAP have such a thing?".  It sounds like the answer is "no".

In that case, please consider this to be a request for such a feature.  Diagnosing LDAP client connection problems is a significant cost; anything that we can do to make it easier would be worthwhile.  I would be happy to participate in the design and implementation of such a feature.

On 4/14/2023 2:11 AM, Ondřej Kuzník wrote:

AFAIK that's correct, some of what you're asking for depends on the errno, some of it is in TLS code and very little, if anything, is currently preserved for that kind of use.

Thanks.

A pretty comprehensive walk of the codebase might be needed to cover the lot?

Alas, yes.  But if there's a pretty general mechanism at the OpenLDAP layer, then OpenLDAP can pass through whatever the lower layer says... and if the lower layer says something useless, then the buck can be passed to them.

But even being able to say "it's a TLS problem" or "it's a Kerberos problem" would be helpful.

Given you've already considered a usecase and some of the requirements users might have on this kind of feature, you're welcome to propose one yourself. If it's ready for inclusion in 2.7, that's where it could go. We can assist where you're unsure of the codebase and eventually review.

I'll work on that.  No specific schedule.  This is not an urgent matter, just something that keeps popping up over and over.

If you want to go that route, let's move the planning into -devel.

Will do.

On 4/13/2023 11:33 PM, Bastian Tweddell wrote:

In the end the message 'Can't contact LDAP server' is correct, but is not very helpful to pinpoint the issue. My practical approach is to use `-d -1` on the ldap commands.

Thanks - and for me personally that's helpful, but what I need is something that my application can call, to retrieve and display error information in its user interface.  I used ldapsearch as an example because everybody knows it and one would hope that it would demonstrate best practices, but my actual application does not offer shell access and does not expect that the user would know how to formulate an LDAP query.