On 12/03/2013 12:38 PM, Yassir Elley wrote:
Hi all,

I have written up a Design Document for GPO Integration with the AD Provider [1]. The Document includes the design, as well as some Unresolved Issues. Your review of the document would be greatly appreciated (and especially your input on the Unresolved Issues)!

Thanks,
Yassir.

[1] https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryGPOIntegration
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel


Comments:

1) Sentence: Note that there must a CSE plugin module and CSE enforcement...
does not read well. Some verb is missing somewhere...

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.

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.

4) "Refresh Interval Configuration" - you lost me there. In the first paragraph you talk about both user and computer refresh intervals and then in the second you talk explicitly about computer_gpo_refresh_interval which seems like the refresh interval for computer based GPO.
I think you tried to explain that there is yet another GPO that can deliver the timeouts that control the refresh of the policy.

5) I suggest that all the configuration settings for the feature key of the fact that it is an AD access provider feature so the names would be something like:
ad_hbac_policy_refresh or something similar. Again I do not think we should expose GPO because it would be misleading and set an expectation that we support GPO or plan to.

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.

7) Should we enforce GPO logon policy settings only at user login, or also at periodic intervals?
Only at login. We do not have any other setting enforced after the login.

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.

9) I do not like just in time approach. It will be too costly by design since GPO are file based and thus slow.
If we look at the cons:
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.

11) Completely disagree with the recommendation. Performance hit on per user basis is IMO a non starter.



-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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