Cannot start kerberos signing/sealing when using TLS/SSL

[Markus Moeller]

I get the following error when I use LDAPS with SASL/GSSAPI authentication
to Active Directory. The error occurs because SASL/GSSAPI tries to encrypt
the connection although SSL encryption is already used. This can be
disabled by setting the sasl security property maxssf to 0, but it seems not
to work. Do I use it wrongly or is the value not passed through ?

Thank you
Markus

The error message I get is:

00002029: LdapErr: DSID-0C09016D, comment: Cannot start kerberos
signing/sealing when using TLS/SSL, data 0, vece at ./LDAP-AD-query.pl

My perl script:

#!/usr/bin/perl
#
# Reads LDAP Attributes
#
#
use Net::LDAPS;
use Authen::SASL qw(Perl);
# use Authen::SASL;
use Authen::Krb5;
use Net::DNS;

my $user = 'mm';

# DNS details
my $ares = Net::DNS::Resolver->new;
my $nres = Net::DNS::Resolver->new;
my $rres = Net::DNS::Resolver->new;
my $aquery = $ares->query("win2003r2.home");
my $hostlist = '';

#
# Query DNS and make sanity checks to guaranty Kerberos works
#
if ($aquery) {
# loop over list of IP-addresses
foreach my $arr ($aquery->answer) {
next unless $arr->type eq "A";
my $nquery = $nres->query($arr->address);
if ($nquery) {
# Get names for IP-addresses
foreach my $nrr ($nquery->answer) {
next unless $nrr->type eq "PTR";
my $rquery = $rres->query($nrr->ptrdname);
if ($rquery) {
# Check if DNS lookup of name gives same IP-address
foreach my $rrr ($rquery->answer) {
next unless $rrr->type eq "A";
if ( $rrr->address eq $arr->address ) {
$hostlist = $hostlist." ".$nrr->ptrdname;
}
}
}
}
}
}
} else {
print("DNS query failed: $ares->errorstring \n");
exit;
}
my @hosts = split(/\s+/,$hostlist);

# ldap details
my $server = \@hosts;
my $bind_path = 'dc=win2003r2,dc=home';
my ($mail, $samaccountname, $userprincipalname, $useraccountcontrol);
my ($ldap, $sasl, $mesg, $entry);

#
# Connect to Global Catalog to get details of all trusted domain users
#
# $ldap = Net::LDAP->new( $server,
# port => 3268,

$ldap = Net::LDAPS->new( $server,
port => 3269,
timeout => 2,
verify => 'never',
version => 3) or die "$@";

# Setup Kerberos cache
Authen::Krb5::init_context();
my $ccache_name = "FILE:/tmp/.client.cache.$$";
my $ccache = Authen::Krb5::cc_resolve($ccache_name);
my $kt = Authen::Krb5::kt_resolve('FILE:./clienttest.keytab');
my $princ = Authen::Krb5::parse_name('client/te...@WIN2003R2.HOME');
$ccache->initialize($princ);
my $creds = Authen::Krb5::get_init_creds_keytab($princ, $kt);
$ccache->store_cred($creds);

$ENV{'KRB5CCNAME'} = $ccache_name;
$sasl = Authen::SASL->new('GSSAPI', 'user' => '','maxssf' => 0 );
# $sasl = Authen::SASL->new('GSSAPI', 'user' => '''maxssf' => 0 , debug =>
13);
# $ldap->debug(15);
# $ldap->debug(255);
$mesg = $ldap->bind( '',
sasl => $sasl) ;

$mesg->code && die $mesg->error;

$mesg = $ldap->search( # perform a search
base => $bind_path,
filter => "(samaccountname=$user)",
timelimit => 2,
attrs => ['mail',
'samaccountname',
'useraccountcontrol',
'userprincipalname']
);
$ccache->destroy;

$mesg->code && die $mesg->error;

foreach $entry ($mesg->entries) {
$mail = $entry->get_value('mail');
$samaccountname= $entry->get_value('samaccountname');
$useraccountcontrol = $entry->get_value('useraccountcontrol');
$userprincipalname = $entry->get_value('userprincipalname');
}

$mesg = $ldap->unbind; # take down session

my $locked = ($useraccountcontrol & 0x0002)?"Yes":"No" if defined
$useraccountcontrol;

print("Retrieved LDAP Attributes:\n");
print("User-Mail = $mail\n");
print("User-SAM-Accountname = $samaccountname\n");
print("User-Account-Control = $useraccountcontrol\n");
print("User-Account-Locked = $locked \n");
print("User-Principal-name = $userprincipalname\n");

