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

• app

| + prefgroup

| | + pref

| | + pref

| + prefgroup

| + pref

• app
  • prefgroup
    • pref

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

---

++ Storage

In order to make Horde Policies as generic as possible, it's probably best to specify a new backend for them. Then we can write policy drivers for the various parts of Horde that might use them, such as Prefs.

I'm a big fan of the Datatree structure, slightly simplified, to hold the Policy information. The DataTree itself has proved not to scale very well, but I think by removing a few unneeded fields (for this application, at least), we can reduce the number of JOIN statements, and it should scale just fine. Another thing to think about is how many Horde Policies is a given site going to have? Probably no more than a handful on average.

Anyway, here's a new table structure idea:

horde_policy

---

policy_id

policy_name

policy_updated

horde_policy_attributes

---

policy_id

attribute_name

attribute_scope

attribute_overrideable

attribute_value

horde_policy_targets

---

policy_id

target_id

target_type <-- maybe

---

++ 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!