> -----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

Reply via email to