On 12/04/2013 10:52 PM, Simo Sorce wrote: > On Wed, 2013-12-04 at 21:28 -0500, Dmitri Pal wrote: >> My point is that the whole page should be about AD access provider and >> the GPO is its implementation detail not a generic mechanism. >> There can be a separate page where you can describe how GPO generally >> works and reference it. Right now the page creates the impression that >> we are starting to build generic GPO infrastructure and just make a >> first step to allow HBAC. IMO this is a wrong impression. We are not >> planning to build a generic GPO provider at least at the moment. But >> we >> need to solve the problem of the AD access control and this is what we >> are solving without any future commitment to the generic GPO support. >> > Well although it is clear we will implement only access related > functionality for now, I do not see why we should go out of our way to > make this a strictly access module specific mechanism as a whole. > > Most of the code needed here is generic in nature as it deals with > downloading GPOs, the whole retrieval and download and parsing process > is quite generic, and should be built in a generic "policy" > module/binary. > > On our side we will just provide a bare bones parser for the actual > policies we are interested in and integration only with the AD access > module. > > If then someone comes along and provides patches for additional GPOs, > including parsers and integration code needed for things they are > interested in (say a plugin to store sudo rules in GPOs) all the better. > > Simo. >
I am not against it if someone comes and implements it as you said. But we should set clear expectations that we are not building a generic GPO solution for all use cases out of box and if someone needs to make it work for other use cases there will be some effort. I am afraid that once we say the word GPO people would think that we can do everything with GPO. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
