Salt: win_snmp module bypasses group policy settings

[doesitblend]

Description of Issue/Question

When retrieving values from the SNMP configuration win_snmp always retrieves values from the registry which is not correct. Windows allows configuring the daemon through the service agent and through group policy, in my case local group policy.

The problem comes when you configure the agent as above and then query the settings with salt '<target minion>' win_snmp.get_community_names. Even though the agent settings have been overwritten by the group policy Salt still returns the original configured community name pulling it directly from a registry setting.

Setup

1. Enable the SNMP service in Windows Server manager Instructions here
2. Follow above instructions to configure a community string
3. Configure a new community string through group policy
4. Check the agent settings through the windows service manager
   
   
   
   • These should now read the new community string set through group policy
   
   
   • May require a gpupdate /force from powershell to update immediately
   
   
5. Query the community name with the command provided above
   
   
   
   • This will return the originally configured community string set manually through the agent configuration
   
   

Versions Report

    Salt Version:
               Salt: 2017.7.2

    Dependency Versions:
               cffi: 1.10.0
           cherrypy: 10.2.1
           dateutil: 2.6.0
          docker-py: Not Installed
              gitdb: 2.0.3
          gitpython: 2.1.3
              ioflo: Not Installed
             Jinja2: 2.9.6
            libgit2: Not Installed
            libnacl: Not Installed
           M2Crypto: Not Installed
               Mako: 1.0.6
       msgpack-pure: Not Installed
     msgpack-python: 0.4.8
       mysql-python: Not Installed
          pycparser: 2.17
           pycrypto: 2.6.1
       pycryptodome: Not Installed
             pygit2: Not Installed
             Python: 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 64 bit (AMD64)]
       python-gnupg: 0.4.0
             PyYAML: 3.11
              PyZMQ: 16.0.2
               RAET: Not Installed
              smmap: 2.0.3
            timelib: 0.2.4
            Tornado: 4.5.1
                ZMQ: 4.1.6

    System Versions:
               dist:   
             locale: cp1252
            machine: AMD64
            release: 2012ServerR2
             system: Windows
            version: 2012ServerR2 6.3.9600  Multiprocessor Free

[doesitblend]

ZD-2392

[rallytime]

@saltstack/team-windows can one of you take a look at this one?

[lorengordon]

Looks like the module is looking up the values from:

HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities

Group policy _usually_ still writes the values in the registry, somewhere. I suppose it may be a different key/value than when set using the SNMP Service, though that would be rather unusual...

I don't personally use SNMP in any manner whatsoever. @doesitblend can you look around the registry in your system to see if you can find the key/value for an SNMP community string written via group policy?

[lomeroe]

group policy writes to HKLM\SOFTWARE\Policies\SNMP

[lorengordon]

I wonder what happens if we just change _SNMP_KEY to r'SOFTWARE\Policies\SNMP\Parameters?

[lomeroe]

I assume the service looks at a merge of both locations -- with the policy location winning over anything defined in the services location

[twangboy]

I would recommend either setting SNMP using Group Policy or set it with Salt. Not both.

[lorengordon]

@twangboy I think it would be valuable for salt to at least be able to read the SNMP community string, even if it is set by Group Policy. Then salt can be used to interact with SNMP applications from that box, since it will be using the correct community.

[twangboy]

Yeah, I was thinking appending something like (group policy) to the end of the ones that are set in the other reg key

[lorengordon]

Appending, as in string manipulation? That sounds pretty awful to me, as the user or any intervening module/script would need to know to strip that out to use the return value.

We know that if set via Group Policy, that overrides. So why not check both keys, and do the same thing, at least when reading values?

Another approach would be to use a new argument that controls the lookup key, so a user can specify to use the group policy path explicitly, .e.g. lookup=(policies|services).

[twangboy]

@lorengordon What if we returned these settings are being managed by Group Policy if it finds the GroupPolicy registry keys?

[lorengordon]

That's probably reasonable for set operations. There's the question of the return code then, though... to err or not to err...

I still think it would be handy for get operations for salt to return the Group Policy values if present, so any SNMP-aware apps can be integrated through salt.

[twangboy]

Here's the proposed fix we're looking at:

• snmp.get will return the SNMP settings as they are in effect on the system. If they are configured via group policy then those will be returned, otherwise, the standard SNMP settings will be returned;
• snmp.set will only set the non-GPO settings. If GPO settings are already applied, it will return a CommandExecutionError;
• Docs will be updated to explain how the functions work when group policy has conflicting settings;

[rallytime]

@doesitblend Can you take a look at the fix above?