On 08/22/2017 11:38 AM, Jakub Hrozek wrote:
On Tue, Aug 22, 2017 at 11:21:43AM +0200, 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 point of this thread is to come up with the design :-) I would
prefer to see what we can do currently, do a first draft of the design
and then pass it on to users and customers who requested the feature and
see if they are OK with this.
>
> The way I understood it is that we want list of ALL users
> in AD with label ALLOWED or DENIED.
Hmm, I was going to say just allowed, but now I remember that we also
can use GPOs to deny access, right?
Yes, we can have rules to specifically deny access and if I am not
mistaken they have higher priority (IIRC if the user is allowed in
some rule and denied in other rule then he is denied access).
With GPOs there is also the issue with security filtering. A GPO
can be filtered out for some users or groups (the GPO can be made
relevent only if specified users and groups are logging in) in
that case it does not matter what is in the GPO.
This can get more complicated, because that means different
users see different subset of GPOs, if we merge all GPOs and
make attestation report based on that, we may actually end up
with list that is not relevant at all.
> 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.
So, here is what I'm thinking for IPA and I initially thought we could
take a similar approach for AD.
For IPA, we fetch all the HBAC rules which apply for this host, either
directly or via a host group. The rules contain the user name or a
group.
Usernames are easy and the report could just print them. For groups,
unfortunately we don't have other mean that to call getgrnam.
GPOs do not contain any names, only SIDs, and those can be
both user SIDs and group SIDs.
So the report would look like this:
for rule in cached_hbac_rules:
for user in rule.users:
print "$user is allowed"
for group in rule.groups:
print "Members of $group are allowed. That includes: "
group_members = getgrnam($group)
for member in $group_members:
print "$member"
In the worst case scenario, we can really fall back to
create a tool for AD provider that gets list of names or
groups and does the GPO evaluation as if those people were
logging in. This would give the most accurate results and
could also be used as debugging tool for GPO processing.
But it would be very slow to do for all users in the AD,
but given the nature of this tool the database can be split
into parts and not everything needs to be done at once
(for example admin decides to create the ALLOW/DENY list
for just users from few groups (linux_users for example)).
I /though/ that we fetch all the GPOs and we could print a similar
report as the pseudocode above, just unrolling the SIDs in the GPOs.
>
> 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.
This could be an option, too.
But as I said the security filter could make this problematic.
>
> 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.
See above, the RFE is a bit fuzzy, we need to see what we can do first.
Sure, thanks for explanation.