On Wed, Aug 23, 2017 at 04:13:07PM +0200, Michal Židek wrote:
On 08/23/2017 03:26 PM, Jakub Hrozek wrote:
> On Tue, Aug 22, 2017 at 03:21:14PM +0200, Michal Židek wrote:
> > On 08/22/2017 12:31 PM, Jakub Hrozek wrote:
> > > On Tue, Aug 22, 2017 at 11:40:39AM +0200, Michal Židek wrote:
> > > > On 08/22/2017 11:21 AM, Michal Židek wrote:
> > > > > On 08/21/2017 02:27 PM, Jakub Hrozek wrote:
> > > > > > Hi Michal and sssd-devel,
> > > > > >
> > > > > > one of the RFEs that keeps coming up for SSSD is to provide
a sort of an
> > > > > > 'attestation report' for SSSD. Mostly the request
is about printing who
> > > > > > can access this client machine.
> > > > > >
> > > > > > I know that we fetch all the HBAC rules for a client with
the IPA
> > > > > > provider, but Michal, you mentioned that it's
problematic do to
> > > > > > something similar for the AD provider. Could you elaborate
why? Would it
> > > > > > be possible to extend the AD access provider to fetch all
GPOs that
> > > > > > match this client?
> > > > > >
> > > > >
> > > > > I am not sure how that attestation should look like. Could you
> > > > > point me to an design page if we have some?
> > > > >
> > > > > The way I understood it is that we want list of ALL users
> > > > > in AD with label ALLOWED or DENIED. I am not sure if this
> > > > > possible to do without basically enumerating all users in AD
> > > > > and do the GPO evaluation for every single one of them.
> > > > >
> > > > > If we just want to print the access control related rules
> > > > > in GPO in some nice format, then it would be possible without
> > > > > the enumeration.
> > > > >
> > > > > My point is that making the ALLOW/DENY list could take a lot of
time
> > > > > even if we use cached GPOs. That was my main concern.
> > > > >
> > > > > But again, maybe I misunderstood the RFE.
> > > > >
> > > > > Michal
> > > > > _______________________________________________
> > > > > sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> > > > > To unsubscribe send an email to
sssd-devel-leave(a)lists.fedorahosted.org
> > > >
> > > > Also there is the question if we want to include users from all
> > > > trusted domains...
> > > >
> > > > I think what could be done relatively easily is to feed some tool
with
> > > > SIDs/fqdns of users/groups and make the list just for them/their
> > > > members. Would that be something we want?
> > >
> > > Where would these come from? If the GPOs that perhaps.
> >
> > The SIDs or names (probably just names) would be provided by the user
> > of the tool. I imagine somethink like this:
> >
> > $ sssctl access-check --users foo(a)ad.com bar(a)ad.com
> > foo(a)ad.com ALLOWED
> > bar(a)ad.test DENIED
> >
> > $ sssctl access-check --groups linuxusers(a)ad.com linuxspecial(a)ad.com
> > linuxusers(a)ad.com:
> > foo(a)ad.com ALLOWED
> > bar(a)ad.com DENIED
> > linuxspecial(a)ad.com:
> > spec1(a)ad.com ALLOWED
> > spec2(a)ad.com ALLOWED
> > spec3(a)ad.com ALLOWED
>
> I'm not sure this will be enough. The request specifically asks for
> per-machine report, not per-user.
We would get that with the above version if there is a group that
contains all users. I think it is better if the admin provides
somehow the scope of users that are going to be checked rather
then us (SSSD) trying to figure this out. Also if we do not need
to get the resulting list fast, then I think this would be easy to
implement. We could enhance it later with --verbose to print
detailed information (like what GPO allowed/denied the access).
As I said, I think this would be good debugging tool :) , but
you are right that we need to align the effort with the RFE
requester's expectations.
So, I looked at the requested RFE again and to my own suprise, it was
mostly about IPA clients. In that case, I think that a) the report would
be better generated on the server and b) we don't have to worry about
the GPO case, then.
Thanks for the explanation nonetheless.