[[toc]]
+ Horde Group Policy Objects
(or perhaps some other name, as Microsoft may have a copyright on that term)
The idea of Horde Group Policy Objects (HGPO) is to implement a replacement for the current prefs system, modeled after how Group Policy Objects work in a Microsoft Active Directory. Including a nice administrative GUI, meaning no more editing prefs.php files, and happier admins :)
----
++ Visualization of a HGPO
<code>
+ app
| + prefgroup
| | + pref
| | + pref
| + prefgroup
| + pref
+ app
+ prefgroup
+ pref
</code>
* The list of apps would be pulled from the registry
* each app would have a prefs.xml file defining what prefs are available.
* bundle the GPO and specify a target. A target can consist of:
* entire horde installation
* horde group
* individual user
* guest user
* OU if using LDAP backend
----
++ What would need to be done
* build a HGPO manager to list, create, edit, delete, etc. HGPO's
* Store HGPO in DB table(s)
* horde_gpo table?
* possible extend the datatree
* would ((RampageFramework|RDO)) apply?
Possible DB schema, extending existing prefs schema:
**horde_prefs** table: {{pref_uid, pref_scope, pref_name, pref_value, HGPO}}
* If pref_uid is set, the pref is a user pref
* if HGPO is set, it is a HGPO pref
* what happens if both are set?
**horde_gpo** table: {{HGPO_ID, HGPO_name, HGPO_target, HGPO_target_type, HGPO_overridable}}
**horde_gpo_targets** table: {{HGPO_ID, target_type, target}}
* link horde_gpo::HGPO_ID to horde_prefs::HGPO to get a list of prefs belonging to a given HGPO.
----
++ Cache
At login, all applicable GPO's should be loaded and cached. We should also try to do something to cache GPO's for guest sessions.
----
++ Other Thoughts
* all $pref->getValue() calls could be handled on the backend by a HGPO manager, giving us a drop-in replacement.
* we'd need a way to clearly define what happens if two HGPO's have overlapping, conflicting settings.
* there should be a default "root" policy, which cannot be detached from the root installation. This policy would be a site-wide policy that always exists.
----
++ Links
http://www.microsoft.com/technet/itsolutions/msit/security/grppolobjectmgmt.mspx - gives a good overview on how MS GPO's work, and a nice graphic that really helped me visualize the internal workings.
----
++ Cut & Paste from mailing list until I can better organize my thoughts
> - with something like this in place I think it would make more and
> more sense to move everything that's at all user-related in conf.php
> files to this system. Things like "user capabilities" in both Horde
> and IMP - they can even be locked (overridable =3D false?) by default,
> but letting people easily manage them on a per-group basis, or
> whatever, sounds very good to me.
Just brainstorming here, but we could even go a step further and use =20
this type of system for all of the configs (except for maybe the very =20
basic stuff, like authentication). Doing so would let different =20
groups have different configs, which might be helpful for sites =20
hosting for various groups.
> If there were a way to manage, say, IMAP server configs, or other
> backend configurations (sieve servers, etc.) using this system, that
> would be even better.
Yes! We could put IMAP server configs, etc. in a GPO and assign to =20
targets as necessary. Same way that printers can be assigned in an =20
active directory. "group A uses this IMAP server, group B uses this =20
other IMAP server, group C gets to specify their own IMAP server." The =20
possibilities are endless! I love it!