Access Table

The vacmAccessTable table stores each group's access rights. Each group can have multiple access rights. The most secure access right is chosen. The vacmAccessTable table is indexed by:

groupName

Returned from the lookup into the vacmSecurityToGroupTable table.

contextPrefix

The valid contextName matched within the vacmContextTable table.

securityModel

Specified in the message's msgSecurityModel parameter.

securityLevel

Specified in the message's msgFlags parameter.

Each of the rows in the vacmAccessTable table contains:

vacmGroupName

The group's name. This group has one or multiple access rights.

vacmAccessContextPrefix

The contextName must match the value of vacmAccessContextPrefix. See vacmAccessContextMatch.

vacmAccessSecurityModel

Indicates the security model that must be used to get access rights.

vacmAccessContextMatch

If vacmAccessContextMatch is set to exact, then the contextName must exactly match the value of the vacmAccessContextPrefix object.

If vacmAccessContextMatch is set to prefix, the contextName can match the first several characters of the vacmAccessContextPrefix object. This contextName is the name already matched within the vacmContextTable table.

vacmAccessSecurityLevel

Indicates the lowest security level necessary for having access to this access right. For information about security levels, see Where VACM Security Information Is Contained.

vacmAccessReadViewName

Authorized MIB viewName for read access. If vacmAccessReadViewName is empty, no active view exists for read access.

vacmAccessWriteViewName

Authorized MIB viewName for write access. If vacmAccessWriteViewName is empty, no active view exists for write access.

vacmAccessNotifyViewName

Authorized MIB viewName for notify access. If vacmAccessWriteViewName is empty, no active view exists for notify access.

If an access right is not found, access is denied. In this case, a return value of noAccessEntry is returned.

When an access right is selected, then the viewName indicated by that access right is selected. This viewName is determined by the PDU. If the SNMP operation in the PDU is a GETNEXT or GET operation, the vacmAccessReadViewName string is used. If the SNMP operation in the PDU is a TRAP operation, the vacmAccessNotifyViewName string is used. If the viewName is not configured, access is denied. In this case, a return value of noSuchView is returned.

If the access right is selected with a correctly configured viewName, access checking continues, as shown in Figure 4–2. Example 4–4 shows typical access table entries.

An additional example, Example 4–5, shows how to check that the users set up in this example and previous examples exist and are registered in VACM tables.

Example 4–4 Creating Typical Access Table Entries

You can create access table entries in two ways:

• You can create an access table entry by adding the entry to the main /etc/sma/snmp/snmpd.conf configuration file:

  access grpnam1 fileX usm priv exact all none none access grpnam1 "" usm auth exact all vwnam1 none

  If the group is created by adding to the main /etc/sma/snmp/snmpd.conf configuration file, then the entries that are created in the vacmAccessTable table are as follows:

  SNMP-VIEW-BASED-ACM-MIB::vacmAccessContextMatch. "grpnam1"."".3.authNoPriv = INTEGER: exact(1) SNMP-VIEW-BASED-ACM-MIB::vacmAccessContextMatch. "grpnam1"."fileX".3.authPriv = INTEGER: exact(1) SNMP-VIEW-BASED-ACM-MIB::vacmAccessReadViewName. "grpnam1"."".3.authNoPriv = STRING: all SNMP-VIEW-BASED-ACM-MIB::vacmAccessReadViewName. "grpnam1"."fileX".3.authPriv = STRING: all SNMP-VIEW-BASED-ACM-MIB::vacmAccessWriteViewName. "grpnam1"."".3.authNoPriv = STRING: vwnam1 SNMP-VIEW-BASED-ACM-MIB::vacmAccessWriteViewName. "grpnam1"."fileX".3.authPriv = STRING: none SNMP-VIEW-BASED-ACM-MIB::vacmAccessNotifyViewName. "grpnam1"."".3.authNoPriv = STRING: none SNMP-VIEW-BASED-ACM-MIB::vacmAccessNotifyViewName. "grpnam1"."fileX".3.authPriv = STRING: none SNMP-VIEW-BASED-ACM-MIB::vacmAccessStorageType. "grpnam1"."".3.authNoPriv = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmAccessStorageType. "grpnam1"."fileX".3.authPriv = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmAccessStatus. "grpnam1"."".3.authNoPriv = INTEGER: active(1) SNMP-VIEW-BASED-ACM-MIB::vacmAccessStatus. "grpnam1"."fileX".3.authPriv = INTEGER: active(1)

  If the group was created by directly editing the main /etc/sma/snmp/snmpd.conf configuration file, the group's storage type would be permanent.