[Markus Moeller]

I think this would fix it

--- LDAP.pm 2008-10-27 20:05:58.000000000 +0000
+++ LDAP.pm.new 2009-11-15 21:07:49.000000000 +0000
@@ -397,6 +397,9 @@
sockname => $ldap->{net_ldap_socket}->sockname,
peername => $ldap->{net_ldap_socket}->peername,
);
+ $sasl_conn->property(
+ maxssf => 0,
+ ) if ($ldap->{scheme} eq 'ldaps'),

my $initial = $sasl_conn->client_start;

Markus

"Markus Moeller" <hua...@moeller.plus.com> wrote in message
news:hdpgn1$9ia$1...@ger.gmane.org...

[Quanah Gibson-Mount]

--On Sunday, November 15, 2009 9:09 PM +0000 Markus Moeller
<hua...@moeller.plus.com> wrote:

> I think this would fix it

I think AD must be broken and non RFC compliant. I've never had problems
using SASL/GSSAPI encryption at the same time as SSL/TLS encryption. It
wouldn't be the first time MS AD was broken in obvious ways.

For example, here is startTLS over ldap with SASL/GSSAPI encryption:

ldap1:/root# ldapsearch -ZZ -h ldap.stanford.edu -b "" -s base
SASL/GSSAPI authentication started
SASL username: qua...@stanford.edu
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#

As such, I would suggest your patch as is be rejected. An option to
disable the SASL SSF should be supported though.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration

[Markus Moeller]

It might be an AD setting (enforcing SSL). But does it make sense to use
SASL/GSSAPI encryption on top of SSL ?

An option would be definitely the best.

Thank you
Markus

"Quanah Gibson-Mount" <qua...@zimbra.com> wrote in message
news:E016E53A28E2FEB16294F53C@[192.168.1.199]...

[Quanah Gibson-Mount]

--On Sunday, November 15, 2009 10:36 PM +0000 Markus Moeller
<hua...@moeller.plus.com> wrote:

> It might be an AD setting (enforcing SSL). But does it make sense to use
> SASL/GSSAPI encryption on top of SSL ?

Well, given things like MITM with SSL, it could be. ;) Plus it could be
possible the SASL SSF is higher than the SSL SSF.

> An option would be definitely the best.

Agreed.

[Markus Moeller]

"Quanah Gibson-Mount" <qua...@zimbra.com> wrote in message

news:13EB6539F13316BC67E8506F@[192.168.1.199]...

> --On Sunday, November 15, 2009 10:36 PM +0000 Markus Moeller
> <hua...@moeller.plus.com> wrote:
>
>> It might be an AD setting (enforcing SSL). But does it make sense to use
>> SASL/GSSAPI encryption on top of SSL ?
>
> Well, given things like MITM with SSL, it could be. ;) Plus it could be
> possible the SASL SSF is higher than the SSL SSF.
>

The only problem with that is that the client not the server can control it
(right now). It just says everything which is DES or better is OK. So
possible yes but when ?

[Quanah Gibson-Mount]

--On November 16, 2009 8:09:44 PM +0000 Markus Moeller
<hua...@moeller.plus.com> wrote:

>
> "Quanah Gibson-Mount" <qua...@zimbra.com> wrote in message
> news:13EB6539F13316BC67E8506F@[192.168.1.199]...
>> --On Sunday, November 15, 2009 10:36 PM +0000 Markus Moeller
>> <hua...@moeller.plus.com> wrote:
>>
>>> It might be an AD setting (enforcing SSL). But does it make sense to use
>>> SASL/GSSAPI encryption on top of SSL ?
>>
>> Well, given things like MITM with SSL, it could be. ;) Plus it could be
>> possible the SASL SSF is higher than the SSL SSF.

I can't help that Microsoft does a poor job of implementation. :) OpenLDAP
certainly supports server side setting of both the SSL SSF and SASL SSF
requirements. And the overall SSF requirement so you don't have to
individually set them, but you can if you want.

[Graham Barr]

On Nov 15, 2009, at 3:09 PM, Markus Moeller wrote:
> I think this would fix it

you you maybe, but I suspect someone else would not want that.

I suggest you look at the next branch in the repository

http://github.com/gbarr/perl-ldap/tree/next/

using this you can call $sasl->client_new and set the property in your own code before passing to ->bind

Graham.