[SSSD] Design Doc review request for AD GPO Integration

Dmitri Pal dpal at redhat.com
Tue Dec 3 19:41:37 UTC 2013


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 at 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:

  * suffers a performance hit on every user login <- IMO this is a show
    stopper.
  * we will not have a refresh infrastructure in place if we end up
    implementing other computer-based GPO policy settings (in a
    subsequent implementation) <- Not a con IMO. The refresh infra is
    there for other reasons.
  * doesn't allow us to perform user logout (if policy settings no
    longer allow access) <- Not a requirement at least in foreseeable
    future.

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/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20131203/4584d026/attachment.html>


More information about the sssd-devel mailing list