[soc] External LDAP support in Samba4.

[Martin Kühl]

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.


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.

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?


Cheers,
 Martin