Archived from groups: microsoft.public.win2000.group_policy,microsoft.public.win32.programmer.3rdparty,microsoft.public.vb.winapi (
More info?)
> > Generally if an app wasn't designed with policies in mind, the settings
> > you would be talking about are configuration options. In other words,
> > even if the app read them from the policy hive, the app will probably
> > allow the user to simply change the values.
>
> But I am proposing hooking the registry *reading* API's, not the API's
that
> write to the registry. The user could enter whatever settings they want
and
> they would be written to the usual location in the registry, but if the
> administrator had applied a group policy in the 'Policies' location, these
> would take precedence over the user settings (which is how it should be
> IMHO) It may cause a bit of user confusion as their settings would never
> 'take' but that would be a small price to pay in order to stop users
> breaking things.
I understood your take on it, but I don't think that it will work out this
way in a lot of apps. Apps don't all read their settings each time they use
them. It's typical to read them once, and write them when they are changed.
However when a setting is changed, it is not necessary to re-read it (since
the app already has the change). Therefore in many apps, and possibly with
different behaviors even in a single app, the "restriction" won't take until
after the user closes the app, and then reopens it. And of course the user
can always change the setting each time they open the app - so it becomes
more of an annoyance than a restriction. Apps that are designed with policy
in mind are supposed to listen for a policy message, and reload policy
following a change event. This would not happen with the system you
describe. My guess is that the end result would be people changing settings
and leaving the app open, and possibly logging off less, in order to avoid
the annoyance.
In the cases where applications read their settings from the registry each
time prior to their use, this would probably work. But there is no reason
to assume this will be the case. Before taking the time to write this
fairly complicated code, I would test out this theory using regmon on the
desired apps and settings.
> > Apps designed to support
> > restrictive policies must not only read the settings from the registry,
> > but prevent the user from changing them.
>
> In the case decribed above, the user could change them all they want but
> the settings would never be read by the application if an over-riding
group
> policy existed in the "policies" subkey.
>
> > This is a design decision
> > within the app, and cannot generally be altered by altering the location
> > from which the setting is retrieved.
> >
> > Your suggestion would allow you to use blue dot ADM settings to control
> > non-policy key registry settings (not including binary and some other
> > types). However, it doesn't seem to be worth the effort - you're better
> > off with the red dot settings, as the result in the app is the same
> > either way.
>
> Not really
> I have seen situations where we want some users to have full access to
> application configurations, while other users need to be locked down. This
> would give us the option of using GP permissions to assign settings to
some
> users, while allowing other users full access to set their own
> configurations.
> I understand that this could be done using red-dot settings, but writing
> the settings to a volatile section of the registry seems a more elegant
> solution. Especially when you are talking about HKLM settings that are
> applied to all users of that machine. In this case, a volatile setting is
> much more desirable.
It's an interesting idea, but my feeling, having worked related issues
closely for a long time, is that even if implemented well, the results would
be inconsistent across apps and settings due to the freedom that
applications have as to how/when they read and retain their settings.
Another thing you might consider is denying write access to the keys into
which the settings are written, especially with HKLM settings. This can be
done with Group Policy as well, and it's more effective since the app cannot
make a change to the setting, and well-written apps should then deny the
change attempt internally as well. The settings can still be written using
ADM Templates or Policy Maker, and when using PM you can also eliminate the
tattooing affect.
> The tattooing of the registry would become irrelevant as the keys that are
> identified would be read from the 'policies' subkey. If this section did
> not exist it would be read from the tattooed registry entries.
>
> > The "tattooing" is an artifact of the Microsoft registry
> > client-side extension (CSE). The Policy Maker registry extension is not
> > tied to the policy sections of the registry in this way, and allows you
> > to create custom settings by simply typing in the values into the GUI,
> > or using a registry browser.
> >
>
> > More importantly, you can specify one of three modes for policy
> > application:
> >
> > (1) remove the setting when it is no longer applied [this is like a blue
> > dot]
> > (2) do not remove the setting [like a red dot]
> > (3) set the setting one time only [a true preference]
> >
> > And you can apply graphical per-item filtering using 25 categories of
> > filters.
> >
> > The Policy Maker registry extension is part of the Policy Maker
> > Professional product, which we sell, however in the next minor update -
> > due out soon, the registry extension will be absolutely free of change.
> >
> > Regards,
> >
> > Eric Voskuil
> > Policy Maker
> >
http://www.autoprof.com/policy
> >
>
>
> Thanks Eric. I'll take a look at it now.
>
> Andy.
Great, let me know what you think.
Regards,
Eric
Facebook
Twitter
Instagram