On Sat, Feb 02, 2019 at 11:11:41AM -0500, Greg Hudson wrote:
> It's also conceivable that Net::LDAP is at fault; I don't know much
> about it.
It could easily be Net::LDAP. IIRC there was once code that amounted
to the same in OpenLDAP (or perhaps Net::LDAP, not sure which one
was the subject of my RTFS back). Whatever it was, it derived the
server's GSS name from the IP address of the connected socket.
In OpenLDAP, there's the somewhat dangerous
LDAP_OPT_X_GSSAPI_ALLOW_REMOTE_PRINCIPAL
option which enables asking the server for its principal name
(perhaps ok, if used over authenticated TLS connections?). But
otherwise it falls back to whatever name is associated with
the connection
ld->ld_defconn->lconn_server->lud_host
which should contain the name parsed out of the LDAP URI.
> But it seems unlikely that any version of libkrb5 would do a
> forward resolution and then try to do a realm lookup of the IP address;
> that would render rdns=false a useless configuration.
It is quite possible that the LDAP layer is the source of the problem.
--
Viktor.
