RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
On a system in a domain/realm where all of kinit / ldapsearch -Y GSSAPI / net ads join -k / etc. work as expected the following the Perl script fails:

$ cat test.pl
#!/usr/bin/perl

use Net::LDAP;
use Authen::SASL;

my $server = 'server.example.com';
my $sasl = Authen::SASL->new(mechanism => 'GSSAPI');
my $ldap = Net::LDAP->new($server) or die $@;
my $res = $ldap->bind(sasl => $sasl);
print $res->error_text;
print $sasl->error;
$ldap->unbind;
$ perl test.pl
An error occurred in C<Net::LDAP>
GSSAPI Error (init): Unspecified GSS failure.  Minor error code may provide more information
Cannot determine realm for numeric host address

It would seem that this cannot possibly work if numeric IP address is used in LDAP.pm for connection as it currently happens.

There is a related Debian bug at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573596 about the same issue.

CC'ing Alexander who already investigated this.

Version-Release number of selected component (if applicable):
RHEL 6.3 / perl-LDAP-0.40.1.el6

This is the famous story about hostname canonicalization which I've seen in other projects too.

Debian decided not to fix it because, according to upstream, it would break other (MIT) users and recommended way is to pass result of Authen::SASL->new(mechanism => 'GSSAPI')->client_new('ldap', $server) to NET::LDAP::bind().

Does this change in your application fix this problem for you?

(In reply to comment #2)
> This is the famous story about hostname canonicalization which I've seen in
> other projects too.

Very (in)famous indeed :)

> Debian decided not to fix it because, according to upstream, it would break
> other (MIT) users and recommended way is to pass result of
> Authen::SASL->new(mechanism => 'GSSAPI')->client_new('ldap', $server) to
> NET::LDAP::bind().
> 
> Does this change in your application fix this problem for you?

Yes, it does, thanks a lot for the tip!

Closing in the hope this answer will find its way to the top of the search results..

For your information, upstream fixed the behavior in 0.57 release with <https://github.com/perl-ldap/perl-ldap/commit/f36b2cd1edc53db262f2292053c07615784461a2> commit. The 0.57 release defaults to SASL hostname given as a hostname to LDAP->new() and an application can override the SASL hostname with a new sasl_host option of bind() argument.