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


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