| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1076.1 | Controlling Write Access | NACAD::SLAWRENCE | | Mon Jun 13 1994 13:53 | 8 |
| Have them set up two hubwatch_agents files; one that uses the default
'read-only' SNMP community for the hubs ('public') and one that uses a
read-write community that they have set on the hub setup port (make
sure you 'reset' [menu choice 2] after changing the community).
They can then control access to the hubs by controlling access to the
agents file that has the read-write community.
|
| 1076.2 | More sophisticated access controll | DPDMAI::DAVIES | Mark, SCA Area Network Consultant | Mon Jun 20 1994 12:56 | 24 |
| Very good. This will give them a select group who can issue SETS to
their hubs. But they also want to know WHICH member of this select
group of priviledged users actually issued the command which made a
specific change on one of the hubs (to associate which a specific event
on the network).
This is similiar to the type of request we are getting from our
customers on the Polycenter Netview product. You either have full
priviledges (root) or you don't.
All of these folks are now looking for a finer granularity of access to
their network management tools. Remember the statement "the network is
the system"? Well it is upon us today. Maybe we should enhance the
sophistication of our management product's security features to match
today's networks.
What are your feelings on this?
Thanks,
Mark
|
| 1076.3 | Log of sets. | NACAD::GALLAGHER | | Mon Jun 20 1994 13:41 | 28 |
| Some thoughts.....
Capturing the last N number of sets could be done by HubWatch or by
the SNMP Agent(s) in the hub. A HubWatch implementation could capture
more data since they can write set information to a disk. The Agent
implementation has the advantage that all SNMP setRequests can be logged -
those initiated by multiple HubWatch sessions, and those from other SNMP
agents. A disadvantage of an Agent implementation is that the set capture
log must be volatile. That is, it can capture sets while the device is
operational but will erase the log when the agent is reset or powered
down. Sets to reset the agent will not be logged. (This is because we
probably don't have room for the set capture log in the Agent's
non-volatile memory.)
An agent implementation would capture:
- the community from which the set was issued,
- the IP address of the station issuing the set,
- a time stamp of when the set was received (based on the
agent's sysUpTime), and maybe
- the first object in the set request.
A HubWatch implementation could capture the entire setRequest packet
and display it in a "user friendly" manner.
Any other thoughts on this? Does this solve the problem? Which solution
is preferred? How important is this?
-Shawn
|
| 1076.4 | | NACAD::SLAWRENCE | | Mon Jun 20 1994 19:04 | 11 |
|
The granularity issue has arisen here in some of our planning sessions
for our own network. One solution I'm thinking of using is this:
Assign the read/write community ownership for the Hub to the Network
group - through it they can make changes to any hub-managable module.
Whenever there is a group who need to be able to manage a subset of the
modules in a hub, assign those modules IP addresses of thier own and
set the read/write community in the module to something for that group.
This does not affect the management through the hubs' address.
|