[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Meta Idassert-bind



***  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? 

My current configuration is...

require authc

access to * by * write

#
# Meta 
#

database        meta
suffix          "dc=meta,dc=example,dc=com"
subordinate

rootdn "cn=manager,dc=example,dc=com"

network-timeout 10

#Target 1

uri "ldap://ldap.acme.org/dc=target1,dc=meta,dc=example,dc=com";

idassert-bind  bindmethod=simple
               binddn="cn=searchuser,dc=acme,dc=org"
               credentials="secret"
               mode=none
               flags=non-prescriptive

idassert-authzFrom "dn.regex:dc=users,dc=example,dc=com"

rewriteEngine on

suffixmassage "dc=target1,dc=meta,dc=example,dc=com" "dc=acme,dc=org"

#Target 2

uri "ldap://ldap.another.com/dc=target2,dc=meta,dc=example,dc=com";

idassert-bind  bindmethod=simple
               binddn="cn=searchuser,dc=another,dc=com"
               credentials="secret"
               mode=none
               flags=non-prescriptive

idassert-authzFrom "dn.regex:dc=users,dc=example,dc=com"

rewriteEngine on

suffixmassage "dc=target2,dc=meta,dc=example,dc=com"
"dc=another,dc=com"


#
#Local
#

database bdb
suffix "dc=example,dc=com"
directory /usr/local/var/openldap-data/base/

rootdn "cn=manager,dc=example,dc=com"
rootpw "secret"

index objectclass eq
index cn,sn eq,sub


The ldif file I use to populate the local database...

dn: dc=example,dc=com
dc: example
description: Container for metadirectory
objectClass: dcObject
objectClass: organization
o: example

dn: cn=Search user,dc=users,dc=example,dc=com
cn: search user
sn:search user
objectclass: top
objectclass: person
objectclass: organizationalPerson
userpassword: secret


Thanks for your help!

Drew


Andrew Graham
ICT
AgustaWestland UK
Tel No: +44 (0) 1935 70 4421
andrew.graham@agustawestland.com

*** Disclaimer ***
The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s). 
For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful.

If received in error please return to sender immediately.

Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence.

Westland Helicopters Ltd 
Lysander Road 
Yeovil BA20 2YB 
England 

Registered in England under No 604352