RE: access control

"Masoud Fatollahy" <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <[email protected]>
Hi,
The new configuration works with the default context. now we have problem 
with the context.

we have register our mibs with new context and  want  to read them by 
setting username and password  HMAC +  context on a mib-browser. the 
following configuration is used.

we created the users:
createUser myuser
createUser myuser1 MD5 "my_password1"
createUser myuser2 MD5 "private_pass"

and the following config file:
####
# First, map the community name (COMMUNITY) into a security name
# (mynetwork, depending on where the request is coming
# from):

#          sec.name    source            community
com2sec local         127.0.0.1           secret42
com2sec cust1_sec 192.168.55.0/24  public
com2sec cust2_sec 192.168.56.0/24  public

####
# Second, map the security names into group names:

#               sec.model  sec.name
group MyRWGroup v1         local
group MyRWGroup v2c        local

group cust1_grp v1         cust1_sec
group cust1_grp v2c        cust1_sec
group cust2_grp v1         cust2_sec
group cust2_grp v2c        cust2_sec

group v3_user_grp            usm    myuser       # SNMPv3 username == 
sec.name#
group v3_user_grp_auth    usm    myuser1      # SNMPv3 username == sec.name#
group v3_user_grp_private usm    myuser2      # SNMPv3 username == sec.name#
# Third, create a view for us to let the groups have rights to:

#           incl/excl subtree                               mask
#---------------------------------------------------------------
view all    included  .1

view cust1_v excluded  .1
view cust1_v included  .1.3.6.1.2.1.1.3.0
view cust1_v included  .1.3.6.1.2.1.2.2.1.1.1 ff.a0

view cust2_v excluded  .1
view cust2_v included  .1.3.6.1.2.1.1.3.0
view cust2_v included  .1.3.6.1.2.1.2.2.1.1.2 ff.a0

view mini_view excluded .1   80
view mini_view included  1.3.6.1.2.1.1.3.0

view if_view excluded   .1     80
view if_view included  .1.3.6.1.2.1.1.3.0
view if_view included  .1.3.6.1.2.1.2.2

####
# Finally, grant the groups access to their views:

#                context sec.model sec.level   match    read     write  
notif
#------------------------------------------------------------------------
access MyRWGroup ""      any       noauth    exact  all      all    none
access cust1_grp ""         any       noauth    exact  cust1_v  none   none
access cust2_grp ""         any       noauth    exact  cust2_v  none   none

#---------------------------------------------------------------------------------------
#                         context     sec.model sec.level   match  read     
write  notif
#---------------------------------------------------------------------------------------
access v3_user_grp            ""            usm      noauth    exact  
mini_view none  none
access v3_user_grp_auth    ""            usm      auth      exact  if_view   
none  none
access v3_user_grp_private "my_context"  usm      auth      exact   all      
none  none

Do i missing something?

Thanks,

/Masoud

-----Original Message-----

From: "Masoud Fatollahy" <[email protected]>

To: "'Dave Shield'" <[email protected]>

Cc: [email protected], [email protected]

Date: Wed, 20 Feb 2008 13:32:54 +0100

Subject: RE: access control




Thanks,



Will try this and comeback with the results.



Regards,

/Masoud



-----Original Message-----

From: [email protected]

[mailto:[email protected]] On Behalf Of Dave

Shield

Sent: den 20 februari 2008 11:17

To: [email protected]

Cc: [email protected]; [email protected]

Subject: Re: access control



On 20/02/2008, Masoud Fatollahy <[email protected]> wrote:

> We want to have support for both view-based and user-based implementation.



That's normal - these are complementary mechanisms.



The User-based Security Model is concerned with defining "who"

  is using the system.   (usernames, passwords, privacy, etc).

The View-based Access Control Model is concerned with "what"

  they are doing.   (read-only, or updates, and of what information).



You need both bits to work properly.





> Can we put the configurations for both of them in the same config file?



You can, but it's not advisable.

The general approach is to put (almost) all of your agent configuration

into the normal ("read-only")  snmpd.conf.    This would typically be

located in either /usr/local/etc/snmpd.conf or /etc/snmpd.conf

(depending on how the package was compiled).



In fact, there will be a list of locations where the agent will look

for configuration settings.   If you run the agent using



     snmpd -f -Le -Dread_config



then it will display the search list as one of the first debug statements.

