|
|
10.1 Overview
10.2 Authentication Support in the Agent
10.3 Community Details for Authentication
10.4 Adding Communities for Managers
10.5 If Authentication Fails
10.6 Implementing Your Own Authentication
10.7 Running the Example
An SNMP Agent exposes critical information about the device or application being managed through its management interface. To ensure some security to the system, a check has to be kept on the people trying to access such information and capable of performing operations on it. This Authentication mechanism aids us in restricting the user and the kind of information he can avail, thus ensuring security from trespassers who are denied admission.
The WebNMS Java Agent supports Community-based Authentication for SNMPv1 and SNMPv2c requests. On receiving a SNMPv1 or SNMPv2c request from the Manager, the Agent will check for Authentication with the received Community string and the received SNMP Request type (GET, GET-NEXT, SET etc.). Later processes the request.
Apart from Authenticating v1/v2c requests, Java Agent also supports View-based access. This facility is provided only when vacl is enabled. Please refer to Enabling Authorization using VACM for more details.
10.2 Authentication Support in the Agent
By default v1/v2c Agents have support for Authentication. The code generated in the Main file implementing Authentication Support is given below : -
|
The Variables Declared for ACL Table support are : // Acl Table Support private com.adventnet.snmp.snmp2.agent.AclTable aclTable = null; private com.adventnet.snmp.snmp2.agent.AclTableRequestHandler acl = null; The code for aclTable instantiation under the initSnmpExtensionNodes are : aclTable = new com.adventnet.snmp.snmp2.agent.AclTable((SnmpAgent)this, "AccessControlTable.xml", "xml"); |
10.3 Community Details for Authentication
An Agent authenticates a request based on the Community. Hence it is required to store the community details and the details of the Manager given access for that particular Community in the Agent side. To store these details you can make use of the aclTable present under AGENT-SNMP-CONFIG-MIB -> agentConfiguration group -> v1v2AthenticationTables. This aclTable (.1.3.6.1.4.1.2162.10.3.1.2.1) maintains the set of authentication parameters given below:
aclCommunity& - the Community used by the Manager to communicate with the Agent.
aclAccess - the maximum access for the Community being either of these : No Access (0), Read_Only (1), Write_Only (2), Read_Write(3)
aclManager - IP address of the Managers who are allowed specified access for the specified community. The default value is '0:0:0:0' which states access is provided to all Managers for the corresponding community.
aclStatus - the Row Status column.
10.4 Configuring Managers to a Community
You can also include new communities and specify the Managers to be given access for the community. There are two ways to add communities to the Managers in the Authentication Table. It can be done either : (1) Before Agent start-up or (2) During Run time.
10.4.1 Before Agent Start-Up
Entries can be added to the Authentication Table before Agent start-up either using MIB compiler UI or using Text/XML file or using API Calls. To specify the entries before Agent start-up,
Using MIB Compiler UI
Create a Project and load a MIB.
Choose Project ->Settings menu from the menu bar of MIB Compiler UI.
Select aclTable in the v1v2Authentication Panel.
Now, Click Add.
A wizard pops up wherein you can specify the community for a Manager entry.
Click OK.
Text File / XML File / RAM (Runtime Memory)
The entries configured through MibCompiler UI get stored in the configuration file, AccessControlTable.xml or AccessControlTable.txt under <Agent Toolkit Home>/snmpprojects/projectname/agent/bin/conf directory, provided the storage type is chosen. For this purpose,
Choose Project -> Settings menu of MIB Compiler UI.
Select aclTable from the v1v2Authentication Panel.
Choose XML File or Text File from the Storage Type Option. By default XML File is chosen.
This file has to be edited for adding Manager Entries. The AccessControlTable.xml given below has been edited for adding a New Manager with Community "xxx" and IP Address as "1.192.68.200".
|
<?xml version="1.0" encoding="UTF-8"?> <Table> <row> <column name="aclCommunity" value="public" ></column> <column name="aclAccess" value="3" ></column> <column name="aclManager" value="0:0:0:0" ></column> <column name="aclStatus" value="1" ></column> </row>
<row> <column name="aclCommunity" value="xxx" ></column> <column name="aclAccess" value="3" ></column> <column name="aclManager" value="1.192.68.200" ></column> <column name="aclStatus" value="1" ></column> </row> </Table> |
Please note that the Agent has to be re-started for the changes to take effect. It is also possible to access the new entries without restarting the Agent. Make use of the following method in the Main file for the Agent to read the entries directly from the text file.
|
acl.setAutoRefresh(boolean flag, int autoRefreshTimeInt) |
This method has to be added after the code for aclTable Request Handler Instantiation.
Using RAM option (Run Time Memory)
Run time memory can be used to store the Manager information in the Agent Memory itself. Using this option will not store the entries in text files or in XML files. To use the run time memory for adding Manager entries dynamically,
Choose Project -> Settings menu from the menu bar of MIB Compiler UI.
Select aclTable in the V1V2Authentication Panel.
Select Runtime Memory from Storage Type combo box.
After choosing the storage option, follow the steps given in adding entries "From the Manager" given under the heading "Adding Entries During Runtime"(10.4.2) . Please note that once the Agent is killed, the entries added are removed from the memory.
Using API calls
If the RAM storage type option is selected for aclTable, then the code gets generated in the Main file as given below. Adding the example code highlighted would authenticate the request from the Manager IP Address "127.0.0.1" with community "xxx" and also provide READ_WRITE Access to the same.
|
aclTable = new com.adventnet.snmp.snmp2.agent.AclTable((SnmpAgent)this); aclTable.addAclEntry(com.adventnet.snmp.snmp2.agent.AclTableRequestHandler.createAclEntry ("public", 3, "0:0:0:0")); aclTable.addAclEntry(com.adventnet.snmp.snmp2.agent.AclTableRequestHandler.createAclEntry ("private", 1, "0:0:0:0")); aclTable.addAclEntry (com.adventnet.snmp.snmp2.agent.AclTableRequestHandler.createAclEntry ("xxx", 3, "127.0.0.1")); |
10.4.2 During Run Time
Communities can be added to the aclTable dynamically during run time ,
From the Manager
To add an entry to the aclTable from the Manager,
Load the AGENT-SNMP-CONFIG-MIB in MIB Browser.
Select aclTable from the v1v2AuthenticationTables module of agentConfiguration group.
By selecting the respective table and clicking SNMP Table icon in MIB Browser will open up a wizard wherein entries can be added to the aclTable.
The entries added from remote get updated in the text/XML file.
Please note that it is possible to access the table from remote only if "Remote Configuration" option is enabled in the aclTable in v1v2Authentication Panel of Project -> Settings menu in MIB Compiler UI.
You can also enable "Remote Configuration" using the following API call in case the UI option is not chosen before generation.
|
// For Acl Table Remote Configuration acl = new com.adventnet.snmp.snmp2.agent.AclTableRequestHandler((SnmpAgent)this, aclTable); acl.addRegistrationListener(hdlr); |
This method has to be included in the initSnmpExtensionNodes of the Main File.
You have seen how a Request is authenticated and how to add a community to the Agent. Let us see the consequences of a community not being authenticated.
If the received Community does not exist then the received message will be dropped and also an "AuthenticationFailure" Trap will be generated by the Agent and sent across to all the registered Managers provided the "snmpEnableAuthenTraps" flag of the SNMPv2 MIB snmpGroupCounters is set. By default the Failure Traps will be generated on a community not being authenticated.
You can also disable the facility of receiving Authentication Failure Traps. To do the same,
Load SNMPv2 MIB in the MIB Browser and
Change the value of snmpEnableAuthenTraps scalar variable in the snmp module to 2(false) from 1(true).
Now the Agent will not generate any Traps for this purpose.
In case the Community exists but does not match with the aclAccess and Request Type, then a noAccess Error or noSuchName error is thrown depending on the version of the Agent.
10.6 Implementing Your Own Authentication
You can also define your own Access Control Table instead of using the
default Access Control Table in
AGENT-SNMP-CONFIG-MIB. For this purpose:
Define a similar aclTable in your MIB using the OBJECT TYPE TABLE construct in MIB Editor. Please refer to "Adding a Table" in Creating a MIB section for using the construct.
The OID structure of the newly defined table should be same as the aclTable in AGENT-SNMP-CONFIG-MIB.txt after the enterprise level as .1.3.6.1.4.1.your enterpriseOID. .1.3.6.1.4.1.2345.10.3.1.2.1 is a sample entry oid.
Add the following piece of code above the code for restartSnmpAgent in the Main file.
|
setOidRep(int[] aclTableOidRep) OR setRegisteredOid(java.lang.String oid) |
Now, compile the code and query the Agent with your defined community.
Request will be authenticated by the Agent and response can be received.
To know more about Authentication, please go through the readme.html of the example available in <Agent Toolkit Home>/examples/snmp/aclandvacl directory.
|
|