<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 12/03/2013 12:38 PM, Yassir Elley wrote:
    <blockquote
      cite="mid:523152922.1117656.1386092287368.JavaMail.root@redhat.com"
      type="cite">
      <pre wrap="">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] <a class="moz-txt-link-freetext" href="https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryGPOIntegration">https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryGPOIntegration</a>
_______________________________________________
sssd-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/sssd-devel">https://lists.fedorahosted.org/mailman/listinfo/sssd-devel</a>
</pre>
    </blockquote>
    <br>
    <br>
    Comments:<br>
    <br>
    1) Sentence: Note that there must a CSE plugin module and CSE
    enforcement... <br>
    does not read well. Some verb is missing somewhere...<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    I think you tried to explain that there is yet another GPO that can
    deliver the timeouts that control the refresh of the policy.<br>
    <br>
    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:<br>
    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.<br>
    <br>
    6) When should GPO retrieval take place?<br>
    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.<br>
    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. <br>
    <br>
    7) Should we enforce GPO logon policy settings only at user login,
    or also at periodic intervals?
    <br>
    Only at login. We do not have any other setting enforced after the
    login.<br>
    <br>
    8) If we implement gpo refresh, which of the refresh configuration
    options should we implement and how?<br>
    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. <br>
    <br>
    9) I do not like just in time approach. It will be too costly by
    design since GPO are file based and thus slow.<br>
    If we look at the cons:<br>
    <ul>
      <li>suffers a performance hit on every user login &lt;- IMO this
        is a show stopper.<br>
      </li>
      <li>we will not have a refresh infrastructure in place if we end
        up implementing other computer-based GPO policy settings (in a
        subsequent implementation) &lt;- Not a con IMO. The refresh
        infra is there for other reasons.
      </li>
      <li>doesn't allow us to perform user logout (if policy settings no
        longer allow access) &lt;- Not a requirement at least in
        foreseeable future.
      </li>
    </ul>
    10) The spec-compliant option is to perform GPO retrieval...  -
    makes more sense for me.<br>
    And AFAIU the performance hit will be only if GPOs changed. Again we
    need to measure the hit.<br>
    <br>
    11) Completely disagree with the recommendation. Performance hit on
    per user basis is IMO a non starter.<br>
    <br>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
<a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a>


</pre>
  </body>
</html>