----- Original Message -----
On 12/03/2013 12:38 PM, Yassir Elley wrote:
I have written up a Design Document for GPO Integration with the AD Provider
. 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)!
sssd-devel mailing list sssd-devel(a)lists.fedorahosted.org
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
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
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
fact that it is an AD access provider feature so the names would be
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).
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
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
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
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
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
* 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
* 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
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.
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.