Re: Can I bind to server with DN not on server ?

[Pierangelo Masarati <ando@sys-net.it>]

Tom Riddle wrote:

> Howard Chu wrote:
>
> > If you're using OpenLDAP 2.1 or newer, you can use back-ldap for 
> > distributing
> > the tree instead of using referrals. In this case, all of the naming 
> > contexts
> > will be defined on all of the servers, but some portions will be local
> > databases and some portions will be proxied via back-ldap. So in 
> > effect all
> > of your binds will always be contained within any of the servers' naming
> > contexts.
> >
> >  
As Tom and I discussed privately, what's basically needed here
is a mechanism, totally transparent to the client, that allows
a system administrator to set up the distributed DSA in such
a way that when a client authenticates to either of the servers,
its credentials are automatically propagated to those members
of the distributed DSA where operations need to be propagated:
a sort of authorization mechanism.  This could be done easily
by means of a control that allows a proxy to connect to a remote
server with an administrative identity and ask the remote server
to replace this identity into that of the client that initiated the
operation.  The remote server must trust the administrative
identity (e.g. there must be some permission mechanism that
allows one identity to become another "lesser" identity; the
easiest way would be to set up a static "proxydn" in the database
portion of slapd.conf, but we could also think of some new acl
permission, or recycle the auth permission).

So, as soon as a client binds to the proxy, and requests an operation
that needs propagation to a remote server, the proxy should bind
to the remote server with the administrative identity, authorize
the client's identity, and reserve that connection to operations for
that client.

To summarize:

at the proxy side:
- a (client-side) control on top of bind to change identity

at the remote server side:
- a (server-side) control on top of bind that changes identity
 if permitted;
- a simple permission mechanism, e.g.:
 * expand ACL auth permission semantics
 * introduce a new ACL permission (su?)
 * use a static "proxydn" statement in slapd.conf

I hope I'm not reinventing the wheel, though: thinking about
the proxyauth mechanism.

The effort is not so small, but I think this could be classified
as a medium project .

Ando.

> Howard,
>
> I followed your suggestion of distributing the tree using subordinate 
> back-ldaps, however I seem to have run into a fundamental 
> limitiation.  I got it working for two sites, but when I add a third 
> site I get results for only two of them.  The details are here:
> http://www.openldap.org/lists/openldap-software/200311/msg00405.html 
> (I initially started using back-ldap, then tried back-meta, then 
> back-ldap again - all with the same result, so that is why the post 
> refer to back-meta)  The conclusion of that thread is that none of the 
> current versions of openldap can do what I am attempting.
>
> Let me restate what I am attempting and why.  I am approaching this as 
> an application developer, not a sysadmin.  We are looking to build our 
> application around openldap or something similar.  As such I am 
> attracted to "set" ACL because it allows me to have a static daemon 
> configuration (slapd.conf), and yet still have the daemon do all the 
> hard work for me:
>
> access to dn.subtree="..."
>   by self write
>   by anonymous auth
>   by set="this->userList->roleOccupant&user" read
>
>
> I have extended the schema of my users like so:
>
> attributetype ( 1.3.6.1.4.1.2286.2.1.13
>    NAME 'userList'
>    DESC 'List of dn with access to me'
>    SUP uniqueMember )
>
> Objectclass ( 1.3.6.1.4.1.2286.2.2.1
>    DESC 'App User'
>    NAME 'appuser'
>    SUP inetOrgPerson
>    MAY ( userList ))
>
> This way my app can create groups, assign users to groups, add or 
> revoke priviledges on groups, then associate groups with other nodes 
> in the tree.  All of this done on the fly without restarting slapd.  
> And this seems to work when the entire tree exists on one server.  
> Where I run into problems is trying to make this work on a distibuted 
> tree.
>
> Is it reasonable to expect openldap to support this ?
> Is this capability on the roadmap ?
> What level of effort would be required to make this work ?
>
> Thanks for your time,
> Tom


+----------------------------------------------------------------------------+
|   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax:+390382476497    |
+----------------------------------------------------------------------------+