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

[Petr Spacek]

On 14.2.2013 03:55, Dmitri Pal wrote:
> On 02/13/2013 09:48 PM, Nathan Kinder wrote:
>> On 02/13/2013 06:18 PM, Dmitri Pal wrote:
>>> On 02/13/2013 02:08 PM, Simo Sorce wrote:
>>>> On Wed, 2013-02-13 at 13:30 -0500, Rob Crittenden wrote:
>>>>> Simo Sorce wrote:
>>>>>> On Wed, 2013-02-13 at 12:59 -0500, John Dennis wrote:
>>>>>>> On 02/13/2013 12:53 PM, Simo Sorce wrote:
>>>>>>>
>>>>>>>> If we can solve the looping and potential deadlocking concerns I
>>>>>>>> think
>>>>>>>> we can avoid the json reply and let the framework do the actual
>>>>>>>> final
>>>>>>>> ldap add.
>>>>>>> Could you elaborate on your looping and deadlock concerns? I
>>>>>>> don't see
>>>>>>> where they would arise if what we're watching is entirely
>>>>>>> independent of
>>>>>>> our LDAP tree.
>>>>>> I do not understand what you are 'watching' ?
>>>>>>
>>>>>> Simo.
>>>>>>
>>>>> I think he means have a persistent search to watch for new entries and
>>>>> then act upon them.
>>>> I think a 2 step approach is misguided, so I've written it off from the
>>>> start.
>>>>
>>>> Simo.
>>>>
>>> This all thread smells like rewriting winsync by using internal plugin
>>> and IPA framework.
>>> Is there any chance we can use existing winsync solution to do what we
>>> need but sync from staging instance rather than AD?
>>> Then the flow will be:
>>> HR system -> staging DS instance -> dirsync -> IPA
>>> Couple assumptions:
>>> a) We are satisfied with the security of the existing winsync solution
>>> and authentication used there. I do not see why it should be different
>>> here as it is a very similar use case.
>>> b) I expect we can sync from 389 to 389 with minor config changes and
>>> effectively no code changes
>> This is not the case.  Winsync uses the AD Dirsync control, which 389
>> does not support.  The Winsync code also expects the AD schema on the
>> entries coming in from the Dirsync response.  Even if 389 supported
>> the Dirsync control, there would be a fair amount of code changes to
>> deal with whatever schema we would need to expect.
>>> c) The users created via winsync now are created in a proper way so IPA
>>> accepts then as IPA users
>>>
>>> This solves the problem of add and delete of the users.
>>> I know that winsync already supports group add/delete but we never
>>> qualified it in IPA. So may be it is time, at least for this use case.
>>> I would really think that this might be a lower cost solution than
>>> writing yet another custom plugin.
>>> Let us try to reuse what we already have.
>> I think a custom plug-in would be easier (though I do have concerns
>> about the performance impact of the JSON approach).
>>
> I really think that we rather have an external solution and not the one
> hot wired into the IPA internals via the proposed plugin.
> Something like an external proxy or gateway rather than the approach
> Simo proposed even if it would be more work. This work would be reusable.
> We already have several use cases for the LDAP proxy. This can be one
> more. A bit more and there will be enough need to build one anyways.
> The main value is that it is optional and external and acts as an
> ecosystem level solution that can be developed and tested on a separate
> schedule rather than being internal to IPA.

In my Fedora 17 I found package python-ldaptor. It seems to offer nice support 
for writing own event-based LDAP servers. For simple LDAP proxy it could be 
enough.

$ yum install python-ldaptor
$ python
import ldaptor.protocols.ldap.ldapserver
help(ldaptor.protocols.ldap.ldapserver)

-- 
Petr^2 Spacek