Change SNMP Community Strings Using Group Policy

[Rob Lowe]

I'd like to use Group Policy to perform the following tasks:

1. Delete all existing SNMP community strings on a Windows Server 2003/2008
server.

2. Define new SNMP community strings that can be set to Read Only, Read
Write and Read Create (Read Write and Read Create are required by our
management software).

3. Prevent or overwrite any manually defined SNMP community string on a
system subject to this policy.

From my research, Group Policy Objects can be used to define SNMP community
strings but can only be configured for Read Only access. This doesn't help
me as the policy must allow Read Write and Read Create strings to be
assigned. The policy also reverts back to the originally defined settings
once the policy no longer applies.

Group Policy Preferences may be a better choice, but I can't figure out a
way to delete all of the existing community strings.

If I delete the ValidCommunities key and recreate it using GPP's, the new
key is created with inherited permissions. This presents a problem in that
best practice (and default permissions when the key is created) is for
Administrators only to have full control.

So unless there is a way to delete existing registry values using GPP's, I'm
stuck.

Any suggestions would be appreciated.

[Florian Frommherz [MVP]]

Howdie!

Rob Lowe schrieb:

> If I delete the ValidCommunities key and recreate it using GPP's, the new
> key is created with inherited permissions. This presents a problem in that
> best practice (and default permissions when the key is created) is for
> Administrators only to have full control.
>
> So unless there is a way to delete existing registry values using GPP's, I'm
> stuck.

What about setting the new key with GP Preferences and putting new
security settings on the key with Registry Group Policy settings?

Cheers,
Florian
--
Microsoft MVP - Group Policy
eMail: prename [at] frickelsoft [dot] net.
blog: http://www.frickelsoft.net/blog.
Maillist (german): http://frickelsoft.net/cms/index.php?page=mailingliste

[Rob Lowe]

Thank you for your response.

I've tried to define the permissions for the key in the GPO, and the
permissions change does apply. Thanks for the tip.

The SNMP community strings can be defined in GPO, but they are configured as
Read Only. I must have Read Write and Read Create strings, and would like
them to be retained on the machine if the machine is no longer applies the
GPO.

But it looks like GPP's are processed after the GPO settings, if they are
defined in the same policy. So once the GPP Replace recreates the key, the
permissions change to inherited again.

I suppose I could split this into two policies, where the GPP is applied
first and then the permissions are set on a higher precedence GPO. But
that's going to present a management headache because the order of precedence
would always have to be retained to prevent registry permissions from being
compromised.

Any other thoughts?

-Rob

[Florian Frommherz [MVP]]

Rob,

Rob Lowe wrote:
> I've tried to define the permissions for the key in the GPO, and the
> permissions change does apply. Thanks for the tip.
>
> The SNMP community strings can be defined in GPO, but they are configured as
> Read Only. I must have Read Write and Read Create strings, and would like
> them to be retained on the machine if the machine is no longer applies the
> GPO.
>
> But it looks like GPP's are processed after the GPO settings, if they are
> defined in the same policy. So once the GPP Replace recreates the key, the
> permissions change to inherited again.

This isn't generally so. The settings are processed in the order based
on the Client Side Extension processing them. ADM templates are always
processed first, followed by the CSE orders by their GUID like in this
list:
http://www.gruppenrichtlinien.de/index.html?/Grundlagen/Client_Side_Extensions.htm.

Apparently, the security settings CSE (which is responsible for applying
registry security settings) is run before GPP Registry. That would mean
that GPP Registry resets any settings prior GPOs or GPPs have set.

> I suppose I could split this into two policies, where the GPP is applied
> first and then the permissions are set on a higher precedence GPO. But
> that's going to present a management headache because the order of precedence
> would always have to be retained to prevent registry permissions from being
> compromised.

Not sure how you can get out that dilemma. Putting the two settings into
different GPOs wouldn't help either...

Cheers,
Florian

[Rob Lowe]

Florian -

Thank you for your response. The link you posted doesn't translate to
English through Bing or Google, so if you can post a link to an English
language version I'll check it out.

I would only want to replace the key if the values defined in it are not set
to the current standard. So if a value is added or changed, replacing the
key will wipe all currently defined values and the values will be repopulated
using the standard values defined in the same preference setting.

I'm looking into using the Registry Match or WMI functions within Item Level
Targeting to make the key replacement conditional on the defined values.

If the values have been added or changed, the key replacement will re-create
the key with inherited values and should remain that way until the policy is
refreshed. If only the standard values exist, the key will not be replaced
and the policy that re-ACL's the registry key should back out inheritance.

Anyone see any flaws in my logic?