[SSSD] Design Doc review request for AD GPO Integration

Jakub Hrozek jhrozek at redhat.com
Thu Dec 5 11:29:55 UTC 2013


On Wed, Dec 04, 2013 at 05:58:31PM -0500, Yassir Elley wrote:
> Comments inline.
> 
> ----- Original Message -----
> > 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...
> 
> Good catch. This should say: "Note that there must be a CSE plugin module and CSE enforcement mechanism, both of which must have knowledge of where the policy settings are being stored (and in what format)."
> 
> > 
> > 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).
> 
> > 
> > 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)."
> 
> > 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.
> 
> In the first paragraph, I was describing the general case, which could include both computer-based and user-based GPOs. However, in the second paragraph, I was describing the one policy setting that we would be implementing in the first implementation (which happens to be a computer-based GPO). And yes, there is a second GPO available that can deliver the refresh policy timeouts (if we decide to use it).
> 
> > 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.
> 
> The configuration naming sounds reasonable. However, we will obviously
> need to document the fact that the AD access provider will be making use
> of the standard logon GPO policy settings used by Windows (so that the
> feature can be used).

Does it make sense to keep "hbac" in the option name?

> 
> > 
> > 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.
> 
> > 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.
> 
> This sounds reasonable.
> 
> > 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!
> 
> > 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.
> 
> 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.

This call would be done in the child, correct? Then if we see this part
as a bottlenec, we can prefork a child process. IIRC this part was
already designed, if not written, back when we were implementing the
winbind provider. But again, this is a future optimization.

> 
> > 
> > 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.

I would actually prototype the per-login download with additional short grace
period (can be hardcoded for the prototype, maybe 5 seconds). If next
login comes during the grace period, cached GPOs are used just as if
SSSD was offline. This should solve the "morning login rush".

I think the periodic refreshes would be more suitable for other GPO use
cases than access control. In my opinion, one of very important aspects
of design of cache logic is to make the cache logic predictable. Various
refreshes and enumerations might make SSSD perform better, but usually
at the expense of good predictability.



More information about the sssd-devel mailing list