Highlighted
Super Contributor.. Super Contributor..
Super Contributor..
111 views

NA: SNMPv3 Authentication / Privacy Encryption method

I found some old topics from 2017 and 2014 about this topic, but couldn't find any new posts about this, and I am hoping I didn't miss something.

We are in progress to move from SNMPv2 to SNMPv3 and it seems a lot of different products have different setups. For example:

- Cisco Meraki: same password for auth and priv, uses fixed methods SHA  for auth, DES for priv

- Cisco IOS: different passwords for auth and priv, configurable encryption methods for auth and priv

- Avocent TerminalServers (at least the old ones): same password again, but fixed to MD5 / DES

 

So, obviously I can setup username / encription keys for all the devices in dedicated password rules, but I'm struggling to find the correct settings for the encryption methods used in SNMPv3.

I can only select "SNMP" under Admin->DeviceAccess, I assume this would mean v2 and / or v3?

And if I create a device-password rule with SNMPv3 settings, there is no way to setup the Auth- and Encryption methods used for this rule? Or is NA just trying all the possible encryption / privacy methods?

Labels (2)
0 Likes
4 Replies
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Hi,

You may be looking for something different, but one challenge I had when we set it up was getting NA to actually work...

We had to add the following line to adjustable_options.rcx:

<!-- enable SNMPv3 globally -->
<option name="ConnectionMethods/CustomDefault">SFTP:FTP:HTTPS:SCP:SNMP:commstr:authpriv_SHA_AES128:ssh </option>

Now, if I'm reading your notes correctly, you don't have one standard, so not sure that works.  If it does, great but wasn't what I had heard.  

So, we have different rules and within the rules there may be different ID / passwords, but the options are the same (that match the line we added).  

Hopefully this helps and let me know if you find a way to handle different options.  

-Chris

 

0 Likes
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Uh, that sounds interesting. We have kind of a default setup for almost all the devices, but as usual we have some exceptions to the rule, or to be more precise: limitation of devices in regards to SNMPv3. But with this option at least we could probably handle.. let's say 80% automatically.

Additionally this "CustomDefault" setting let's me hope there are more options there. I'll try to research this, thanks so much for this hint 

 

0 Likes
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

One other tip with NA and v3...

If you've used the tc_tools.sh script to get info from the rules or devices, the v3 info isn't captured.  So, make sure you have a "personal" backup of the v3 info.  

Good luck!

0 Likes
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Unfortunately I didn't find any solution, even with the help from the support.

There is a "-connectionmethods" option when you add a new password rule via NA-Proxy (add authentication) but it only allows me to set telnet, ssh or console.

With the general option explained by  @Chris_Powers  (adding <option name="ConnectionMethods/CustomDefault"> to the adjustable options) we can at least solve this for a big junk of devices (thanks again for this hint)

I added the Idea  Passwordrules to include connection-options (SNMPv3) to the Idea Exchange and hoping for votes.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.