Log LDAP "diagnostic messages"?

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Log LDAP "diagnostic messages"?
Date: 2017-07-26 01:21:26
Message-ID: CAEepm=2_dA-SYpFdmNVwvKsEBXOUj=K4ooKovHmvj6jnMdt8dw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

Some LDAP error codes are a bit vague. For example:

LDAP_CONNECT_ERROR Indicates a connection problem.
LDAP_PROTOCOL_ERROR A protocol violation was detected.

To learn more, you have to call
ldap_get_option(LDAP_OPT_DIAGNOSTIC_MESSAGE). Should we do that? For
example, instead of:

LOG: could not start LDAP TLS session: Protocol error

... you could see:

LOG: could not start LDAP TLS session: Protocol error
DETAIL: LDAP diagnostic message: unsupported extended operation

Well, that may not be the most illuminating example, but that's a
message sent back by the LDAP server that we're currently throwing
away, and can be used to distinguish between unsupported TLS versions,
missing StartTLS extension and various other cases. Perhaps that
particular message would also be available via your LDAP server's
logs, if you can access them, but in some cases we're throwing away
client-side messages that are not available anywhere else like "TLS:
unable to get CN from peer certificate", "TLS: hostname does not match
CN in peer certificate" and more.

Something like the attached.

--
Thomas Munro
http://www.enterprisedb.com

Attachment Content-Type Size
ldap-diagnostic-message.patch application/octet-stream 3.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-07-26 01:26:41 Re: segfault in HEAD when too many nested functions call
Previous Message Craig Ringer 2017-07-26 00:54:37 Re: Syncing sql extension versions with shared library versions