Put your snmpd.conf file in any of these locations.

   Oh, except /var/net-snmp - this is where the agent maintains its

own internal settings.  The *only* directives you should put there

are "createUser" lines.





> Is it snmp itself which create the other read only config file



No - you create the read-only config file.



>   If we should create it; then where should we placed the file



See above   (anywhere on the -Dread_config search list).



> and what name should we use

> for this file? Can both of them have same name? (snmpd.conf).



Both of them *should* have be called "snmpd.conf", yes.







> If we have following configuration in a file called snmpd.conf for our

> view-based case and use the flag -c to use it as our configuration file

and

> use flag -C to not use the default configuration, should it work the?

>

>

> com2sec local     localhost       secret42



That line doesn't seem to be active.

You never mention the internal user "local" anywhere else.







> com2sec custom_sec 192.168.1.0/24  public

>

> group custom_grp v1         custom_sec

> group custom_grp v2c        custom_sec



> view custom_v excluded  .1

> view custom_v included  sysUpTime.0

> view custom_v included  interfaces.ifTable



> access custom_grp ""     any       noauth    exact  custom_v  none   none





That block should give access to the ifTable (plus sysUpTime.0)

when using the community string "public"





> group incremental usm       myuser      # SNMPv3 username == sec.name



> access incremental ""    usm       noauth    exact  mini_view none  none

> access incremental ""    usm       auth      exact  if_view   none  none



> view mini_view excluded .1 80

> view mini_view included  sysUpTime.0

>

> view if_view excluded .1 80

> view if_view included  sysUpTime.0

> view if_view included  ifTable





That block (with a suitable "createUser myuser" line in the persistent

snmpd.conf file), should give read-access to the sysUpTime.0 value

for both "noAuth" and "authNoPriv" requests.





> access incremental ""    usm       priv      exact  all_view  none  none



This line won't do anything, because you haven't defined the view

"all_view".   Perhaps you meant



> view all    included  .1

access incremental ""    usm       priv      exact  all  none  none





> access MyRWGroup ""      any       noauth    exact  all      all    none



That won't do anything either, because you haven't defined anything

in the group MyRWGroup.







> And how should it looks like when we want to add support for user-based

> case:



You've already got a user-based entry in the snippet above.

(The "incremental" group).





(should we just add following lines?

>

>  rocommunity COMMUNITY SOURCE -V VIEW

>  rwcommunity COMMUNITY SOURCE -V VIEW

>  rocommunity6 COMMUNITY SOURCE -V VIEW

>  rwcommunity6 COMMUNITY SOURCE -V VIEW



Those are nothing to do with user-based requests (i.e SNMPv3).

This is an alternative form of configuring SNMPv1/2c access





>  rouser USER noauth|auth|priv -V NAME

>  rwuser USER noauth|auth|priv -V NAME



These *are* concerned with SNMPv3 requests.

Again, this is an alternative to the group/view/access directives above.



  I suggest that you use one *or* the other, rather than trying to mix

the two.   At least until you get more familiar with how all this works.





It would also be worth having a look at the FAQ entries

    How do I configure access control?

        http://www.net-snmp.org/wiki/index.php/FAQ:Agent_23 
[http://www.net-snmp.org/wiki/index.php/FAQ:Agent_23]

and

    I don't understand the new access control stuff - what does it mean?

        http://www.net-snmp.org/wiki/index.php/FAQ:Agent_24 
[http://www.net-snmp.org/wiki/index.php/FAQ:Agent_24]





Dave



-------------------------------------------------------------------------

This SF.net email is sponsored by: Microsoft

Defy all challenges. Microsoft(R) Visual Studio 2008.

http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ 
[http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/]

_______________________________________________

Net-snmp-users mailing list

[email protected]

Please see the following page to unsubscribe or change other options:

https://lists.sourceforge.net/lists/listinfo/net-snmp-users 
[https://lists.sourceforge.net/lists/listinfo/net-snmp-users]









-------------------------------------------------------------------------

This SF.net email is sponsored by: Microsoft

Defy all challenges. Microsoft(R) Visual Studio 2008.

http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ 
[http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/]

_______________________________________________

Net-snmp-users mailing list

[email protected]

Please see the following page to unsubscribe or change other options:

https://lists.sourceforge.net/lists/listinfo/net-snmp-users 
[https://lists.sourceforge.net/lists/listinfo/net-snmp-users]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.