• Alternatively, you can create an access table entry by using the snmpvacm command:

  # snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createAccess grpnam1 "fileX" 3 3 1 all none none

  Here, the user myuser has rwuser level access. Therefore, access entries are created in this example as this myuser user where appropriate for the context.

  # snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createAccess grpnam1 "" 3 2 1 all vwnam1 none

  If the group is created by use of the snmpvacm command, then the storage type would be nonvolatile. Objects created by use of either the snmpvacm or snmpusm commands have storage type of nonvolatile.

Example 4–5 Checking That Users Exist in the VACM Tables

Using the information in Example 4–3 and Example 4–4, check that the SNMPv3 user, user2, created in Example 4–2, exists. Validate the access entries already created for user2, by checking and setting values for the user. Use the snmpget and snmpset commands, once with encryption and once with no encryption. This method illustrates that the access entry for user2 is the minimum security level required, defined as auth= 2. The method also illustrates that priv can be used as well, since that level is more secure.

Use the snmpget command to check that the new user exists, with the DES option set for encryption. A context, -n fileX, is specified:

# snmpget -v3 -u user2 -a MD5 
-A my_password -l authPriv -x DES -X my_password
-n fileX localhost 1.3.6.1.4.1.42.2.2.4.4.6.1.1.0

This command validates one of the access entries that you set up for user2. The options that are associated with use of the snmpget command are described in the snmpcmd(1M) man page.

The snmpget command retrieves the following information:

SNMPv2-SMI::enterprises.42.2.2.4.4.6.1.1.0 = INTEGER: 111

In this returned output, 111 is an integer that is stored in the specified OID.

Similarly, snmpget command can be used to check that the new user exists, without the DES option set. If you do not set the DES option, no encryption is requested. This example shows that the user, user2, can execute an operation not in a context:

# snmpget -v3 -u user2 -a MD5 
-A my_password -l authNoPriv localhost 1.3.6.1.2.1.1.3.0

The snmpget command retrieves the following information about system uptime:

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (5375) 0:00:53.75

Try to set a new value for sysLocation:

# snmpset -v3 -u user2 -a MD5 
-A my_password -l authPriv -x DES -X my_password 
localhost 1.3.6.1.2.1.1.6.0 s "new val"

In this command, the s indicates “string”. The OID is sysLocation. The value being added to the sysLocation is new val.

Note that user2 has full access rights to the context (authPriv) for DES. The password is my_password. The following is returned:

SNMPv2-MIB::sysLocation.0 = STRING: new val

Confirm these settings with the snmpget command:

# snmpget -v3 -u user2 -a MD5 
-A my_password -l authPriv -x DES -X my_password localhost 1.3.6.1.2.1.1.6.0

SNMPv2-MIB::sysLocation.0 = STRING: new val

Try the same command without the DES encryption set:

# snmpset -v3 -u user2 -a MD5 
-A my_password -l authNoPriv localhost 1.3.6.1.2.1.1.6.0 s "new val2"

The same result is successfully returned:

SNMPv2-MIB::sysLocation.0 = STRING: new val2

# snmpget -v3 -u user2 -a MD5 
-A my_password -l authNoPriv localhost 1.3.6.1.2.1.1.6.0

SNMPv2-MIB::sysLocation.0 = STRING: new val2

This output shows that the user has write access to MIB-II.

If user2 has been defined in the snmptrapd.conf file, then start the SNMP trap daemon using the snmptrapd command:

# /usr/sfw/sbin/snmptrapd

Also, use the snmpinform command to send an INFORM-PDU trap. The snmpinform command validates that the user, user2 or user2, can generate notifications. Notifications can be generated if you perform a cold start. A cold start generates a notification, or a “trap.” The user can see this trap in the /var/log/snmpd.log file.

# /usr/sfw/sbin/snmpinform  -v3 -u user2 -a MD5
 -A my_password -l authNoPriv localhost 42 coldStart.0

For more information, see the snmptrapd.conf(4) and snmpinform(1M) man pages.