[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-software
Subject:    Re: Meta Idassert-bind
From:       Pierangelo Masarati <ando () sys-net ! it>
Date:       2008-07-31 18:42:07
Message-ID: 20266397.1901217529727360.JavaMail.root () mail2 ! sys-net ! it
[Download RAW message or body]


----- "Andrew Graham" <andrew.graham@agustawestland.com> wrote:

> ***  Before acting on this email or opening any attachment you are
> advised to read the disclaimer at the end of this email ***
> 
> I've re-read my original message and it didn't make alot of sense. So
> here's take two!
> 
> I'm using back-meta to attempt to amalgamate several ldap servers
> into
> one single tree. This should cater for users that exist only in a
> local
> BDB database, and also for users with accounts in one of the target
> ldap
> servers. If I say 'local' or 'remote' user at any point, I'm
> referring
> to users stored in the local bdb database or a remote ldap server
> respectively. I shall refer to the local openldap server as the proxy
> server.
> 
> The meta database is subordinate to the local database. This allows
> me
> to have a base record for the entire directory.
> 
> Everything works perfectly for targets that don't require a bind
> before
> searching. For targets that do require a successful bind, I've been
> trying to use the 'idassert-bind' feature with mixed results. The
> following is a description of the behaviour I am trying to achieve:
> 
> If a local user binds to the proxy server, and performs a query with
> one or more targets in scope, then the proxy server should use
> predefined credentials to bind to and search only the targets in
> scope
> on behalf of the local user.
> 
> If a remote user binds to the proxy server, and performs a query
> affecting only the target where that user is stored, then the proxy
> server should bind to that target using the credentials supplied by
> the
> remote user. If there are any other targets in the scope of the
> query,
> openldap should not attempt to use the predefined credentials to bind
> to
> and search on that target.
> 
> To try to achieve this, I have placed all local users in their own
> branch of the tree, and set the 'idassert-authzFrom' for each target
> to
> match this branch only, thus preventing remote users from using the
> idassert feauture and barring them from querying other targets than
> their own. 
> 
> Here is the first of two 'interesting' results. If I bind to the
> proxy
> server as a remote user with multiple targets in scope, the bind is
> proxied to the remote user's target correctly. The proxy then
> proceeds
> to attempt to bind to the other targets in scope using seemingly
> random
> names. Some examples (captured with wireshark) are '\270+1\b',
> '\250\202/\b\005', '\220\241\322\267\220\241\322\267\020' and
> 'x\267.\b'. The name changes every time, but each time no password is
> provided. The proxy will not attempt to search any of the targets
> after
> binding, even the target to which the user belongs.
> 
> I'm not sure I understand the purpose of the 'non-prescriptive' flag,
> but if I set it on each target (as Pierangelo suggested previously),
> the
> unusual behaviour changes. When binding with a remote user, the proxy
> will correctly bind to the target to which the remote user belongs
> using
> the remote users credentials. If another target is in scope, the
> proxy
> will attempt to bind to it without name or password. The proxy will
> proceed to search the targets. This is fine for my situation, but I
> would like to understand why this happens?
> 
> The second problem I'm having is with the local users. If the
> 'network-timeout' statement is used in the meta database definition,
> whenever a local user binds to the proxy and queries one or more of
> the
> target servers, the proxy will attempt to bind to the targets with
> the
> predefined name but with no password. If network-timeout is not
> specified, the proxy binds with both the predefined name and password
> to
> every target in scope. Is this behaviour intended or a bug? 

I think your explanation is clear enough, provided some of the behaviours you \
describe are quite unexpected.  There seems to be quite a few bugs in this feature.  \
Unfortunately, I won't be able to work at it in the next few days, you'll need to \
wait at least until the end of next week.

p.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]