Dear Maintainer,

I have a Perl script to read from an OpenLDAP instance using Net::LDAP
with a GSSAPI bind. The script works fine on Debian stretch but fails on
Debian buster.

Note that on both servers the line at the bottom of the Perl code that
runs ldapsearch produces the same correct results, so I am sure that the
Kerberos ticket cache is correct on both servers.

Looking at the OpenLDAP logs I see that the ldapsearch run shows up with
the strength factors sasl_ssf=256 ssf=256 while the Net::LDAP bind shows
up with the strength factors sasl_ssf=1 ssf=256. Since the Net::LDAP bind
is using Kerberos, the sasl_ssf should be 56, not 1.

#######

use strict;
use warnings;
use Authen::SASL;
use Net::LDAP;
use Data::Dumper;

my $server_name = 'ldap.example.com';
$ENV{'KRB5CCNAME'} = '/tmp/krb.tkt';

my $ld = Net::LDAP->new($server_name, version => '3');
$ld->start_tls(verify => 'require');

if (!$ld or $ld == -1) {
    die "Could not connect to directory server $server_name";
}

my $SASL = Authen::SASL->new('GSSAPI');
my $status = $ld->bind(sasl => $SASL);

if ($status->code) {
    die  'Bind error: (' . $status->error_name . ') ' . $status->error_text;
}

my $base   = 'dc=example,dc=com';
my $filter = '(uid=johndoe)';
my @attrs  = ('uid', 'sn');
$status = $ld->search(
    base    => 'dc=example,dc=com',
    filter  => $filter,
    attrs   => \@attrs,
    ) ;

my @entries = $status->all_entries;
# This results in nothing (but should result in the same data as the ldapsearch below):
warn Dumper @entries ;

my $attrs = join(' ', @attrs) ;
my $cmd = "ldapsearch -LLL -h $server_name -b $base '$filter' $attrs";
# This gives the correct result:
warn `$cmd`;

As a further test, here is a simple python script that does the same
thing as the Perl script. It works fine and the LDAP logs show
"sasl_ssf=256 ssf=256" when I run it:

#######
import ldap
import ldap.sasl
import os

ldap_server = 'ldap.example.com'
os.environ["KRB5CCNAME"] = "/tmp/testing.tkt"

conn = ldap.ldapobject.ReconnectLDAPObject('ldap://' + ldap_server,
retry_max = 5)
auth = ldap.sasl.gssapi("")
conn.sasl_interactive_bind_s("", auth)

basedn          = 'dc=example,dc=com'
searchScope     = ldap.SCOPE_SUBTREE
searchFilter    = '(uid=johndoe)'
searchAttribute = [
     "uid",
     "sn",
]
ldap_result_id = conn.search(basedn, searchScope, searchFilter,
searchAttribute)
result_type, result_data = conn.result(ldap_result_id, 0)
print(result_data)
#######

So, ldapsearch and the python script appear to connect with
"sasl_ssf=256 ssf=256" but the Perl script connects with "sasl_ssf=1
ssf=256". Why?

ssf=256" but the Perl script connects with "sasl_ssf=1 ssf=256". Why?

The cause lies in this section of the code base:
https://metacpan.org/release/EHUELS/Authen-SASL-2.1700/source/lib/Authen/SASL/Perl/GSSAPI.pm#L140-146
which says:

        # set SSF property; if we have just integrity protection SSF is set
        # to 1. If we have confidentiality, SSF would be an estimate of the
        # strength of the actual encryption ciphers in use which is not
        # available through the GSSAPI interface; for now just set it to
        # the lowest value that signifies confidentiality.
        $self->property(ssf => (($choice & 4) ? 2 : 1));

It would be absolutely perfect to get a patch to address this issue. I'd be
happy to include. Please forward the bug upstream (
https://github.com/gbarr/perl-authen-sasl) so others can learn about this
problem and/or contribute to the solution.

Thanks for reporting!


Regards,

A PR has been submitted (upstream) which may be able to address this bug as
well: https://github.com/gbarr/perl-authen-sasl/pull/11

It would be absolutely great if someone could confirm this, because I don't
have an LDAP setup handy to test the solution. Please let me know if the
patch as submitted should be merged, so I can merge and release in time for
Trixie.