OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/7678
Full headers

From: matth@netsight.co.uk
Subject: Operational Error propagated from back-meta
Compose comment
Download message
State:
0 replies:
3 followups: 1 2 3

Major security issue: yes  no

Notes:

Notification:


Date: Mon, 02 Sep 2013 14:48:42 +0000
From: matth@netsight.co.uk
To: openldap-its@OpenLDAP.org
Subject: Operational Error propagated from back-meta
Full_Name: Matt Hamilton
Version: 2.4.36
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (213.133.64.253)


I am using the meta backend to query multiple LDAP (AD) backends. This is to
consolidate several directories in different departments into one. We attempt
both simple binds with username/password and also anon binds to look up user
information.

database	meta
suffix		"DC=hscic,DC=nhs,DC=uk"
rootdn		"DC=hscic,DC=nhs,DC=uk"
chase-referrals no
norefs yes

uri 		"ldap://dc1lv.npfit.nhs.uk/DC=hscic,DC=nhs,DC=uk"
"ldap://dc2lv.npfit.nhs.uk" "ldap://dc1dr.npfit.nhs.uk"
suffixmassage	"DC=hscic,DC=nhs,DC=uk" "OU=Accounts - Active Users, OU=routine
objects, DC=npfit, DC=nhs, DC=uk"
idassert-bind bindmethod=simple 
	      binddn="CN=webuser,OU=Surnames Q to Z,OU=Accounts - Active
Users,OU=Routine Objects,DC=npfit,DC=nhs,DC=uk" 
	      credentials="secret1"
	      mode=self
idassert-authzFrom      "dn:*"

uri 		"ldap://ts-l-dci-350.ic.green.net/DC=hscic,DC=nhs,DC=uk"
"ldap://ts-l-dci-344.ic.green.net" "ldap://hg-l-dci-332.ic.green.net"
suffixmassage	"DC=hscic,DC=nhs,DC=uk" "OU=HSCIC,DC=ic,DC=Green,DC=Net"
idassert-bind bindmethod=simple 
	      binddn="CN=z-CFHimport,OU=Service
Accounts,OU=Administration,DC=ic,DC=Green,DC=Net" 
	      credentials="secret2"
	      mode=self
idassert-authzFrom      "dn:*"

At the moment, trying to do an authenticated simple bind to slapd caused an
Operational Error to be propagated to the client regardless of the setting of
'onerr'. Even when a result is successfully found. This is due to one server in
the backend succeeding and the other returning an operational error due to an
invalid bind (as would be expected as the credentials supplied from the client
will only work with one of the backends).

Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that
the code is not checking for 'Operational Error' as a specific case above and so
uses the default case (line 1665). Hence sres is set to 'Operational Error' too
at line 1934.

The server should be changing this to LDAP_SUCCESS somewhere in that logic
unless META_BACK_ONERR_REPORT.

Followup 1

