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. |
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. |
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. |
Free forum by Nabble | Edit this page |