> -----Original Message----- > From: Wes Hardaker [mailto:harda...@users.sourceforge.net] > Sent: Thursday, 22 September 2011 4:17 a.m. > To: Harvey Shepherd > Cc: net-snmp-coders@lists.sourceforge.net > Subject: Re: USM Users > > >>>>> On Thu, 15 Sep 2011 23:06:38 +0000, Harvey Shepherd > <harvey.sheph...@aviatnet.com> said: > > HS> Does anyone know if there is a similar exclusion within the SNMP > agent > HS> itself to prevent community based access to objects in snmpUsmMIB? > In > HS> other words, can new SNMPv3 users be defined via SNMPv1 or v2c > using > HS> the USM MIB? If this is prevented, could you please point me to the > HS> specific piece of code which prevents the access. > > The code to look at is in the agent/mibgroup/snmp3v/usmUser.c file. > > The problem is that there is a mib object in the usmUserTable that > requires that only the user from the row be allowed to modify that > particular object. IE, only "joe" can change "joe"'s password if using > the usmUserOwnAuthKeyChange object. This object won't work with v1/v2c > because there is no incoming user. > > Actually, other operations can succeed using v1/v2c but it's easier to > say "don't do that" (because it defeats the purpose anyway). > --
Thanks Wes. Yes I agree it does defeat the purpose and I fully intend to prevent access to that MIB via v1/v2c. I just wanted to know if it would natively do that anyway, but I'll setup VACM to prevent it now. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders