[SSSD] Design Doc review request for AD GPO Integration

Dmitri Pal dpal at redhat.com
Thu Dec 5 02:28:01 UTC 2013


On 12/04/2013 05:58 PM, Yassir Elley wrote:
>
> 2) IMO it should be stated as a clear non goal to create a pluggable CSE
> framework on the client at least at the moment and extend it on case by case
> basis.
> Although the intent is to only implement one CSE plugin module for the first implementation, it makes sense to design a pluggable mechanism since the GPO specs themselves require different CSE plugin modules for different cse-guids. Other than allowing us to be spec-compliant, designing a pluggable mechanism also allows us to add additional CSE plugin modules (perhaps for GPO refresh parameters) as needed in the future (on a case by case basis).

I suggest to be explicit that it is a non goal for the first implementation.

>
>> 3) The specific use case is to provide access control so the feature from
>> SSSD POV is a special ad centric access provider. There is no intent to
>> drive the whole SSSD configuration via GPO, probably ever. So the GPO is
>> really a delivery mechanism and internal detail of the new access provider.
>> So IMO the design spec should be around a AD access provider feature. Then
>> in the implementation you can drill down into all the details of the fact
>> that the policies would actually be GPO based.
>>
> I agree that the access control GPO will only be enforced by the existing AD access provider. I tried to make this clear in the document. For example, "This design page proposes adding GPO support to the AD provider, thereby enabling the AD provider to use GPOs for policy decisions (such as client-based access control)."

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.

[...]
>
>
>> 6) When should GPO retrieval take place?
>> May be it should happen periodically but triggered by user login or max
>> interval. However I would start with what is simple and then optimize based
>> on testing.
>> IMO the simplest would probably to read it once at startup. At least for the
>> first iteration. Then we will be able to test and see how bad it is
>> performance wise and determine what refresh approach would be preferable.
> Here, you suggest triggering GPO retrieval by user login (or max interval). But later, you indicate that you are not in favor of retrieving GPOs at user login. I assume that you mean the latter (not at user login). If not, please provide another comment.

I was not clear. I said "triggered" by user login. I meant that if user
logs in after some max period of time the login will trigger an async
refresh but would not block and wait for the inline GPO update. We need
to think it through better but I mean async refresh related to user
login if user login happens long time after last refresh.


>
>> 8) If we implement gpo refresh, which of the refresh configuration options
>> should we implement and how?
>> None at the beginning and then do a simple periodic refresh and then add
>> support for GPO based definition refresh configuration. But this can be done
>> is several takes and over the course of several releases. We do not need to
>> do it all upfront.
> If we are not retrieving GPOs at every user login, then I think we need to at least do a simple periodic refresh. Otherwise, any change in the whitelist or blacklist for logon access would not take effect until the next system boot!
As I said. We need to do on the SSSD restart and then try different
options and see how bad things are and make decisions then.
I think we would end up with periodic refresh but I might be wrong. May
be we will create a mechanism similar to the mid-point cache refresh
that we have now for core data. I do not think we are in the position to
make this determination upfront. We will not release it without a
solution but I do not think we can decide 100% now.


>
>> 10) The spec-compliant option is to perform GPO retrieval... - makes more
>> sense for me.
>> And AFAIU the performance hit will be only if GPOs changed. Again we need to
>> measure the hit.
> Your understanding is correct that the policy files will only be retrieved if their policy settings differ from the locally cached versions. Since we are talking about whitelists and blacklists for logon access, I suspect these will typically not change for days, if not weeks or months (which might go against my recommendation on the importance of having fresh data). As such, whether we retrieve per user (with no refresh) or per system boot (with refresh), we will typically not need to retrieve any policy files and we can use our locally cached files. However, in order to determine which GPOs are applicable for the computer, the spec requires us to make two LDAP calls every time. Additionally, in order to determine whether the policy settings have changed, the spec requires us to use SMB to retrieve a small version file (per GPO). Only then can we be sure that the actual policy settings haven't changed.

Implement a generic get_ad_ hbac_policy(user, host) call.
We will use it at startup and then try periodically, on login or in some
more complex scheme. If we have a call it would be easier to make a
determination whether the performance hit is acceptable or not.

>
>> 11) Completely disagree with the recommendation. Performance hit on per user
>> basis is IMO a non starter.
> In general, the performance hit (per user login) is two LDAP calls and one SMB call (per GPO). For our use case, there will typically only be a single GPO.

Even this might be too much in some cases.

>
> Regards,
> Yassir


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/







More information about the sssd-devel mailing list