FQDN needed by sasl_gss_client_step or gss_import_name?

[Steve Langasek]

On Thu, May 16, 2002 at 04:40:47PM -0700, Dave Snoopy wrote:
> I am using OpenLDAP's ldapsearch tool, in conjunction
> with Cyrus SASL and MIT Kerberos 5. The tool allows me
> to do LDAP queries against a Microsoft PDC, assuming
> that I have first obtained the ticket from the
> Microsoft KDC. It works great, except for one
> problem...

> My DNS server has two entries for my PDC/KDC. The two
> entries are:
>    gem-pdc.gem.company.com  -> 192.168.10.87
>    gem-pdc  -> 192.168.10.87

> A reverse DNS lookup on the IP will return either of
> the host names.

> I guess that either SASL or Kerberos does a reverse
> DNS lookup based on the IP. When the non-FQDN host
> name is returned, my LDAP/SASL/Kerberos gives the
> following error:

>  added plugin '/usr/lib/sasl/libgssapiv2.so'
>  mech list from server is GSSAPI GSS-SPNEGO
>  Considering mech GSSAPI
>  Best mech so far: GSSAPI
>  Considering mech GSS-SPNEGO
>  sasl_gss_client_step: AUTHNEG
>  Trying to get userid
>  SASL/GSSAPI authentication started
>  sasl_gss_client_step: AUTHNEG
>  Trying to get userid
>  Userid: -C
>  name: ldap at gem-pdc
>  ldap_sasl_interactive_bind_s: Local error

> I traced down the error to the Kerberos function
> "gss_import_name", which is being called from the SASL
> function sasl_gss_client_step. This problem only
> happens when the non FQDN kdc name is returned from
> DNS. Is this a Kerberos or SASL problem? Does anyone
> know how to resolve it (without changing my DNS)?

Why do you have two PTR records for the same IP address, and why is one of 
them not a valid FQDN?

How else would you expect GSSAPI to determine the canonical name for the
machine?

By and large, storing a non-FQDN as a PTR record is broken.

Steve langasek
postmodern programmer