Here is the completed version of the patch (against 2.4.8) I initially brought up a week or so ago. It makes the hostname canonicalization step for SASL optional, both via ldap.conf and commandline arguments for the client tools. I submit it for consideration into the mainline code, as I believe it would provide a great benefit to a number of users such as myself.
I present the completed version after some of the comments on the initial snapshot. The majority of comments were, frankly, what I had expected - "fix the DNS, that's the real problem." I argue that such an approach is somewhat narrow. While undoubtedly a best practice, it is not always feasible. I'll share my thoughts and comments on some of the previous responses. I hope to get some good feedback and reconsideration of the knee-jerk reactions.
SASL authentication is not strictly dependent on hostname canonicalization in any form. There are, however, certain common implementation schemes that do require a canonical hostname determination in order to function properly. This unfortunately seems to have led to an implicit edict that all DNS configurations must be perfectly compliant in order for OpenLDAP to be able to use SASL authentication. The emphasis is always to 'fix your DNS, then we'll talk', rather than relaxing the overly strict requirement of the canonicalization step - overly strict because it is *not* required from SASL itself, only from OpenLDAP's usage of SASL.
There exist broken DNS setups for which a user/admin may not be in a position to remedy the errors. Sorry Howard, saying "just use static /etc/hosts files" or "run your own local authoritative DNS server" are not very viable options. On my home server I have a dynamic IP. When I get a new IP, the machine updates its own /etc/hosts file, and while it would be possible to push the value to others, there are synchronization issues, not the least of which is that the other machines are more than likely not powered on when the update occurs. Running my own DNS server works great when within that netwok, but what about the cases where I'm at work/school/friend/in-laws/wherever and would like to connect? Or when I give access to external users? They certainly aren't going to be using my DNS server as a first line source. Anyway, why should I need any of that additional overhead when alternative, perfectly viable solutions exist.
What benefit does the hostname canonicalization procedure provide? In a nutshell, it is simply a method of determining the identity of the entity with whom I'm communicating. When done using DNS it certainly has known security issues, but aside from direct attacks is generally quite reliable if properly configured. I believe that this is why it's not atypical to say "fix your DNS" if something isn't working properly. But why must this be the only option? There are at least two other cases to consider: 1) there are cases where we may not really care one iota about server authentication, and 2) there are options other than DNS for providing, at the very least, the same level of confidence in the identity of the peer.
As for the first case, it's not one I'm involved in nor all too familiar with, but it certainly doesn't stretch the imagination to think of a case where the data returned is self-validating or requires no validation.
With regard to the second case, alternative host identification, I'm currently using TLS for this, requiring a minimal level of validation. Yes, you can shoot yourself in the foot on this too (no self-signed certs, minimally a cert signed by a self-signed "CA"), but it certainly provides an option where there otherwise might not be one (as in my case).
RFC 4752 (SASL GSSAPI), Section 5 states: "When constructing the input_name_string, the client SHOULD NOT canonicalize the server's fully qualified domain name using an insecure or untrusted directory service."
I mentioned a similar quote from a less SASL-specific (more Kerberos-specific) RFC before. The emphasis of this statement is to not use improper directory services to perform canonicalization. However, this does *not* imply that canonicalization must be performed, rather it states that *if* the client decides to use it, then a trusted naming service should be used to perform it. RFC 4422 (SASL) makes this explicit and confirms that the canonicalization is at most optional for a client, directly stating that "there is no requirement that the authorization identity string be canonical" (Section 5).
Having said all of that, it is also noteworthy to note that canonicalization will often be enforced server-side simply based on the authentication configuration. In the specific case of using Kerberos, if the service principal uses the canonical hostname, the client better be getting a ticket using the canonical hostname as well.
As a wrap-up, DNS has issues - some technical and some non-technical. I'm not in anyway suggesting that a proper setup should not be pursued, if such an option is available. But the fact of the matter is that it is not always possible. In such situations, the OpenLDAP software should not overtly preclude the user from using it (or indirectly require large workarounds) to the greatest extent in any situation, even if the configuration of a certain system is not idyllic.
A few (or more) thoughts for consideration - Thanks, Joel Johnson