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