SNMP Community String Permissions

2

I am looking at deploying SNMP Settings for windows servers via Group Policy and have an administrative template prepared. However I am noting strange behaviour when applying the policy.

Two Community strings are created, with different permissions. ie:

MYCOMMUNITY - READ ONLY
MYCOMMUNITY - READ CREATE

The Windows Registry also shows two values being created in

HKLM\Software\Policies\SNMP\Parameters\ValidCommunities

NAME         TYPE       DATA
1            REG_SZ     MYCOMMUNITY
MYCOMMUNITY  REG_DWORD  0x00000010 (16)

It is the latter of these two registry values that generates the READ CREATE community that I want, yet I seem to be unable to stop the first string entry from being generated.

My question is Whether READ CREATE Permissions will take precedence over READ ONLY permissions, or will there be "Random" behaviour with this configuration?

Thanks

windows
group-policy
snmp
windows-registry
asked on Server Fault Feb 10, 2010 by Ben Short

2 Answers

0

For SNMP v1, you want the communities to be different, ie

MYROCOMMUNITY - READ ONLY
MYRWCOMMUNITY - READ WRITE

Since there are no user names for SNMP v1, the community is what decides what the access level is. I don't know how Windows deals with this situation.

answered on Server Fault Feb 10, 2010 by David Mackintosh • edited Feb 10, 2010 by David Mackintosh
0

Have actually found a solution using Group Policy. Despite what I read yesterday, you can in fact delete registry values with an adm template. The policy code that solved this for me is as follows.

        POLICY "Delete Default SNMP Community"
            EXPLAIN "Deletes the first Community String from SNMP"
            KEYNAME "Software\Policies\SNMP\Parameters\ValidCommunities"
            VALUENAME "1"
            VALUEON DELETE
            VALUEOFF "MYCOMMUNITY"
        END POLICY

Slightly different to the question asked, I know. However this achieves the result I needed - which was a single community which I know has READ CREATE access.

answered on Server Fault Feb 10, 2010 by Ben Short

User contributions licensed under CC BY-SA 3.0