If you can use snmpget then you can use
snmpget -v3 -l authPriv -u USERID - a SHA -A "<SHA_PASSWORD>" -x AES -X "<AES_PASSWORD>" <hostname> snmpEngineID.0
We had a CSV file of the hostname,sha_password,aes_password and used this to get the EngineID from the 200+ devices in the original list and then do incremental runs when either new devices or old device are updated (use a OS patch can change the EngineID, what fun). But then we had to individual create the snmptd entries for the actual trap decoding, and then generate trap to see that we got it correct, which also required something like wireshark or local firewall to see the UDP packets arriving as we cound not get snmptd to log invalid traps for v3 (again even more fun).
This is not a project for the faint of heart or done quickly.
Finally our devices were "internal" I dont know how you might deal with a "external" cloud service. Good luck
Regards, Andrew
Note: we ended up using a Linux based workstation for the "discovery" as the SNMP command-line options were more extensive than Windows
------------------------------
Knows a little about UIM/DXim, AE, Automic
------------------------------
Original Message:
Sent: Mar 14, 2024 10:39 AM
From: Sam Green
Subject: Engine id for SNMPV3 Trap alert configure in UIM 9.02 using snmptd prob
Reviving an old thread here. But looking to receive v3 traps from Meraki Cloud.
Does anyone have any ideas on how to get the EngineID?
Original Message:
Sent: Feb 05, 2021 06:47 AM
From: Andrew Cooper
Subject: Engine id for SNMPV3 Trap alert configure in UIM 9.02 using snmptd prob
The snmptd probe is very "old" and only just supports v3. So you have to provide the engineID manually at profile generation time.
What this means is that you need to do the "discover" yourself for each device, however the engineID is exposed in the standard MIB (as defined in the RFC) so something like
snmpget -v3 -l authPriv -u USERID - a SHA -A "<SHA_PASSWORD>" -x AES -X "<AES_PASSWORD>" <hostname> snmpEngineID.0
will return the engineID used by the device, often it is related to MAC and the device/appliance creates it when snmp v3 is enabled. The effect of this is that as you cannot define (or manually set) the Engine ID each device will be different and so you need a different user definition for each device.
Regards, Andrew
------------------------------
Knows a little about UIM/DXim, AE, Automic
Original Message:
Sent: 02-05-2021 06:08 AM
From: Glenn Weavind
Subject: Engine id for SNMPV3 Trap alert configure in UIM 9.02 using snmptd prob
I'm not convinced. The KB refers to RFC5343 which describes a mechanism for the trap receiver to *discover* a sender's EngineID, as it's clearly unrealistic for any management tool to know, in advance, the EngineID of every possible trap sender.
The current probe does not permit EngineID to be blank (unlike in Spectrum): does the current probe support the referenced EngineID discovery process, please?
If not, then it doesn't make a lot of sense to hide behind the SNMP V3 spec (we *have* to know the sender's EngineID) and then not support the mechanism designed to overcome the obvious limitation of this requirement.
If the probe *does* support this RFC mechanism, how do we use it please?
Original Message:
Sent: 09-21-2020 03:35 AM
From: Luc Christiaens
Subject: Engine id for SNMPV3 Trap alert configure in UIM 9.02 using snmptd prob
https://community.broadcom.com/communities/community-home/digestviewer/viewthread?MID=779883-------------------------------------------
https://knowledge.broadcom.com/external/article/12307
https://knowledge.broadcom.com/external/article/121594/uim-snmpv3-traps-not-processed-by-snmptd.html