[Freeipa-devel] What about desktop policies?

Tue Feb 26 20:11:24 UTC 2013

On 02/25/2013 02:15 PM, Loris Santamaria wrote:
> Hi all, 
>
> some customers of ours are interested in managing desktop policies for
> their linux workstations, really nothing fancy, corporate background and
> proxy settings are the most common requests.
>
> In the past I created Gnome desktop profiles using Sabayon, distributed
> them using puppet and associated them to user accounts with a Sabayon
> specific LDAP attribute, a process a bit convoluted, and no longer
> possible since sabayon is no longer developed. Also it was really buggy,
> and very gnome specific.
>
> I was thinking in how integrate desktop policies in freeIPA in a general
> manner and I wanted to share my ideas with you. Hopefully some of this
> may be incorporated in IPA at some point in the future.
>
> Properties of a "policy":
>
>       * is a collection of "settings"
>       * can be associated with users or groups (desktop policy) or with
>         hosts or hostgroups (system policy)
>       * is associated with a "consumer", the client software that
>         interprets and applies the policy. This way one could define
>         policies for dconf, policies for kde, policies for WBEM.
>
> Properties of a "setting"
>       * is a key-value pair
>       * must conform to a "schema"
>       * may be mandatory
>
> The schema:
>       * indicates which attributes a policy may consist of
>       * indicates which kind of value may take an attribute. Bool,
>         string, etc.
>       * There may be more than one schema for a given "consumer". For
>         example for dconf you may have an evolution schema, a
>         gnome-games schema, etc.
>  
> Sample policy creation process:
>      1. The admin creates a new schema in IPA, with a command like "ipa
>         schema-add --consumer=dconf gnomeSettingsSchema"
>      2. The admin adds some definition to the schema: "ipa
>         schema-add-setting gnomeSettingsSchema
>         --name=/schemas/desktop/gnome/background/picture_filename
>         --type=string --description='File to use for the background
>         image.'"
>      3. He creates a new policy: "ipa policy-add corporateBackground
>         --type=desktop --consumer=dconf
>      4. He adds a setting to the policy: "ipa policy-add-setting
>         corporateBackground
>         --name=/schemas/desktop/gnome/background/picture_filename
>         --value=file:///san/wp/wallpaper.jpg --mandatory". Ipa would
>         check that the key is defined in one of the dconf related
>         schemas and the value is acceptable for that key.
>      5. He associates the policy with users: "ipa-policy-add-user
>         corporateBackground --groups=ipausers"
>
> How should the policy be applied? On the workstation, on startup, an ipa
> related utility should check if there are any policies related to the
> workstation, if there are any it should call a helper capable of
> applying a specific type of policy. Then on user logon another ipa
> related utility should check if there are any policies associated with
> the user and call the appropriate helper, if available.
>
> For the policy created in the above example, on logon the ipa policy
> utility would find that there is a policy of type dconf associated with
> the user. It would check if there is a dconf policy helper installed and
> if positive it would call the helper passing it the parameters defined
> in the policy.
>
> Hope this is useful at least as a starting point in defining desktop
> policies in IPA.

This is great!
Thank you for sharing some ideas.
We sort of stayed away from centralized policy management for quite some
time.
Originally we thought that IPA will do policy management and did a lot
of design around it.
However at some point we realized that there is an overlap with the
system management and content management for which things like puppet
are more suitable. We said then that IdM would focus on managing
identity related policies that are traditionally served via LDAP.
The things that you are talking about resemble to some extent MSFT GPO
and we felt that IdM might not be the right place for it. May be it is
time to reassess it.
I would however not go that route at least yet.

If Desktop can read additional properties related to user (background,
default language, etc.) from SSSD over a DBUS interface the SSSD should
be able to pull this data from the IdM (eventually). On the IdM we
probably can make these additional attributes available in the user
entries using class of service like we do with password policies.

We have plans for SSSD to handle more attributes than posix and
integrate with Desktop.
https://fedorahosted.org/sssd/wiki/DesignDocs/AccountsService

IMO once this work is started we would be able to see how we can
configure and serve more data from IPA for clients to consume.

Meanwhile I suggest you create a ticket in IPA trac and put your ideas
there.  

>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130226/7eede985/attachment.htm>