[SSSD] [RFC] Remove enumeration support from the AD and IPA back ends

Dmitri Pal dpal at redhat.com
Sun May 10 22:38:11 UTC 2015


On 05/10/2015 02:41 PM, Jakub Hrozek wrote:
> Hi,
>
> this proposal might be a bit controversial, so I hope there wouldn't be
> any big flame.
>
> In the past, the AD and IPA back ends were just a wrapper around the LDAP
> provider that used different defaults customized for the particular server.
> But that's not the case anymore. We keep adding features to the AD and IPA
> back ends that require different smart logic to get the right data, might
> require several lookups (IPA ID views), might require looking up huge amounts
> of data (looking all users/groups from a trusted AD forest) or might not even
> support the "get all" semantics (trusted AD users on an IPA client).
>
> As a result, enumeration doesn't work at all for IPA ID views, doesn't
> work at all for AD trusted users on IPA clients and performs badly (and
> is not tested well) for trusted AD domains. If you cross out all the
> use-cases that don't work, you end up with..what the LDAP provider
> supports.
>
> Therefore, I would like to propose that we remove enumeration support from AD
> and IPA back ends eventually. Clearly, there must be some transition
> period for such a big feature that /is/ being used by our users.
>
>  From the top of my head, this could be a syslog warning for one release,
> requiring to add another config option to get the deprecated functionality
> back in another release and finally a cut in the next one. I know removing
> functionality is always a sensitive topic, but I also think that removing
> broken enumeration is also a better choice than pretending it works.
>
> What are your thoughts?
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
The direction makes sense for me.

-- 
Thank you,
Dmitri Pal

Director of Engineering for IdM portfolio
Red Hat, Inc.




More information about the sssd-devel mailing list