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

Simo Sorce simo at redhat.com
Thu Feb 14 14:01:11 UTC 2013


On Wed, 2013-02-13 at 21:55 -0500, 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.

Penrose.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-devel mailing list