Viewing Incoming/6770
Full headers

Major security issue: yes  no

Notes:

Notification:

Date: Mon, 03 Jan 2011 23:02:02 +0000
From: jwinius@umrk.nl
To: openldap-its@OpenLDAP.org
Subject:  	Proxy authorization fails with SASL-GSSAPI

Full_Name: Jaap Winius
Version: 2.4.23-7
OS: Debian squeeze
URL: 
Submission from: (NULL) (2001:888:10:d5f::2)


Proxy authorization works with SIMPLE binds, as well as with SASL binds using
various other mechanisms, but not with SASL and GSSAPI. In that case it may only
work initially, but eventually the problem is that, for no apparent reason, the
consumer instead attempts to use a SIMPLE bind to authenticate itself to the
provider. Naturally, this fails.

For detailed background and debugging info, see this thread:

   http://www.openldap.org/lists/openldap-technical/201101/msg00002.html

Followup 1

Date: Tue, 4 Jan 2011 17:50:03 +0100 (CET)
Subject: Re: (ITS#6770)  	Proxy authorization fails with SASL-GSSAPI
From: masarati@aero.polimi.it
To: jwinius@umrk.nl
Cc: openldap-its@openldap.org

Let me confirm that it works as expected with SIMPLE and SASL bind using
EXTERNAL (TLS) and DIGEST-MD5.  I haven't tried with GSSAPI; the issue
might be specific to it.

p.

Followup 2

Date: Fri, 15 Jul 2011 10:08:52 +0200
From: =?ISO-8859-15?Q?Christian_W=E4schenfelder?= <c.waeschenfelder@websale.de>
To: openldap-its@openldap.org
Subject: Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI

Same problem here:

If I use the cn=config style, proxy authorization works directly after 
configuring it.
If I reboot the slave server the authorization fails to work and the 
bindmethod switches from SASL/GSSAPI to SIMPLE.

If I delete the configuration directory /etc/ldap/slapd.d and use a 
simple /etc/ldap/slapd.conf and make the same configuration the old way 
everything keeps working after reboots.

So I think there is a Problem while loading the cn=config configuration.

Followup 3

Date: Tue, 19 Jul 2011 21:15:09 +0200 (CEST)
Subject: Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
From: masarati@aero.polimi.it
To: c.waeschenfelder@websale.de
Cc: openldap-its@openldap.org

> Same problem here:
>
> If I use the cn=config style, proxy authorization works directly after
> configuring it.
> If I reboot the slave server the authorization fails to work and the
> bindmethod switches from SASL/GSSAPI to SIMPLE.
>
> If I delete the configuration directory /etc/ldap/slapd.d and use a
> simple /etc/ldap/slapd.conf and make the same configuration the old way
> everything keeps working after reboots.
>
> So I think there is a Problem while loading the cn=config configuration.

Something in this area should have been fixed in master code; some fixes
may have been released in 2.4.26.  Can you indicate what version you're
using?  In case you're using the latest, can you test with master code?

p.

Followup 4

Date: Wed, 20 Jul 2011 12:28:54 +0200
From: Pierangelo Masarati <masarati@aero.polimi.it>
To: =?ISO-8859-15?Q?Christian_W=E4schenfelder?=
 <c.waeschenfelder@websale.de>
CC: "openldap-its@openldap.org" <openldap-its@openldap.org>
Subject: Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI

Please keep replies in cc with the ITS.

On 07/20/2011 10:28 AM, Christian W.schenfelder wrote:
>
>> Something in this area should have been fixed in master code; some
fixes
>> may have been released in 2.4.26. Can you indicate what version you're
>> using? In case you're using the latest, can you test with master code?
>>
>> p.
>>
>
> At the moment I'm using 2.4.23-7 on debian squeeze.
> I'll try it with 2.4.26 and master code.
>
> Ahhm... were can I get the master code, just download via git?

yes.  p.

Followup 5

Date: Wed, 20 Jul 2011 18:10:01 +0200
From: =?ISO-8859-15?Q?Christian_W=E4schenfelder?= <c.waeschenfelder@websale.de>
To: Pierangelo Masarati <masarati@aero.polimi.it>
CC: "openldap-its@openldap.org" <openldap-its@openldap.org>
Subject: Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI

> Something in this area should have been fixed in master code; some fixes
> may have been released in 2.4.26. Can you indicate what version you're
> using? In case you're using the latest, can you test with master code?
>
> p.

The problem seems already solved in 2.4.26.

The authorization seems to work reliable now,
I couldn't recognize any authorization errors after upgrading to 2.4.26.