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