Bug 856155

Summary:	perl-LDAP fails GSSAPI authentication
Product:	Red Hat Enterprise Linux 6	Reporter:	Marko Myllynen <myllynen>
Component:	perl-LDAP	Assignee:	perl-maint-list
Status:	CLOSED WORKSFORME	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.3	CC:	abokovoy, ppisar, psabata
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-09-12 08:19:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marko Myllynen 2012-09-11 10:32:02 UTC

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

Comment 2 Petr Pisar 2012-09-12 07:12:45 UTC

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?

Comment 3 Marko Myllynen 2012-09-12 08:19:10 UTC

(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..

Comment 4 Petr Pisar 2019-07-11 11:33:46 UTC

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.