Present the name provided by the caller for SASL/GSSAPI authentication

[mkomitee]

In commit af63067 on 2008-04-21 there was an attempt to "Fix a problem with Net::LDAP when talking to a round-robin LDAP server(s) using SASL/GSSAPI authentication to use the provided hostname not the canonical name"

This commit changed Net::LDAP so that it passes an IP Address to SASL/GSSAPI as the server identification instead of the server name supplied by the client. This assumes that Kerberos (the usual GSSAPI mechanism employed) will do a reverse DNS lookup to construct the Kerberos service principal name, since IP Addresses are almost never used for this. This need not be the case; MIT Kerberos, for example, can be configured to resolve CNAME and PTR records, just CNAMEs, or perform no DNS canonicalization at all.

Since we've configured Kerberos to not do PTR lookups, Net::LDAP with SASL/GSSAPI does not work in our environment.

The problem here is in assuming that it's even possible for Net::LDAP to (as the Changes explanation says) "Pass correct hostname to SASL when connecting to a round-robin" There's no real way for the library to know what the "correct hostname" is supposed to be, beyond that specified by the caller. It's the responsibility of the systems administrator to ensure that Kerberos, DNS records, service principals, and application configuration are arranged such that they all work together, and if a library tries to second-guess this by altering the name passed to it, it will likely cause this kind of breakage at some point. As a default, a library should pass the hostname unaltered to SASL/GSSAPI so that it can obey the local rules for locating the correct service principal.

This isn't only a functional problem, it could be considered a security problem. If the caller intended to authenticate to one service with a certain service name and ends up successfully authenticating to an entirely different service due to unintended canonicalization, one could argue that the service ought not be trusted.

Sometimes we face the opposite problem -- getting Kerberos to work in a misconfigured environment where the rules in effect produce the wrong result. In that case it may be useful to offer the library client the option of performing some DNS canonicalization on its own, or alternately allow the client to specify the Kerberos principal directly -- but these should be options, not the default.

This patch reverts the behavior to using the name supplied by the caller instead of using the address to which a connection has been established. This will reliably produce the service name that the caller intended to authenticate.

[mkomitee]

I created a patch which makes the current behavior optional instead of impossible.