Setting rdns = false causing "cannot determine realm" error

[Adam Lewenberg]

For some time we have been recommending people use the setting "rdns =
false" in the "[libdefaults]" section. However, recently we have run
across one case where that setting is causing an issue.

A client is running a Perl script where, using Net::LDAP, they make a
GSSAPI connection to our load-balanced endpoint. The endpoint they
connect to is "ldap.example.com". The DNS looks like this:

   ldap.example.com is a CNAME for ldap.best.example.com
   ldap.best.example.com is a CNAME for ldap-lb.example.com
   ldap-lb.example.com is an A record

If rdns is set to "true" then everything works. However, when set to
"false" we see the message "Error: Unspecified GSS failure.  Minor code
may provide more information (Cannot determine realm for numeric host
address)"

The "Cannot determine realm for numeric host address" message suggests
that the Kerberos client is trying to get a ticket for an IP address.

Note: I realize that this may not be a Heimdal issue since the client
uses MIT Kerberos, but I thought I'd take a stab at someone on this list
having a useful suggestion.

[Greg Hudson]

On 2/2/19 9:22 AM, Adam Lewenberg wrote:
> If rdns is set to "true" then everything works. However, when set to
> "false" we see the message "Error: Unspecified GSS failure.  Minor code
> may provide more information (Cannot determine realm for numeric host
> address)"

It sounds like the client program is resolving the name to an IP
address, then importing a host-based GSS name like "ldap@1.2.3.4".  With
rdns=true, MIT krb5 will reverse-resolve 1.2.3.4 to a hostname; with
rdns=false, releases 1.11 and earlier will error out with that message.
 (Later releases would try to use the service principal
"ldap/[hidden email]", which would likely also fail.)  The script
probably needs to be changed to pass a hostname to Net::LDAP.

It's also conceivable that Net::LDAP is at fault; I don't know much
about it.  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.

> Note: I realize that this may not be a Heimdal issue since the client
> uses MIT Kerberos, but I thought I'd take a stab at someone on this list
> having a useful suggestion.

You might try [hidden email] for future questions like this.

[Viktor Dukhovni-2]

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.