Download message
Date: Mon, 02 Sep 2013 08:15:35 -0700
From: Howard Chu <hyc@symas.com>
To: matth@netsight.co.uk, openldap-its@openldap.org
Subject: Re: (ITS#7678) Operational Error propagated from back-meta
matth@netsight.co.uk wrote:
> Full_Name: Matt Hamilton
> Version: 2.4.36
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (213.133.64.253)
>
>
> I am using the meta backend to query multiple LDAP (AD) backends. This is
to
> consolidate several directories in different departments into one. We
attempt
> both simple binds with username/password and also anon binds to look up
user
> information.

That doesn't make much sense, since AD disallows anonymous Binds.

> At the moment, trying to do an authenticated simple bind to slapd caused an
> Operational Error to be propagated to the client regardless of the setting
of
> 'onerr'. Even when a result is successfully found. This is due to one
server in
> the backend succeeding and the other returning an operational error due to
an
> invalid bind (as would be expected as the credentials supplied from the
client
> will only work with one of the backends).
>
> Looking at servers/slapd/back-meta/search.c at around line 1903 it appears
that
> the code is not checking for 'Operational Error' as a specific case above
and so
> uses the default case (line 1665). Hence sres is set to 'Operational Error'
too
> at line 1934.

back-meta/search.c has nothing to do with Binds. Not sure what you're trying 
to demonstrate there.
>
> The server should be changing this to LDAP_SUCCESS somewhere in that logic
> unless META_BACK_ONERR_REPORT.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 2

Download message
Cc: "openldap-its@openldap.org" <openldap-its@openldap.org>
From: Matt Hamilton <matth@netsight.co.uk>
Subject: Re: (ITS#7678) Operational Error propagated from back-meta
Date: Mon, 2 Sep 2013 18:43:18 +0100
To: Howard Chu <hyc@symas.com>
On 2 Sep 2013, at 04:15 PM, Howard Chu <hyc@symas.com> wrote:

> matth@netsight.co.uk wrote:
>> Full_Name: Matt Hamilton
>> Version: 2.4.36
>> OS: Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (213.133.64.253)
>> 
>> 
>> I am using the meta backend to query multiple LDAP (AD) backends. This
is to
>> consolidate several directories in different departments into one. We
attempt
>> both simple binds with username/password and also anon binds to look up
user
>> information.
> 
> That doesn't make much sense, since AD disallows anonymous Binds.

Sorry, I wasn't clear. I mean we do both anon and simple binds to OpenLDAP.
Hence why the config has credentials in it to use against the backends if not
supplied by the client. 

>> At the moment, trying to do an authenticated simple bind to slapd
caused an
>> Operational Error to be propagated to the client regardless of the
setting of
>> 'onerr'. Even when a result is successfully found. This is due to one
server in
>> the backend succeeding and the other returning an operational error due
to an
>> invalid bind (as would be expected as the credentials supplied from the
client
>> will only work with one of the backends).
>> 
>> Looking at servers/slapd/back-meta/search.c at around line 1903 it
appears that
>> the code is not checking for 'Operational Error' as a specific case
above and so
>> uses the default case (line 1665). Hence sres is set to 'Operational
Error' too
>> at line 1934.
> 
> back-meta/search.c has nothing to do with Binds. Not sure what you're
trying to demonstrate there.

I'm not talking about binds there. I'm talking about errors being propagated. 

-Matt


>> 
>> The server should be changing this to LDAP_SUCCESS somewhere in that
logic
>> unless META_BACK_ONERR_REPORT.
> 
> -- 
>  -- Howard Chu
>  CTO, Symas Corp.           http://www.symas.com
>  Director, Highland Sun     http://highlandsun.com/hyc/
>  Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 3

Download message
Date: Sat, 07 Sep 2013 13:53:15 -0700
From: Howard Chu <hyc@symas.com>
To: Matt Hamilton <matth@netsight.co.uk>
CC: "openldap-its@openldap.org" <openldap-its@openldap.org>
Subject: Re: (ITS#7678) Operational Error propagated from back-meta
Matt Hamilton wrote:
> On 2 Sep 2013, at 04:15 PM, Howard Chu <hyc@symas.com> wrote:
>
>> matth@netsight.co.uk wrote:
>>> Full_Name: Matt Hamilton
>>> Version: 2.4.36
>>> OS: Linux
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (213.133.64.253)
>>>
>>>
>>> I am using the meta backend to query multiple LDAP (AD) backends.
This is to
>>> consolidate several directories in different departments into one.
We attempt
>>> both simple binds with username/password and also anon binds to
look up user
>>> information.
>>
>> That doesn't make much sense, since AD disallows anonymous Binds.
>
> Sorry, I wasn't clear. I mean we do both anon and simple binds to OpenLDAP.
Hence why the config has credentials in it to use against the backends if not
supplied by the client.
>
>>> At the moment, trying to do an authenticated simple bind to slapd
caused an
>>> Operational Error to be propagated to the client regardless of the
setting of
>>> 'onerr'. Even when a result is successfully found. This is due to
one server in
>>> the backend succeeding and the other returning an operational error
due to an
>>> invalid bind (as would be expected as the credentials supplied from
the client
>>> will only work with one of the backends).
>>>
>>> Looking at servers/slapd/back-meta/search.c at around line 1903 it
appears that
>>> the code is not checking for 'Operational Error' as a specific case
above and so
>>> uses the default case (line 1665). Hence sres is set to
'Operational Error' too
>>> at line 1934.
>>
>> back-meta/search.c has nothing to do with Binds. Not sure what you're
trying to demonstrate there.
>
> I'm not talking about binds there. I'm talking about errors being
propagated.

You said, exactly:
 >>>
At the moment, trying to do an authenticated simple bind to slapd caused an
Operational Error to be propagated to the client regardless of the setting of
'onerr'.
<<<

So again, are you talking about Bind or are you talking about Search?

I'm unable to reproduce any of the behavior you're describing since the config 
snippets you provided reference servers that are private to your network. Nor 
do I have any local AD servers to test against. Nor have you given exact 
details of the client side commands being issued.

With so little ungarbled information to go on, we cannot investigate.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org