[soc] External LDAP support in Samba4.

[Andrew Bartlett]

On Sun, 2006-06-04 at 21:13 +0200, Martin Kühl wrote:
> For my SoC project I'll assume an external LDAP server with the Samba3
> schema as the LDB backend (for a stable base).  The work then consists
> of three subproblems:
> 
>   1) Defining mappings from AD to Samba3 and back.
>   2) Applying these mappings from a module.
>   3) Loading LDB modules with an LDAP backend.
> 
> I'll work on these in reversed order so I can test my intermediate
> results as I go.
> 
> 
> Loading LDB modules with an LDAP backend
> ----------------------------------------
> 
> The main problem seems to be lacking support for special DNs with an
> LDAP backend.  An easy solution to this would be mapping them to
> "real" DNs (from ldb_ldap or a module) as it's currently done with
> rootDSE.
> Andrew has a different (better) way in mind, but this should suffice
> to get started.

Yeah, I think a 'partitions' module would help solve some of this.  It
would also avoid having the rootdse and schema be stored in the target
LDAP server.

> Applying mappings from a module
> -------------------------------
> 
> A module to perform general mappings should be similar to the existing
> ldb_map module which is currently disabled and needs to be perform
> asynchronously.  For looking at them, I'll have to bug Jelmer about
> the mapped/fallback database distinction.
> 
> There's also the issue of using JavaScript for mappings.  ldb_messages
> can be expressed easily in JavaScript (conversion is defined in
> mprutil.c), and mappings of add and modify requests could be expressed
> as easyily with functions mapping messages to messages, so using
> JavaScript for mappings makes sense.
> 
> Search requests seem harder because (i) ldb_parse_trees can't be
> converted to JavaScript yet and (ii) both the request and the response
> would beed mapping.
> 
> To support mappings in JavaScript I see several possible ways:
> 
>   1) Extend ldb_map to support JavaScript objects in
>      ldb_map_attributes.
>   2) Create a new module that supports mapping via JavaScript,
>      possibly loading sources from a special folder (ala
>      ldb_try_load_dso).
>   3) Extend ldb_modules to support writing complete LDB modules in
>      JavaScript.  This could be done by allowing ldb_module_ops to be
>      JavaScript objects or contains JavaScript functions instead of C
>      function pointers.
> 
> I'll look into these approaches but will probably go with 2) as that
> method is more flexible than 1) (e.g. it could allow dropping js files
> into a folder to use them for mapping) but less disruptive than 3) (a
> lot of additional levels of indirection would be required for that).
> 
> Remaining problems are:
> 
>   * search requests (as mentioned above)
>   * useful syntactic abstractions (for e.g. MAP_RENAME mappings)
>   * asynchronism (are there examples for this in ejs?)
> 
> 
> Defining mappings from AD to Samba3 and back
> --------------------------------------------
> 
> This will be the bulk of the work.  Mappings should be classifiable as
> per the ldb_map module (ldb_map_attr_type), so I will aim for
> completeness of these classes first, completeness of the Samba3 schema
> later and treat complete AD as optional.

You should look carefully at the old Samba3 module that Jelmer did for
last year's SoC.

> This part will also require more effort comparing samba.schema to
> schema.ldif (I'm assuming that
> dn: CN=Aggregate,CN=Schema,CN=Configuration,${BASEDN}
> represents the samba4 schema).
> 
> Is there a place to look for the *semantics* (i.e. not just syntax and
> equality) of the contained attribute types anyone can hint me at?

Not really, and this is the biggest part of the job.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20060605/52e0042d/attachment.bin