[Freeipa-devel] [RFC] Creating a new plugin to make it simpler to add users via LDAP

[Petr Spacek]

On 13.2.2013 15:53, Simo Sorce wrote:
> Hello list,
>
> with recently seen a few requests to add FreeIPA users via LDAP
> directly. This is a common method supported by many meta-directory/HR
> systems, however so far we cannot really recommend it because we add
> quite a number of attributes automatically in our framework code when we
> create users, and those functions can change in future versions.
>
> However these external tools are usually not very flexible and
> supporting them as they are would make for a much better experience for
> integrators.
>
> I had a brief discussion with Rob on IRC on how to address this
> situation.
>
> If we limit ourselves to users we could probably resolve this problem
> with a relatively simple 389ds plugin that intercept add operations that
> try to add a user.
>
> The idea is that the remote system would be allowed to set a minimum of
> attributes (even incomplete according to our schema). But as long as a
> specific set of objectclasses is set (say person and posixaccount) the
> operation would be recognized as an attempt to create a user account.
>
> In this case the plugin would take over the operation and perform a call
> against our framework using json. The call would send a reformatted
> request using the data we got in input so that any custom
> objectclass /attribute can be preserved. The call would also add a
> special flag so the framework knows this is coming from 389ds itself.
>
> The framework would treat this requests in a slightly special way, it
> would use all the common code currently used to properly format a user
> entry adding all the ancillary data we need, but instead of trying to
> ldapadd the entry, it would instead return it back to the caller.
>
> 389ds at this point gets back a json reply, convert it into an ldap add
> operation and proceeds with this new 'augmented' operation instead of
> the original one.
>
> What do people think about this option ?
> I think it would be extremely valuable for admins, as it would allow
> them to drive user 'synchronization' in a very simple way.
> It could also be used to properly augment winsync users so we can allow
> full creation when syncing from AD with all the proper attributes
> created through the json request. So I see a lot of optential here.
>
> The only doubt is the json back and forth communication.
>
> What do people on the framework side think ? Is there going to be any
> big problem in adapting the framework so we can use common code to
> prepare the object but then change the last stp and return a json reply
> instead of perfroming an ldap add operation ?

Personally, I don't like the idea of JSON requests & response parsing *inside* 
389. I see a lot of opportunities for crash or security hole.

What about small (optional) separate daemon?

A) Variant with separate sub-tree

1. create some new subtree, e.g. cn=useradd-playground,dc=example,dc=com
2. watch this sub-tree with persistent search
3. catch new objects and run IPA commands as necessary
4. replace "old" objects with referrals to IPA objects (or do something different)

I'm not sure that various meta-directory systems can handle situation where 
user disappeared/object is moved/object is morphed to referal. That can be a 
problem.


B) More crazy variant with LDAP "proxy"
(Now I'm on very thin ice, I don't know how complex it would be. I only found 
some examples like [1].)
Prepare "fake" (non-IPA) LDAP server with same LDAP "structure" and let 
separate daemon watch server's content and run IPA commands as necessary. It 
would be best if the small daemon can pretend to be LDAP server and catch LDAP 
operations directly, as shown in [1].

[1] http://tonthon.blogspot.cz/2011/02/ldaptor-ldap-with-twisted-server-side.html

-- 
Petr^2 Spacek